I want to use the browser detection script to do privide different content for different user agents. Following these rules

- Does the browser support HTML5 / CSS3
- Is it an older browser
- Is it a mobile device.

For each of these rules serve up different content.

here's the code i came up with.



Can anyone advise if this is the right way to detect the user agent is HTML5 /CSS3 compliant. Is there a better way. are the numbers of the browser version correct? Any other browsers i need to consider? Any help would be greatly appreciated.
Back to top

if you're doing math comparisons, you have to make sure to strip out all the non math numbers in the version numbers, ideally use something like intval($browser_nu) to pull out only the starting integer.

I'd just make the firefox test for >= 4 and not worry about 3.6, easier math, or do: engine = gecko && (browser >= 4 or strstr($browser_nu,'3.6.') )

note the last dot in the 3.6. that helps avoid fake detections of say, 2.3.6

that's pseudo code.

browser numbers can be: 2 dot, not a decimal, like 3.6.4, they can have b+23 type syntax for testing, or alpha, or other non numeric strings, so the best thing is to just test the primary integer value.

but the overall idea is good, in fact, it might be time to add in a primary data return type of html5, which now appears to really be for real and here to stay.

However, keep in mind, you want to know both if it's mobile AND if it supports html5 for general use, although your specific case will of course vary depending on the site needs.
Back to top

Thanks for the advice. I did wonder about the double dots but did a test and noticed


the float comparison was truncating the second dot and the numbers after. Isn't it everything before the last set of dots what i need? then i could continue to do float comparisons? Maybe a regex would be easier say


then do a float comparison of this. Im not sure though because i don't know exaclty what the browser_num can be? You probably know far more about user agents than me. Maybe its better to just get the first number before any dots


or



And do a integer comparisons?

I will change firefox to 4.

Glad you think it is a good idea and would love to see the script include an html5 test of some sort. I will continue with what i am doing using your excellent script though. It's a good learning process for me.
Back to top

following your advice here's what i came up with.


Back to top

}
elseif($html5_compat[$browser] < $browser_int)

should be:

}
elseif($html5_compat[$browser] <= $browser_int)

I believe to avoid 4 < 4, or 10 < 10.

preg_match is less efficient than plain intval, php recommends avoiding regex unless you have to use it, the builtins like strstr or intval are more efficient.

Keep in mind that you need the true msie and the true opera numbers.

intval is also useful because it returns 0 if it's false, not null, so the following math will not kick out an error if the browser number is not numeric.
Back to top

Ah ok i didn't know that

So if i want to get the true Ie version i would use



I couldnt see how to get the true opera version though? Is my browser detection script out of date it's version 5.3.18

I didn't realise that regex was less efficient. I don't see how i can use strstr without testing every possible value individually like



Maybe it's enough to just use the intval function (which is new to me thanks)



Are you saying use one or the other? Thanks for spotting the <= bug.
This is my code



Is that an better?
Back to top

I wasn't suggesting using strstr, just noting that php recommends using builtin functions like strstr or intval over using regex if you can. Since intval will or should be error free, that's what I'd use in your case. Sorry if that wasn't clear. You definitely do NOT want to use strstr in this case since t will not return a number on error, nor is it fitting to the task.

the browser detection script has always returned the true opera number, which wasn't disguised like the msie true numbers in the useragent string, just noting that to make sure, that might change depending on what opera does with their useragents in the future.

For testing purposes you can also feed the browser detection script alternate UA strings for debugging / dev tasks, that was a feature added a while ago by user request.

Also of course use firefox useragent switcher list for dev and testing purposes, which I make in conjunction with the php browser detection script, for testing new features or more complex detections, like the msie true/claimed numbers for example, or the opera 9.8 vs 10 or 11 numbers. That useragent list is fairly complete and has reasonable utility, though I am not trying to keep up with the somewhat absurd version number inflation that chrome and sadly, now firefox, are engaging in. In other words, I update the list a few times a year at most.
Back to top

Well thanks kindly for all the work you are doing with the browser detection script. I think it will work great for what i intend to do for the time being. Thanks for all the help in this forum thread also. I will test it as i use it and if i find any new bugs or problems detecting new UA strings i will be sure to let you know. I guess i might have to make some tweaks myself if i find something that's not working. I can only test on new versions of chrome, firefox, opera, safari, ie, and andriod browsers and older versions of ie from ie6 upwards.
Back to top

Been looking at the user agent switcher list that should be useful for testing. Is there anyway i can feed these UA strings in to the script to test those strings. How can I feed the browser detection script alternate UA strings? I'm guessing feed it in as the third parameter


Back to top

that's correct, 3rd parameter feeds it the ua string. I've never used that feature, as noted, it was added as a user request with a crude patch, not unlike what you're doing here in fact. Putting up code, testing, revising, etc, as you're doing here, is probably one of the best ways to get a patch in quickly, it motivates me much more than just asking for x or y, since it shows clear and real interest on someone's part for the feature in question.

You could loop that third arg with an array of ua strings, for example, which you can grab from the ua switcher list, or you can write php to read the ua list xml file directly, a lot of work though, usually all you need is a handful of tests to cover most all cases.

I think there's enough in there though to let you test what you need to test in terms of mobiles, non mobiles, false positives and so on.

Everything is documented in the script head section, failure to be clear, or if something is ambiguous in that top head doc secction, is a bug, and will be corrected if it's pointed out, especially if it's explained why it was unclear and how to make it more clear.



be careful with that one by the way, you have to make sure it's one of those browsers before doing a numeric math comparison >=

do:



always make sure the tests are protected from bad data or unexpected circumstances with any web scripting.
Back to top