- From: Sam Ruby <rubys@intertwingly.net>
- Date: Fri, 22 Apr 2011 20:49:42 -0400
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- CC: Mark Watson <watsonm@netflix.com>, Eric Carlson <eric.carlson@apple.com>, Ian Hickson <ian@hixie.ch>, "public-html-a11y@w3.org Task Force" <public-html-a11y@w3.org>
On 04/22/2011 05:50 PM, Silvia Pfeiffer wrote: > On Sat, Apr 23, 2011 at 2:36 AM, Mark Watson<watsonm@netflix.com> wrote: >> >> On Apr 21, 2011, at 9:02 PM, Silvia Pfeiffer wrote: >> >> 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. >> >> I don't mean to force anything and maybe I am mis-understanding the HTML WG >> process (which is anything but simple), but I think we should avoid the >> situation where the multi-track solution goes out for LC with a significant >> requirement not addressed (and btw, this requirement has been there from the >> beginning and is properly addressed in Change Proposals 2& 3). >> My opinion is that if we shipped the spec to LC with a multi-track solution >> that didn't meet the track discoverability requirements, this is evidence >> that despite our best efforts we weren't able to converge on a solution in >> time. It would be better to leave it out and work on it during Last >> Call. Remember that we were all skeptical that we could get this done in >> time, but we agreed to try. >> The other four issues all have work-arounds, but the kind issue does not. >> What's important is to me whether there's a general consensus. If the people >> with opinions on this say it's no big deal and they're reasonably confident >> we can work it out as a bug, then fine. But last I heard this was not the >> case as there was a difference in principle as to whether W3C should define >> these "kind" values itself for audio and video. >> ...Mark > > Hi Mark, > > It's up to the chairs now how to deal with this. Maybe they can make a > survey that has proposal 4 accept/reject, and proposal 4 plus "kind" > attribute accept/reject as two alternative change proposals, while > requiring to register the rest as bugs. That way we can at least move > forward and have the multitrack in the spec. The alternative is not to > have any multitrack in the spec (as you are suggesting) and that is > clearly not acceptable from an accessibility requirements POV. The chairs are requesting an actual Change Proposal for anything that people would like to have surveyed. More information in this post: http://lists.w3.org/Archives/Public/public-html/2011Apr/0533.html > Cheers, > Silvia. - Sam Ruby
Received on Saturday, 23 April 2011 00:50:11 UTC