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

|   From: Glenn Adams <glenn@stonehand.com>

|       From: preece@predator.urbana.mcd.mot.com (Scott E. Preece)
|
|	  From: Glenn Adams <glenn@stonehand.com>
|       |   It already exists, e.g.,

|       |   <STYLE NOTATION=css>
|       |   [ID=P123] { color : red }
|       |   </STYLE>

|       |   <P ID=P123>A random red paragraph.</P>
|
|       Oh, come on.  The example is not one whit better than putting the
|       styling directly on the paragraph.  It has no readability,
|       debuggability, reusability, or other advantage.
|
|   I disagree, both as an author of documents and as a UA (with CSS support)
|   implementer. [I architected and implemented our style sheet support].
|
|   It is more readable because style data is stored in one location rather
|   than randomly distributed through the document.
---

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.

---
|
|   It is more debuggable because the single ID rule can be reused and therefore
|   its parsing need not be replicated.
---

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.

---
|
|   It is more reusable since it can be used with any element.
---

Again, that style rule affects only that paragraph.

---
|
|   As for other advantages, (1) it preserves separation of content and
|   presentation data; (2) it restricts the scope of the style language parser
|   (i.e., the parser need only be instantiated once during document header
|   processing); (3) it permits optimizations in the represesntation of
|   style rules through automatic merging that can only occur when all
|   style rules are available (incremental merging is more costly); (4) it
|   permits better resource usage since the UA can predict processing and
|   formatting requirements earlier.
---

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

---
|
|       In either case you have pure, unblemished, ad hoc styling.
|
|   I'm not arguing for or against ad hoc styles.  I'm assuming they will
|   exist and be used.  I'm arguing for where they are specified and when
|   they must be processed (compiled).
|
|   The only argument I've seen for style attributes that has any merit
|   is that it permits lazy typists to be lazier.  Is that your argument?
---

I don't really care about the typing; tools really should take care of
that.  I do care about the author's mental model.  Information,
including styling information, that is specifically local to an element
should be with that element.  The information that should be in the
stylesheet is global information that affects the document as a whole
(even though it achieves its effect by making many individual elements
take on specified appearances).  It makes a great deal of sense, to me,
to say in the stylesheet "H1 elements should be in 14-point Helvetica";
it makes no sense, to me, to say in the stylsheet "paragraph 14 should
be in strike-through mode".  Maybe your mental model of the authoring
process is different from mine, but those two cases seem qualitatively
different to me.

scott

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

Received on Thursday, 7 December 1995 16:53:03 UTC