- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 08 Apr 2010 09:41:28 -0400
- To: Mikko Rantalainen <mikko.rantalainen@peda.net>
- CC: www-style list <www-style@w3.org>
On 4/8/10 8:51 AM, Mikko Rantalainen wrote: > I understand that the time window for feedback would be much shorter but > I fail to see actual problems caused by this change. It's not like I'm > proposing no time for feedback but instead only a couple months instead > of years (in practice). No, your proposal cuts the time to pretty much 0. > Implementors are already independently selecting which features they > will even try to implement. A spec that describes some nice to have > feature that is not implemented anywhere does not matter. I think that > if a feature is badly conceived, either the implementors will notice > that even before trying to implement the said feature or they will try > to implement the feature and hit the problem during the implementation. > In the latter case, it would probably be the case regardless of longer > Last Call phase. I'm having the opposite concern: a feature that implementors propose that's badly conceived. Your proposal has no way for anyone else to review such features. > I honestly believe that Last Call could be dropped altogether. Just keep > the requirement that there must be at least two independent > interoperable implementations before a feature can reach Recommended status. That's not acceptable, since it means that any two implementors can just make a feature Recommended in spite of what anyone else (including other implementors or other constituencies) wants. >> Given you lack of a review period, this effectively allows implemeters >> to implement whatever they want: just propose it the day before feature >> freeze, and then no one else can suggest changes to it. > > They can already do that today. As a matter of fact, they can't. After they propose it, there's a review period for public comment. That's the whole point. > However, such tricks cannot be used to > achieve the Recommended status unless another independent implementor > decides to also implement that feature. Sure, and we have examples of that right now where poorly-conceived and underdefined features (text-overflow:ellipsis, display:run-in) would have been Recommeded per your criteria today. > If that happens, I believe that > the feature is good enough (and specified with enough detail) to be > Recommended. I see nothing in your proposal that ensures the "specified with enough detail" aspect other than completeness of the test suite. I also see no provisions for ensuring completeness of the test suite. > I agree that this is a problem. For example, the HTML5 wouldn't be in > the shape it's today if Ian Hickson weren't the editor. Yep. > The editor makes > all the difference and the editor must have enough time to do his work. > Hopefully somebody pays for that work, too. That's nice if it happens, yes. But not all specs are giant balls of twine that require a single editor, and smaller editing jobs can in fact be done on a semi-volunteer basis (at least as far as producing a first draft). > >> 2) Lack of implementor time to implement all the things that people >> care to think up all at once. > > This is the most important part in my mind. My point is that > implementors are already independantly deciding which parts they will > implement. Sure. > I guess I'm suggesting more power to implementors on deciding which > parts get Recommended No, you're suggesting more power to early-adopter implementors on deciding exactly how the things that are "Recommeded" work and look. This biases toward fast implementation in a way that's as easy as possible in your particular codebase without worrying overmuch about the long-term health of the web. I think we have quite a bit of bias in that direction already, and don't need more. > It would be great if a feature couldn't receive Recommended status > without a test suite testing every part of the feature. However, I > understand that such test suite requires really much work. If the test suite is not comprehensive then a reasonable review period is a must, no? > If I have to choose between a feature that has been already implemented > interoperable and a feature that has test suite and hopefully gets an > implementation in the future, I will rather take the former. How do you know it's "interoperable" without a test suite? > Unfortunately, I don't have enough time (I don't get paid for that in my > job). As it happens, neither do I... Nor do a number of other people that have contributed to the CSS specs and test suites. -Boris
Received on Thursday, 8 April 2010 13:42:06 UTC