W3C home > Mailing lists > Public > www-style@w3.org > August 1996

Re: Formalize the hyphen?

From: Ka-Ping Yee <kpyee@aw.sgi.com>
Date: Wed, 07 Aug 1996 14:38:50 +0900
Message-Id: <32082BEA.2F1C@aw.sgi.com>
To: www-style@w3.org
I just thought a little more about what i said and
realized that using the hyphen as a hierarchical
separator forms a close analogy to the X resource
scheme, except with hyphens instead of periods.

Let me make an attempt to specify more precisely
what i had in mind.  As an example, expanding the
hierarchy for "margin" gives something like the
following.  By my count there are six value types
in CSS1: length, percentage, colour, URL, string,
and keyword.

 |  `-width [LENGTH | PERCENTAGE | KEYWORD{auto}]
 |  `-width [same as above]
 |  `-width
Now, specifying

   margin: 1em 2em

can be thought of as attempting to assign the values "1em"
and "2em" to matching properties under the "margin" hierarchy.

This is something like saying

   margin*: 1em 2em

in an X resource file, except that in this case we have
multiple values.  I suggest a policy where each value is
assigned to the next matching property.  Thus, 1em is
given to the first available property accepting a LENGTH
type, which is "margin-top".  2em gets assigned to
"margin-right".  And then beyond that we can apply the
rule of taking missing values from the opposite side.

For a more elaborate example we can look at "border":

 |  |-width [LENGTH | KEYWORD{thin, medium, thick}]
 |  |-style [KEYWORD{none, dotted, dashed, solid, double, ...}]
 |  `-color [COLOUR]
 |  |-width [LENGTH | KEYWORD{thin, medium, thick}]
 |  |-style [KEYWORD{none, dotted, dashed, solid, double, ...}]
 |  `-color [COLOUR]
 |  |-width [LENGTH | KEYWORD{thin, medium, thick}]
 |  |-style [KEYWORD{none, dotted, dashed, solid, double, ...}]
 |  `-color [COLOUR]
    |-width [LENGTH | KEYWORD{thin, medium, thick}]
    |-style [KEYWORD{none, dotted, dashed, solid, double, ...}]
    `-color [COLOUR]

Applying a similar shortcut rule to "border" where all sides
take the same value if only one value is specified for a given
"border-<side>" sub-property, we can interpret

    border: solid red

in the same way as before.


So why bother thinking about it this way if it makes almost no
difference to what you put in your stylesheet now?

Because it means that there is a more consistent way to handle
extensions (by just adding more nodes to the tree) and to allow
shorthand.  The "font" shorthand, currently described as a
special case, could work practically as it is, simply by
checking the values one by one to see which properties they
might match.

It also lends itself to possible new structures such as

H1 {
  text-shadow: { xoffset: 2px; yoffset: 5px; color: red; blur: 3px; };

which provides a way of giving "keyword arguments" to
"sub-properties" without introducing new syntax concepts.

The more general shortcut scheme would also let you write, e.g.:

BODY { border: blue green yellow red; }

instead of having to spell it out for border-top, border-right, etc.

These are just some thoughts on organizing the properties
into a hierarchy.  This isn't really a formal proposal yet,
but i just wanted to find out what people think about this
way of organizing CSS.

Received on Wednesday, 7 August 1996 17:02:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:40 UTC