W3C home > Mailing lists > Public > public-html@w3.org > August 2011

Re: HTML.next and Rechartering

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Fri, 12 Aug 2011 17:37:46 -0500
To: Aryeh Gregor <ayg@aryeh.name>
Cc: John Foliot <jfoliot@stanford.edu>, public-html@w3.org, public-html-request@w3.org, Sam Ruby <rubys@intertwingly.net>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Message-ID: <OF80F7A87D.31F1EC79-ON862578EA.007B430A-862578EA.007C4EB9@us.ibm.com>

I am reluctant to engage in this conversation as I think we are putting the
cart before the horse and because this is a hypothetical discussion.
However, if we do not address accessible media in HTML 5 then we are going
to have a world of hurt when the new FCC Regulations come out next October.
While we don't always agree on things we are all in the same boat on this.
This would not be good.

I would be more apt to leave all the media stuff until 6 for this reason,
if we don't get the accessibility issues addressed in 5, and leave it up to
the plug-in providers.

So, I would opt for 2) or 3) on this.

What exactly is the hold up on the APIs? I had been following some of the
discussions on the IAccessible2 list that Silvia contributed to.



Rich Schwerdtfeger
CTO Accessibility Software Group



From:	Aryeh Gregor <ayg@aryeh.name>
To:	John Foliot <jfoliot@stanford.edu>
Cc:	Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Sam Ruby
            <rubys@intertwingly.net>, public-html@w3.org
Date:	08/12/2011 04:57 PM
Subject:	Re: HTML.next and Rechartering
Sent by:	public-html-request@w3.org



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.






graycol.gif
(image/gif attachment: graycol.gif)

Received on Friday, 12 August 2011 22:38:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:27 UTC