Re: Feature queries

Hallo,
> Pascal Germroth <pascal@germroth.name> wrote:
>> If media-query like operators were allowed, we need no @else:
>>   @if supports( display: run-in; ) { ... }
>>   @if supports( not(display: run-in); ) {...}
> 
> Then you have to write the expression twice, yuck.  And @elif becomes
> awkwardly verbose.

But it would be easier to parse... (and it seems, the WG likes
ease-of-parse more than ease-of-use, else we would have variables and
macros by now...)

Considering user style sheets, some way of querying values would be
great too, for example if an Opera user forces light text on dark
background, but the default style for the site is dark text on light
background, the stylesheet could query the user's override and alter
itself accordingly (instead of providing multiple alternative stylesheet
links). Like:
  @if darker( body { background-color }, #ccc ) {...}
But this might add a lot of unnecessary complexity and might be better
solved using scripting...


> The generic grammar probably can't handle
> 
> div {
>   /* common */
>   @if supports (...) {
>      /* cool stuff */
>   } @else {
>      /* fallback */
>   }
> }

That would be great. But haven't all questions for nested selectors been
shot down?

[OT:]
It would enable a whole lot of interesting uses, for example:
  #foo > div { @import url(...); }
could apply the imported stylesheet only to div child-elements of #foo
(:root in the external stylesheet would mean "#foo > div" in the global
context, sel would become "#foo > div sel" etc). Partly user-editable
sites could then give users full control over the styles for their part,
since they can't alter the surrounding page.
Instead of
  #nav li a:hover, #nav li a:active {...}; #nav li span {...}
one could write
  #nav li { a:hover, a:active {...}; span {...} }
Pure bliss.
(Also, it's really beyond me, how CSS is used for selecting and styling
element trees, but does not allow tree structure itself)

Or has this already passed?

Received on Wednesday, 9 December 2009 22:00:31 UTC