Hacker News Reader

Comment by squarecat | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com