Re: Conditional CSS sections based on property support

Mikko Rantalainen wrote:
> Laurens Holst wrote:
>> Problem with this is that if you want to use e.g. browser-specific CSS 
>> to solve certain issues, it needs to be excluded from the group somehow. 
> 
> The key words here are "browser-specific" and "certain issues". I think 
> the real problem you're trying to solve is forward compatible 
> workarounds. As it's workaround, I don't think the rest of the styling 
> should be affected by it.

It was just an example, hence the e.g.. There are other examples which 
have nothing to do with ‘browser specific’ (but a lot with forward 
compatible of course).


>> Because such a single rule would make the block not be applied on all 
>> other browsers as they do not support it, yet it would need to be part 
>> of the group because it depends on the condition.
> 
> That's a good point. Previously I'd have suggested to just use that 
> special property outside the @require-all-properties section but it 
> might not make any sense without the other rules.
[...]

Actually, a problem I can see with all this grouping is: it requires the 
style to receive a strong structure for it to be really meaningful and 
more than just browser hacks.

I think that in practice the addition, placement and usage of these 
required blocks will still be dictated by browser tests. As I said 
earlier, it will be dependant on one or a few singled out properties, 
and portions of CSS which are basic enough to work in all browsers will 
not be enclosed in requirement grouping boxes for browsers with more 
minimal CSS support compared to the current web browsers.

For this to truly work, I think there needs to be a methodology that 
dictates users to group all styles for e.g. the link styling or the 
navigation area together. Authors need to think in a different paradigm. 
Think of this like graphics software where belonging elements are 
grouped together into bigger ‘objects’/units/whatever to handle.

Of course, for such grouping a container may not be strictly necessary 
(probably even undesired), as you can already informally group things 
together by their selector. E.g. everything with an ‘a’ selector and 
descendants are links, everything with a ‘.nav’ or ‘navigation’ selector 
and descendants is the navigation, etc.

I could even make a wild suggestion based on this:

Make a require-properties: require; property (the irony :)), which makes 
all given properties for the selected element required, even when 
they’re not in the same selector. And of course some way to exclude 
certain properties (which are e.g. used for browser hacks). With a 
selector of ‘a, a *’ you could then easily make all children of ‘a’ 
required as well.

I guess in reality this would probably bothersome too. And there’s no 
way to provide an ‘alternate’ rendering which I mentioned as desireable 
earlier.

Point though is that I’m trying to look at a different approach which 
uses the current model as a basis, and not requiring the style author to 
think/work in a different paradigm (too much). Yet at the same time make 
this work more broadly and avoid the objections I mentioned earlier.


> As a side note: should @require-* rules be allowed to be nested? I can 
> think of cases where somebody could want to write

Yes.


~Grauw

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san!!

Received on Wednesday, 6 April 2005 10:47:36 UTC