4 ms·

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 the

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.

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.