On Fri, 14 Aug 2009 12:01:31 +0100, Ian Hickson <i...@hixie.ch> wrote:
On Sun, 9 Aug 2009, Aaron Boodman wrote:
I frequently see the comment on this list and in other forums that
something is "too late" for HTML5, and therefore discussion should be
deferred.
I would like to propose that we get rid of the concepts of "versions"
altogether from HTML. In reality, nobody supports all of HTML5. Each
vendor supports a slightly different subset of the spec, along with some
features that are outside the spec.
This seems OK to me. Instead of insisting that a particular version of
HTML is a monolithic unit that must be implemented in its entirety, we
could have each feature (or logical group of features) spun off into its
own small spec. We're already doing this a bit with things like Web
Workers, but I don't see why we don't just do it for everything.
Just as they do now, vendors would decide at the end of the day which
features they would implement and which they would not. But we should
never have to say that "the spec is too big". If somebody is interested
in exploring an idea, they should be able to just start doing that.
I agree in principle.
I wholeheartedly agree with all the reasoning, but there are issues.
From an implementor's point of view it is much harder to implement and
keep up with a mutating specification. During implementation a stable spec
is preferred.
So versioning will allow an implementor to decide to implement the latest
stable version of some spec, while work proceeds on a newer one.
And when I refer mutating specification I'm not referring to the whole
html5 spec, but each separate component, like web storage, web workers,
video, etc...
Currently, because specs are being edited and might take a while to get to
CR, we have different implementors implement different parts of the
specifications, and then meanwhile the specification mutates and
implementors have to waste time updating their implementation which could
have been right from the start. I understand that implementation feedback
is necessary, but this is not very optimal.
After a spec gets to CR it can't just mutate out of thin air, hence
forking it into a new version is the way to go.
Example: Gecko, Webkit and IE have localStorage, but the spec changed a
few days ago to allow structured storage.
