I think i will write a script to loop through the UA strings on the XML file and test each one individually. It will be important to see what all the UA strings return in my case.

Thanks i have added the extra array_key_exists condition in to my test. Think i am ready to start testing those strings now.
Back to top

I wrote my test script for the UA strings in the switcher list. All the webkit data seems to be OK. Having problems with the browser numbers for firefox, opera and IE. Often the browser number is unexpected comparing it to the UA string. The mobile test seem ok though. All the browsers UA strings on my MAC return correctly. Just seems to be a lot of errors from the user switcher list. Or am i misunderstanding the switcher list.



Hope you can advise?
Back to top

$xml = simplexml_load_file("http://techpatterns.com/downloads/firefox/useragentswitcher.xml");

I'd change that to use a local file first of all, that ua list doesn't change much.

Second, the ua switcher list, you should take a closer look at it.

It has more than 1 level of folders, it varies.

I don't remember the logics of how to do that type of directory tree parsing, but the basic idea is to search for containers, then if not container, do....

The useragent strings are all real useragent strings, so if there is a bug in the user agent detection script, that would be good to fix.

However, I was working on a start of adding html5, 6 etc support to the script, and one thing I noticed was that you are usingi the firefox version number, that's not a good idea, you should be using the rv version number, which in most cases is the actual rendering engine of the browser. In other words, as with using webkit version, you are checking the actual engine, not the branded name version, which is largely irrelevant.

This won't work on all browsers by the way, the msie derived ones like maxthon and others often do not use the real msie string, which is stupid on their parts, but that's a small part of the market anyway.

A second note is that when msie users have their browsers set to be in say, msie 7 mode for msie 8, it will render as msie 7. So you probably do not want to use real msie number there, but rather the msie number that msie returns, since I believe that is what it will rendered as.

To see what is going on, add echoes to the data as it is generated, ie, the useragent, what the browser detection script claims it is, and what it actually is, that is.

I'm not aware of any glaring logic errors that will yield a false result, but sometimes the user agent strings change for no real reason and that change might mess something up.

Of course, first verify that a suspect UA is actually being handled wrong by the browser detector, you can do that by going to this page and verify that the string is wrongly handled. My guess is it isn't, but if it is, give me the user agent id / definition from the xml file and I'll double check that. The computer info box is run by the current browser detection script, so what it shows is what the data is. That's using firefox, the useagent switcher, and the imported useragent switcher list, that is.
Back to top

Hi,

I don't think there is anything wrong with the browser detection script. but rather my understanding of the UA strings and understanding of exactly how to use the script. I plugged my testing script in to this list of MSIE UA strings www.useragentstring.com/pages/Internet%20Explorer/ and all the MSIE strings gave me the results i expected. I did change this line of code.



I'm still unsure about the MSIE strings on the userswitcher list you gave me and still a bit unclear how i test for users having their IE mode different to their browser number say IE8 rendering on IE7 mode. Would that mean using the browser_number rather than true_ie_number afterall? If i can get these things cleared up i will be happy with MSIE.

Looking at firefox i did notice that the browser number being returned in most cases if not all cases was the rv number. So if i am using the rv numbers to test for html5 then i need to test for the first rv number of version 4. But i noticed some firefox 4 rv are 1.9 and some firefox 3 rv are also 1.9

e.g
Firefox 4
Mozilla/5.0 (Windows NT 6.1; rv:1.9) Gecko/20100101 Firefox/4.0

and

Firefox3
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100915 Gentoo Firefox/3.6.9

However most firefox 4 are rv >=2 so i could just change to testing for rv >= 2.0?

If that is correct i think firefox will be sorted.

Chrome seems ok, once i have got MSIE and firefox cleared up i will begin work on opera and safari.

I promise to download the userswitch xml to a local file before i use it for my tests again and will begin to look at the folder levels.

That's great news that you have begun to look at HTML5, 6 support, that's music to my ears and look forward to that. For the time being i will continue getting my script working with the test data provided.

Thanks for all your help
Back to top

using rv 2 for html 5 I think is a solid test, I checked, and 1.9 covers 3.0 to 3.6.

Also, it's important to remember that not all of html 5 is supported by the various browsers, I looked that up, and it's quite varable, so this test is NOT the same as meaning that any html 5 method will work, it won't.

Also, I noted that I'd noted in the comments of browser detection that some browsers that used the gecko engine used their own rv number, there's nothing you can do about that really, and almost nobody uses those, galeon for example,. but I think that switched to webkit anyway, not sure.

msie 9 has the worst support, but it does have some.

The way I'm going to do this is have return values for a new parameter, 1 is for regular html, that's default, all useragents will return this if they don't trigger the positive case. html5 will return 2, and the next major html, if present, will trigger 3, and so on. That way, you can simply do a basic arithmetic >, < type test on the return value to determine what to offer it.

Maybe I'll just launch that feature now and you can suggest fine tunings if you're so inclined.
Back to top

Check quirksmode.org HTML5 compatibility. quirksmode has been around a long time, and are a good resource.

opera support

As you can see, there's not really such a thing as a point where html5 support is on or off, and, like css support, it's a matter of each version fixing or adding support to one part of the specification.

Here's some html5 / css3 support tables, and here's an even better html5/css3 readiness gui tool, and here's another support table. That last table for example shows that msie 9 has no html5 forms support at all. And here's wikipedia Comparison of layout engine

Based on that, could be a thought to make opera 11 the best supported version, not 10, hard to say, it's a question not of full support, but a fair amount of support. Looks like webkit has the most complete support, chrome 9 is probably the cutoff, but it's of course depending on if a specific feature is in place in the browser or not.

msie 9 is a safe start, not complete, but ok. And firefox 4 is a safe point too I think, ie, rv 2.x.

webkit looks like it should be version 500 or greater, not 400.

I'm wondering if it might not be a good idea to make the support numbers a bit more fine grained, but that's a lot of upkeep, ie, if the thing supports basic html5 but not html 5 forms, assign 2, else assign 3. Since html5 forums are actually kind of a big deal, not supporting those is not supporting a key part of html5.

I'll think about this for a while.

Looks like html5 support is so varied that the return value should show more of what the browser can do, so I'll consider that. The wikepedia page is easy to read, and there are only 4 main rendering engines considered, so it's easy to track.

Looking at this, in fact, it looks like the browser detection should always return the rendering engine number, like it does for moz and webkit.

<update>I took a closer look at the html support tables in wikipedia, and I think I will add specific returns: 1 for regular html, 2 for regular html5, no forms, 3 for html5, forms.

That lets me do more fine grained, since only webkit 528 for instance supports html 5 forms, but 525 supports most html5. That will work fine, as long as there is one main source I can use to track the support of the features, and this wikipedia page is good.
Back to top

Wow that's excellent news. You have been busy :D thanks.

Yes since HTML5 is still very much a draft i guess browsers are just implementing new parts as they go along. I have book marked some of those HTML5 readiness tables and will use them as a reference for the future.

I guess the proper way to do this would be return some sort of a list of exactly what is supported by a browser, which would be a lot more work and probably a nightmare to maintain over time. At least until all browsers support all features, if ever.

I did find when i was developing some test sites in HTML5 /CSS3 all the new browsers i tested on were supporting enough of the stuff to render something that looked and worked ok. But some of the old browsers were not. Also some of the new elements such as <header>, <nav>, <footer> I can use a js function to test those elements and if they are not supported add them with the



Its more the css3 like box-shadow, rounded corners, opacity and animations, plus canvas support i was interested in.

Having the support for the forms could be useful. I did find that if a browser didn't support a certain feature then it would just replace the form with a textbox if it didn't recognise it. But would be useful to know so i can add some sort of alternative validation for browsers that don't support those attributes etc.

For these reasons just returning a number for HTML5 / CSS3 support was all i was looking for the extra numbers for HTML5 forms will be a great addition also.

I have changed my numbers for the checks on my scripts and very much look forward to seeing what you have come up with. When you have added this feature let me know and i'll have a closer look and help you test it if you like.

Thanks for all you are doing.
Back to top

I'm hitting a snag with the math, because I've dealt with globally distributed programming I've learned the issues / problems with ignoring locales.

Locales are what set the decimal place for math, and since I need math for the engine versions vs numbers of supported browsers, I have to take the ./, or whatever else separators into account.

Sadly, floatval does NOT respect declared locales, even when you use setlocale(), so I have to find a bullet proof way of doing that. Has to be tested on a system that is running non us/brit style decimal separators.

not as easy as I'd hoped initially, the integer test is not adequate sadly.

What I'll be testing is the primary engine version, trident, presto, gecko, and webkit, not the browser number. This will also result in a new return parameter, engine data array, since I will need that anyway.

trident/ie and webkit can be tested as integers, but presto and gecko require decimal to one place.

The drag with doing a script that runs globally across locales is that you can't just make it run on your system, it has to run on all systems..

The main resource I'd use for support information is the wikipedia page, it's correctly done, that is, the tables list the first version of each engine to support the feature. Most of the others are very poorly done, and only list by browser number, and then only to show if a certain browser number has that support or not. I wouldn't have added the feature if I hadn't found that wikipedia was done intelligently, with clear showing of engine numbers that introduce the support.

The use of rendering engines sort of crept up on me with the browser detector, only webkit and gecko used them initially, then opera added that with their 10 release, and msie with their 8 release, so the browser detector didn't have an integrated method of dealing with that information category, so rather than add more hacks, I'm going to remove all the rendering engine hacks I'd added for webkit/gecko and make one unified rendering engine return value.

No existing api or parameters will break, but new ones will be added and old ones will be deprecated I think, I'll see. As always, no new browser_detector will ever break existing programming, I will just translate the legacy stuff to current methods as I always do, handling those changes internally to keep it clean.

So this change isn't as easy as I hoped, but it is timely, it now appears that the major browser makers are going to stay with showing their rendering engine names/numbers, which was not at all clear a few years ago.
Back to top

So if you change in the way the script handles the math, will this effect the way the website that uses the script handles decimal maths? Not really sure what you are attempting to do with the maths. Would need more information to understand the problem with regarding locales.

I have been studying the comparison of layout engines on wikipedia closely and the information looks good. I think its good that it lists all the HTML elements and attributes to be supported. It does seem to be missing the CSS3 though maybe there is a similar page for the CSS stuff? I will have a search. Looks like wikipedia have a similar page for css: en.wikipedia.org/wiki/Comparison_of_layout_engines_%28CSS%29 Its good that these pages show the information with regards to the layout engines rather than the browsers as the layout engine is the rendering engine used for these features across the browsers. I'm guessing the only engines we need to consider are trident, webkit, Presto and Gecko or would we need to consider the KHTML engine.

I have compiled a list of 1000's of possible UA strings for different versions of Firefox, Internet Explorer, Chrome, Safari, Opera and some mobile strings. I have organised these in to text files with each string separated by a line break or carriage return (depending on my mac). That should be easier for testing purposes then i can just use file() to read them to an array.

I don't have any worries with how long it would take and if you feel it will require too much work i would understand if you didn't want to continue. If so I could continue to work with and test what i have with the integer comparisons. But would be great if i could do this the correct way rather than having something that is not correct. I hope that other users would benefit from this also.
Back to top

I added some tablet support to my script using mobile_data[8]. Here's my code so far



Since i am using multiple calls to the browser_detection function i might just do one call with 'full_assoc' as the first parameter to see if that's more efficient.
Back to top