Bert Bos wrote:
> 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 understand. Thank you for reading and thinking carefully about
> 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.
The only thing that bugs me is that you have to make up a new grammar
with associated semantics every time you want to sort-of-group
properties into a shorthand. I was just trying to find a more
general way to do this so that it can apply to extensions too.
> 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
<shrug> These two make reasonable sense to me, although they
could be just "text-shadow-x" and so on. A matter of opinion,
i suppose; but having a hierarchy doesn't mean we have to let
the number of levels get out of hand.
> 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.
I don't see these two properties as ungroupable. They both apply
to the text itself, which is why they start with "text-" in the
first place. Maybe there are worse examples, but i didn't see
any outright contradictions in CSS1.
> 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?
The X resource system is a lot larger and has many more hierarchy
levels than we need for CSS, so it doesn't have to be that bad.
But as to whether people prefer not to think in hierarchies, i
honestly can't say. Maybe i'm too used to it, but i wouldn't mind
hearing some more opinions on the topic.
> 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.
Yes, the designer could change one of these properties at a time,
and that's one advantage of being able to choose the grouping level.
But if, in the entire stylesheet, some shadow subproperties are
defined and others are not defined anywhere, the designer is asking
for trouble. Presumably if you were to cascade a different style
sheet that had a different shadow definition, it would define all
the shadow parameters, wouldn't it?
> 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.
I guess this is true. I follow.
> 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).
Then i guess it is the last type that i've been thinking about.
From what you've posted, it does look like the @-rule scheme is
a pretty good solution to grouping parameters. I'm happy with it,
and it looks to me like the best way of adding a shadow property
to things as they stand.
Ping (Ka-Ping Yee): Developer, Alias|Wavefront Inc. (Tokyo)
Don't wait: use mathematics in your web pages TODAY with
the world's first browser-independent expression system.
- Re: shadows
- From: firstname.lastname@example.org (David Seibert)