- From: Ka-Ping Yee <kpyee@aw.sgi.com>
- Date: Sat, 10 Aug 1996 02:54:11 +0900
- To: Hakon Lie <howcome@w3.org>
- Cc: David Perrell <davidp@earthlink.net>, www-style@w3.org
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