See also: IRC log
<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
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
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
<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
<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?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17660
david: this was filed by joe a long time ago
adrianba: this is one of my actions that I didn't complete
ACTION-54?
<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
https://www.w3.org/html/wg/media/track/actions/54
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22909
<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?
[silence]
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23733
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
DASE
<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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944#c31
<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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17202
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21869
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17202
<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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21869
<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
to support the ISO Base Media File Format
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673
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
the key for an encrypted block is not available
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23619
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
<SteveF> This is editorial and should not be blocking anything (in my opinion)
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21579
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=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
<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....
http://www.w3.org/wiki/HTML/wg/2013-11-Agenda
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/
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:
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
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
<adrianba> ScribeNick: adrianba
<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
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
<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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21203
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17750
<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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23827
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23828
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?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20991
ddorwin: did this yesterday
<paulc> see https://www.w3.org/Bugs/Public/show_bug.cgi?id=20991#c9
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19156
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=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
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]