Re: [Suggestion] Multiple 'property' tokens in 'declaration' syntax

On Thu, 31 Oct 2002, Christopher Lee wrote:
> 
> --- Ian Hickson <ian@hixie.ch> wrote:
> > It makes the syntax in my opinion more confusing to authors,
> > and also makes the parsing significantly more confusing.
> > 
> >    padding-top, color: green;
> > 
> > ...would have to be ignored, for example.
> 
> This example would expand to:
> 
>     padding-top: green;
>     color: green;
> 
> The padding-top declaration would be ignored, yes, but the color
> declaration is still valid.  The entire declaration need not be ignored.

This is different from selectors, where "h1, <foo>" is ignored completely,
for example.


> How does this make parsing more difficult?  This is similar to selector
> grouping, which has been implemented already.

You basically would have to parse the value as many times as there are
properties in the list.

For example:

   font-family, conter-increment: test 1, demo 2, serif;

...would need to be parsed as:

   font-family: "test 1", "demo 2";
   counter-increment: test 1, demo 2, serif 1;

...where in the font-family case you have two strings (font names) and one
keyword, while in the counter-increment case you have three counter names
with associated integers.


>> This suggestion also removes the possibility of using commas in
>> declarations in future, should we find a use for them.
> 
> Commas have already been used in selectors to group rules with identical
> declarations together

Selectors are in a different place in the CSS grammar than the property
side of declarations. The two are independant. (Indeed in CSS3, the
selectors are not even part of the core CSS syntax any more.)


> This would allow related measurements to be grouped together so that
> the value could be modified in a text editor once, and all of the
> associated properties would update correspondingly.

Please show me an example of this in practice. I have rarely found myself
repeating the same number for multiple properties on the same selector.

In practice, what I have found to be much more useful for simplifying
stylesheet maintenance is a postprocessing system. For example, several of
my stylesheets are generated on the fly using TemplateToolkit [1], and
some people I know are using a custom preprocessor script [2] with macro
expansion to generate their stylesheet.

[1] http://www.template-toolkit.org/
[2] http://software.hixie.ch/utilities/unix/preprocessor/


> The author would not need to scan through the style sheet and update
> every single reference.  In my opinion, this would slightly simplify
> adjustment of values.

It will need to do more than "slightly" simplify anything to be added to
CSS, since it has a high cost in implementation and time-to-market.

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
"meow"                                          /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 1 November 2002 09:33:41 UTC