[whatwg] Removing versioning from HTML

On Sun, Aug 9, 2009 at 11:50 AM, Aaron Boodman<aa at google.com> wrote:
> 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.

Certainly, but the spec gives some nice direction.  Nobody implemented
the new <input> types, frex, until someone wrote it up; now Opera has
some decent support for it, while Webkit is starting support.  Aiming
at a target, especially one that you know other people will probably
also be aiming at, is a lot easier than coding up a new feature that
you just dreamed up.

>> 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.

Not completely, sure.  But they'll get closer.  And we certainly won't
wait for everyone to implement everything - the "2022" date that keeps
getting bandied about was Ian's estimation of when complete
conformance from 2 browsers would first happen.  HTML6 will start
*long* before that.  Giving people a bit of breathing room, though,
and a static target to code towards, helps out.

> 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".

Agreed.  However, using *only* author feedback to direct browser
implementors seems insufficient when we can also direct it in a useful
manner by the spec.

>> 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.

Nobody's preventing that sort of discussion, even if Ian says "Not for HTML5".

> 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?

That reality is fantasy, though.  ^_^  The rate at which an
implementor can code is independent of the number of features that are
in the spec.  Increase the number of features (and assume some
reasonable distribution of interest among the features) and the % of
them that are interoperably implemented, especially within a given
time frame, will drop.

There's clearly some optimizing to be done - it's silly to spec only
one thing at a time and wait for everyone to implement it, but an
unbounded spec size is also bad.  Ian's charting a course that already
leans heavily into the "lots of features" side of the debate, and I
disagree that pushing it further in that direction will necessarily
help interop.

~TJ

(Imo, we are getting *way* too meta about the whole thing lately.
Meta is rarely a good thing...)

Received on Sunday, 9 August 2009 10:34:07 UTC