Re: css21 list-style-type dropped types

On Sun, 9 Nov 2003, Jungshik Shin wrote:

>   I understand your point about having to adhere to the basic idea of CSS 2.1,
> but still I don't feel comfortable about what you described as
> 'debatable'.

I actually didn't mean that we should adhere to the basic idea - rather, I
took it as a fact of life that the W3C is defining a modified "practical"
subset of CSS 2 under the name CSS 2.1. What I meant is that this idea has
pros and cons, and we lose much of the pros if the idea is not applied
consistently.

>  Because Tex already has given an elaborate argument against using
> frequency and popularity as a guideline for standard-writing, I'll just
> point out that Mozilla has supported all those list styles dropped in
> CSS2.1  for a long time

I'm happy to stand corrected. (I had confused various practical
considerations with each other.) But Mozilla support still doesn't mean
much. I admit that my suggestion to pick up lower-greek was culturally
biased.

(I won't comment separately the notes on standards that Tex wrote. The
points are important. But, on the other hand, the W3C is not a standards
organization. However I hope that CSS 2.1, if approved, will however
_resemble_ a standard at least by actually being a stable document, not
something that will be substantially changed without prior or posterior
notice by writing something into an "Errata".)

> It's unfortunate that MS IE doesn't supprot any of them but would that
> be a sufficient ground for dropping those styles?

I would say yes. There are some features not supported by IE that have
been kept in CSS 2.1, but the list style type features are less relevant
than most of them. If we could choose which CSS 2 features are implemented
next in IE, I would surely vote for position: fixed or generated content
much more than the new list-style-type values.

Besides, the list-style-type property is still poorly _defined_. It's not
at a suitable level of exactness. Not saying what happens after 'z' isn't
constructive. Moreover, when we have no adequate method for even
specifying that a particular _character_ (such as em dash) be used as a
list marker - which would appear to be one of the simplest features to
define and implement - it looks somewhat premature to add a few numbering
systems (which still cover just a subset of systems used in various
languages and scripts).

>  Besides, I don't see what practical reason there could be. I mean,
> if a particular list style is not supported by a browser, it's supposed
> to fall back (gracefully) to 'the default'.

That's a good point. On the other hand, by saying in a specification that
such features exist, you encourage authors into using them - and they will
then not consider the simplistic but robust method of using the markers
they like: put them into list item contents and use list-style-type: none
to suppress the browser-generated markers. This is often the practical
solution when the number scheme really matters.

-- 
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

Received on Sunday, 9 November 2003 19:14:16 UTC