Re: shadows

Ka-Ping Yee writes:
 > 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?

No, you cannot add new properties. For extending CSS we currently
envisage two paths: (1) new versions edited by W3C, and (2) explicit
hooks for people to hang extensions on. (CSS1 doesn't have such hooks
yet, except that we do know their syntax.)

 > 
 > 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.

We're not trying to fake hierarchies. The dashes are there purely for
readability: line-height is easier to read than lineheight or
line.height or LineHeight.

Properties aren't grouped. What looks like grouping is just a
shorthand, or a macro if you like. `Font' is a shorthand for five
other properties, `border' is a shorthand for four other
properties. We could have omitted `font' and `border', but we expect
that they will make writing CSS by hand a little bit easier.

 > 
 > > 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).

A hierarchical naming scheme has several disadvantages:

1. in many cases, the names won't sound as natural anymore:
   textdecoration-shadow-x, textdecoration-shadow-transparency

2. in other cases, an obvious name would be forbidden because it
   shares a prefix with another property: text-decoration and
   text-transform are unrelated and must therefore be renamed.

3. it forces people to think in hierarchies, which those of us who
   have studied computer science will have learned to do, but many
   others will have difficulty with. Ask around you how many people
   can comfortably set a resource using the X resources?

4. it introduces complex rules for cascading and inheritance; clearly,
   if we have textdecoration-shodow-x and text-decoration-shadow-y,
   then the designer can change one of them later in the same style
   sheet, because presumably he knows what he is doing. But if one of
   them is changed in a different style sheet, we will want to ignore
   that change, since it probably relates to a different shadow.

5. a corrollary of the above is that it sends the wong message to the
   designer; it appears that you can set these values independently of
   each other, while in practice you cannot.

 > 
 > > 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.

It is not really hierarchy that we should be discussing, but
grouping. CSS1 has several mechanism for grouping, some are for
convenience only (the comma between selectors, the semicolon between
declarations, the `font' property), others indicate alternatives (the
comma in font-family), yet others are necessary because the values are
multi-dimensional (background, font-style and also text-shadow).

For the latter type of grouping we have been playing with three
different syntaxes, of which only one is currently used. That is the
simple juxtaposition of values, as in background and in the
text-shadow proposed above.

The next one is functional notation: max(x,y),
shadow(0.1em,0.1em,black). This one is often our first idea (we're
computer scientists ourselves...), but so far we've always dropped it
for other solutions. We have only retained function-like notation for
url() and rgb(), which we thought of as a type-cast, but your (Ping)
explanation of them as an escape into a 3rd-party syntax (resp. URL
and sRGB) is actually more accurate.

The third one we think will play a large part in future versions of
CSS, for which reason we've included it in the conformance
requirements, even though CSS1 has no hint of it. This is the
@-rule. The current @import is an @-rule, but is of an extemely simple
form. Here is a complex @-rule for the shadow:

    @shadow unsharp-gray-shadow {
        x: 0.3em;
        y: 0.3em;
        color: gray;
        transparency: 80%;
        blur-type: gaussian;
        blur-radius: 0.1em
    }

    H1.headline {
        text-decoration: shadow(unsharp-gray-shadow);
        ...
     }

In effect, this achieves what you wanted. You could implement this by
converting the explicit indirection into an implicit hierarchy:

    text-decoration->x = 0.3em
    text-decoration->transparency = 80%
    ... etc.

But the point is that it doesn't look like a hierarchy. It keeps the
non-hierarchical keyword-value pairs, but the value now refers to an
object that is defined elsewhere, such as in an imported style sheet:
@import "http//a.b.c/std-effects.css".

So, to summarize, we have three grouping mechanisms: simple
juxtaposition for simple cases, indirection through an @-rule for
complex cases, and the functional notation which we may still decide
to use some day.

Back to the shadow property: the reasons for proposing it as we just
did above are twofold: (1) it is a simple enough property that it can
have all its dimensions on a single line, and (2) it is so pervasive
in current graphic design that it deserves a property of its own. The
shadow is independent of the other text decorations, so it can be
split off without harm.




 > 
 > 
 > Ping
 > 
 > 
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/pub/WWW/People/Bos/                      INRIA/W3C
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 93 65 77 71                 06902 Sophia Antipolis Cedex, France

Received on Friday, 9 August 1996 16:34:26 UTC