Re: shadows

I wrote:
>
> If "shadow" is going to have possibly four or five parameters of
> its own, maybe it should be its own property rather than a special
> value of "text-decoration" which happens to take extra parameters.
 
Hakon Lie wrote:
> 
> This is a good idea.

Yes, but my intent was not quite what you ended up proposing.

> ______________
> 
> text-shadow
> 
> Applies to: all elements
> Value: none | [<color>||<offset>||<transparency>]
> [,<color>||<offset>||<transparency>]*
[...]

What you just did here was to make up a completely new syntax
for a new property.  This is actually what i wanted to avoid.
When you have people extending CSS to add their own properties,
is this how you would want them to do it?  By making up their
own grammar for a property with a new name, and their own rules
for interpretation?

I wrote:
> The extra grouping levels are dropped so that it looks like all
> properties have two levels, even though they don't really.
 
Hakon Lie wrote:
> I'm not sure I understand what you mean here. Some CSS properties
> allow multiple values and could have been split up into several
> properties.

What i'm trying to get at is that the real information is organized
into many more than two hierarchical levels.  To me it appears that
CSS1 is currently just trying to "fake" two levels by collapsing
some levels and not others, and using the hyphen in a somewhat loose
fashion to indicate grouping.  At the moment it is possible to pick
out a set of properties so that you only use at most two keywords,
but i am not certain that will always be the case as CSS grows.

> E.g. 'background' could have been split the current
> 'background' property into: bg-color, bg-url, bg-repeat, bg-scroll,
> bg-hposition and bg-vposition. The reason for not doing it this way is
> that grouping is necessary to ensure that values meant to go with,
> e.g., one image ends up influencing another image.

Yes, that's the whole point of having a hierarchy.  What CSS1 does
right now is loosely group a bunch of values, sometimes by putting
them on the same line and giving some rules for saying what goes
with what (as in font or background), and sometimes by giving them
all the same prefix before the hyphen.  This limits us because when
it comes time to introduce more detail -- as with the "shadow"
property, which we wanted to be part of text-decoration -- we have
to make up a new syntax for a third level of grouping, as you have
just done (in two ways -- first with the functional syntax, and
then with your recent message).

I'm suggesting that we generalize a bit and allow for new properties
to fit under the hierarchy so we can go with one grouping mechanism
and one set of matching rules (e.g. match the values in turn to the
first available property which accepts the correct type, as i wrote
in my previous post).

> Do we need to clarify this in the specification?

I think CSS1 stands fine on its own as it is -- but i do think such a
clarification is necessary if you want a consistent extension scheme.

Hakon Lie wrote:
> Right. Blur is cool, but maybe too resource-intensive? Implementors
> resisted the background gradients that were in CSS1 earlier, and blur
> falls into the same category. Best to leave it out for now, but
> reserving the percentage units for its use? The same argument can be
> made againt transparency?
[...]
> If we want to add blur at a later point we can do so by adding another
> length value. Then, we would not be able to specify a blur without
> also specifying both x and y offsets, but that shouldn't be a major
> problem.

See?  If you want to introduce some sub-properties now and others
later, it makes things difficult -- you have to change the grammar
and interpretation later, and make sure it is backward-compatible.
Then you have to start worrying about what order the values come
in, and so on.  This would not be so fragile if there was a defined
tree of properties and sub-properties and a consistent matching rule.

I'm not saying i have all the answers, but i have some ideas about
what i think we need.


Ping

Received on Friday, 9 August 1996 14:04:17 UTC