- From: Aaron Boodman <aa@google.com>
- Date: Sun, 9 Aug 2009 09:50:35 -0700
On Sun, Aug 9, 2009 at 9:21 AM, Tab Atkins Jr.<jackalmage at gmail.com> wrote: > A feature that is not widely supported is a feature we authors can't > depend on. ?If we're lucky, we can put in some extra effort to work > around the lack and still deliver a decent experience. ?If we're not, > we simply don't do what we wanted, or deliver something inferior that > relies on technologies we *can* rely on. Clearly, but how does limiting the things that vendors can work on affect this one way or the other? I think there is an assumption that vendors will implement something solely because it is in the spec. This is not true, and can be verified by looking at history. Just yesterday, Jonas mentioned that Mozilla was less than enthused about implementing the <bb> tag from HTML5. Microsoft recently suggested they weren't happy with some of the new tags introduced in HTML5. And Ian has repeatedly said that he is not interested in writing fiction: he will only spec something that vendors will implement. > The idea behind pushing something to the next version is that it gives > implementors time to catch up to the spec and converge on what they > support. ?This is good for people like me. ?^_^ I don't think implementations will ever "catch up". Partial mixed support is the natural state of a system where there are several completing implementations, and it is healthy. Some ideas aren't good. We shouldn't halt work on other things waiting for everyone to implement every idea. That is a recipe for stagnation. Instead, let some ideas die on the vine, and let growth occur in other places. If authors want a vendor to implement something, they will still be able to put pressure on the vendor to do that. In fact, that is exactly what happens today. Ian frequently says "if you want that, please go talk to the vendors". > In the meantime, there's certainly nothing preventing someone from > exploring an idea. ?The fact that it won't make it into a spec *yet* > doesn't mean you can't still discuss and refine it, or implement test > versions of it in js, or anything else. In theory this is true. In practice, there is a lot of nice infrastructure setup at WhatWG that would be nice to reuse. Plus the WhatWG mailing list has become a very nice place for vendors to come together and discuss browser futures. What I am suggesting is that there should be no limit to the number of "micro specs" in a draft state concurrently at WhatWG. On Sun, Aug 9, 2009 at 9:29 AM, Adam Shannon<ashannon1000 at gmail.com> wrote: > If we never cut things off then the spec will really never be finished > before 2020. Why does this matter? At the end of the day isn't the goal to have the largest number of interoperable features? Consider one reality where we try to limit what HTML5 is, and it has n features, and we get an average of n*.9 features interoperably implemented on browsers by 2020. Consider an alternate reality where we let things be a bit more open-ended and we get n*1.5*.9 features interoperably implemented by 2020. Isn't the second reality better? - a
Received on Sunday, 9 August 2009 09:50:35 UTC