Re: css21 list-style-type dropped types

On Mon, 10 Nov 2003, Jungshik Shin wrote:

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

Checking the ISO FAQ I find
"2.2   Where can I find links to other international, regional or national
standardization bodies, or information about their standards?
Consult the World Standards Services Network, accessible via the ISO
Online home page. It contains links to international, regional and
national standardization bodies, including international and regional
organizations which develop standards in their specialized subject area,
in addition to their principal activity."
  http://www.iso.org/iso/en/faqs/faq-standards.html
The site mentioned there is
http://www.wssn.net/WSSN/
which has the document "International Standardizing Bodies"
http://www.wssn.net/WSSN/listings/links_international.html
which does not mention W3C. IETF is there. Unicode consortium is not.
This looks relatively simple to me: industry consortia are not
standards organizations.

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

Correct. But some of them are widely supported by browsers and provide for
replacements for HTML attributes, and these practical considerations
prevent dropping them, even though the definitions are not very mature.

> Why would some of them have to take a blame on behalf of others?

Because others are protected by practical considerations I mentioned.
It's not really fair, but we can't really be fair to property values.

Besides, one might ask whether the list-style-type property will really be
the way to go. It's a simple and easy to understand idea, which is
currently suitable for some limited tasks. But maybe the enhancements that
let authors (and users) specify different types of list item markers
should be based on a different approach, instead of just adding new values
to this ad hoc property.

To take a simple example, the CSS specifications seem to imply (by not
saying anything to the contrary and in their examples) that the
various numbers generated by most values of list-style-type do not contain
a full stop (period) character or anything else beyond the number. Most
browsers however include a full stop. Should we add a large set of new
values to cope with this, or should we take a different approach to the
whole business?

You're right, of course, in saying that the question at hand is about
dropping some values, not adding new values. On the other hand, with
respect to CSS 1.0, the values discussed are new, and CSS 2.1 is really a
successor to CSS 1.0 rather than to CSS 2.0.

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

I think this is the basic point where we disagree. I understand your
point, but I don't think CSS 2.1 is really being created to put pressure
on browser vendors. Rather, it's a move based on experiences on failed
efforts to create sufficient pressure.

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

I'm afraid authors mostly _do_ ask for such things. Besides, _all_ of CSS
should degrade gracefully, though we know it wasn't quite designed that
way. But for example, aural style sheet properties are being completely
dropped. They cannot possibly hurt browsers that never even tried to
implement them, and authors should naturally not ask for 100% guarantee
that they'd be available always and everywhere, even on aural browsers.

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

Received on Monday, 10 November 2003 05:09:28 UTC