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

Re: W3C Core Styles

From: Todd Fahrner <fahrner@pobox.com>
Date: Tue, 17 Feb 1998 12:16:48 -0800
Message-Id: <v03102807b10f989e65e6@[]>
To: Chris Lilley <chris@w3.org>
Cc: Gayle Kidder <reddik@thegroup.net>, www-style@w3.org
Thus spake Chris Lilley:
> 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 */
> }

Terrific. <troll>But Chris - why would anybody need to implement CSS2 when
they can just auto-generate a string of GIFs and non-breaking spaces in a
DIV from XML with a XSL transformation/template/stylesheet thingie. It'll
even work in Netscape 3! </troll> Back to you, Chris:

> Or smaller, subtler gaps which are much less intrusive than paragraph
> indents whilst still enabling easy comprehension and facilitating rapid

<plug>Like those of three of the four Core styles?</plug>.

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

Yes, but what I really want to provide is paged screen mode, Chris. Do I
have to put "best viewed on a Projector" to get this? Bah! - I thought a
CRT was a projector anyway. Would it help if we sat behind them and viewed
with a mirror? We just need a "display type" or "flow object", or whatever,
that represents a series of screenfuls, bounded both above and below. BODY
{ display: viewportset } . The text would flow through, filling as many
screens as the viewport's geometrical constraints and the available fonts'
metrics would permit. Many of the properties now being relegated to the
"print" and "projector" media types have a place on screen, I'm convinced -
and not just a "projector" screen. You could have columns, and marginalia,
and nav as "running headers" or footers. Mmmm.

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

Aye. Favorite Eric Gill quotation: "Letters are things, not pictures of
things." So are documents.

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

Hearty agreement. I think that rich structure and semantics are wasted,
however, to the extent that the style language cannot negotiate its
presentation based on the very particular restraints of the rendering
environment - tell me how much space I have (in a typographical unit system
- not pixels), its aspect, the color depth, the metrics of the available
fonts and whether or not they can be anti-aliased, and THEN I'll tell you
whether and how to transform and stylize the various bits of content. A
rendering environment query language and conditionalization mechanism
should be part of the style language, IMO - HTTP can't go far enough, and
it encourages server-side transformation and redundancy anyway.

Todd Fahrner
Received on Tuesday, 17 February 1998 15:12:04 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:46 UTC