> Bert Bos wrote:
> > 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.
If properties aren't grouped, why do you say later in your note that CSS
has several mechanisms for grouping?
> > 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.
That's right, well-chosen hierarchical names could sound very
natural, and would carry more information. You need some way to
describe the quantities, so what would you say now - transparency
of shadow text-decoration? To me, that sounds less natural than
what Ping proposed.
> > 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.
I agree totally.
> > 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.
Noone has to understand the X-resource system to be able to think about
hierarchies properly. What about telephone numbers, bureaucracies,
many countries postal addressing conventions, and other real-life
hierarchies? Anyone who works with computers a lot learns fairly
quickly how to deal very well with the hierarchy involved in an
internet address, and I hope that the CSS hierarchy would be much less
> > 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?
Right - do you really want to restrict what good designers can do,
just to help out bad designers? That's one function a smart editor
could serve ;-), but I see no reason that it needs to be incorporated
into the language design, especially when that makes the language less
useful for the more capable people. You can't turn bad designers into
good ones by giving them a good stylesheet language, but you can annoy
good designers by not allowing them to do what they want, making it
more likely that they quickly adopt any new language that gives them
> > 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.
That's true, but why can't I set those values independently? I could
set line height and font-size independently, use negative margins, set
color and background-color independently, use underline and overline
and line-through and blink all on the same element, switch elements
from block to inline to list-item to undisplayed, and or a number of
other things that could produce very ugly documents. Loosening the
restrictions that CSS currently places on authors wouldn't let me
produce uglier documents than I can produce with current CSS.
I'm not suggesting that authors shouldn't be allowed to do these things,
they've got to have these powers to be able to design documents that
look really good. I remember reading in an html style guide a few
years ago that good writers should use structural markup as much as
possible and then "trust the browser" to get the display right. I
thought that was very good advice, and I still do. Maybe CSS should
give users power to set properties independently, trust authors not to
screw up their design, and trust users to not set up personal
stylesheets that make everything look bad on their browser.