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

Re: [media] proposed a11y TF letter on issue-152

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 22 Apr 2011 14:02:47 +1000
Message-ID: <BANLkTiknXEq2+nhQAFeKmg9KogOBYtTNpA@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: Eric Carlson <eric.carlson@apple.com>, Ian Hickson <ian@hixie.ch>, Sam Ruby <rubys@intertwingly.net>, "public-html-a11y@w3.org Task Force" <public-html-a11y@w3.org>
On Fri, Apr 22, 2011 at 1:14 PM, Mark Watson <watsonm@netflix.com> wrote:
> I would suggest a small change to replace the words 'However, we request'
> with the word 'with', so that the sentences run together and our proposal to
> withdraw 1-3 is somewhat contingent on the changes being agreed to proposal
> 4.

I do not think that any of the change proposals 1-3 are sufficient and
all of them are inferior to proposal 4, even as it stands now. I've
asked Eric about this, too, and both him and I are going to withdraw
our proposals, no matter whether the changes are applied now or
continue to be worked on in bugs.


> It's good that Ian is sympathetic to adding things exposed by media
> containers, but I don't agree we should be constrained by that: as I said,
> others (MPEG DASH) are looking to W3C to lead on these items and some (all?)
> of the proposed 'kinds' are really pretty straightforward and obviously
> useful.

Discussion is more productive than trying to force things. In the end,
what Ian says doesn't matter - what the browsers implement does. Eric
is supportive of this and IIRC so is Frank. That's the progress you
want - not stopping a solution for multitrack from going in because
not all the details have been sorted out yet.

Cheers,
Silvia.

> ...Mark
>
> Sent from my iPhone
> On Apr 21, 2011, at 7:48 PM, "Eric Carlson" <eric.carlson@apple.com> wrote:
>
>
> On Apr 21, 2011, at 7:15 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
> wrote:
>
> Are you following the discussions on the main list and on whatwg? Ian
> mentioned there that he'd be open to add it if media resources exposed it.
> We could just insist on this change. It seems this is the only breaking
> point.
>
> Will I then send off the email today as it was and we resolve it on the main
> list?
>
> Yes, I think you should send it in as planned.
>
> eric
> Sent from my iPhone
>
>
>
> Sent from my iPhone
>
> On 22/04/2011, at 2:40 AM, Mark Watson <watsonm@netflix.com> wrote:
>
>
> On Apr 20, 2011, at 7:43 PM, Silvia Pfeiffer wrote:
>
> I would personally think that we can resolve the 5 changes through the
>
> bug tracker and that they are not substantial to be solved before LC.
>
> They are "part of the plumbing" as John put it so nicely. But it is
>
> indeed a good question whether turning the 5 changes into bugs would
>
> be agreeable with other members of the group.
>
> I disagree that the "track kind" is "part of the plumbing". Whether you can,
> or cannot, discover the types of tracks available from a script makes the
> difference (for me at least) as to whether this multi-track support is
> useful or not.
>
> I would at least like to hear Ian's opinion on the "track kind" issue before
> agreeing that it can be dealt with as a bug, with the associated possibility
> that multi-track support goes into the LC draft without this feature. It's
> there for text tracks and I don't see any difference in rationale when
> considering audio and video tracks.
>
> ...Mark
>
>
> Cheers,
>
> Silvia.
>
>
> On Thu, Apr 21, 2011 at 12:28 PM, Sam Ruby <rubys@intertwingly.net> wrote:
>
> On 04/20/2011 09:00 PM, Silvia Pfeiffer wrote:
>
> We appreciate the extra time provided to us by the chairs to further
>
> discuss the submitted four change proposals and come to an agreement.
>
> There have indeed been lengthy discussions during the provided time
>
> frame and we have made great progress.
>
> Something to consider: think about what you could do if you had until May
>
> 14th...[1]
>
> The group has come to a consensus on which proposal to support. While
>
> some of our feedback on that change proposal has already been taken on
>
> board, there is still a list of 5 outstanding changes that need to be
>
> addressed for the specification text to be complete.
>
> One way to proceed is to see if that number can be reduced between now and
>
> Friday, and then to have a survey on the remaining items (asking for
>
> objections to INCLUDING and objections to EXCLUDING each change).  The
>
> results of the decision will affect what goes out in the Last Call.  The
>
> standard for revisiting the decision would be New Information or a Formal
>
> Objection.
>
> Another way to proceed is to open bug reports on each and continue to work
>
> on them until May 14th.  Changes over which there is WG consensus can be
>
> made during that time.  Changes that reduce consensus can be reverted[2].
>
> With the second approach, it still will be possible to raise issues and have
>
> these issues resolved in time for HTML5 (as in CR, PR, and Rec). What you
>
> gain if you go this way is a few more weeks to find WG wide consensus.  What
>
> you lose is the opportunity to get these changes into the spec in time for
>
> Last Call over objections should the chairs find that there to be stronger
>
> objections to EXCLUDING these changes than there is to INCLUDING these
>
> changes.
>
> At this point, the issue has been raised and Change Proposals have been
>
> written so the only way we will decide to close this issue and proceed with
>
> bugs is if we have Amicable Consensus to do so.  If anybody objects to such
>
> an approach, we will go with a survey.
>
> - Sam Ruby
>
> [1] http://lists.w3.org/Archives/Public/public-html/2011Mar/0759.html
>
> [2] http://lists.w3.org/Archives/Public/public-html/2010Sep/0125.html
>
>
>
>
>
>
>
>
Received on Friday, 22 April 2011 04:03:34 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:19 UTC