Re: shadows

David Seibert writes:

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

Bert was responding to a claim that CSS is "using the hyphen in a somewhat
loose fashion to indicate grouping". In this sense, properties are not
grouped; 'margin-left' is independent from 'margin-right'.

There are mechanisms for grouping in CSS. E.g., when specifying a
color:

  BODY { color: #F00 }

Above, the red, green and blue "properties" are grouped into one. In
CSS terminology, we only have one property.

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

We've been down this road and found it hard to find good names. What
would you name line-height, word-spacing, letter-spacing and
white-space?

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

No, but understanding (or, more correctly, being able to understand)
the X resource system would be required to write CSS style sheets.
We've been down this road as well. Bert's first style sheets
implementation as well as my first examples were based on the X
resource model since that's the world we're coming from. With tears in
our eyes we must admit that it doesn't work, though.

(To be fair, it would be a little simpler than with application
resources since -- hopefully -- fewer people would extend the CSS
specification than those who write widgets. Still, the same problems
apply.)

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

Principles are fine, but at some point we come down to reasonable
judgement. E.g., I do not believe you would like to see these
properies created:

  color-red
  color-blue
  color-green

To me, the above properties are unreasonably detailed. Now, I have
more understanding for:

  background-color
  background-image-static
  background-image-animated

Still, we have come to the conclusion that this is also too detailed
and in some cases will have unexpected results. Instead we have:

  background: white url(marble);

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

True, it's possible to produce garbage with CSS1. We do think,
however, that some of language constructs makes it easier to write
good style sheets that bad ones. That why the shortest way to set font
properties are:

  font: 12pt/14pt helvetica

Although 'font' is not a real property (it's a macro), it will still
encourage authors to consider the line-height in relation to
font-size.

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

After almost 2 years of discussions -- most of which are available
on-line -- a simple but powerful specification has emerged. At this
point, making the changes you suggest would be very expensive and I
believe we would end up close to 0 in gain.

Regards,

-h&kon

Hakon W Lie, W3C/INRIA, Sophia-Antipolis, France
http://www.w3.org/people/howcome  howcome@w3.org

Received on Thursday, 15 August 1996 13:22:00 UTC