Re: Cascade: Supplement instead of Overwrite

On Sun, 10 Oct 1999, Sjoerd Visscher wrote:

>> This requires the redefinition of every property which is going to
>> support this. The other suggestions use a syntax independent of the
>> syntax of the property itself.
> I didn't think of it as such. As I am a programmer,

So am I, but CSS is not a programming language.


> I see old-values() as a function call, which is simply replaced with
> it's return value. Functions are already mentioned in the CSS2
> syntax, so when the return value is defined in some general chapter
> of the CSS recommendation, it is not required to redefine all
> properties. This is why I called it 'old-values()' instead of simply
> 'old-values'.

But you still have to modify the syntax of each property to say that
the function can be accepted. For example, just inventing the attr()
function didn't mean that any property could take it -- it has to be
explicitly stated in the syntax of the 'content' property.

Maybe this should be changed, but I imagine that would be quite a
complex task. One of the CSS2 drafts touched on this. One problem is
that you have to define the return type of the functions -- currently
CSS strategically avoids that by only allowing functions in
predescribed places which know how to cope with each of the functions.
Once a return type for each function is defined, then you have to
explicitly say which types each property understands. This is all not
as obvious as it may seem -- The attr() function, for example, can
return a string, a URI, a number, a space delimited keyword list, etc.
But how do you know that it has returned a URI and not a string? 


>> To actually implement this, UAs would have to traverse the matched
>> rules twice: backwards to find the first rule which didn't contain
>> old-values(), and then forwards to insert the old values. The other
>> suggestions only need a single traversal.
> ??? my suggestion does exactly the same as yours, it's just a little
> bit more flexible.

No. Take the following rules (they are already sorted):

   x { p: v1; } 
   x { p: v2 ! supplement; } 
   x { p: v3 ! supplement; } 
   x { p: v4 ! supplement; } 

My suggestion requires these steps:

   1. Start with last matching rule. 
   2. If rule is marked supplement, then find previous matching rule.
      2.1 Add it to the value. 
      2.2 Go to 2.
   3. You have the value.

Now take your equivalent: 

   x { p: v1; } 
   x { p: v2 old-values(); } 
   x { p: v3 old-values(); } 
   x { p: v4 old-values(); } 

This requires these steps: (Hmm. Actually, I just stumbled across an
algorithm that would work bottom-up for your syntax, although it
requires more memory since you need to remember the current position
in the value of the pending old-values() call.)

   1. Start with last matching rule. 
   2. If rule contains old-values(), then 
      2.1 Remember where old-values() was in the value list.
      2.2 Find previous matching rule.
      2.3 Insert it in the location stored in 2.1
      2.2 Go to 2.
   3. You have the value.


> I wonder why you have a top-down approach in mind.

If you reread my original suggestion you will find I don't. The
"supplement" declaration (or the alternatives "prepend" and "append"
or whatever I called them) start from the bottom and add values until
they get to a property which is not marked "supplement".


I any case, the syntax is really important. I am more interested in
seeing this functionality in CSS that a particular syntax.


> There's another one thing I'd like to be able to do with multiple
> values. Is this allowed:
> 
> BODY {font-family: Arial,Helvetica}
> H1 {font-family: Comic Sans,inherit}
 
No, because of the current definition of font-family's syntax. It
would be useful, though, wouldn't it? It would also be useful on
short-hand properties such as 'border-color':

   border-color: silver inherit gray silver; 

...or something...

So, when _is_ the "Value assignments, cascading and inheritance" CSS3
draft coming out? :-)

-- 
Ian Hickson
"I take a Professor Bullett approach to my answers. There's a high
probability that they may be right."
  -- Dr Snow; Mechanics Lecturer at Bath University; 1999-03-04

Received on Sunday, 10 October 1999 14:21:31 UTC