W3C home > Mailing lists > Public > www-style@w3.org > November 2003

Re: css21 list-style-type dropped types

From: Tex Texin <tex@i18nguy.com>
Date: Sat, 08 Nov 2003 18:30:05 -0500
Message-ID: <3FAD7C7D.94564957@i18nguy.com>
To: "Jukka K. Korpela" <jkorpela@cs.tut.fi>
Cc: W3C Style <www-style@w3.org>, W3c I18n Group <w3c-i18n-ig@w3.org>


Thanks for the quick reply.
I embedded a comment below on the idea of standards being popularity driven and
features coming and going in a standard.
I appreciate that the CSS group is trying to be practical and cleaning up a
standard paves the way for future versions to better architected. I would love
to have that option with respect to character encodings!
But there is a down-side and I felt obligated to raise it.

The [DIN] reference in the web page I cited is a good reference for benefits of

With respect to the individual list style types, I would hope we don't need to
review one by one which should stay and which should go. If needed the i18n
group could comment on them. However, I don't want to bring additional work to
the group unless it is really needed. If it is needed, I would ask the style
group to make a formal request. 
(Nothing too elaborate, an e-mail will do.)


"Jukka K. Korpela" wrote:
> On Sat, 8 Nov 2003, Tex Texin wrote:
> > The section on list-style-type no longer references several international
> > styles.
> - -
> > They have been implemented by some browsers.
> A few, but CSS 2.1 apparently tries to cover CSS du jour as implemented by
> most browsers as counted by frequency of use, and a little more. This is a
> somewhat debatable move, but it has good practical reasons. In any case,
> deviating from the basic idea in some details tends to lead to confusion
> and could make CSS 2.1 lose its point and identity.

I guess it depends on what we mean by a standard. I thought it was a precise,
stable definition that we all attempt to implement to, in order to have the
benefits of portability, reliability, security, and a common understanding that
results in cost savings thanks to economies of scale, reduced training costs,
See http://www.xencraft.com/resources/stdsbenefits.html

On the other hand, if developers are supposed to define future releases by
placing bets on how the standard will change based on which features are
becoming popular and which aren't, and if companies strategize that by not
implementing features, or implementing them differently, that they can actually
drive further changes to the standard, well that's not really a standard- it's
a marketplace or an auction.

A frequency of use policy puts i18n (and WAI) features at a particular
disadvantage, since first implementations of products often do not include i18n
features, and the user community for these features may be smaller so will
always be less popular or frequent. If such a policy is in writing somewhere, I
would be glad to know it and raise formal objections to it.

On a separate note, it might be better to leave the features in and mark them
as deprecated then to remove them altogether. It helps people understand
features or behavior they might stumble upon when looking at old code or even
implementing something new and accidentally invoking a deprecated feature.

Doing so at least relieves implementers that tried to fully implement w3c
standards of the burden of having to point to different versions of standards
in their documentation.
"This feature came from this spec ...TR/css2, and was deprecated in TR/css21.
this feature came from this spec ..TR/css21, and was deprecated in TR/css3. 
this feature came from this spec TR/css3, and was deprecated in TR/css4.

> > Were these intentionally dropped?
> Most probably.
> > [3] http://www.w3.org/TR/CSS21/changes.html#q51
> But it probably wasn't intentional to omit this from the list of changes.
> You might have some arguments in favor of restoring lower-greek, which
> is supported e.g. by Mozilla at least from version 1.2 onwards.
> Luckily they have restored lower-alpha and upper-alpha, which were dropped
> in an earlier CSS 2.1 draft. It would have been a bad idea to omit them,
> since they, and not the synonyms lower-latin and upper-latin, are
> supported by IE. However on the same grounds it would make sense to drop
> the latter. It's worse than futile to give authors two alternatives when
> we know that one of them is supported by the browser that is by far most
> popular today and in the near future and the other is not, and there are
> probably no examples of the opposite problem. It is true that -latin is
> more _logical_ than -alpha for referring to the Latin alphabet, but such a
> matter of principle should be ignored here. After all, the names of CSS
> properties and values don't really constitute a coherent, logical set
> anyway.
> --
> Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

Tex Texin   cell: +1 781 789 1898   mailto:Tex@XenCraft.com
Xen Master                          http://www.i18nGuy.com
XenCraft		            http://www.XenCraft.com
Making e-Business Work Around the World
Received on Saturday, 8 November 2003 18:30:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:10 UTC