Firefox supports supports, gets my support | Hacker News Reader

Firefox supports supports, gets my support

broken-links.com

64 pointscleverjake28 comments

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

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

Agreed :).

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

Many people have that concern. What we don't want is to take away CSS maintenance from non-developer designers.

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?

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

It's so simple and elegant I'm surprised we haven't added it before. Oh well.

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

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

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.

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

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.

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.

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.

I rather see this:

    @supports (vendor-prefix)

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

End of nightmare.

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

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.

Just me, or an issue with the styling?

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

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

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.

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

I'm seeing the same thing, running chromium 18 on ubuntu.

Oh that's weird, as I run Ubuntu myself. Will download Chromium and have a look, see if I can replicate it.

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.

I am the author of some of the related code in Chrome. It's a Linux Chrome bug caused by text-rendering:optimizeLegibility.

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.

Ah, interesting. I've removed that declaration from my stylesheet now, so hopefully that will fix the problem.

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

Linux Mint 11 with Chrome 18.0.1025.162.

Reply on news.ycombinator.com