- From: Tex Texin <tex@i18nguy.com>
- Date: Sat, 08 Nov 2003 18:30:05 -0500
- To: "Jukka K. Korpela" <jkorpela@cs.tut.fi>
- Cc: W3C Style <www-style@w3.org>, W3c I18n Group <w3c-i18n-ig@w3.org>
Jukka, 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 standardization. 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.) regards, tex "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, etc. 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