Media Subteam Minutes for 13 April

Minutes from today's HTML-A11Y Task Force Media Subteam teleconference are
provided below in text. They are also available as hypertext at:

http://www.w3.org/2011/04/13-media-minutes.html 
 

   W3C

                                                           - DRAFT -

                                                       HTML-A11Y telecon

13 Apr 2011

   See also: IRC log

Attendees

   Present
          janina, +1.650.862.aaaa, +44.154.558.aabb, Judy, +1.510.367.aacc, Eric, John_Foliot, silvia, Frank, Bob

   Regrets
   Chair
          John_Foliot

   Scribe
          janina

Contents

     * Topics
         1. Identify Scribe
     * Summary of Action Items
     __________________________________________________________________________________________________________________

   <scribe> agenda: this

Identify Scribe

   <scribe> scribe: janina

   Judy: Do we have all proposals sufficiently elaborated and we're now focussing on #4 because we still prefer it? Or
   just because it's the only one sufficiently elaborated?

   <silvia> http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Change_Proposals_Summary

   Silvia: OK, Let me summarize ...
   ... We do have a summary page. Creating it required a more in depth look at Ian's proposal.
   ... I put my concerns in a section called '"Silvia's Notes"
   ... So, I'm asking what our opinions are

   JF: I'm noting you mention some attributes are missing, i.e. seeking. Can you say more?

   Silvia: Yes, jumping to a specific time, either via user control or via js

   Eric: The attribute relates to whether a seek is in progress, and don't think it's particularly helpful\
   ... We can certainly seek via the controller

   Silvia: We have had additional discussion since Monday, including responses from Ian. There are other attribs I'm no
   longer looking for
   ... These are details on this proposal.
   ... If we decide to go with this proposal, we want to make sure the details are consistent with what we want.

   Frank: Think this is a good way to proceed. I have some concerns about complexity, though.

   JF: Any deal breaks so far?

   Frank: With #4?

   Sean: A few issues around exclusive, but mostly OK

   Frank: Yes, I think it maps well to what we have. We need small bug fixes, not major rewrites.

   Silvia: May I propose a way forward?
   ... If we're all happy--Frank, Eric, Sean, myself--can we pull our proposals and work on fixing #4?

   Frank: Yes. My proposal was around exposing audio tracks. #4 does that.

   Silvia: Yes, it incorporates yours.

   Sean: I'm also prepared to withdraw mine. I believe I can achieve what I need with #4

   Eric: I also agree. Though, I think we need to make it clear that there's more work to do to make #4 sufficient.

   JF: I've not seen feedback from Opera. Anyone know how Phillip is with this?

   Eric: My impression is generally supportive, based on list mail.

   JF: Other question is that we continue to indicate status on this. Can we report that we are coalescing around #4,
   though it needs additional work?

   Eric: I think it makes sense for the authors of the other proposals to send email saying that.

   Judy: I don't think it hurts to communicate additionally.
   ... We should also make sure to check with other key people.

   Silvia: Think we should summarize the sticky points in an email to the list. Don't think we need to withdraw our
   proposals just yet.

   <silvia> http://www.w3.org/WAI/PF/HTML/wiki/Media_TextTrack_Issues

   JF: Sean, anything to discuss?

   Sean: Most of my issues ongoing in email ...
   ... It all seems to be coming together

   Eric: I'd like us to discuss audio/video/text tracks issue

   <frankolivier> Sound is dropping out for me on the phone; Anybody else having this issue?

   Eric: I probably don't have the terms off the top of my head right now ... inband, exclusive, etc
   ... Some have proposed a single "tracks" attrib

   Sean: Understand you can have one video in the track, but doesn't prevent you from other videos, you need to use
   multiple video elements to get at them
   ... My preference would be for a single API to find them, identify them, and switch them on and off
   ... That was our TPAC approach, and I think it was simpler.
   ... Currently, it's all there, but too complex

   Eric: Agree
   ... Don't think exclusive on video makes sense
   ... Agree that's it's useful to have a single way to identify everything

   Frank: How does this concept work?

   Eric: Like on the element restricted to text tracks, but able to enumerate all video and audio

   Frank: Is that a big change?

   Eric: Yes, it would cut down from 3 to 1 the attribs on media element

   JF: How do we move that forward?

   Eric: We need to discuss it further in email. Either we convince everyone else--or not. But, if we agree, and it's not
   in the spec, then we need a change proposal on this.

   JF: Is there a bug filed on this?

   Eric: No, but don't think it makes sense to file a bug at this point.

   JF: My concern is timing

   Judy: I think you're asking about process specifically with respect to multitrack?
   ... I think a number of people consider this critical for last call
   ... All I can say is keep refining the proposal, and on expedited work on this, and let's not focus on process
   particularly

   JF: So, we cut from 3 to 1, but add one other?

   Eric: Yes
   ... Though we seem to agree we can live with what's there now, though we prefer the change we're proposing

   Sean: Understand what we have is sufficient on this to take us through the April 22 deadline. If we go further, we do
   it as a CP

   Eric: Yes, it's a polishing thing

   Judy: Now I'm confused ....
   ... Might we not end up with something we're unhappy with?
   ... In other words, why not offer it ahead of April 22

   Eric: It's perhaps not worth falling on our sword

   <judy> s/something that we're unhappy with/something that would break a bit when it's cleaned up in the next LCWD/

   Eric: I think we should push on this, but we're OK either way

   Judy: If not accepted early, wouldn't it break implementations if tried later?

   Eric: Yes

   Judy: So it's worthwhile to work hard on getting an optimal proposal now

   Eric: Yes, which is why we need to take this discussion back on list

   JF: Not on our agenda, but we have Silvia's wiki page on text format and multiple format ...
   ... I was expecting this is a non issue? That we would see support for multiple formats in browsers? Yes, no?

   Eric: Are you asking if we need to define a single (or multiple) format?

   JF: I got the impression we don't need to specify a file format in track?
   ... I'm unclear where the discussion is on this, this

   Sean: The issue is whether or not track elements supports src as a sub, so you cannot put src inside it.
   ... So future compatibility, etc., I believe we need to allow a source selection algorithm
   ... We did agree to take this up outside of Issue-152

   JF: So should we be taking this up? Or ddo we finish 152 first?

   Sean: We should finish 152, but I don't see anyone disagreeing on multiple formats

   JF: So is it OK as an LC issue?
   ... So we can still submit a CP ...

   Sean: I'd like to see that

   JF: I would as well. Anyone disagree?

   Eric: I agree with it

   Frank: I also

   <silvia> I also

   Bob: Also I

   <silvia> captured in http://www.w3.org/WAI/PF/HTML/wiki/Media_TextTrack_Issues for now

   JF: Anyone willing to take this up?

   Sean: Silvia would be the logical person. If not she, I'll do it.

   <JF> Silvia, would you be prepared to take that wiki page and advance it to the mailing list as a CP for the spec?

   <JF> we seem to have un animity on the proposal on this call

   <silvia> Can it wait until we've got issue-152 out the door, so after 22nd or do we want to start this before?

   <silvia> in any case, we can put a bug in the tracker

   <JF> I think we would like to have this in the last call document, so likely before the 22nd

   Judy: Is this a clarification of an existing issue or proposal? I'm concerned this not be seen as something new, if it
   is indeed a clarificationon an existing issue or proposal

   Sean: My understanding is that this part of an old bug of ours that fell out
   ... So it's a corollary of our actions on this

   <silvia> do we want to attack all the changes on the wiki page together or just the multiple formats issue on <track>
   elements?

   Judy: Mainly concerned how this is going to be presented. I'm now understanding we've worked on this before

   <Sean_> just the multiple formats issue. And to state that this is part of making the spec format neutral

   Judy: Ian almost got it into his proposal? Something like that?

   <silvia> Sean: so in your eyes this is a stumbling block on accepting the Controller as a solution for issue-152?

   JF: This was when we were discussing SRT (WebVTT); and TTML, etc
   ... Our guidance was support them all

   <Sean_> No this is unrelated to 152

   <JF> Silvia, we are trying to figure out how to ensure we get this: "The proposal is therefore to implement the same
   mechanism for <track> elements as we have for <audio> and <video> elements: namely to use the <source> element for
   format selection. "

   Janina: The process point is that this is what we came to a decision on back when we were discussing WebSRT (now VTT)
   vs TTML, etc. It's not new, but the spec isn't saying how to get it right

   <silvia> hmm, so do we have another bug that we could attach this so it is a pre-LC? I think it may be hard to still
   push this in before the deadline...

   <Sean_> [Bug 11207] Make track element additions technology neutral

   <Sean_> http://www.w3.org/Bugs/Public/show_bug.cgi?id=11207

   Sean: When we took out the specific references to WebSRT, nothing replaced that text to include the ability to do this.

   Judy: Thus, the bug isn't actually fixed

   <judy> Judy: when the srt references were taken out at our request, it left a gap on ability to express multiple
   format; therefore a bug that is marked as "resolved fixed" no longer is. we offer the following correction to that gap.

   But, that would mean post last call

   <silvia> so for the record: I'd be happy to just have it added as a bug right now and start discussions on list - I
   think we may be able to resolve it in this way, too

   <silvia> yes, it would mean post LC, but it may just get support from everyone because it stops prefetching

   <silvia> ups :)

Summary of Action Items

   [End of minutes]
     __________________________________________________________________________________________________________________

-- 

Janina Sajka,	Phone:	+1.443.300.2200
		sip:janina@asterisk.rednote.net

Chair, Open Accessibility	janina@a11y.org	
Linux Foundation		http://a11y.org

Chair, Protocols & Formats
Web Accessibility Initiative	http://www.w3.org/wai/pf
World Wide Web Consortium (W3C)

Received on Wednesday, 13 April 2011 23:26:23 UTC