[whatwg] Removing versioning from HTML

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