Re: HTML.next and Rechartering

On Fri, Aug 12, 2011 at 1:57 PM, John Foliot <jfoliot@stanford.edu> wrote:
> I wonder how everyone would feel if instead of "accessibility" in that
> statement, you replace it with the word "security":
>
>        "HTML5 does not define any mechanism for authors to include security
> requirements for 'foo' elements, but it is expected that HTML6 will do so."

The Process requires that the only features that can make it into a
REC are ones with two interoperable implementations.  If at the time
we want to progress to PR, video and audio themselves are
interoperably implemented, but accessibility APIs for them are not,
then we can't put the accessibility APIs in the standard.  In that
case, either 1) we put media stuff in HTML5 but push off accessibility
to HTML6, or 2) we push off all media stuff to HTML6 (!), or 3) we
delay REC for some indefinite period while we get interoperable
implementations.  (2) seems crazy, so it's a choice between 1) leave a
feature only partially defined in HTML5 or 3) delay REC until it can
be fully defined.

So as a rule, for any given feature that's not implemented fast
enough, we can either push off REC until it's implemented or we can
push it to HTML6.  If people think particular features need to be in
HTML5 and not HTML6 for whatever reason, then you'll want to delay
REC.  As I've made it clear before, I think the entire idea of
versioned standards is undesirable and don't care about the contents
of anything other than the latest Editor's Draft.  Thus I'm entirely
neutral on the question of which version number gets which features.
I'm just pointing out that we *do* have the option of leaving key
things undefined in HTML5 if we want to get to REC quicker.  We also
have the option of delaying REC.

None of this has to do with the importance of the features.  CSS2.1
left absolutely essential things undefined, like table layout, so that
it could progress to REC.  The point is if they're not interoperably
implemented, however important or unimportant they are, you can't have
them in a REC.

All that said, from what I've seen, it seems likely that we'll have
interoperable implementations of the media accessibility stuff by the
time there's any possibility of progressing to PR, so I don't think it
will be an issue in this specific case.

> I wonder how Google's security officers (or Mozilla's, Opera's or Apple's)
> would feel about that?

As always, I do not speak for Google.  I haven't discussed this with
anyone, and my opinions have nothing more to do with what Google's
security officers think than anyone else's.  (Supposing there were
such a thing as Google's security officers, or that they had any
opinion on what goes into which standard.)

> Would they *really* want to launch a product/service
> with a known security defect in it?

That's irrelevant, because browser implementers are not going to use
anything other than the latest Editor's Drafts unless they want to
introduce bugs.  They aren't going to use the REC, so it doesn't
matter what's in the HTML5 REC vs. HTML6.  If they want to implement
media accessibility and it's in HTML6 rather than HTML5, they'll use
HTML6.  In fact, at least two browser implementers will have to
interoperably implement each feature *before* HTML5 can go to PR, so
they can't possibly be using RECs to write the features.  What winds
up in HTML5 vs. HTML6 is essentially academic from a technical
perspective (as opposed to IPR etc. perspectives) except to the extent
that it determines what people will be confused about when they
erroneously look at HTML5.

Received on Friday, 12 August 2011 21:56:40 UTC