W3C home > Mailing lists > Public > www-style@w3.org > February 1998

Re: W3C Core Styles

From: Chris Lilley <chris@w3.org>
Date: Tue, 17 Feb 1998 20:23:26 +0100
Message-ID: <34E9E3AD.237659E7@w3.org>
To: Todd Fahrner <fahrner@pobox.com>
CC: Gayle Kidder <reddik@thegroup.net>, www-style@w3.org


Todd Fahrner wrote:

> After discussing with Hakon, I think I have this right: HTML's content
> model, defined in a DTD, does not necessarily correspond with its rendering
> model (which before CSS had no language, even, much less a communicable
> model). The document tree and the rendering tree are distinct, though often
> morphologically similar.

Yes. Good summary. See

  http://www.w3.org/TR/WD-CSS2/intro.html#h-2.3

> It does not aid understanding that the same
> descriptive terms - block and inline - are shared across trees. There is no
> redundancy in saying that block level elements may render as blocks, nor
> any contradiction in saying that they may render inline.

Right.

> * Look at the web and you'll frequently see navigational items arranged in
> a single line, delimited by virgules or nasty little GIFs or whatever. The
> semantically appropriate markup for such would be the now deprecated MENU
> or DIR elements, I think. Nobody used these, though, because the LI
> elements each sat on their own line, as blocks. Through CSS you could
> simply set the display type of LI to inline,

Yes. The CSS1 spec notes that some UAs may have the block/inline property hard coded;
it seems that this has not changed much in the interim.

> and ... well what about those
> markers? There'd be work to do,

Not too much, in CSS2:

ul.navbar li {
  display: inline /* this makes the single line of list items */
}
ul.navbar li:before {
 content: url(nasty-little.gif) /* they all have a nasty little gif in front */
}
ul.navbar li:first-child:before {
 content: "" /* except the first one */
}

Note the ordering in that last selector, which contains both a pseudo class (first
child) and a pseudo element (before). The pseudo element must come last. The selector
in the third rule is more specific that that in the second, so it would still overide
the second rule even if it didn't come after it. The result is that all list items
have a gif in front, but the first one doesn't so the nasty little gif appears as a
list item separator.

See
  http://www.w3.org/TR/WD-CSS2/selector.html#first-child
  http://www.w3.org/TR/WD-CSS2/generate.html#before-after-content
  http://www.w3.org/TR/WD-CSS2/selector.html#h-5.10.6

> but it's an interesting direction that I'm
> sad to see appears not to have been taken by implementors.
>
> * Look at the paragraphs here: http://www.tiro.com/ . This is an ancient
> mode of delimiting them - not with line breaks, but with inline markers.

The same sort of declarations would work for that example too

> Scribes using one color of ink would write out the text, leaving gaps
> between the paragraphs. They'd then pass the sheet on to another scribe
> using red ink - the "rubricator", who would scan for gaps and make marks in
> them. (This was a very economical way to do layout when paper was dear,
> just as pixels are now. The dense, uniform field of text on a sheet
> resembled woven cloth, and was accordingly called a "textus", whence text
> and textile.)

And besides the economies, the resulting typography was pleasing to the eye and nice
to read.

> Anyway, the rubricator could work faster and more accurately
> if he could just scan the left edge of the textus for gaps, so the scribes
> started putting the new paragraphs on new lines, leaving a little gap as
> before. Then somebody realized that these *indents* made the rubricator
> and his expensive red ink totally superfluous - and there you have it.

<soap>Thus giving the horrible, to my eyes, indent layout often used in typewritten
matter where inter-paragraph spacing could only be an integral number of lines, or at
best a half line. Yuk. Some people still like this style; together with the use of
over-serifed typefaces like Computer Modern in gives the instantly recognisable,
dated, "TeX style".
</>

> Much
> later, when fashion and cheaper paper meant that something had to give,
> somebody came up with the extravagantly barbarous idea of hacking up the
> textus with big gaps between paragraphs.

Or smaller, subtler gaps which are much less intrusive than paragraph first-line
indents whilst still enabling easy comprehension and facilitating rapid reading. I
prefer the inter-paragraph leading and the scribal fleuron styles over the
first-line-indent style. But then, a full CSS implementation would let me have my
preferences and you have yours.

> Meanwhile, on the Web, where we've regressed all the way back to the
> cumbersome scroll, we still cling to the convention of starting paragraphs
> on new lines, even with gaps. Sometimes I'd much prefer P { display: inline
> }, especially now that red is cheap. For WebTV or a handheld, this could
> make a huge difference.

Yes.

@media projection, tv, handheld {
  H2, H3, H4, H5, H5 {
    display: run-in
  }
}

> If you, like me, have been confused by Microsoft's talk of "HTML/CSS flow
> objects" as the output of their XSL interpreter, realize that these would
> be nonsensical if they'd just support the CSS1 display types.

That is a good point, although there would still be the need to do forms and suchlike
which XML does not define. But yes, a client-side stylesheet using a full CSS
implementation with no hard-wired values on the display property would be much better
for the user since  the XML semantics would be retained. Server-side processing to
give content-free pictures of documents (eg font and br as the only tags used) is a
major retrogressive step.

I should perhaps point out that XSL does not require this sort of stripping of
semantics, and good practice is as always to minimise the loss of semantics and to
put the rendering as close to the user as possible.

For example, it would be possible to have server-side processing of rich well
structured HTML 4.0 and CSS2 and serve up rendered JPEG images of each page, or
something, and this would be a really bad idea. I think it comes down to how muchg
semantics is actually transmitted to the end user, and this is to some extent
independent of the style-sheet technology used. It is how the technology is applied
that counts.

> As it is now,
> their main need to invoke HTML as a display format is to patch the gaps in
> their CSS implementation. Otherwise they could style a lot of XML directly
> with CSS, with XSL serving as just the transformation language.

Certainly a lot of people have been saying that an XML to XML transformation
language, preferably client-side, followed by a robust CSS rendering, would get many
people a long way towards where they want to go.

--
Chris Lilley, W3C                             http://www.w3.org/
Graphics,Fonts,Stylesheets Guy    The World Wide Web Consortium
http://www.w3.org/people/chris/              INRIA,  Projet W3C
chris@w3.org                       2004 Rt des Lucioles / BP 93
+33 (0)492 387 987 <NEW    06902 Sophia Antipolis Cedex, France
Received on Tuesday, 17 February 1998 14:23:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:53:54 GMT