CSS Format: More Notes
Subject: CSS Format: More Notes
From: email@example.com (Kevin Hughes)
Date: Fri, 2 Jun 95 16:59:17 PDT
(I sent this out two weeks ago but just I realized that it
bounced, so I'm sending it again. Apologies if duplicated.)
Hakon, thanks for getting the list going! It was pretty
clear that style-sheet related discussion was not appropriate for
html-wg, and www-html is too general. I hope that good things come
out of here.
Looking over the draft specification you've put up, here
is some more feedback. You wrote:
H1: oversize.font.size += 3
The main reason for something like "oversize" is to allow
for large capitals. However, I'm sure you can make something more
intuitive to allow authors to change properties of capitals. Maybe
H1: font.size.capitals += 3
H1: font.size.caps += 3
These lines do the same thing. They change the first
letter of every word in the element.
H1: font.size.firstcap += 3
This only changes the size of the first letter in the element.
I think it would be better not to use the word "dropcap" since it's
Now, when it comes to doing things like this:
---- blah ---- blah
| | blah | | blah
---- blah ---- blah
blah blah blah blah
Where the first element might be a dropcap, and the second may
be an image. I think a good place to start would be a "wrap" property:
*.dropcap: align = top
*.dropcap: wrap = on
*.dropcap: wrap (not specifying a boolean is equivalent to ON).
In this example, anything with the "dropcap" style is aligned
to the top of the line and the text wraps around the rest of the element.
I realize that wrapping may require a good deal of parsing lookahead,
IMG.wrapped: align = bottom
IMG.wrapped: wrap = on
blah blah blah
blah ---- blah
blah | | blah
blah ---- blah
The above example might be what such an image might look like.
P: back.color = "blue"
I would avoid using "back" as a word for background, since
"back" may be used for something else in the future (as opposed to "next").
txtlink.color = "red"
imglink.size = 3px
I agree that "txtlink" and "imglink", etc. are too specific.
This should instead just be "link", and allow the browser to make the
appropriate decisions depending on the context.
*: numbering = on|off
I like this, not because it can allow you to make numbered
lists, but it would be great if it could allow one to make numbered
elements - paragraphs, headers, etc.
WIDTH: window width
HEIGHT: window height
DWIDTH: display width
DHEIGHT: display height
I think most authors will only be concerned with the display
width and the display height. Perhaps the display properties should
be renamed to WIDTH and HEIGHT to make them easier to remember, and
the window properties should be renamed to WINWIDTH and WINHEIGHT?
Alternates to WIDTH and HEIGHT could also be PAGEWIDTH and PAGEHEIGHT,
WINWIDTH: window width
WINHEIGHT: window height
WWIDTH: window width
WHEIGHT: window height
WIDTH: display width
HEIGHT: display height
PWIDTH: display width
PHEIGHT: display height
PAGEWIDTH: display width
PAGEHEIGHT: display height
You write about "dummy elements" like:
doc: margin.left = 20pt
window: width = 500px
source: font.size = 14pt
I think control over the source view format is best left to
the user, not authors, but of course "source:" is good if you are
allowing the user to change browser preferences using this style
sheet mechanism (in this case the author is the user).
Instead of "doc", how about using the word "page" for everything
that refers to the document display area?
Most people think of the Web as a collection of pages anyway.
And in place of "window", perhaps a good substitute may be "browser",
as window properties refer to the overall size of the browser.
So you get:
page: margin.left = 20pt
browser: width = 500px
...and it seems closer to the way people think about these
As a side note: I've been following the LINK discussion on
html-wg, and it's so unnecessarily complex! If it keeps up, they're
going to end up killing HTML as long as people are expected to write
it by hand. I might as well as go back to writing HyperCard stacks
and Macromind Director movies, or just putting everything in PDF.
The point is, if you expect humans to be reading and writing this,
it should be clear, simple, and easily understood. This does not mean
that it can't be powerful or extensible.
Kevin Hughes * firstname.lastname@example.org
Enterprise Integration Technologies Webmaster (http://www.eit.com/)
Hypermedia Industrial Designer * Duty now for the future!