You can call it multiple times with great efficiency, it's designed that way, everything is stored in static values after the first run through, and each subsequent request takes almost no time, I've microtimed it several times while working on some optimization features.

However, you should use the full associative since it only takes one request then, that's what I would do.

The issue of math is just part of reality, made the feature a bit harder to do than it would be if I pretended that issue doesn't exist.

2.9 > 2.8 works in our system, but 2.9 > 2.8 gives error or should do so on a euro server, don't know about asian languages and others.

However, php has built in functions that tell you the locale of the php on the server running it, so one just has to carefully convert everything before comparing it.

No huge deal, just something you have to be very careful with.

mobile data probably could use a tablet return, but the capability of tablets really is just dependent on the browser in it, except for screen res.
Back to top

Ah OK now i understand. Though i didn't realise the rest of the world didn't do math in the same way. Looking on the internet i see other countries using a comma. Not quite sure what to suggest here. Wonder if you can get their locale formatting info then convert the browser strings to match?

My idea with tablets was to have it treat them as html5 / html rather than treating them as mobile which is what was being returned before. With this change i have HTML5 or HTML being returned depending on the browser.

I added the full_assoc to my script


Back to top

New browser detection version 5.4.0 features two new return values.

See release notes for details.

Return values are: html_type, which returns an integer based on html level, 1 for regular, 2 for basic html 5, 3 for html 5 forms.

More levels will be added over time depending on the progress of the browser world and HTML.

To make this work, I also had to add a new return value, engine_data, which is an array that returns if available the layout engine name, version string, and version math number.

As always, note that while floatval will maintain math functionality inside the functions of the script, once it is returned in an array, it becomes a string, so if you are in a locale that does not use . decimal separators, for example Germany with , then you need to handle that explicitly externally in your programming.

UK/USA users don't have to worry about these things.

This change turned out to be pretty big internally, but I think I preserved all the previous return values and methods as usual, just added more options.
Back to top

Wow thanks... that was quick. Just downloaded the new version and I'll have a play today.

Thanks again much appreciated.
Back to top

This is my script now


Back to top

thanks for spending the time / energy on this problem, was worth adding it to the script since layout engines have become a detectable standard in the 4 biggest engines.
Back to top

No problem. Now it's time to use this script. I will be working on some new projects after xmas and will be able to put it to good use. I will let you know if anything pops up when i come to testing. Its been a good experience for me because i have learned a lot about layout engines, browsers and the likes. I hope other people will find this new feature useful. I'll be sure to check the forums for future releases and discussions on the subject.

Thanks for everything.
Back to top