W3C home > Mailing lists > Public > www-style@w3.org > April 1996

RE: 'legal' / 'important' and cascading order

From: Chris Wilson (PSD) <cwilso@microsoft.com>
Date: Mon, 22 Apr 1996 10:11:07 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-76-MSG-960422171107Z-25419@abash1.microsoft.com>
To: "'rieger@bse.de'" <rieger@bse.de>, "'Chris Lilley'" <Chris.Lilley@sophia.inria.fr>
Cc: "'www-style@w3.org'" <www-style@w3.org>
This issue is something that I mentioned to Hakon last week - it's kind
of a pain to have to split important/legal weighted properties out of
the declaration at parse time.  What would people think about putting
the important/legal moniker on the entire declaration instead of a
property declaration, e.g.:

H1.foo !important { color:red; font-style: italic }

This would seem to simplify the management of important and legal
declarations significantly, at least in my opinion.  Anyone else?

	-Chris
Chris Wilson
cwilso@microsoft.com
-[-

>----------
>From: 	Chris Lilley[SMTP:Chris.Lilley@sophia.inria.fr]
>Sent: 	Monday, April 22, 1996 6:49 AM
>To: 	rieger@bse.de
>Cc: 	www-style@w3.org
>Subject: 	'legal' / 'important' and cascading order
>
>Wolfgang Rieger writes:
> > The following example shows a problem connected with the use of
> > 'legal'or 'important' and the cascading order:
> > 
> > Example:
> > 
> > Rule 1:
> > 
> > spec1 { prop1 : value1 !important;
> > 	prop2 : value2; }
> > Rule 2:
> > 
> > spec2 { prop1 : value1;
> > 	prop2 : value2 !important; }
> > [...]
> > However, IMHO there is no big use in being able to specify weight on
> > the declaration level. As far as I can see, it would be sufficient
>to
> > specify weight on the rule level. 
>
>Yes, in effect
>
> > In this case, one would have instead
> > of the example given above the following rules:
> > 
> > spec1 { prop1 : value1; !important }
> > spec1 { prop2 : value2; }
> > spec2 { prop1 : value1; }
> > spec2 { prop2 : value2; !important }
>
>Surely this can be generated very easily (without placing the
>semicolon before the ! ) from the foregoing. In other words, one
>performs a sort of macro expansion preprocessing step such that
>
>  sel { decl1; decl2; decl3 }
>
>expands to the exactly equivalent
>
>  sel {decl1 }
>  sel {decl2 }
>  sel {decl3 }
>
>Where sel is some selection term and decl is some declaration
>property: value plus optional !weight.
>
>[ Whether a particular implementation actually performs this step or
>simply behaves as if it had been done, is of course up to the
>implementor. Thus, a semicolon could be taken to mean, write the
>current selector and the current declaration (property, value, weight)
>into the internal table, retain the current selector, and continue. ]
>
>Advantage: the formal grammar need not be changed. People can still
>write the short forms.
>
>I believe this macro expansion concept was proposed earlier in
>connection with the font shorthand notation, although I cannot find
>the reference at present.
>
>--
>Chris Lilley, W3C                          [ http://www.w3.org/ ]
>http://www.w3.org/people/chris/                       INRIA/W3C
>chris@w3.org                       2004 Rt des Lucioles / BP 93
>+33 93 65 79 87            06902 Sophia Antipolis Cedex, France
>
>
Received on Monday, 22 April 1996 13:13:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:53:44 GMT