HTML Weekly Teleconference

14 Nov 2013


See also: IRC log


WayneCarr, Shenzhen, Adrian_Bateman, Glenn_Adams, Arnaud_Braud, Jonathan_Jeon, mark_vickers
cyns, cyns_, MarkS, travis


<paulc> trackbot, start meeting

<trackbot> Date: 14 November 2013

<paulc> We are trying to get the conference setup with a polycom. Please be patient.

<acolwell> paulc: I'm assuming this channel be the one used for all html-wg proceedings? The wiki states #html-media

<paulc> I will fix the wiki,

<paulc> The teleconference code with be HTML (4865) once we are setup.

<MikeSmith> trackbot, start meeting

<trackbot> Meeting: HTML Weekly Teleconference

<trackbot> Date: 14 November 2013

<glenn__> mikesmith: i took care of it

<paulc> http://www.w3.org/wiki/HTML/wg/2013-11-Agenda

<Eliot> http://www.w3.org/wiki/HTML/wg/2013-11-Agenda

<Eliot> http://www.w3.org/wiki/HTML/wg/2013-11-Agenda

<acolwell> paulc: I'm getting "The conference is restricted at this time" when I try to join the call.

<ddorwin> acolwell: discussing it now

<acolwell> ddorwin: ok.

<ddorwin> …MikeSmith is looking into it I believe.

<ddorwin> Starting to discuss agenda.

<MikeSmith> acolwell, I can skype you in from my laptop for now if you want

<MikeSmith> honestly the sound quality from the polycoms in these big rooms is close to useless anyway

<ddavis> acolwell: Someone else was able to dial in. Please could you try again? The code is 26631 (CONF1)

<acolwell> adrianba: hi

<paulc> All MSE LC bugs: http://tinyurl.com/lfq3scr

<cyns> scribe: cyns

MSE last call bug discussion and moving to CR

PC: 23663 resolved fixed

<ddorwin> acolwell: you're breaking up. You may want to type a summary

<acolwell> made proposed text changes

<ddorwin> acolwell: We can't really hear you

<paulc> actual change: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23663#c2

<acolwell> provided links to discussion about primer and preference for algorithmic text instead of duplicate informative text

PC: updated 2.4.3 with changes proposed in comment 1

AB: we talked about this on the last conferece call and the conclusion was that in general this was a duplicate request of the ones for an MSE primer. The spec is currently focused on what is needed to implement MSE, and we've asked for volunteers for an authoring guide
... this bug is for more details on how to use API, we still have that request pending. Aaron made a small change to clarify

PC: Aaron has implemented the chagne that was previously agreed upon. response to comment is that we need a volunteer

CC: I am considering volunteering.
... we also talked about where it would be. is www.webplatform.org the right place?

<cyril> http://www.webplatform.org/

PC: webplatform.org is a project in w3 to document as much of web platform as possible. anyone can supply documentation

EG: we would welcome that contact on webplatform.org

PC: Eliott can help you get started. I know you were worried about how much work. On webplatform.org, you can start an outline and crowdsource the rest.
... only outstanding bug is 23619

<paulc> Bug 23169 - reconsider the jitter video quality metrics again

<adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23169

PC: this was originally closed. David Singer asked to have it reopened. I've been trying to get David or Apple to give us some feedback.
... David is at the AG meeting. Sending Cyril to go get him
... bug 23441

<adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23441

Pieer Lemieux repoppended. asking for a text change.

text implied that if text was not listed in table it could never be used

<adrianba> +1

PC: ask the editors to implement change in comment 3

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23441#c3 is the proposed change,

<acolwell> Does this also Adrian's concern about the language being strong enough?

<adrianba> yes

<acolwell> ok

<cyns_> scribe: cyns

<cyns_> scribe: cyns_

PC: the last bug 23169

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23169#c13

DS: the comment was that the sum of all frame delays. If you're a small amount late, it won't matter because it will hit the same refresh
... 2000 frames there were each 5 seconds late is very different from 5 frames that are miliseconds late
... we weren't sure this would help us detect that the media engine is getting into trouble

<paulc> Orginal problems: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23169#c0

DS: we weren't sure that this metric was useful.

see bug comment for details

CC: who would provide the threshold? the applciation or the engine?

DS: intitalized to a default, then app would set it

<cyril> ack

BW: Option 3 is best. can't have a bunch of isolated late frames without having a lot stacked up behind very late ones, or you'll see drop frames.
... you'd want to sample more often. Behind each very late frame, either all the ones behind it are rendered and they are also late, or they are dropped. I feel like you can do it with a modified version fo the existing text.

DS: 2.5 seconds late will result in a burst of late seconds. 10 frames late is badly late, but 10 frame lateness may not be distinguisable from 50 frames taht are slightly late. There may be a serious grey area.

BW: Isn't that the same example? distinguising the one that is a lot late from many that are a little late.

DS: there is a grey area

BW: I don't think it is very big

PC: 3 alternatives. I've heard one vote for #3.

<acolwell> Should we defer this metric until we have more implementation experience with MSE? Netflix and YouTube are already shipping adaptive streaming players based on top of MSE w/o this and are essentially using prefixed versions of totalVideoFrames and droppedVideoFrames. It doesn't feel like this should block MSE from moving forward since this is essentially an extension of the HTMLVideoElement.

DS: this was the most minor part. If we want more experience with this metric before changing, that's ok

PC: what we're saying is that there is no measure of late frames in those 2 numbers?

DS: today we have totalvideoframes, droppedvideoframes, and totalframedelay.

PS: If you only have the total delay, you don't have a measure of slightly late and noticeably late

AB: I think what aaron was suggesting was similar. I think Aaron's suggestion is that people aren't currently using the frame delay in their experimental implementations based on browswers currently supporting this.
... I think Aaron's proposal is that we move forward and he doesn't think this is blocking.

<acolwell> +1

<dsinger> It may be that we need experience with multiple media engines, and finding the cases where we are not adapting appropriately because of the 'strange' behavior of some media engine(s). We did not intend this as a blocking issue (indeed, expected it to be deferred as we posted it after a deadline).

AB: my comment was going to be that we should have the changes Mark talked about to change the approach so it's based on frame rate. Perhaps we can mark this at risk, and determine during impl whether this is correct, doesn't matter, or needs to be modified.

PC: Can I have a better definition of what mark wants to change

<acolwell> I'm fine with including Mark's proposed text

change is in comment 15

<paulc> see https://www.w3.org/Bugs/Public/show_bug.cgi?id=23169#c15

PC: we talked offline, DS wasn't expecting to block last call. could this be marked at risk and ask for impl

DS: Mark's changes will allow us to cover the important part of the bug.

PC: editors, do you know what changes you need to make?

AB: Mark made a proposal for specific chagnes. DS was that ok?

DS: yes, his changes fixed my points 1&3, 4 can be handled late

PC: what section is this in?

<adrianba> https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#videoplaybackquality

<dsinger> so, summary, fix points 1-3 by editing, mark totalFrameDelay as 'at risk' or under consideration, get implementation experience with a variety of media engines and uses, and see where we go?

PC: make changes in explanation in section 5 VideoPlaybackQuality Object
... all last call bugs are processed with good disposition. Next step is propose to go to CR
... here's what we need to do.
... 1. editors need to finish resolving bugs and produce candidate CR draft

<acolwell> ok. Is this just a new WD or do I have to make a special version?

PC: assume we'll have that by end of November. faster is ok too

AB: approx Nov 30.

<acolwell> I think that is reasonable.

PC: 2 do a CFC in task force and/or in working group. run simultatiously

(no objections)

PC: 3 what is the minimum time for CR to run

PL: There are some features hard to test without implementations

PC: yes, get out of CR by knowing that combo of impl and test results

PL: so we won't be able to exit for awile?

PC: asking for minimum. there is no maximum. need to warn people how long they have

<acolwell> 3-6 months seem reasonable since IE & Chrome already have implementations started

PC: assuming we'll use same criteria as html5, 2 independent interop implementaitons (not 10)
... I propose 3 months.

<adrianba> for example, see HTML5 http://www.w3.org/TR/html5/#status-of-this-document

CC: do we know how many tests?

<adrianba> "This Candidate Recommendation is expected to advance to Proposed Recommendation no earlier than 01 September 2014."

PC: no we need to do that work. discuss at Dec 3 taskforce meeting. TF needs to move from speccing to testing
... 3 months

(no objections)

PC: 4. Are there any sections we should mark at risk?
... If we have a section that we're not sure we're going to get interoperability proof for, if that's marked at risk, then we can cut that feature from the spec and go forward.
... if you haven;t warned that the feature is at risk, they you have to go back to last call before going to PR.

<acolwell> totalFrameDelay and appendStream() are the only 2 I can think of. TotalFrameDelay because of the previous discussion. AppendStream() because the Stream API is not stable.

PC: you want to get the list right, but it's a bit of a black art to get list right, because it's based on impl experience. we've already have metrix suggested for at risk
... videoplaybackqualtiy object is a candidate for at risk. Is it the whole object?

AB: can we mark one attribute at risk.

<acolwell> I'd prefer just marking the one attribute

PC: "one or more of the attributes" allows you to drop all or some

<adrianba> https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#sourcebuffer-stream-append-loop

CC: 3.5.6 Stream Object may be at risk.
... depends on Streams API which is in flux
... are our refrences stable enough?

PC: HTML5, so we're our own worst enemy
... File API is now a last call, not working draft

Robin: these are all marked as informative references, but I think that's a bug and they should be normative.

CC: yes, they are normative

Robin: file API is a problematic dependency, that's not its first last call. some parts are stable.

PC: Streams API is marked as editors draft, was just made working draft Nov 5.

AB: Cyril's point is that streams concept in gerenal is in flux, so you should rely on the status of working draft.

<MikeSmith> what AB said

AB: discussed this at the last conf call, options for stream dependency
... option 1 mark sections that are dependent on stream at risk

<MikeSmith> zakimm, who's on the phone?

<acolwell> nope

AB: option 2: are we insulated enough from details of stream, just take it as a param, and details of streams spec left out. Might be blocked from CR, but wouldn't have to modify text
... option 3: stream changes enough taht we drop it

<acolwell> just heard some beeping

AB: my opionion is that we don't want to drop it, so we need to wait and see.

PC: AB does not want to mark at risk or remove.

<acolwell> I agree w/ adrian. We don't want to drop it

<joesteele_> can you post the conf code again - my phone was disconnected

AC: I'd like to keep it in there. I think I agree that we really only rely on the name of stream object
... right now msft ships with a prefixed stream object. will that block interop and moving out of CR

PC: msft policy is to leave prefix until spec leaves CR. Is that correct?

AB: that is a judgement call. not the same for every spec.
... want more demonstration of interop before dropping prefix. I don't see the prefix stream as a blocker for testing. I think we can make progress.

PC: Stream NOT marked as risk

CC: filed a bug that informative references should be informative
... I agree stream is an important feature, especially for embedded device. It's a feature we need. You could maybe leave it out for a first version.

<MikeSmith> joesteele_, please try again

CC: on the stream API spec, it's completely changing. maybe the new one will be the same from a usage point of view, but maybe not. not marking as risk is risky

PL: what is plan b?
... what happens if stream API changes in ways that don't work for this spec?

AB: there's broad recognition that we need the concept of stream. lots of use cases, this is one. I belive the discussions will lead ot a solution that works for MSE
... I'm not convinced there will be a complete chagne that willl not work for MSE. I don't think we need a plan b. Plan B is to go back to last call and try again with this feature.

PL: are we talking to streams about our requirements and schedule?

<acolwell> I have been talking with the Streams editor that works for Google

PC: that's something the chair should do. I'll take an action if we agre

CC: what is the downside of marking a feature at risk?

PC: usually causes it to be tested first. people who think it's important will work hard to demonstrate that it works.
... If people don't think MSE should go forward without Streams, then we shouldn't mark it at risk.
... another Plan B. If streams API changes too much, we can pull the part we want into our spec. The Director won't like that.

<cyril> for the minutes, the bug I filed regarding normative references is https://www.w3.org/Bugs/Public/show_bug.cgi?id=23818

PC: Plan B is that we make our intent really clear to web apps

AB: the reson we have stream in MSE is so we can consume streams created from other specs, likely doens't make sense to suck it into MSE

<MikeSmith> again, what AB said

PL: Please share intended features and also timing

<pal_> PL suggests creating an explicit action to communicate intentions to webapps re: Streams API

PC: summary: editors produce a candidate CR draft by Nov 30. fix normaitve/informative reference bug. Draft presented to TF and WG to go into CR. Draft would indicate minimum CR period of 3 months. The only feature at risk is the one we idenitifed earlier. Chairs have action to coordinate with Web apps on stream object.

<scribe> ACTION: paulc to coordinate with Web Apps on the streams API, give them MSE requirements and timeline [recorded in http://www.w3.org/2013/11/14-html-wg-minutes.html#action01]

<trackbot> Created ACTION-231 - Coordinate with web apps on the streams api, give them mse requirements and timeline [on Paul Cotton - due 2013-11-21].

PC: no objections from people in the room. CFC will be in early december, and you can object then if you wish.

<denis> joesteele_, can you try to call zakim?

<darobin> paulc: we're going to process bugs for EME

<darobin> ... we might continue after lunch

<darobin> scribenick: darobin

MSE bugs

<paulc> http://lists.w3.org/Archives/Public/public-html-media/2013Nov/0015.html

paulc: David Dorwin gave an update about some changes he'd made
... I responded with an email of the outstanding bugs
... David responded overnight with an enumeration of the order in which we should discuss these bugs [see link above]
... he hasn't relettered them, but they're in an order that he feels best for discussion
... he has also enumerated a subset of the bugs that are lower priority
... I would like to close as many as we can
... since we have joesteele_ here, and I don't know what TZ he's in, should we do any of his items first?

<joesteele_> don't worry about my items -- I am sitting at home

davidd: we can jump to 17660

d) Bug 17660 - need token relative with user identity for a new generateKeyRequest parameter

<paulc> test

<joesteele_> I cannot understand well enough to respond to questions unless they are in the IRC

paulc: david, do you want to introduce?


david: this was filed by joe a long time ago

adrianba: this is one of my actions that I didn't complete


<trackbot> ACTION-54 -- Chris Wilson to ask PF WG to look at drafted text for HTML 5 spec to require producers/authors to include @alt on img elements -- due 2008-09-26 -- CLOSED

<trackbot> http://www.w3.org/html/wg/tracker/actions/54

[that's not the right action]

adrianba: joe initially raised this issue about the need to provide information in createSession, which for his use case was about user information
... we actually have a more general issue here
... which is that playready provides a way of having app specific info included in the key request
... a while ago you could package that up with EME in the same request you used to the license server
... more than 50% have used this functionality

<paulc> https://www.w3.org/html/wg/media/track/actions/54

adrianba: so in our implementation today we have an additional parameter which allows people to provide this data
... there may be a more general solution to this that may address joesteele_'s concern

<paulc> Media TF action item on Adrian is still outstanding.

adrianba: the CDN can decide what it wants to do with this information later


paulc: so ACTION-54 is still outstanding

david: so I think this causes interop problem

<joesteele_> the more general solution I proposed was to "bless" a direct communication channel between the CDM and the application where necessary - using the keyRequest/update channel

david: this makes it more difficult and likely that other DRMs will be supported
... so I'm not a fan of adding a parameter that decreases interop

<paulc> joe?

<joesteele_> did you ask a question? all I heard was "joe"

markw: I think there are two separate issues
... adrianba's proposal is about the app providing an extra piece of data to the CDN which it then includes in message
... whereas joe's communication between CDM and client-side application code

adrianba: so I think there are a number of separate but related issues

<joesteele_> I am in favor of Adrians proposal -- but it is separate issue as Mark pointed out and does not address my whole concern

<joesteele_> but would help

adrianba: my action is to summarise why I think providing information to the CDM which it can decide what to do with
... that certainly could cause issues with interop
... if you didn't already need to have a CDM-specific server point, with CDM-specific logic processing
... in practice I don't think it causes a problem
... so I think there are multiple items related by a common thread

<joesteele_> I agree -- in practice this will not be a problem -- for either of our proposals

adrianba: I think there are a number of apps that have logic that varies with using different CDMs
... while it 's possible to write apps that can operate with multiple CDMs
... in practice people will need to do something that's CDM-specific

ddorwin: some of those 50% are already supporting playready and for that reason don't want to port

markw: our principle here is to place the burden on the service provider rather than on the user
... it should be that if the service providers need to adapt then it's the whole idea
... I can see a situation in which the information is passed inside the key message
... if there's a second system that doesn't support this
... then the provider need to update to pass the information out of band
... so it seems that this is a transitionary thing while there's a provider that supports a key system that doesn't support this
... so the question should be how important we think it is to support that transtion

<joesteele_> that assumes that the mechanism you are referring to is not a significant feature add for the provider

<joesteele_> in those cases the provider will *not* want to make the transition

<joesteele_> and will instead rely on existing DRMs

q) Bug 22909 - Needs non-normative Security Considerations section


<markw> @joesteele_: I didn't assume it's not a significant feature. I just said that whether we include it in the specification depends on how important we think it is to support this transition.

ddorwin: I dropped some of the action done

markw: I had actions to address these bugs for non-norm security and privacy sections
... to get discussion going I provided some text
... I expect comments, not polished

<ddorwin> text starts here: https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#security

markw: encourage anyone with expertise to review
... text in the ED
... [link above]
... in both cases users rely on the UA to look out for their interests

<ddorwin> And for bug 22910: https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#privacy

markw: we have a case in which the key system and CDM are from different people
... the CDM implementers are going to have to provide information to the UA about privacy and security properties
... so that UAs can make informed decisions
... we should thnk about how to make that happen
... it's an important aspect of the ecosystem we're creating
... UAs should meet users' expectations

paulc: I take it these sections satisfy the AI

adrianba: we have feedback saying that if they're non-normative we shouldn't use RFC 6919 keywords

paulc: you've left the action open?

markw: the bugs are still open
... do we close these bugs and let people raise more on specific issues?

paulc: that's typical
... it'll get too confusing
... mark as resolved, and people who want frther changes file additional bugs

wseltzer: W3C staff
... member of the Privacy IG
... thanks Mark for sending us notice of these sections, we've been trying to get this reviewed
... will increase the urgency
... the points you've made here, interaction between browser and CDM, are interesting and we want to review
... we can try to see if the Security group can find people to review

paulc: there's a thread
... wseltzer is referring to a dialogue between the TF and the PING

<paulc> http://lists.w3.org/Archives/Public/public-html-media/2013Oct/0046.html

adrianba: the reason I didn't resolve the bugs
... I put markw's text into the specs
... wasn't sure if we wanted to do something in spec to indicate stability of these sections
... I want people to understand that we welcome solid feedback here

paulc: we've done this before, you can add markers to indicate this
... we give the editors some leeway to indicate to people that this isn't a fait accompli

markw: two things
... I agree we should put markers in the spec
... leave the bugs open and indicate that in the bugs
... and also ask people to raise new bugs for new issues
... also, I was wondering if wseltzer is volunteering to find someone to review the security section

paulc: any suggestions on where we might find such an expert
... webappsec?

glenn__: just a reminder I made a link to RFC6973 about privacy considerations for internet protocols, maybe the list of authors can help

paulc: if it's just privacy it doesn't help

<slightlyoff> note that the TAG can help coordinate if this group would find it usefu

<scribe> ACTION: Paul to work with Wendy to make sure we get a security review [recorded in http://www.w3.org/2013/11/14-html-wg-minutes.html#action02]

<trackbot> Created ACTION-232 - Work with wendy to make sure we get a security review [on Paul Cotton - due 2013-11-21].

paulc: I would prefer to close the bugs
... we've given the inital attempt, we want review
... any object to closing 22909 or 22910?


CLOSING bugs 22909 and 22910

pal: to help others schedule their review, what's the timeline?

paulc: I'd know the answer if I knew the results from the comments
... is Dec 15 reasonable?

wseltzer: I will make sure I can get an answer on whether that's reasonable

RESOLUTION: we plan to give a month from today to review these sections

t) Bug 23733 - Consider prohibiting support of active content by CDMs


markw: this came from the text I initially proposed there was a mention of active content
... some people commented that we might simply want to prohibit CDMs from processing active content
... it would certainly simplify our security section

pal: I commented on that bug
... what does active content really mean?
... if this is made normative, we have to think really hard about the definition of that term

<mark_vickers> +1 on active content being too vague.

pal: if I read the definition in RFC 4949 pretty much everything falls under that

<joesteele_> my comment was basically agreeing with pal -- and also to point out that BD+ uses active content by this definition

pal: hopefully everyone agrees that the client executing arbitrary native code in a trusted env is a really bad idea
... but the definition of active content in the document is much broader than that
... there are other examples of content that would all under that, e.g. PDF

<ddorwin> I don't think we want things like PDF running in CDMs

paulc: so how is this term actually used?

pal: the question was about whether to make the prohibition normative
... my comment is in reaction to that
... unless active content can be defined in a way that makes sense, there cannot be such a prohibitions

paulc: so what markw wanted was an addition to the security section for this
... I hear people saying that we should understand what we're doing but not hearing yay or nay

pal: with current text, nay

mark_vickers: I would say no under that definition
... also point out that the RFC is information, not standards track

markw: we need a better definition, I just saw that the text was already there, wondering if it was good enough
... executing code from the internet that may have access to system API would raise a security question
... we should keep this under review, the question of excluding some active content remains open

paulc: so we keep this open, and should ask the security reviewer when we find them

mark_vickers: if this is the only definition we have, I would say we don't want to do that
... if we have something we should exclude, we should list that
... if we want to say no to executing arbitrary code from an unknown source, fine
... but I'm not sure what we're going for since the text is too vague

glenn__: just a note to markw, I defined active object content in the DIS standard 2003
... there is at least one definition


<glenn__> http://www.atsc.org/cms/standards/a100/a_100_1.pdf

paulc: other opinions?

<glenn__> see "active object content" definition in section 3.3

ddorwin: difference between seeing something and acting on it, and actually running it
... I think running active content in the context of a CDM, hardware or root, would be bad

<paulc> acl pal

pal: what's needed is for someone to make a proposal for something better than current definition
... unless there's a better proposal we can't leave this open forever

mark_vickers: I want to close because I don't udnerstand what this is doing, so unsure how to help wirte text
... things I've heard so far seem to apply to all parts of the UA
... so why are we applying this here?

paulc: so if HTML5 had a security consideration section, why would it say something different?

mark_vickers: right

<joesteele_> isn't the key concern about "unrestricted code execution" not the particular type of code being executed?

paulc: so maybe because CDM is out of scope?

mark_vickers: but there are also lots of other things that are linked to by the UA, nothing CDM unique about this

wseltzer: webappsec probably has some definition that could be useful here
... there's a difference between the user trusting a CDM accepting arbitrary content, and a process doing the same but without the sort of opaque power that the CDM has

j) Bug 20944 - EME should do more to encourage/ensure CDM-level interop


<Tomoyuki> s/rich/rice/

paulc: appears to be an open ended question
... outstanding since last phone call

ddorwin: I think this and the privacy and security issues were the last outstanding from the discussion around FPWD

paulc: I think this issue was there in the FPWD
... sotd now points to bits for review
... but 20944 is still outstanding

markw: want to point out that 1) my summary of roc's proposal of what should be a possible resolution, I think it wouldn't work for some people but I haven't heard back from anyone

[summarises the comment]

scribe: both 2 and 3 would be progress

<Zakim> MikeSmith, you wanted to ask what efforts are being made to get DMR reps participating in the discussion

MikeSmith: so this discussion has been pretty much going nowhere
... part of the reason is that the people participating are not those in a position to comment on whether the proposals are acceptable
... we should elicit direct public feedback from CDM vendors as to whether this is acceptable, and if not why not
... but there has been no effort to make this happen

pal: this group can't compel anyone to respond to anything
... what happens if no response is received?

<wseltzer> darobin: if there's no response on an important bug, then at the next transition, the Director might conclude that there has not been broad review, and decline the transition request

paulc: this is important enough, the team might ask for a Director's call before LC (instead of CR)

mark_vickers: I just think that looking at these proposals, if you substitute CDM for UA it would be clearly unreasonable
... the publicity of APIs for instance wouldn't work, e.g. file system APIs
... otherwise, why isn't this a general W3C policy on components of a UA

<ddorwin> 3 comments:

mark_vickers: I think the CDM is being singled out in an unfair manner

<ddorwin> 1) Does what is being discussed even address the real concerns/objections?

<ddorwin> 2) I worry about putting requirements to document any internal implementation? It could result in a) slow development (imagine writing publicly visible design documentation for your entire project) b) lead to stale and useless documentation, and c) discourage supporting additional platforms

<ddorwin> 3) As for a registry, the same key system name can be implemented in different ways on different platforms.

<Zakim> MikeSmith, you wanted to say that the comparison to the FileSystem API is not relevant and to say that CDM vendors are not being singled out; what is being is asked here is not

MikeSmith: I completely disagree about this being unreasonable
... I don't think that other people involved in the bug discussion find this unreasonable
... there's discussion of the level of detail that a vendor could provide without compromising the security of their system
... it's certainly not true that CDM vendors are being singled-out

<joesteele_> It would be more reasonable to ask the CDM vendors to disclose the details of the message requests and responses. That would at least have some privacy value.

MikeSmith: the discussion is about exposing just the information to enable open source implementations to interact with their system
... but again, we haven't had a chance to interact with someone who might find this unreasonable
... I think we're treading water

markw: difference between item 1 and items 2-3
... the latter are small and reasonable

<joesteele_> +1 to Marks comment -- those are easily discoverable in any event

markw: there is a Play Ready porting kit
... item 2 would just require you to map from the playready API to the CDM API so everyone doesn't have to determine that independently
... so it seems very reasonable to require

<joesteele_> #1 is far too vague to be actionable

markw: for item 3, if you've built a UA that uses specific components from an OS, it's pretty reasonable to ask that the APIs be published
... seems reasonable and encourages interop
... we can't require people to do this, but we can make it a condition of registration

pal: not going to argue for solution

<joesteele_> I disagree that this would help interop in any significant way

pal: it would be goood for this group to have a plan
... it won't close itself

paulc: I think I'd like to talk to some members of the TF about this
... may have to go to the Team to figure out how to handle this bug
... don't think there are action items on this

<markw> #joesteele_ Robert O'Calaghan provides a more detailed description of #1 earlier in the bug

paulc: I am concerned that we will have to anticipate how the Director will want this bug handled or not handled
... if the group WONTFIXes this, we'll get an FO
... I think that MikeSmith's comments about this bug languishing are factual

<scribe> ACTION: Paul to report back about the plan for 20944 due 2013-12-15 [recorded in http://www.w3.org/2013/11/14-html-wg-minutes.html#action03]

<trackbot> Created ACTION-233 - Report back about the plan for 20944 due 2013-12-15 [on Paul Cotton - due 2013-11-21].

ACTION-233 due 2013-12-15

<trackbot> Set ACTION-233 Report back about the plan for 20944 due 2013-12-15 due date to 2013-12-15.

MikeSmith: God forbid that I ever were the Director
... but my response would be "what have you done to resolve this?"
... there hasn't been sufficient action on this bug
... it's not clear what we can do
... I'm giving my feedback early to gain time

c) Bug 17202 - Explicitly document how keys are to be shared


ddorwin: I think these bugs are open for reasons different from their original summaries

<joesteele_> My comments are in the bug

ddorwin: I propose that we close these bugs and ask for use cases to address


ddorwin: I suggest we take action agreed upon, close those bugs, and for unmet use cases open new bugs

<joesteele_> I do not want 21869 closed without action

paulc: are you suggesting we close these bugs and look at new proposals

ddorwin: lots of discussion on the UCs behind the proposals
... I think we're down to no change necessary
... if something missing, he can file new bug

<adrianba> joe, the proposal is for you to file a new bug to track the action

<joesteele_> no -- the issue is that the spec does not explicitly say that sharing of keys is allowed -- it must say that

ddorwin: I think that this is similar to before, close and people can open more specific bugs

<adrianba> joe, because the bugs have drifted from the original point

<joesteele_> or point me to the text that says it

<joesteele_> I am tired of opening bugs to say the same thing -- key sharing is a requirement

paulc: suggesting we can just action this bug but it says new — is there a concrete proposal that we have already adopted?
... I understand your point on the first bug but not on the second

ddorwin: I have gone through those many pages recently, but there's no actionable item in the summary — don't know what to do

<joesteele_> I need clarity on the CDMs ability to store keys -- that is the title of the bug

<joesteele_> what needs clarification?

adrianba: do we have spec text proposed? ddorwin said no. So get spec text from the person who wants the spec changes

paulc: okay, let's do these bugs one at a time


<paulc> see Joe proposal for 17202: http://lists.w3.org/Archives/Public/public-html-media/2013Nov/0022.html

<joesteele_> I am fine with closing 17202 -- Davids solution made sense to me

[group argues about what joesteele_ meant on IRC]

<scribe> [ongoing IRC exegesis]

joesteele_: for 17202 ddorwin pointed out that a UC could be solved by framing a player @@ okay to close with no change to spec

paulc: objection to closing?

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17202#c3

The editors will take into consideration the unrelated in the above link

paulc: is that wording in c3 or other discussion?

ddorwin: mostly c3, but I will be sure not to break his UC
... in summary I don't think we want to share content keys between sessions
... joesteele_ wants to share the key hierarchy
... I will try to specify that the former is not allowed, while allowing the latter

<joesteele_> yes -- I want to share the key hierarchy -- not the content key

<joesteele_> I can't hear you guys anymore BTW

p) Bug 21869 - Need clarity on stored keys for CDMs


<joesteele_> ok -- you guys dropped me. I will try ti dial back in

<joesteele_> cya later!

<adrianba> ScribeNick: adrianba

Scribe+ Adrian_Bateman

<joesteele_> ok

<MikeSmith> thank you Ralph very much

Bug 17673 - Define Initialization Data for implementations that choose

to support the ISO Base Media File Format


paulc: we had some action items on johnsim to work on corner cases and to draft a proposal
... i don't think we've seen any action - what do we do?

ddorwin: there are two models for this
... for bmff, cenc is one of the possible modes of encryption
... but others could be
... we're not putting data into initdata the way the iso bmff spec is written
... the target is cenc because it is easier for the main use cases
... but this isn't as flexible
... would like to have a discussion and move forward

dsinger: i need a little education on the problem
... if we said initdata is sinf followed by any pssh then we would have every thing
... there are other things in sinf that you might want even in cenc case

ddorwin: i'm not an iso expert but i believe the problem is pssh don't always appear with sinf?

dsinger: i'm suggesting you get the scheme information inside the sinf
... it may be empty with cenc sometimes
... you could say get sinf if not empty and then pssh
... i think this covers everything
... [quickly describes the moov box]
... the data starts with one time initialisation
... pssh might appear with the initialisation or later in the fragment
... today the API returns the concatenated PSSH since the beginning
... i'm saying prepend that with SINF

ddorwin: you're proposing to always append pssh to the sinf

paulc: do we know where this belongs in the spec?

ddorwin: yes, the BMFF section

markw: my recollection of the history was that we went through the exercise of describing it with sinf
... and we found some problems and then we were talking about going back to pssh
... henri asks the question of why we need to support formats other than CENC
... he wanted justification for other formats

<ddorwin> "…it sounds like using |sinf| might also be incompatible with SampleGroups. This means that supporting other scheme types limits our ability to support features of specific scheme types."

<ddorwin> ^ from the bug

<pal_> adrianb: one option (see david singer), find the sinf box and then, if cenc, append pssh box

<pal_> ... and use the result as init data

<pal_> ... does the implementation need to keep sinf if future pssh are found

<pal_> ... initidata is fired everytime pssh is found

<pal_> davids: need to keep sinf around

<pal_> adrianb: second option, UA parses sinf. if cenc, provide pssh only. if other, TBD in future specification

<pal_> ... initdata is sequence of boxes

<pal_> davids: propose that, everytime sinf is found, append any pssh and provide as initdata. later in the file, if pssh are found, just provide those as init data

ddorwin: we are saying the first needkey event would have a different set of boxes?

dsinger: yes?

markw: i think one of the things mentioned in the bug is that could be a sinf in each track?

<pal_> markw: what about one sinf in each track?

dsinger: yes, but also pssh in each track

markw: so there could be multiple sinfs not just one
... but we haven't addressed henri's question

dsinger: i don't understand how you can decrypt the data without the SINF

markw: you don't have to have the all the data to decrypt

dsinger: so why pass the PSSH at all?

markw: you might get the initdata from another source

dsinger: but there are systems that need SINF data
... i think the mechanism of getting all the SINF with a non-empty encrpytion atom
... and adding PSSH will give you everything you need and often SINF will not be included for CENC

[some discussion about whether to limit to CENC or be more open]

dsinger: think it should be possible to use this with fairplay

pal: is there a proposal on the table?

<dsinger> Suggestion: given a movie atom, give me the sinf boxes from each track (possibly optimized to say if it has a non-empty scheme information box), plus the pssh boxes (if any); for a movie fragment, give me pssh boxes (if any).

<silvia> I ran MediaStreamTrack.getSources(function(result) {console.log(result);}); in the console of chrome31

<dsinger> That allows the API to confirm the scheme type, the original format, and so on, and is quite general.

<dsinger> It gives the cenc 'track encryption' box when present.

ddorwin: we think the current text is buggy but i don't remember the details

<ddorwin> it sounds like using |sinf| might also be incompatible with SampleGroups. This means that supporting other scheme types limits our ability to support features of specific scheme types.

[discussion about https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673#c10]

dsinger: this about a different topic
... this is a related but different problem
... you can set-up defaults at the beginning of the file
... you can also include sample groups
... as you walk down the file you can have data that belongs to different groups
... the first version of CENC used that
... so you can have runs of samples using different groups
... later, you wanted to introduce new sample group descriptions after you started the movie
... in the latest version you can include group descriptions in later fragments
... if we don't get the sample groups out later then we won't be able to use them
... and the question is how to handle this
... question is how to handle sample groups later in the move

paulc: do we agree that we should put comment 10 into a separate bug?

dsinger: the second half, yes

paulc: and the solution?

dsinger: i need to refresh my understanding of the boxes - maybe you don't need this at the api level

markw: the assumption is there is sufficient information in PSSH to know what keys it needs to fetch
... for that PSSH is sufficient
... you don't need this in the initdata

paulc: still think this is an orthogonal bug - resolve it that way

ddorwin: sounds like this is resolved

dsinger: can markw write a response to comment 10?

markw: yes

paulc: and we need to tell johnsim that his actions are done

adrianba: think we have the general outline - might need some help

dsinger: happy to help with editing

ddorwin: 21869 - we will have to revisit
... 17750 - adrian has done work on close - will need to revisit in telcons
... 21798 - recommendation for media key error codes - waiting for feedback

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21798

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17750

ddorwin: feedback is coming in on mailing list

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21869

<joesteele_> I left a comment for 21869 -- you should be able to close it I think

ddorwin: 18515 - think this would be good for the broader group

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515

<joesteele_> I had not read the latest section 8.2

Bug 18515 - Provide more details on behavior of the media element when

the key for an encrypted block is not available


ddorwin: not clear what to do here, for example if you have the data from the network but are blocked for some reason

adrianba: there is an action on jerry to make a proposal for this
... we've been discussing at microsoft
... [discussion of why we want to solve this problem]
... the beginning of the proposal might be to update the waiting event to include a reason for why the media element is waiting
... if it is something other than waiting for data from the network

Bug 23619 - Drop or change MediaKeyError constant prefix


ddorwin: proposal to use strings instead of numeric constants
... seen this for other places but not for error codes
... if anyone has guidance on this it would be good to hear
... we haven't seen other APIs use enums for error codes
... i could talk to Alex directly

paulc: nobody from the TAG is here
... we discussed 7 comments in detail
... 4 of them are going to be closed
... there are a bunch still to be worked on
... sounds like 10+ bugs still open after this
... do we want to spend more time making progress here?
... we have all tomorrow afternoon

<joesteele_> did you see my comment about closing 21869? Or was there another reason to keep it open

<joesteele_> I will not be available that late tomorrow -- are there any more issues you need my input on?

<ddorwin> Thanks joesteele_. I just mentioned it in the room.

paulc: we'll organise a session after lunch

<scribe> ScribeNick: edoyle

<ddorwin> joesteele_, nothing stands out. Thanks for attending!

<SteveF> ok

Next topic: Status of CR bugs on HTML5 and Canvas2D

<SteveF> Bug 20987 - The main element could do with some more examples

<SteveF> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20987

Status of CR bugs on HTML5 and Canvas2D

<SteveF> This is editorial and should not be blocking anything (in my opinion)


SteveF: will review and resolve 21579 within the next week

its a matter of clarifying what's in the spec (nothing controversial)

SteveF to provide the text

<MarkS> ACTION: stevefaulkner to resolve bug 21579 and will provide spec text [recorded in http://www.w3.org/2013/11/14-html-wg-minutes.html#action04]

<trackbot> Error finding 'stevefaulkner'. You can review and register nicknames at <http://www.w3.org/html/wg/tracker/users>.

<SteveF> my nick is SteveF

<MarkS> ACTION: stevef to resolve bug 21579 and will provide spec text https://www.w3.org/Bugs/Public/show_bug.cgi?id=21579 [recorded in http://www.w3.org/2013/11/14-html-wg-minutes.html#action05]

<trackbot> Error finding 'stevef'. You can review and register nicknames at <http://www.w3.org/html/wg/tracker/users>.

<slightlyoff> apologies for not seeing the ping earlier...ddorwin how can I help?

<SteveF> ACTION: SteveF to resolve bug 21579 and will provide spec text https://www.w3.org/Bugs/Public/show_bug.cgi?id=21579 [recorded in http://www.w3.org/2013/11/14-html-wg-minutes.html#action06]

<trackbot> Error finding 'SteveF'. You can review and register nicknames at <http://www.w3.org/html/wg/tracker/users>.

<MarkS> ACTION: Steve to resolve bug 21579 and will provide spec text https://www.w3.org/Bugs/Public/show_bug.cgi?id=21579 [recorded in http://www.w3.org/2013/11/14-html-wg-minutes.html#action07]

<trackbot> Created ACTION-234 - Resolve bug 21579 and will provide spec text https://www.w3.org/bugs/public/show_bug.cgi?id=21579 [on Steve Faulkner - due 2013-11-21].

MarkS: those were the 2 assigned to SteveF, there are 3 remaining ones that janina will take care of

(going through this list by assignee: https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=ASSIGNED&bug_status=NEW&bug_status=REOPENED&component=HTML5%20spec&keywords=CR)

hober: 18728 is editorial, nothing to block CR

<scribe> ACTION: hober to resolve 18728 https://www.w3.org/Bugs/Public/show_bug.cgi?id=19728 [recorded in http://www.w3.org/2013/11/14-html-wg-minutes.html#action08]

<trackbot> Created ACTION-235 - Resolve 18728 https://www.w3.org/bugs/public/show_bug.cgi?id=19728 [on Edward O'Connor - due 2013-11-21].

next is i18n issue: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16970

hober: requires testing to know what we should be specifying
... probably the most useful thing to make progress on this bug is feedback from i18n

r12a: addison can help out here

paulc: so we need a test case demonstrating the problem and then interop report

r12a to ask for such a test

scribe: so we can know whether to change implementations or spec (or both)

<MarkS> ED: translate attribute. looks like we need a test. https://www.w3.org/Bugs/Public/show_bug.cgi?id=23208

<MarkS> RI: I think we need more clarification in the spec. I think you agree that there would be named attributes that would not be translatable. That is what I am asking for here.

<MarkS> ...the following attributes are translatable attributes

<MarkS> PC: what is missing is anything not on this list. is that what you would like to see?

<MarkS> RI: translate set to no: you don't translate the attribute value either.

<MarkS> PC: the following attributes are translatable when the parent has translate set to yes

<MarkS> ...make the corner cases explicit

<MarkS> RI: question about the translatable attributes contained in that list

<MarkS> PC: orthogonal question. would require a new bug

<MikeSmith> trackbot, reload

<MikeSmith> trackbot, status

<MarkS> ACTION: erica to resolve bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=23208 as discussed [recorded in http://www.w3.org/2013/11/14-html-wg-minutes.html#action09]

<trackbot> Error finding 'erica'. You can review and register nicknames at <http://www.w3.org/html/wg/tracker/users>.

<MarkS> ACTION: erika to resolve bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=23208 as discussed [recorded in http://www.w3.org/2013/11/14-html-wg-minutes.html#action10]

<trackbot> Created ACTION-236 - Resolve bug https://www.w3.org/bugs/public/show_bug.cgi?id=23208 as discussed [on Erika Doyle Navara - due 2013-11-21].

<MarkS> ED: https://www.w3.org/bugs/public/show_bug.cgi?id=22326 bulk of conversation is happening on WHATWG

<MarkS> ...changing the default behavior of the dir attribute. isolation instead of embedding behavior.

<MarkS> ...seems like good evidence that making this change should be good and should not have any negative implications.

<MarkS> ...i made the change and put it to the public list for review on WHATWG

<MarkS> RI: there was a request to tackle <bdo> as well (isolation) which involves the same thing. do we need a separate bug for that?

<MarkS> RB: I think your comment in the bug is enough to add the bdo change. email public-html

Next are robin's 5 ruby-related bugs

scribe: these will be addressed by the ruby extension spec.

bugs 19251 through 19255

these should all be fixed by end of year

robin to update these bugs with an indication that they are being addressed by ruby extension spec

Next are the bugs on travis

travis to check if these should be fixed in time for CR

travis to look into this. it may be a non-issue for CR due to a cascade of at-risk feature removal

(in reference to 16957, 16959, 16960)

<glenn__> scribenick: glenn

<glenn__> intros of guests from WAI and pF

<hober> scribenick: glenn__

paulc: thanks to janina for participating today
... made a list of possible discussion items
... (1) 3 A10Y CR bugs

<jcraig> s/A10y/A11y/

jcraig: tnx

paulc: relationship between DOM3 and DOM4
... believes this answered off list
... (4) status of canvas CR spec
... draw custom focus ring
... one request to extend
... will discuss tomorrow morning
... probably best handled in canvas session

janina: would like more time probably for coming to conclusion, at least no earlier than next THU

paulc: no problem with that

<jcraig> could someone clarify scribe comment "relationship between DOM3 and DOM4"

jcraig: no

<MarkS> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18574

paulc: 18574

hober: 19277

<MarkS> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19277

hober: summarize bug...
... hidden attribute
... rendering sections defines as sugar on top of display: none
... several interrelated problems
... in common style sheets ... div.foo
... might style .foo as display: flex, but if hidden present, wouldn't hide
... change default for hidden to display: none !important
... but other problems with this
... thinking of resolving according to Boris' comment 5

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19277#c16

hober: should be able to describe in terms of existing features
... also use cases where authors should be able to use visibility: hidden
... inclined to resolve as Boris suggests
... i.e., as display: none
... thinks it will resolve both of these bugs (18574 and 19277)

<jcraig> +1 to Boris comment #16 item 2, "No CSS box (e.g. display:none) means no accessible object."

<jcraig> so this is somewhat of a non-issue in most user agents

paulc: janina?

<jcraig> (for accessibility)

janina: appears this was conflated with discussion "issue 204"
... maybe related (or not)... needs clarity

<jcraig> however, I agree that the mapping in HTML should be move from "strong" semantics table to the "weak" semantics table. b/c

janina: is there a relation between this solution and where "issue 204" ended up?
... wants to check with ARIA subteam in PF

<jcraig> currently WebKit is the only UA that correctly implements: <div hidden aria-hidden="false">exposed to accessibility API, but not rendered visually</div>

janina: need to be careful

hober: yes, related to 204
... need to make sure that this resolution doesn't affect 204 resolution

janina: probably could take up on ARIA call this coming week

paulc: sounds like reasonable plan
... reference to comment #15, janina takes away, discuss, etc, inform hober

janina: sounds ok

<Zakim> jcraig, you wanted to have someone read my comments started with the +1 to boris

<jcraig> currently WebKit is the only UA that correctly implements: <div hidden aria-hidden="false">exposed to accessibility API, but not rendered visually</div>

jcraig: comment about move from "strong" to "weak" semantics table
... do agree it can be resolved

hober: describing 18574

<jcraig> and boris is absolutely right that "No CSS box (e.g. display:none) means no accessible object." (unless overriden with aria-hidden="false")

cynthia: can we do in TF on THU?

janina: yes

paulc: 19277 and 18574... plan to discuss on ARIA call, also agenda item for THU TF call
... attempt to get consensus on Boris' comment
... third item 23380


janina: recent bug
... due diligence matter
... get right people to handle soon...

paulc: ARIA related
... assigned to SteveF
... janina to confer with SteveF
... wants deterministic status
... final item - image description
... when HTML5 came out of LC to CR
... a few contentious issues kept in WG
... one was definition of longdesc
... chairs proposed something called plan 2014
... delegated to A11Y TF
... the dev of an extension spec
... a significant success
... what are plans going foward

janina: have gone through LC on spec published early 2013
... continuing to work on comments
... finalizing responses to comments
... mostly editorial.
... but probably won't come to unanimity
... due to polarization in a minority community
... some have asked to be more prescriptive
... e.g. how longdesc is discoverable
... don't want to be overly prescriptive on this now
... left a lot up to UA
... how UA exposes is UA dependent
... have series of tests and results
... on way to CR, not sure on CR duration or post-CR, e.g., whether to maintain as standalone spec
... or whether to ask to fold back into HTML5

<MarkS> Test results

janina: perhaps ask WG to resolve

marks: good summary
... getting consensus from TF about final responses
... a few outstanding Qs but mostly straightforward
... 22 tests
... HTML testing TF invited to submit to github platform repo

paulc: plan 2014 shows paragraph about folding back in
... to identify date 3 months before completion of CR
... for which can identification extension specs to fold back into HTML5 spec
... A11Y TF took care of longdesc work with option to fold back into HTML5 spec
... would require decision by WG, but process has worked well
... could also take directly to REC, but chairs haven't looked at this yet
... community has been waiting some time, so really looking to A11Y TF for guidance/recommendation
... good example of using modularity/extensions to empower people to progress more rapidly than larger group
... look forward to complation of AIs (janina)
... taking breaks (sam also) until early Dec
... only outstanding A11Y item is canvas, to deal with focus ring issues
... to discuss tomorrow AM
... next segment is HTML5 testing

take 5mins break

<MarkS> scribe: MarkS

Testing and HTML5 Exit Criteria

<paulc> http://dev.w3.org/html5/decision-policy/public-permissive-exit-criteria.html

PC: Model CR Exit criteria. Rules for exiting CR stage. Looking for independent, interoperable implementations. Features that are well known, deployed and match the spec, we will assume good to go.
... went through HTML5 and Canvas spec at last F2F to identify sections we *thought* were interoperable.
... Overview of testing in view of CR document.
... either considerd interoperable, requires testing, at risk has tests, has implementations and has implementations and tests.

RB: this key made sense at the time, looking back on it, we now know it probably does.'t
... it is a bit confusing.
... anything blue or yellow bar needs testing.
... if its not green it is not widely considered interop
... there should probably be requires testing and does not have tests and req testing and does have tests.
... i will most likely go through and update this document.

PC: eventually, the purple items will require tests and we will report on them to the director
... the chairs have not produced a WG Decision on the original CfC
... in september we received feedback on 3 points. first was a bug report, chairs would like to see a decision on that bug
... bug 18490

ED: this bug we asked i18n if we could remove CR keyword, but the referencing bug is the one we talked about today.
... we are ready to go forward on this.

PC: is 22326 directly related to his issue?

ED: don't know at this time.

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18490#c14

Comment 14 indicates this bug is no longer blocking the CfC

PC: look at more recent research that have gone into testing this condition
... earlier this week, I asked erika, denis and robin to go through HTML5 test suite and look through TOC to identify places where we didn't have tests
... produced this list

<paulc> http://lists.w3.org/Archives/Public/public-html/2013Nov/0025.html

ED: went through the suite and identified sections that had NO tests. cross referenced with robin's chart

PC: this should help robin update his doc
... this research doesn't included un-reviewed tests

JG: their are thousands of un-reviewed tests

RG: reviewing is a fair bit of work, sometimes more than writing the tests.
... denis is working on reviewing tests
... anyone who is considering writing tests should look for existing tests, then in non-reviewed tests to see if tests have already been written
... lots of improvement on testing documentation.
... canvas test suite is working again. improved test writing documentation

JG: this came up in web apps as well, a tool for seeing which tests touch which specs (and where)

PC: robin, your recommendation on this? if that one bug was resolved, can chairs close this and issue a resolution?
... can you take an action item to update this by dec?

<paulc> revision of http://www.w3.org/html/wg/tests-cr-exit.html

<scribe> ACTION: robin to give us a revised overview of testing document - in 4 weeks [recorded in http://www.w3.org/2013/11/14-html-wg-minutes.html#action11]

<trackbot> Created ACTION-237 - Give us a revised overview of testing document - in 4 weeks [on Robin Berjon - due 2013-11-21].

<darobin> ACTION-237 due 2013-12-4

<trackbot> Set ACTION-237 Give us a revised overview of testing document - in 4 weeks due date to 2013-12-04.

PC: in the previous sessions, we now have a clear picture of CR bugs. it was 480 when robin came on board. with new editors, we've reduced that number to 20 or less.
... to get out of CR we need 3 things: no bugs, tests, and implementations for those places were we don't have tests that aren't satisfied by the exit criteria. No tests, we don't get out of CR.
... wanted to come out of this F2F with a better understanding of at least 2 of those.
... implementation timing is harder to nail down.
... no implementations, they will most likely get cut from 5.0 (stay in 5.1)
... thanks to tobie, erika, denis etc for all this work.
... need tests in order to prove implementations.
... if we have a Spring meeting, major topic will be testing. may be the only reason. Web apps may do the same. Need to get the right people in the room to achieve this.

RI: i look at the overview document and see areas where I have submitted tests that indicate no tests. Are we going to update it...

RB: yes, we have a clear plan to do that.

PC: will have a discussion about canvas tomorrow.

M5: i will be able to show some canvas test results.

TL: w3c testing fellowship from Facebook. Looking for testing coverage from members to extend my fellowship. If this is of interest to you or your company, please talk to me or Phillippe

PC: motion to adjourn and reconvene tomorrow morning. We will start with Canvas, features at risk, Accessibility features....


expect to adjourn no later than 3PM tomorrow

<SteveF> darobin: groundhog day 'Editor's Draft 7 November 2013' less 青啤 more HTML编码 ;-)

<gitbot> 01[13html01] 15stevefaulkner pushed 1 new commit to 06master: 02https://github.com/w3c/html/commit/450185e45fde0f23d00b5d97ad500d5fdc50b76b

<gitbot> 13html/06master 14450185e 15steve faulkner: fix hidden/aria-hidden...

<MikeSmith> SteveF: :-)

<SteveF> hober: i took https://www.w3.org/Bugs/Public/show_bug.cgi?id=18574 as I have made a change to spec to hopefully resolve, if you want to keep change back :-)

<SteveF> MikeSmith: working every angle to get robins arse into gear :-)

<gitbot> 01[13html01] 15stevefaulkner pushed 1 new commit to 06master: 02https://github.com/w3c/html/commit/985415ccc0d5ae13c0acc61d0dcbf3e50112c01e

<gitbot> 13html/06master 14985415c 15steve faulkner: fix link to required in aria section...

<SteveF> darobin: the audio is for you http://www.youtube.com/watch?v=1tER_2xmVlU

<stommepoes> SteveF 青啤, trying to make us thirsty

<SteveF> stommepoes: always thirsty

<stommepoes> You *do* keep talking about this... false dichotomy of "drinking" and "coding"... haven't you heard of the Ballmer Peak?

<stommepoes> see, now I'm seeing double stevefaulkner s

<gitbot> 01[13html01] 15darobin pushed 1 new commit to 06feature/whatwg: 02https://github.com/w3c/html/commit/a43f5fb21c05c159be980c9567bcaa59a49308f1

<gitbot> 13html/06feature/whatwg 14a43f5fb 15ianh: [cgiow] (3) Change how dir='' works, from being an embedding to being an override, for better results on mixed-directionality sites. THIS IS A HIGH RISK CHANGE, EXPECT BREAKAGE. Please report breakage on the bug if it's higher than acceptable, so we can revert the change if necessary....

<paulc> trackbot, start meeting

<trackbot> Meeting: HTML Weekly Teleconference

<trackbot> Date: 15 November 2013

<paulc> Is there anyone else that is going to join the teleconfernce?

<Travis> scribe: travis

<scribe> scribeNick: Travis

<paulc> Status of CfC on Canvas: http://lists.w3.org/Archives/Public/public-html-admin/2013Oct/0009.html

<paulc> Canvas CR features at risk: http://www.w3.org/TR/2012/CR-2dcontext-20121217/

paulc: Now looking at at-risk features in original canvas CR
... some folks mistook an at-risk wiki as normative

<paulc> Editors draft with different features at risk: http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/

paulc: showing current editor's draft of canvas 2d w/ at-risk features
... path objects + hit regions (in the original)
... now a revised set of at-risk features in editor's draft
... added more stuff from path objects
... hit regions still there
... all attributes of text-metrics (except width)
... ellipse is going out due to lack of implementations..
... focus ring stuff
... So we didn't have the right at-risk feature list originally.
... how to move forward?
... we could 1) publish revised version of canvas w/revised at-risk features.
... but we'd have to go back to LC.
... per the process
... or 2) we could remove all the items from the spec
... go back to LC then directly to PR.
... there's also some variations possible
... a11y TF is also considering removal of all but focus-ring items
... go to LC then back to CR

<paulc> A11Y TF CfC on Canvas features at risk: http://lists.w3.org/Archives/Public/public-html-a11y/2013Nov/0006.html

paulc: quotes the mail
... in long term, some features may transition to canvas L2
... a11y looking for CfC on this. Should close on Wednesday
... wanted to ask folks in room what they think of this plan.
... and whether we should keep the focus-ring stuff in the spec.
... ack. that we're missing Rich (IBM)'s opinion
... there's a proposal to keep the a11y TF open.

MarkS: No sure--don't have consensus

<MikeSmith> Canvas2D test results

paulc: Mike can you update on canvas testing?

<MikeSmith> Canvas2D test (non)failures

MikeSmith: now looking at Canvas 2d test results
... should have safari there eventually
... purpose was to see the failures.
... we have Fx26, Cr 31, IE10
... results generated from test framework authored by ms2ger
... green = good
... other colors = bad
... some tests failed because test case harness issues (generator failures--those in yellow)
... reds are failing, we know why most of them are, but not all.

paulc: need to understand why some tests are failing.

MikeSmith: one more class (blue?) are manual tests
... I haven't run those.

paulc: CR exit criteria is 2 interop impls.
... the implementation has to be "public" could be a beta release.
... are there other options other than the implementations we've looked at?

MikeSmith: blink/webkit are not far enough apart in the failure details.
... for me, it looks like we're ready to go into the CR transition given the test results.
... note: test suite doesn't include at-risk features.
... otherwise, we're ready to go.

paulc: summary:
... if we remove at-risk features, we can go back to short last call.
... and declare that we'll go (next) to PR.
... perhaps we could have a canvas REC early in 2014.
... looks like a11y TF wanted to get consensus to leave focus-ring in, and extend the CR
... I want to chat about that.
... (hear from the group)
... we won't make decisions here today
... but want to know what a CfC result might be.
... looking for input on at-risk features in editor's draft

cynthia: any chance that canvas l1 rec earlier would speed up v2?

paulc: yes.

jmann: hi folks
... worked on implementing canvas
... we've been looking at draw focus ring
... seems like draw focus ring stuff needs work
... ric and I have some feedback
... draw focus ring seems to be trumping user's settings
... some of the methods may need more thinking
... focus rings and hit regions may have some overlap
... also API name may be a bit confusing
... the draw command doesn't actually draw anything
... and it's not a ring
... we have 2 early implementations
... cabanier also has some spec questions
... I propose we move these to v2 for clarifying

Lisa: I wasn't following this issue
... bear with me
... legislation around the world fines folks for not producing a11y content
... folks will produce quick fixes just to ship
... people need to make a11y content
... please don't release canvas until you have a solution that works for a11y

paulc: canvas is in CR.

<MikeSmith> I agree with Jatinder's assessment about DrawCustomFocusRing and further would state it as, we don't have consensus on DrawCustomFocusRing and in particular we don't have implementor agreement on DrawCustomFocusRing (and I say that having followed all the public discussions on blink-dev (chromium-dev?) and webkit-dev and mozilla bug and now the comments from Jatinder here)

<Zakim> MikeSmith, you wanted to express support to the chairs and group from the team side for readiness of transition out of CR for features that are in the test suite

paulc: today, if someone builds a site with canvas, can they still get fined (canvas features from today's draft)?

Lisa: yes

MikeSmith: acks. lots of history around this
... draw system focus ring is not as controversial
... draw custom focus ring (with lots of discussion from implementors)...
... from W3C team side, looking at results and making objective assessment
... chairs and WG are in a good position to transition canvas spec with the given features

hober: thanks jmann, good summary
... it's important that we get this right and have accessible canvas.
... what's current speced in draw ** focus ring doesn't meet high quality bar
... for getting the feature right
... in response to lisa:
... browsers have shipped this for years
... we need to get the spec done
... we need to get a11y right
... we probably can't get these out simultaneously
... a11y seems to be taking longer, but we need to do the right thing

cynthia: if we ship what we have, we can focus on a11y, and shift our attention to it.

jmann: for lisa: canvas ships with one accessibility feature (shadow dom -- meaning content tree under canvas)
... does work for some scenarios, not all (game)

MarkS: lisa is right.
... we hear from epub (e.g.) that focus stuff is important
... we should set a high a11y bar
... yes jmann, we do have sub dom, but drawFocusRing is an important component in making the sub dom accessible...
... seems like we're getting close and can meet a minimum bar
... is there a possibility for the big three browsers to get these all working minimally
... we are sending a message that there will be a rec without this a11y support.
... devs will say, my app meets canvas v1 and that is good enough for me, w/out a11y features.
... we should be cautious

cabanier: jmann said you can use shadow dom--it's pretty powerful and accessible
... the implementations in Fx and Cr are differnet, spec needs to be clarified
... I don't think it helps to ship something today
... no reason to not have a short level 2

hober: a 1.1?

paulc: here's another alternative
... no reason not to move these to an extension spec
... do these a11y features on top of canvas as an extension spec
... and not tie these new features to a v2 at all.
... what do folks think? It's another possibility.
... moving these out of band may be helpful

hober: clarify that we have a process for extension specs
... modularity is good
... there's a concern that extensions specs are less real

<MikeSmith> to be clear, I don't think cabanier was saying the implementations of the content tree under canvas (what in the past has been called the "canvas shadow dom") are different; instead he was talking about the implementations of DrawCustomFocusRing (I think)

hober: clearly not the case.

paulc: empowering people to work on a separate spec, improves it's visibility

cyns: to MarkS a bad API codified in browsers will live forever.
... we don't want to end up there.
... sounds like all browsers are working on this.

<paulc> who is rniwa?

cyns: moving to extension spec, v2, whatever may not be a concern

<rniwa> paulc: Ryosuke Niwa from Apple

cyns: does the idea of extension spec work for epub?
... I think it could work.

rniwa: google implemented in chrome.
... then AT comes in and shows the focus ring
... API is deceiving

<paulc> Thank Ryosuke

rniwa: may be worse having the bad feature name in the spec v1
... browser will be able to implement new features soon

<MikeSmith> about DrawCustomFocusRing and a11y, if people want a perspective from somebody who has particular insight all-around on this (including from having tried to implement it per spec), talk with Dominic Manzonni

rniwa: we will see interop soon

adrianba: will be brief, we all seem to be agreeing
... so why move this spec forward?
... some folks have said we need a rec, but why?
... agree with engineering discussion that needs to fix the focus stuff.
... it won't stop; browsers keep working on it.
... there are important IP considerations here.
... don't want to revisist
... there are some old discussions about canvas in HTML5
... the royalty free committment in the rec is desired
... there are important consequences to have a rec
... we're happy to see lots of green in the test suite

cabanier: some red box are because the test are relying on some html5 features that aren't working quite as nice in implementatios
... if we move this to extension spec

<MikeSmith> big +1 to what adrianba said about importance of getting canvas to rec for IP/RF-agreement reasons

cabanier: want feedback from a11y group on our open questions.
... let's not let the discussion die. We need to make progress.

paulc: summarize the state of the world
... we have CfC that I don't see consensus.
... we also have offline discussion going on, but we need to make this more visible
... especially janina & charles.
... we need to see answers on the list.
... we need to see the discussion in either the TF or somewhere else.
... how to move forward.
... I would get strong support for moving this forward, probably will get formal objections
... love given those FO's to the director
... please, cabanier, jmann, hober summarize your questions, take it to the list
... start good "solid" thread
... will make it easier for TF facilitators to identify next steps.
... we've met my goal of having an open discussion, and we've seen the test results
... show's we've got the right data to send to the director.
... thanks all!

<darobin> http://darobin.github.io/html-ruby/

ruby markup

darobin: we have minutes linked from somewhere.

paulc: prestart...

darobin: ruby has been a long-time problem in html
... some work over the years, but it wasn't done.
... last 2 years of use cases gathered by i18n
... based on this, we started on improving ruby in html
... we also coordinated with *those* css people
... because there's a complicated rendering that goes with it.
... and I think we've got it!
... on plenary day, we had a breakout session about ruby
... we agreed (non-binding) about

<r12a> http://www.w3.org/TR/ruby-use-cases/

darobin: taking the current ruby spec and integrate it into html

<paulc> W3C HTML Ruby Markup Extensions: http://www.w3.org/TR/2013/WD-html-ruby-extensions-20131022/

darobin: would include some limited parser changesj
... not huge changes
... adding rb elements so they're not implicit
... these are in content (real ruby content)
... also adding rtc elements
... (ruby text container)
... first step is do document this plan
... then to integrate the changes
... plan to do that in the next few weeks

<paulc> Ruby HTML CR bugs: 19251-19255 in:

<paulc> https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=ASSIGNED&bug_status=NEW&bug_status=REOPENED&component=HTML5%20spec&keywords=CR&list_id=29878

darobin: then speak to implementors
... I hope that with a few tests we'll show that ruby is interoperable
... to show decent ruby support in html5.0

paulc: showing the bugs related to ruby
... when we looked at HTML5.0 cr bugs, ~18
... 5 of these are fixed by the ruby extension spec.
... my question: after interop, and you attempt to fold in the new material.
... will the old info be corrected/replaced?

darobin: yes. I can close the bugs, the html spec will be fixed.

paulc: this will show interop in html.
... timeframe?

darobin: starting now

paulc: I know epub really needs this.

darobin: ditto

paulc: I've talked with some folks in the hallway that don't understand the licensing experiment
... using cc-by only applies to extension specs
... when we fold ruby back in, it will then be covered by the doc license of the HTML spec
... make sure that (for the community) we publish a heartbeat doc under cc-by that will be the exact same thing we fold in.
... if we all die tomorrow, someone could pick it up and run with it.

darobin: I can do that (publish the final ruby extension spec before folding it in)

paulc: questions?
... last call?
... we're on break!

<darobin> http://www.w3.org/html/wg/wiki/HTML_Normative_References

<hober> scribenick: hober

Normative References

darobin: in order to ship, we need to ensure the references in our spec are to things that are stable
... the documents they point at don't have to be entirely stable, but the features we rely on in them need to be
... i've been going through our existing references to fix
... erring on the side of inclusion

<masinter> ((can someone repost the URL of what is showing??))

darobin: many references are safe
... unused references have already been pruned from the spec

<adrianba> http://www.w3.org/html/wg/wiki/HTML_Normative_References

darobin: there are a number of refs that can be made informative
... e.g. the references to the whatwg wiki and becss can be made informative
... there are a number of references to LC or CR documents
... these are lower risk, overall they're fine
... then there are the problematic references
... many of them can be dealt with easily
... e.g. xhr, but we only rely on progress events
... so we can reference the other progress events doc instead

paulc: are these changes editorial or are you filing bugs for them?

darobin: changes are largely editorial

paulc: should we have an uber bug covering all of these changes?

darobin: any change that involves a change in behavior will have bug filed
... biggest issue are a chunk of references we can't possibly remove or make informative
... e.g. dom4, which this wg has taken on and will advance
... travis, where are you with dom parsing / innerHTML

Travis: I've made 3 years of progress in the past few nights
... I thought DOM parsing and serialization would be one bug fix
... i've ported bug fixes from the living standard
... hopefully start a last call next week

darobin: other problematic refs include encoding, url
... talking with anne, i think we can handle this
... nightmare reference is mime sniffing
... no w3c spec, whatwg spec full of missing pieces and TODOs
... we need this for image loading, etc.
... that document has some good parts, but we need a plan to get a doc we could rely on

masinter: this doc was in the ietf web security wg for a while
... abarth was working on it but abandoned it

darobin: went to ietf and got abandoned, went to whatwg next and has largely languished

<Daniel_Austin> [XHTMLMOD] should point here: http://www.w3.org/TR/xhtml-modularization/

paulc: why can't the html spec say this is up to the UAs?

MikeSmith: we need interoperable behavior here

paulc: are the existing browsers sniffing in the same way?

darobin: they're not

annevk: they're pretty close though

adrianba: i agree with aspiration to have clear spec on this
... but we don't have one

<masinter> to finish ALL of mime sniffing you have to specify file: and ftp:

adrianba: it would be OK but not desirable to leave it undefined now and fix it later

paulc: these are all subjective
... not many people in the wg realized robin was doing this work; i wanted people to be aware of it
... some of these need bugs to be more visible in the wg
... so interested parties can weigh in; people have different opinions
... would we hold up html5 until we can demonstrate interoperable sniffing?

masinter: to really spec sniffing, you need to spec it for http, ftp, files, etc
... no one's been willing to do this
... you could say there's some process to go from a url to data with a mime type, and leave it at that

MikeSmith: where we started was with this in the spec, then removed it
... if something isn't working per spec, not correct to punt and say it's UA defined
... [describes page loading as an example of this]
... i don't think this is a prudent way to go about this

<masinter> it would make more sense to merge it with "Fetch" and start a working group to finish fetch

MikeSmith: the only reason sniffing is separate is because we moved it out; it's logically the same spec

annevk: sniffing is largely interoperable

<masinter> i'm not in favor of saying "implementation dependent", but it is in the OS and not the browser in many cases

annevk: the work abarth did has led mozilla and chrome to have largely aligned behavior here
... most of the red boxes in the spec are related to work gordan has been actively working on

<MikeSmith> http://mimesniff.spec.whatwg.org/

darobin: you mean the spec looks bad but isn't that bad

annevk: yes
... the red boxes are around new stuff related to parsing and serializing mime types
... octet stream v. code point stream, etc.

<MikeSmith> MIME Sniffing spec

darobin: could we ship it in a year if someone worked on it

annevk: yes

<MikeSmith> we also need a test suite for MIME sniffing...

darobin: maybe we could do this as an extension spec

masinter: what about merging it with fetch?

annevk: i've been trying to think about the layering there
... not quite sure what i would think of that right now
... fetch is getting the bag of bits
... sniffing is an api endpoint thing and not a network thing
... fetch is about getting the bytes; endpoint decides what to do with the bytes

[HTTP example]

masinter: protocol could be "here's a uri, give me the bag of bytes and your best guess mime type"

paulc: we won't solve this today

masinter: one of the normative references marked safe
... multipart form data, RFC2388

<paulc> [RFC2388] Returning Values from Forms: multipart/form-data, L. Masinter. IETF.

masinter: hixie asked me to update it, since i wrote it 15 years ago

<paulc> see http://www.ietf.org/proceedings/88/slides/slides-88-appsawg-8.pdf

masinter: turns out people didn't do non-ascii names like RFC2047
... can we get some of the ietf specs updated to reflect new reality
... it was a lot of work to convince ietf ADs etc. to do this work

[summarizes form processing material from slides linked above]

scribe: i have a github repo

<paulc> https://github.com/masinter/multipart-form-data

scribe: i put the whatwg spec in the repo to, so we can figure out what will need to change in it
... i haven't fixed much
... still some work to be done to align this with reality

darobin: the classification i made is process-wise
... in terms of interop, this work is needed

masinter: you should edit the document to say this work is ongoing
... don't make a time dependence on this
... we should proceed to work on this, but not make it the long tentpole

paulc: raising a bug on this would give us a great way to track this

masinter: i would love help on doing the technical work

paulc: good way to get help is to file a bug

joint meeting with web performance wg

<adrianba> ScribeNick: adrianba

Web Performance


<paulc> http://microformats.org/wiki/rel-prerender

jmann: thanks for having us here - we have two topics that will be quick
... first topic is prerender
... we opened a bug 22737

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22737

jmann: today the html5 spec defines link rel prefetch but doesn't define prerender

<paulc> <link rel="prerender" href="http://www.example.org/survey/question-2">

jmann: both IE and Chrome support prerender and while we have added the item into the registry we were hoping to also get it into the html5 spec
... there was a discussion in the bug about putting in html 5.1
... but we have two implementations so we wonder if it will be able to go to 5.0
... they also support dns-prefetch - maybe we could bring this in too
... dns-prefetch isn't in this example but the approach is the same
... this is the first item

paulc: comments from the floor?
... either the general functionality or moving into 5.0?
... reps from webperf say they have interop

jmann: we can provide test cases

paulc: is there a spec?

plh: you are looking at it
... the spec says to do what we did and add to the wiki
... this is the spec as best as we can so far

paulc: are there other rel values in this page?

plh: this is just one value - dns-prefetch is somewhere else on the same wiki

paulc: the html5 spec proposed to use extensibility using the wiki
... why would we make your proposals more important by putting in the spec

jmann: because the spec includes prefetch - it is odd to only have half of the solution

plh: also this one has an impact on user agents - for example, the license one you looked at doesn't have an impact on UA
... like prefetch, these have an impact on UAs

paulc: so the list is two parts, those that impact UAs and those that don't and you would like to propose to get these into HTML5 because they do impact UA

<Jirka> list of rel values is at http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions

<darobin> http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions

larry: http 2.0 group is working on this using a push model
... and you might question the long term stability of this feature because of that

arvin: the http 2 implementation for push is different than this
... that is when the web server knows what to push

<plh3> https://developer.mozilla.org/En/Controlling_DNS_prefetching

<plh3> http://dev.chromium.org/developers/design-documents/dns-prefetching

arvin: but this is where the publisher is making a hint to the browser to decide what to do

rniwa: one qualifying question
... is the prerender required, are UAs required to do this or is it a hint

arvin: this is a hint

rniwa: so it is still valid if you don't do this

Daniel_Austin: how do developers do this in http2? web developers do this in mark-up

paulc: i think larry is saying that if servers are pushing and UAs pulling they have to work together
... as co-chair, you have done the right thing putting it into wiki
... you have asked us about putting in html
... plan 2014 says publish an extension spec and if you catch up in time then it can be folded into html5
... so if you have the spec with the test cases and through the process and you catch-up to html 5.0 then you could better propose adding in
... worst case you miss the train but you have the spec and demonstrate interop

Resource Priorities update

jmann: second item is webperf wg is working on new spec called resource priorities
... touches html and we wanted to make sure there is visibility
... want to get your feedback
... today browsers download resources in doc order
... we don't have signal from dev about what is important
... we want dev to give browser a hint about what is important
... we have lazy load attribute to give to elements

<sunyang> can you provide a link about this, thank you?

<paulc> http://www.w3.org/TR/resource-priorities/

jmann: in cases of constrained network, for example, no more connections available

<sunyang> thanks

<paulc> http://www.w3.org/TR/resource-priorities/#attr-lazyload

jmann: priority would be given to elements that do not have this attribute

<paulc> http://www.w3.org/TR/resource-priorities/#attr-postpone

jmann: we are also considering postpone attribute which means don't download unless in the viewport
... touches image element for example
... want people to see this and give feedback
... may be in this one spec or maybe we put html pieces in html and svg in svg
... but we're doing end to end design first

darobin: as a general comment this is interesting - of course needs work
... in terms of putting in html spec i don't think we need everything related to html in the html spec
... big doc published not often
... if can define orthogonal and can implement on its own then in general better not to touch html spec
... not rejecting idea - just a process question
... this simplifies life
... of course sometimes it makes no sense to stay outside

paulc: if it is an extension spec then needs to track whether it applies to new elements
... but it isn't amending deep understanding of algorithm, where having that outside makes life harder

darobin: for example, html template was making parser changes and was hard to review
... next question is bikeshedding but it looks like lazy load is not doing lazy load
... lazy load is load when you need it but this is about not loading when resource restricted

jmann: we're open to name changes - initially was defer but that existed
... looking for single word - it is fpwd looking for ideas

<plh3> http://www.w3.org/2013/Talks/1015-webperf-update/#/7

plh: i did presentation about lazy load last month listing how it affects script element
... we are modifying ordering of when things happen
... both for async and defer
... so that would modify precise ordering question especially for defer
... then maybe that would be one consideration

<fantasai> wrt name changes, I propose swapping 'postpone' and 'lazyload'

darobin: good point - if impacting the way script is loading when it is supposed to be deterministic then it warrants a change to the spec

larry: if resources are on multiple servers then it can't be deterministic

<fantasai> since postpone is really more about lazyloading, and lazyload seems to be more about postponing

adrianba: the html5 spec does make it deterministic today so this would be a change

hober: more of a css question - how does the webperf wg think the postpone value of the resource-priorities css property will interact with the preload scanner?

jmann: we're considering removing that piece - we put it in to get broad feedback
... with the network layer and styling being far apart it doesn't make much sense
... we got lots of good feedback yesterday
... and so the spec is out of date
... so please review and continue to give feedback

paulc: did we meet the webperf wg goals?
... about how to fold things in to html5
... and getting visibility
... we will hold people to plan 2014
... we have lunch from now until 1.30 for EME

<yohsumi> quit

<paulc> track0at, start meeting

<paulc> trackbot, start meeting

<trackbot> Meeting: HTML Weekly Teleconference

<trackbot> Date: 15 November 2013

EME bugs Part 3

<paulc> test

<paulc> Bug 23619 - Drop or change MediaKeyError constant prefix

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23619

<hober> ScribeNick: hober

paulc: recent comment: do we use an enum or character error codes
... david is looking for suggestions on how to do this

<paulc> see https://www.w3.org/Bugs/Public/show_bug.cgi?id=23619#c6

adrianba: we asked alex and travis for guidance on this
... we probably need a bit more help to get this right
... the solution is to use the name attribute of error
... we also need the system code, we can't use DOMError, so we'll extend it
... this way we don't have to define a list of numeric values

paulc: which of numeric short or string do you end up using?

adrianba: neither
... this bug represents the pattern we should use

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21798

adrianba: bug 21798 is the bug which tracks exactly what the errors should be and what strings we'll need

<slightlyoff> sorry I can't be tehre in person; happy to help design a good answer; likely with Yehuda, Travis, and Anne.

<paulc> Proposed errors are in thread at: http://lists.w3.org/Archives/Public/public-html-media/2013Nov/0011.html

adrianba: for now we can say that these two bugs track the errors related to sessions
... we need to finalize granularity of errors

<scribe> ... ongoing discussion; we probably won't finish up this meeting

paulc: action on edtitors to make a concrete proposal?
... yes, editors will resolve these two bugs


adrianba: we've revisited this several times to get all the issues raised
... bug is misnamed now

<paulc> see http://lists.w3.org/Archives/Public/public-html-media/2013Nov/0011.html

adrianba: there are a couple of interrelated things here
... this is also error related
... previously we tried to define the error that would occur when an application unaware of eme tries to load encrypted content
... when the needkey is fired, it was providing information about the media to the application
... that can't happen cross-origin
... so we also threw an error
... this is complicated
... but we've arrived at a simpler approach
... described in comment 30
... instead of throwing an error, we will fire the needkey event again but without the init data
... if an app can get the init data from another source, it could continue playing
... instead of detecting apps which can't handle eme, we know that the media element will block waiting for a key and it'll never get one
... which is fine since it never would have played anyway
... this lets us eliminate MEDIA_ERR_ENCRYPTED

<paulc> see https://www.w3.org/Bugs/Public/show_bug.cgi?id=21203#c30

adrianba: this is a bit messy, since we're extending an enum from HTML5
... there's a risk of collision, so it's nice to eliminate the need to do that

paulc: you now have a way forward here?

adrianba: yes
... we will implement this soon unless we get objections


<paulc> see https://dvcs.w3.org/hg/html-media/rev/196e6b904b22

adrianba: i've implemented most of what's necessary for the new closed state

paulc: would you like an answer to the question here (in the bug)

adrianba: i wasn't sure how to handle this re: key release; maybe it should be discussed when we talk about that bug
... maybe we need another bug for finishing key release
... i have to update the state transition diagram to match the new text


adrianba: this is how we're tracking features at risk for cr
... keysystem attribute of source element
... had a bug to remove the attr
... we will keep it for now, but if people don't implement it, there's a concern
... so this is a good candidate for the cr at risk list
... wondering where keyrelease will fit into this
... haven't heard of any planned implementation
... at least in the same timeframe as the rest of the spec
... there's a bunch of remaining work to do to define key release
... raises the question: should we spend the time now to add it (in v1) given the lack of implementor interest?

paulc: you mean, if we're going to put it at risk, should we even bother finishing the work on it now

adrianba: yes

markw: 1) what exactly do we need to document for key release
... may want to document as little as possible, like the heartbeat feature
... with key release, you just go through the PENDING state into the CLOSED state
... we need a mechanism to retreive an old session
... could explicitly provide session id for previous session
... 2) should this be at risk? i expect there to be implementations
... i don't have problems marking things as at risk
... maybe doing so will cause implementations to happen sooner

paulc: is this a feature of significant value you'd want to use on your site?

markw: yes

paulc: which bug is this under? 17199?

markw: arguably yes
... with the CLOSED state, we could declare the messaging in that case done, which just leaves recovering pre-existing sessions

<paulc> Key releas MRDV (minimum required to declare victory) is in bug 17199: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199

ddorwin: there are various other scenarios that we're not targeting here

[...scribe missed...]

ddorwin: there's a whole host of other issues we may need to deal with

adrianba: sounds like mark is happy to do the editing work for this

markw: we need to decide what we want to do first

adrianba: build a strawman and add it; people will file bugs on it

ddorwin: section 5 is just sitting there; need to revisit after this

paulc: looks like 17199 is on markw
... media tf meets in ~2 weeks
... please send agenda info on this to the list


ddorwin: this is related to the source element
... how to most reliably get best performance across impls
... you can get that with source element instead of js
... this bug suggests to create new media keys with the key system when you have a source element match
... implicitly run when source element is selected

adrianba: it seems like a simple change

paulc: what haven't we touched?


ddorwin: did this yesterday

<paulc> see https://www.w3.org/Bugs/Public/show_bug.cgi?id=20991#c9


ddorwin: we added the suggested text and removed some old incompatible text

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20991 for previous discussion

ddorwin: this discussion led to the new <source> bug we just talked about (23828)

adrianba: wanted people to know we've done this work
... and how we arrived at the followup questions

ddorwin: we closed some other bugs during the meeting

[bug math]

paulc: we're making progress
... these 15 bugs are all in progress
... any specific ones you want review on?

ddorwin: the error codes one

paulc: getting the granularity correct

ddorwin: yes

<paulc> Thread on error codes would be good to get input on: http://lists.w3.org/Archives/Public/public-html-media/2013Nov/0011.html

ddorwin: we want to make sure the error codes we define have use cases
... error codes that an application can actually do something with

adrianba: it's not whether to signal an error, but when to distinguish errors
... is an app going to display something different to the user when it sees a different error code?
... we haven't yet talked about bug 21854


adrianba: we're debating : should an application be able to call update at any point?
... my proposal is that we should be precise about when you're allowed to call update
... ddorwin has some cases where he would like more flexibility
... we talked about all the other bugs yesterday

paulc: yes

<scribe> topic : adjournment

paulc: thank you everyone for attending
... neither the wg nor the media tf are meeting next week
... i encourage people who participated in the canvas discussion to join the a11y tf call on thursday
... still haven't decided what the plan is for the next F2F
... likely to be in the spring
... other working groups are interested in colocating
... we'll start planning in more detail in december

daniel_austin: ebay hosted 5 wgs last spring, including html and webapps
... we'd be more than happy to do it again this coming spring

paulc: thank you for the offer!
... we are adjourned

RRSAgent: make minutes

Summary of Action Items

[NEW] ACTION: erica to resolve bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=23208 as discussed [recorded in http://www.w3.org/2013/11/14-html-wg-minutes.html#action09]
[NEW] ACTION: erika to resolve bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=23208 as discussed [recorded in http://www.w3.org/2013/11/14-html-wg-minutes.html#action10]
[NEW] ACTION: hober to resolve 18728 https://www.w3.org/Bugs/Public/show_bug.cgi?id=19728 [recorded in http://www.w3.org/2013/11/14-html-wg-minutes.html#action08]
[NEW] ACTION: Paul to report back about the plan for 20944 due 2013-12-15 [recorded in http://www.w3.org/2013/11/14-html-wg-minutes.html#action03]
[NEW] ACTION: Paul to work with Wendy to make sure we get a security review [recorded in http://www.w3.org/2013/11/14-html-wg-minutes.html#action02]
[NEW] ACTION: paulc to coordinate with Web Apps on the streams API, give them MSE requirements and timeline [recorded in http://www.w3.org/2013/11/14-html-wg-minutes.html#action01]
[NEW] ACTION: robin to give us a revised overview of testing document - in 4 weeks [recorded in http://www.w3.org/2013/11/14-html-wg-minutes.html#action11]
[NEW] ACTION: Steve to resolve bug 21579 and will provide spec text https://www.w3.org/Bugs/Public/show_bug.cgi?id=21579 [recorded in http://www.w3.org/2013/11/14-html-wg-minutes.html#action07]
[NEW] ACTION: stevef to resolve bug 21579 and will provide spec text https://www.w3.org/Bugs/Public/show_bug.cgi?id=21579 [recorded in http://www.w3.org/2013/11/14-html-wg-minutes.html#action05]
[NEW] ACTION: SteveF to resolve bug 21579 and will provide spec text https://www.w3.org/Bugs/Public/show_bug.cgi?id=21579 [recorded in http://www.w3.org/2013/11/14-html-wg-minutes.html#action06]
[NEW] ACTION: stevefaulkner to resolve bug 21579 and will provide spec text [recorded in http://www.w3.org/2013/11/14-html-wg-minutes.html#action04]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2013-11-15 06:24:40 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/webplatforms.org/www.webplatform.org/
Succeeded: s/eitehr/either/
Succeeded: s/chagnes/changes/
Succeeded: s/chagne/change/
Succeeded: s/prodcue/produce/
Succeeded: s/workign/working/
Succeeded: s/secitons/sections/
Succeeded: s/taht/that/
Succeeded: s/disucussed/discussed/
Succeeded: s/droppign/dropping/
Succeeded: s/siid/said/
Succeeded: s/objections from/no objections from/
Succeeded: s/??%/50%/
Succeeded: s/more that/more than/
Succeeded: s/david's/joe's/
Succeeded: s/something else/communication between CDM and client-side application code/
Succeeded: s/thikn/think/
Succeeded: s/have very big @@/are already supporting playready/
Succeeded: s/ac adr//
Succeeded: s/secruty/security/
FAILED: s/rich/rice/
Succeeded: s/ddorwin: I think the privacy and security issues were the last outstanding from that draft/ddorwin: I think this and the privacy and security issues were the last outstanding from the discussion around FPWD/
Succeeded: s/ague/vague/
Succeeded: s/[very fast talking]/you to map from the playready API to the CDM API so everyone doesn't have to determine that independently/
Succeeded: s/or more/or be more/
Succeeded: s/hello hober!//
Succeeded: s/yar/year/
Succeeded: s/sepc/spec/
Succeeded: s/WAI/WAI and pF/
FAILED: s/A10y/A11y/
Succeeded: s/editoria/editorial/
Succeeded: s/serious/series/
Succeeded: s/tets/tests/
Succeeded: s/shadow dom, but/sub dom, but drawFocusRing is an important component in making the sub dom accessible/
Succeeded: s/my app needs only canvas v1/my app meets canvas v1 and that is good enough for me/
Succeeded: s/yanina/janina/
Succeeded: s/it is and absurdly//
Succeeded: s/this will work with postpone in css/the postpone value of the resource-priorities css property will interact with the preload scanner/
Succeeded: s/diagram/state transition diagram/
Succeeded: s/19156/20991/
Succeeded: s/19156/20991/
Found Scribe: cyns
Inferring ScribeNick: cyns
Found Scribe: cyns

WARNING: "Scribe: cyns" command found, 
but no lines found matching "<cyns> . . . "
Continuing with ScribeNick: <cyns>
Use "ScribeNick: dbooth" (for example) to specify the scribe's IRC nickname.

Found Scribe: cyns_
Inferring ScribeNick: cyns_
Found ScribeNick: darobin
Found ScribeNick: adrianba
Found ScribeNick: edoyle
Found ScribeNick: glenn
WARNING: No scribe lines found matching ScribeNick pattern: <glenn> ...
Found ScribeNick: glenn__
Found Scribe: MarkS
Inferring ScribeNick: MarkS
Found Scribe: travis
Inferring ScribeNick: Travis
Found ScribeNick: Travis
Found ScribeNick: hober
Found ScribeNick: adrianba
Found ScribeNick: hober
Scribes: cyns, cyns_, MarkS, travis
ScribeNicks: cyns, cyns_, darobin, adrianba, edoyle, glenn, glenn__, MarkS, Travis, hober

WARNING: Replacing list of attendees.
Old list: Shenzhen Amy Aaron_Colwell +1.925.648.aaaa joesteele_ Shenzhen.a
New list: Shenzhen joesteele_

WARNING: Replacing list of attendees.
Old list: Shenzhen +1.503.264.aaaa joesteele_ Shenzhen.a stevefaulkner James_Craig
New list: +1.971.998.aaaa Shenzhen +1.971.998.aabb +1.503.264.aacc WayneCarr

WARNING: Replacing list of attendees.
Old list: +1.971.998.aaaa Shenzhen +1.971.998.aabb +1.503.264.aacc WayneCarr
New list: WayneCarr Shenzhen

Default Present: WayneCarr, Shenzhen
Present: WayneCarr Shenzhen Adrian_Bateman Glenn_Adams Arnaud_Braud Jonathan_Jeon mark_vickers
Agenda: http://www.w3.org/wiki/HTML/wg/2013-11-Agenda#Agenda

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 14 Nov 2013
Guessing minutes URL: http://www.w3.org/2013/11/14-html-wg-minutes.html
People with action items: erica erika hober paul paulc robin steve stevef stevefaulkner

[End of scribe.perl diagnostic output]