Per https://bugzilla.wikimedia.org/show_bug.cgi?id=32183 ...
In r101860 I've removed most of the client-* classes from the <html> that were added based on user-agent sniffing. Sniffing UA strings is a fragile practice which should be strongly discouraged in favor of checking for the actual features or bugs that you need to address -- encouraging people to use styles like "client-firefox7" makes me feel a little ill inside. :)
The client-js / client-nojs classes remain; they are in fact a good example of use of feature detection (whether JS is enabled or not) which allows targeting display of UI elements specifically at that condition.
No extensions in SVN or core code appears to be using any of the other client-* classes; there could be some in user JS/CSS code -- if you've been using them or seen someone use them, you should see about fixing them up to make sure they don't break in unexpected browsers or on MediaWiki 1.19.
-- brion
On Thu, Nov 3, 2011 at 12:23 PM, Brion Vibber brion@wikimedia.org wrote:
In r101860 I've removed most of the client-* classes from the <html> that were added based on user-agent sniffing. Sniffing UA strings is a fragile practice which should be strongly discouraged in favor of checking for the actual features or bugs that you need to address -- encouraging people to use styles like "client-firefox7" makes me feel a little ill inside. :)
On a related note I took a quick peek over some of the other uses of jquery.client.js, through $.client.profile() direct checks or $.client.test() with a compatibility map.
I'm proposing swapping the direction of the compatibility maps to make them a little easier to read and maintain: < https://bugzilla.wikimedia.org/show_bug.cgi?id=32188%3E
At some point in the development of these code bits I remember we established that unknown browsers should be considered as compatible unless discovered to be otherwise, which changed the test() behavior from a strict whitelist to, effectively, a blacklist.
But, the comparisons in the maps are oriented at a whitelist, which makes it kinda look like you should add more browsers to it or think that unlisted browsers will get disabled.
I propose changing the name to eg $.client.isBlacklisted() and swapping the order on the operators, so it's clear that we're eg "blacklisting IE older than 7" rather than "whitelisting IE 7 and up".
This should make the maps easier to read and maintain, and will encourage dropping unnecessary entries (no need to blacklist old versions that don't work with jQuery, if we've already aborted the script loaders due to lack of jQuery compat.)
Seems wise? Horrible? :)
Of course we'll want to keep the old .test() for compatibility.
-- brion
On Thu, Nov 3, 2011 at 8:42 PM, Brion Vibber brion@wikimedia.org wrote:
On Thu, Nov 3, 2011 at 12:23 PM, Brion Vibber brion@wikimedia.org wrote:
In r101860 I've removed most of the client-* classes from the <html> that were added based on user-agent sniffing. Sniffing UA strings is a fragile practice which should be strongly discouraged in favor of checking for
the
actual features or bugs that you need to address -- encouraging people to use styles like "client-firefox7" makes me feel a little ill inside. :)
Sounds good.
On a related note I took a quick peek over some of the other uses of jquery.client.js, through $.client.profile() direct checks or $.client.test() with a compatibility map.
I'm proposing swapping the direction of the compatibility maps to make them a little easier to read and maintain: < https://bugzilla.wikimedia.org/show_bug.cgi?id=32188%3E
That has been confusing be from the beginning. I stumbled across it when looking for code to cover in unit tests. Decided to skip that function for the time being. This will ease it up.
-- Krinkle
wikitech-l@lists.wikimedia.org