
Firefox supports supports, gets my support - cleverjake
http://www.broken-links.com/2012/08/06/firefox-supports-supports-gets-my-support/
======
squarecat
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...

~~~
harlanlewis
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")

~~~
cleverjake
>>But what about detecting features that are separate from rendering? Should
@support check for geolocation?

>>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.

~~~
harlanlewis
Agreed :).

My point is only that the alternatives aren't all that less silly, at least
from an actually-building-and-maintaining perspective.

------
zacharyvoase
Is it not ironic, though, that we’re at a point that any browser which
supports @supports would also support any property you’d test for support for?

~~~
rmc
Now yes. But what about in 5 years time? You'll be able to use @supports to
find out what a browser supports

------
MatthewPhillips
Good step in the right direction. Now we need the same thing for JavaScript.

~~~
notatoad
JavaScript already has this, no? Just check to see if a function is typeof
undefined.

~~~
MatthewPhillips
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.

~~~
eli
Fair enough. Though that's exactly what <http://modernizr.com/> provides, no?

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.

~~~
paulirish
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.

------
Kilimanjaro
I rather see this:

    
    
        @supports (vendor-prefix) 
    

then apply vendor prefixes to all css rules not understood by the browser.

End of nightmare.

~~~
nathan_long
>> to all css rules not understood by the browser

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?

~~~
harlanlewis
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.

------
FlukeATX
Just me, or an issue with the styling?

<http://i.imgur.com/pEzve.png>

~~~
stopsatgreen
I'm the site owner; never seen that before. Which browser/OS are you on?

~~~
TazeTSchnitzel
I'm not him/her, but I've experienced this on Linux sometimes. It's not
something you can fix as the site owner, I think.

~~~
ReidZB
If I reload the page, it always fixes itself for me.

