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

|   From: Glenn Adams <glenn@stonehand.com>
|       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.

I've already said that for generic, planned styling stylesheets are
exactly what you want (though I'd like to see the ability to do textual
rearrangement and modification in the right-hand-sides, rather than just
text presentation attribute changes).

Your example, however, contains something totally unplanned and
non-generic.  The reader reasonably knows that H1 appearance is
controlled by the stylesheet and will be done in an appropriate way.
She has no reason to expect, when reading the text, that a particular
paragraph has been styled by name.  I still think that's broken - if
you're going to apply special styling to a named element instance, there
should be some indication at the point of the instance.

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

What has CD-ROM-ness got to do with anything?  It shouldn't change the
interpretation of STYLE="{font.size: 14}" that I can think of.

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

Umm.  OK, I guess I'll grant that that's reuse.  Whether it's helpful or
not depends on whether the applied styling is common or specific and is
useful anywhere else, but there's the potential for gain.

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

No, I haven't built a browser, though I have walked  parse tree from
time to time and queried the occasional dictionary. If you entered those as
objections on an IEEE standards ballot, though, you'd need to present a
wee bit more detail to convince people the issues were universal and

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

Because, as a potential consumer of the product, it "feels wrong" to me.
Stylesheets feel right, but the inability to put information locally,
when appropriate, feels wrong.  Intuition, based on experience, tells
me I will want to put my fingers where your restriction says I can't...


scott preece
motorola/mcg urbana design center	1101 e. university, urbana, il   61801
phone:	217-384-8589			  fax:	217-384-8550
internet mail:	preece@urbana.mcd.mot.com