- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Fri, 22 Apr 2011 14:02:47 +1000
- 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