- From: Jungshik Shin <jshin@i18nl10n.com>
- Date: Mon, 10 Nov 2003 14:23:47 +0900 (KST)
- To: "Jukka K. Korpela" <jkorpela@cs.tut.fi>
- Cc: W3C Style <www-style@w3.org>, W3c I18n Group <w3c-i18n-ig@w3.org>
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) Jungshik
Received on Monday, 10 November 2003 00:24:04 UTC