6 ms·

Firefox supports supports, gets my support

64 points by cleverjake 14y ago

squarecat 14y ago
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...
- MatthewPhillips 14y ago
  Many people have that concern. What we don't want is to take away CSS maintenance from non-developer designers.
- harlanlewis 14y ago
  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 14y ago
    >>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 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 14y ago
      Agreed :). My point is only that the alternatives aren't all that less silly, at least from an actually-building-and-maintaining perspective.
Kilimanjaro 14y ago
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 14y ago
  >> 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 14y ago
    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/ 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 14y ago
Just me, or an issue with the styling? http://i.imgur.com/pEzve.png http://i.imgur.com/pEzve.png
- stopsatgreen 14y ago
  I'm the site owner; never seen that before. Which browser/OS are you on?
  - TazeTSchnitzel 14y ago
    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 14y ago
      If I reload the page, it always fixes itself for me.
  - staticshock 14y ago
    I'm seeing the same thing, running chromium 18 on ubuntu.
    - stopsatgreen 14y ago
      Oh that's weird, as I run Ubuntu myself. Will download Chromium and have a look, see if I can replicate it.
      - skymt 14y ago
        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.
        evmar 14y ago
MatthewPhillips 14y ago
Good step in the right direction. Now we need the same thing for JavaScript.
- notatoad 14y ago
  JavaScript already has this, no? Just check to see if a function is typeof undefined.
  - MatthewPhillips 14y ago
    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 14y ago
      Fair enough. Though that's exactly what http://modernizr.com/ 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 14y ago
        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.
        deleted 14y ago
        [deleted]
    - paulirish 14y ago
      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 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 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.
zacharyvoase 14y ago
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 14y ago
  Now yes. But what about in 5 years time? You'll be able to use @supports to find out what a browser supports
- TazeTSchnitzel 14y ago
  It's so simple and elegant I'm surprised we haven't added it before. Oh well.

64 points by cleverjake 14y ago

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

MatthewPhillips 14y ago
Many people have that concern. What we don't want is to take away CSS maintenance from non-developer designers.
harlanlewis 14y ago
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 14y ago
  >>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 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 14y ago
    Agreed :). My point is only that the alternatives aren't all that less silly, at least from an actually-building-and-maintaining perspective.

Kilimanjaro 14y ago

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 14y ago
>> 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 14y ago
  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/ 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 14y ago

Just me, or an issue with the styling? http://i.imgur.com/pEzve.png http://i.imgur.com/pEzve.png

stopsatgreen 14y ago
I'm the site owner; never seen that before. Which browser/OS are you on?
- TazeTSchnitzel 14y ago
  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 14y ago
    If I reload the page, it always fixes itself for me.
- staticshock 14y ago
  I'm seeing the same thing, running chromium 18 on ubuntu.
  - stopsatgreen 14y ago
    Oh that's weird, as I run Ubuntu myself. Will download Chromium and have a look, see if I can replicate it.
    - skymt 14y ago
      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.
      - evmar 14y ago

MatthewPhillips 14y ago

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

notatoad 14y ago
JavaScript already has this, no? Just check to see if a function is typeof undefined.
- MatthewPhillips 14y ago
  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 14y ago
    Fair enough. Though that's exactly what http://modernizr.com/ 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 14y ago
      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.
      - deleted 14y ago
        [deleted]
  - paulirish 14y ago
    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 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 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.

zacharyvoase 14y ago

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 14y ago
Now yes. But what about in 5 years time? You'll be able to use @supports to find out what a browser supports
TazeTSchnitzel 14y ago
It's so simple and elegant I'm surprised we haven't added it before. Oh well.