I don't get it. It seems like you're saying, "if it supports the -moz prefix, it's FireFox, therefore I know that it doesn't support X and needs -mox-X."
But that requires you to separately know that the browser doesn't support X - the very thing this is trying to solve.
It's much simpler to say "if it supports X, use it." If the browser releases a new version that supports X, you don't have to do anything for those users to get the benefit.
The progressive enhancement approach you describe does not address cases where an alternative should be provided for less capable browsers.
The closest analog in existing tools might be YepNope - "a conditional loader for your polyfills." http://yepnopejs.com/
There's an argument to be made that this is unnecessarily reducing maintainability and increasing development complexity by building redundant functionality to account for edge cases, but there are scenarios where it's appropriate. Building modern web apps with a support gradient more inclusive than latest Webkit/Gecko will appreciate the tools.
I've seen what I think is the same bug on Webkit/Linux, and I traced it to the text-rendering CSS property. If you can replicate the glitch, try unsetting text-rendering.
It's unlikely anyone else will fix it, either. Linux Chrome doesn't get much love. (Alternatively, it gets a proportionate amount of love to the size of its userbase.)
I'm really sorry I never fixed it. I sometimes use Firefox on sites like this if the rendering really matters. You can also use a user stylesheet to unset it for all sites.
It would be amusingly relevant to the subject of the actual post if that feature was implemented in Chrome so you could conditionally turn this off just for the browser where it's broken. :)
I meant to test of HTML5/CSS features are supported through JavaScript. For example, if I want to know if the browser supports <input type="number" /> it's not as easy as it should be.
I realize nobody likes adding extra JS libraries, but if your only trying to access these properties from JS to begin with it doesn't seem like that big a deal.
It does, but since browsers have no defined API for this Modernizr deals with quite a few false positives. Putting the onus on browsers to accurately describe what features are present is good.
Plus it's always a good thing to kill off javascript libraries; we don't want to always keep sending JS down the wire when the platform should have this stuff by default.
Me too! When @supports was proposed I made sure to propose a JS API for the same functionality. David Baron liked the idea and it's now (mostly) in the spec: http://dev.w3.org/csswg/css3-conditional/#window-api
Also on browser support: Opera already has an implementation in progress of @supports; we haven't seen patches yet from WebKit but there is definitely interest.
Is there a discussion somewhere that clearly articulates the merits of the increasing complexity of CSS? I realize there's some maturation taking place, but there seems to be a giddy, almost drunken, exuberance for expanding a language beyond logical context. (e.g., Frodo carrying a BFG?) At what point does a new container become reasonable? Something such as "SOS" (Style Objects Sheet)?
I'm not confident if that made sense, but basically I'm concerned that we're (re)creating a personally oft-encountered tension where the individuals that best understand a complex syntax are the least able to create anything aesthetically-pleasing, let alone usable, from it...
I'm concerned about what level feature detections occurs.
For example, it makes sense to have a native @support CSS rule checking for things like border-box support.
But what about detecting features that are separate from rendering? Should @support check for geolocation?
If not, where does that test live - javascript (modernizr, yepnope)? Is separating tests based on type of feature a good thing? If so, how should the interactions between display and feature be intelligently managed? If not, is CSS, Javascript, or some other layer the appropriate place to consolidate tests?
Testing for non-rendering concerns in CSS doesn't make any sense to me, and I'm afraid our future will be HTML markup full of classes namespaced by concern, managed by javascript & feature detection. It's an evolution, but hardly elegant. (class="js-toggle function-geolocation structure-list typography-chrome")
29 comments
[ 46.9 ms ] story [ 3053 ms ] threadEnd of nightmare.
I don't get it. It seems like you're saying, "if it supports the -moz prefix, it's FireFox, therefore I know that it doesn't support X and needs -mox-X."
But that requires you to separately know that the browser doesn't support X - the very thing this is trying to solve.
It's much simpler to say "if it supports X, use it." If the browser releases a new version that supports X, you don't have to do anything for those users to get the benefit.
Did I misunderstand you?
The closest analog in existing tools might be YepNope - "a conditional loader for your polyfills." http://yepnopejs.com/
There's an argument to be made that this is unnecessarily reducing maintainability and increasing development complexity by building redundant functionality to account for edge cases, but there are scenarios where it's appropriate. Building modern web apps with a support gradient more inclusive than latest Webkit/Gecko will appreciate the tools.
http://i.imgur.com/pEzve.png
http://code.google.com/p/chromium/issues/detail?id=55458
It's unlikely anyone else will fix it, either. Linux Chrome doesn't get much love. (Alternatively, it gets a proportionate amount of love to the size of its userbase.)
I'm really sorry I never fixed it. I sometimes use Firefox on sites like this if the rendering really matters. You can also use a user stylesheet to unset it for all sites.
I realize nobody likes adding extra JS libraries, but if your only trying to access these properties from JS to begin with it doesn't seem like that big a deal.
Plus it's always a good thing to kill off javascript libraries; we don't want to always keep sending JS down the wire when the platform should have this stuff by default.
Right after @supports landed I got a bug filed for supportsCSS() https://bugzilla.mozilla.org/show_bug.cgi?id=779917 and a few days later an initial patch landed. So I think we're all set here.
Also on browser support: Opera already has an implementation in progress of @supports; we haven't seen patches yet from WebKit but there is definitely interest.
I'm not confident if that made sense, but basically I'm concerned that we're (re)creating a personally oft-encountered tension where the individuals that best understand a complex syntax are the least able to create anything aesthetically-pleasing, let alone usable, from it...
For example, it makes sense to have a native @support CSS rule checking for things like border-box support.
But what about detecting features that are separate from rendering? Should @support check for geolocation?
If not, where does that test live - javascript (modernizr, yepnope)? Is separating tests based on type of feature a good thing? If so, how should the interactions between display and feature be intelligently managed? If not, is CSS, Javascript, or some other layer the appropriate place to consolidate tests?
Testing for non-rendering concerns in CSS doesn't make any sense to me, and I'm afraid our future will be HTML markup full of classes namespaced by concern, managed by javascript & feature detection. It's an evolution, but hardly elegant. (class="js-toggle function-geolocation structure-list typography-chrome")
>>The ‘@supports’ rule is a conditional group rule whose condition tests whether the user agent supports CSS property:value pairs.
Source - http://dev.w3.org/csswg/css3-conditional/#at-supports
So, no. @supports will check for css rules, and nothing else.
That would just be silly.
My point is only that the alternatives aren't all that less silly, at least from an actually-building-and-maintaining perspective.