W3C home > Mailing lists > Public > public-html@w3.org > October 2008

Re: UA style sheet for <q>-- why required?

From: Sam Kuper <sam.kuper@uclmail.net>
Date: Fri, 31 Oct 2008 13:07:51 +0000
Message-ID: <4126b3450810310607s1b564a6br18bb2999a9f10277@mail.gmail.com>
To: "Jim Jewett" <jimjjewett@gmail.com>
Cc: "HTML WG" <public-html@w3.org>
2008/10/31 Jim Jewett <jimjjewett@gmail.com>

> On Fri, Oct 31, 2008 at 12:07 AM, Robert J Burns <rob@robburns.com> wrote:
> > Without a default UA stylesheet (or some equivalent
> > styling mechanism) then the best a UA could
> > do would be to present the DOM tree as simply a tree
>
> That is already some styling; I was talking about the extremely basic
> degrade-to-text option, in which all elements are replaced by their
> content -- effectively stripping out the element names and attribute
> information.


If a UA really implemented rendering the way you've described it, then the
following fragment:

<p>When I'm tired, I like</p>
<ul><li>books</li><li>being in the bath</li><li>singing</li></ul>
<p>above all.</p>

would render as:

When I'm tired, I like books being in the bath singing above all.

which doesn't make much sense (e.g. I don't like singing books, especially
not books that sing in the bath!), and certainly doesn't really suggest the
intended rendering along the lines:

When I'm tired, I like

   - books
   - being in the bath
   - singing

above all.

So, I really don't think UAs ought to aim to "[strip] out the element names
and attribute information", as you put it. That's a very dangerous default
rendering policy and not a use case we should consider sensible or realistic
for HTML 5.



> ...
> Plucker does not support CSS.  It has been on the TODO list for a few
> years, but ... given that plucker continues to support monochrome
> 160x160 pixel screens, the styling will never be extensive.


Styling can be very useful indeed without having to be terribly extensive or
in colour/grayscale.


> There is (usually) a step which replaces unknown characters, but there
> is nothing else that modifies the text itself -- as a change to
> quotation marks would require.  I'm not saying it couldn't be done,
> but it would require an extra pass, and special logic, and ... maybe
> that development time is better spent elsewhere.


I'd be very happy to see the burden of developing the styling rules for <q>
handled by a spec body, as I've made clear elsewhere. This would, if it
happened, *substantially* reduce the work the Plucker developers (for
instance) would need to do in order to have <q> render as intended.

Regards,

Sam
Received on Friday, 31 October 2008 13:08:29 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:58 UTC