CSS Format: More Notes

	(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
something like:

	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
too specific.
	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,
for instance:

	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").
	I wrote:

	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.
	You wrote:

	*: 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.
	You wrote:

	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,
so:

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

--
Kevin Hughes * kevinh@eit.com
Enterprise Integration Technologies Webmaster (http://www.eit.com/)
Hypermedia Industrial Designer * Duty now for the future!

Received on Monday, 23 January 2023 01:05:51 UTC