Re: css21 list-style-type dropped types

On Mon, 10 Nov 2003, Jukka K. Korpela wrote:

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

  That's exactly what I though you had meant. Perhaps, my use of
'have to' was not such a good way of expressing that.

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

  Actually, my point was not only that _all_ of them have been supported
but also that they've been supported for almost (if not over) three
years (i.e. not just since 1.2 released in late 2002 - as you confused
- but since 0.6(?) or something like in 2000). Why am I emphasizing
that? Because other developers has had time (3 years or longer) and
implementing them is not a rocket science (a lot easier than other
sophisticated but a lot more important features of CSS 2).

> the W3C is not a standards organization.

 I'm wondering what your definition of standard organization is. Is IEEE
one? How about IETF and Unicode consortium? It seems that in your view,
only ISO and its national counterparts count as standard organizations.

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

  I'm not sure what you meant by 'less relevant', but I would use
it 'against' you.  If it's not an important part of CSS 2.1
(architecture), which I believe is true, why would CSS WG bother to change
the spec instead of just leaving them alone as they're in CSS 2 just
for the sake of the stability of the specification if not for anything
else? Also, the fact that CSS WG kept some features not available in MS
IE indicates that there's room for other criteria different from your
'frequency and popularity' criterion (or the basic idea of making what's
implemented at the moment as 'de jure' instead of just being 'de facto').

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

  I'm likely to vote for the same as you do (if I were forced to
choose between two).  Again, the fact that your favorite wish item is
not list styles in question can be used to counter your argument.  If it's
a minor issue in your opinion, why would you actively touch the
spec? Instead of keeping using your words in my favor, I'd ask you
a question.  Which one do you think it's more likely to be implemented
in terms of the easiness of the implementation (one important practical
consideration)? If I ask an MS engineer to support list styles not
currently supported in MS IE, it's very unlikely that (s)he would cite
a technical difficulty as a reason for not supporting them. With your
top item in the wish list, that answer (e.g. it's a major undertaking,
it would change our architecture significantly, etc)  is more likely to
come back, isn't it?

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

  Obviously, this problem is common for all list-style types whether
they're kept in CSS 2.1. or not. So, I don't think dropping several of
them in CSS 2.1 or keeping them all would make any difference at
all in this regard. Why would some of them have to take a blame on
behalf of others?

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

  Note that the issue at hand is NOT adding  BUT dropping them for
no practical merit. As you know too well, I'm not arguing for adding NEW
list style types (just because Mozilla, Opera, and Konqueror/Safari have
supporte them) but for keeping what has been there for a few years. If
they had NOT been there (CSS 2) in the first place, I'd agree that it's
premature to ADD them to CSS 2.1 (knowing what 2.1 is for). However,
I don't see anything premature in saying that they have to be KEPT in
CSS 2.1 as they're in CSS 2.

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

  Yes, it would encourage authors into using them and at the same time
encourage(put pressure on) browser developers into supporting them. That's
why I'm making a case for keeping them in CSS 2.1. Otherwise, why would
I bother? :-) However, UNLIKE other features likely to take significant
development resource to implement (and unlikely to be implemented
'soon'), it's rather easy(almost trivial) to support them (with the
problem of ill-definedness understood).  To me, that's a very important
__practical__ consideration.

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

  Again, your argument is not specific about several styles dropped but
is true of all generated list styles. As such, I'm afraid it doesn't
consitute a rationale for dropping only some of them. If I follow your
logic, all of them (not just some of them) had better be dropped because
your simple and robust (not that robustness is very important here because
those authors using them are willing to accept the graceful degradation.)
method can be used in place of _any_ list style(e.g. lower-alpha,
upper-latin).  Obviously, you wouldn't, would you? Besides, your method
may be simple and robust, but is that in line with the spirit of CSS?
With that method, every time you want to change the way list contents are
'numbered', you have to touch the 'content' instead of the stylesheet.

My point here is that authors (who wish to use them) don't ask for 100%
guarantee that they'd be available always and everywhere(that is, I'm
not talking about cases where using the particular numbering system is
critical). As is the case of many other features of CSS and other web
standards, they're aware (if not, they should be) that not all features
are supported by all 'devices' so that they learned (should learn if
not already) to make their pages degrade without information loss.
(I guess that employing some CSS 2 features would result in pages that
can't be navigated nor viewed when 'rendered' by devices not supporting
them. For these features, applying frequency/popularity criteria would
be acceptable given the purpose of CSS 2.1) In this particular case,
authors using them do so not so because they want them so badly but because
it's 'nice' to have them.  While doing that, they'd hope to keep their
pages compliant to the standard as much as possible. Removing some list
styles would all of sudden make their stylesheets not compliant to CSS 2.1
(while having been complaint to CSS 2), which does only harm to CSS as a
standard (if you agree that it's a standard) for no overwhelming reasons
(that could be quoted for other CSS 2 features dropped in CSS 2.1)


Received on Monday, 10 November 2003 00:24:04 UTC