Re: draft-ietf-html-style-00.txt & class as a general selector

Glenn Adams (glenn@stonehand.com)
Thu, 7 Dec 95 17:26:18 -0500


Date: Thu, 7 Dec 1995 15:42:48 -0600
From: preece@predator.urbana.mcd.mot.com (Scott E. Preece)

Nonsense. It is *less* readable. When you read the text for the
indicated paragraph you have *NO IDEA* that there is styling magic
affecting it somewhere else, unless you have memorized the STYLE element
or refer to it for each paragraph you read.

Amazing aint it. That's precisely what separation of content and
presentation is all about. If you are generating content that is
expected to last beyond a couple of days or hours, you'll see the
light too.

Say you have a CD-ROM with HTML text on it; what are you going to
use, STYLE attributes or IDs? If you use STYLE attributes then --
you lose. That is, when you want to change the appearance, good luck.
On the other hand, if you do The Right Thing and use IDs or a style
attribute whose declared value is restricted to NAMEs (see below), then
you're in good shape: you can simply change the contents of your off-
board stylesheet, and off and away you go!

There's no way you can reuse that styling rule - the ID is required
to be unique, so it cannot affect any other element anywhere.

You can resuse it by adding additional selectors to the LHS of the rule.
Of course you can use CLASS instead of ID, or perhaps, if you really want
a STYLE attribute, then restrict its declared value to be NAME or NAMES only.

Again, that style rule affects only that paragraph.

No. See above.

(1) is an arguable goal (hence the arguing we've been doing). I
don't know whether (2) is important or not in your implementation -
again, I can imagine impleemntations where it made no difference at all.
I don't see (3) as interesting as stated (who cares about merging style
rules when you're just adding additional styles to whatever the rules
would have applied anyway?), but, again, I don't know your
implementation. (4) doesn't make sense to me (why do you care about
predicting processing requirements) and seems trivial compared to other
things you might encounter on the fly.

You don't understand because you haven't attempted to implement support
for any of the ideas you are proposing. Or, if you have, then you haven't
attempted to make your implementation efficient.

Information, including styling information, that is specifically local
to an element should be with that element.

I disagree. Others do too. I'd suggest you read "Making Hypermedia Work"
by S. DeRose and D. Durand if you want to see the big picture.

BTW, if you don't care about typing, then why are you arguing these points
at all? If the user isn't typing in style data, then there is absolutely
no reason to have the style attribute as its been discussed thus far (i.e.,
putting the rule in the attribute). If the user isn't typing the document,
then the model can be an abstraction which is serviced by the implementation
in a way which doesn't permit use of local style rules embedded in the tags.

Regards,
Glenn