Re: Suggestion: Inheritance

>Some have rightfully argued that these abilities already exist in other 
>tools, that are in use today.

I'd like to stress the fact that you wrote "in other tools". So there's 
always a proprietary, third party tool required to be present. In case of 
web controls or any web libraries being made available no external tool nor 
preprocessor can be applied. Moreover, using external sources requires a 
breach in media, which a comprehensive standard should not require.


>thing about standards is that there are so many to choose from."

Any other way won't be an option to choose from at the moment this proposal 
gets added to the standard as they all have the drawbacks I described.


>Yes, a client-side processor would have many different and interesting 
>abilities over a server-side processor. It's intriguing, and I for one 
>would use such a thing.

Me too, definitively and thoroughly...


>The problems with your proposal are that you suggest using selectors as 
>identifiers, and you propose using the computed value of rules.

I admit that I was wrong when using that term at the beginning. In the 
course of this discussion I now dissociate myself from the term "computed 
values". In fact, I suggest a plain and simple rule replacement algorithm as 
given by the example code in my last article. So a "110%" rule basically 
remains "110%" rule, applied to another selector.

Computed values can not be uniquely identified by selectors, just like you 
described. Moreover, I also believe referencing rules is more intuitive to 
the CSS designer.


>-- I like that idea.

I'm very happy to read that. So what does it require then to get a common 
consent and have this proposal added to CSS3?

Axel Dahmen




>From: Ben Curtis <bcurtis@bivia.com>
>To: www-style@w3.org
>Subject: Re: Suggestion: Inheritance
>Date: Thu, 19 May 2005 11:41:48 -0700
>
>
>>It brings unprecedented flexibility and maintainability to CSS, 
>>particularly in multi-client environments where design templates could 
>>simply create a whole new design by just changing some basic rules.
>
>Some have rightfully argued that these abilities already exist in other 
>tools, that are in use today. A new spec that covers the same ground runs 
>the risk of supporting the derisive joke, "The great thing about standards 
>is that there are so many to choose from."
>
>Yes, a client-side processor would have many different and interesting 
>abilities over a server-side processor. It's intriguing, and I for one 
>would use such a thing.
>
>The problems with your proposal are that you suggest using selectors as 
>identifiers, and you propose using the computed value of rules.
>
>Rules describe how to arrive at the computed values for elements; they 
>themselves do not have computed values (e.g., a rule for a font size of 1em 
>may have a computed value of 16.5px in one paragraph and a computed value 
>of 10px in another).
>
>Since selectors are not unique, and can be very messy once you start 
>cascading, you likely want to create some way to identify rule blocks. Once 
>you assign unique identifiers to rule blocks (to avoid, for example, cases 
>when a selector with spaces is used where a property value may contain 
>spaces as delimiters), then you have essentially moved your proposal into 
>the realm of the variables/constants/etc. that gets discussed here about 
>once a month. To that discussion, you contribute the notion of assigning 
>entire rule blocks to a variable name, instead of just single values -- I 
>like that idea.

Received on Monday, 23 May 2005 15:12:24 UTC