HTML Working Group face-to-face -- 09 Apr 2014

<krisk_> rubys: meeting at recess until tomorrow morning at 9am PST

<gitbot> [13syntax] 15sideshowbarker pushed 1 new commit to 06master: 02https://github.com/validator/syntax/commit/cb21b5354cc6fd939cf38e8221282c17b6f5e79d

<gitbot> 13syntax/06master 14cb21b53 15Michael[tm] Smith: Minor change.

<gitbot> [13html] 15techtoons pushed 1 new commit to 06html5_canvas_CR: 02https://github.com/w3c/html/commit/c209df326f23fa17f95edf9187dfab12e231a0ef

<gitbot> 13html/06html5_canvas_CR 14c209df3 15Jay Munro: Added clearHitRegion() and other edits...

<gitbot> [13html] 15techtoons pushed 1 new commit to 06html5_canvas_CR: 02https://github.com/w3c/html/commit/b17e400197770c9cae24bbd7b5398076cc02ce3f

<gitbot> 13html/06html5_canvas_CR 14b17e400 15Jay Munro: added trace a path back...

<scribe> scribenick: joesteele

<markw> .me conference bridge is still "restricted"

<plh> passcode is 26631

<plh> please use this when connecting on the bridge

paulc: walking through the agenda first
... this is the meila - http://lists.w3.org/Archives/Public/public-html-media/2014Apr/0058.html
... posted a link to the review of the pull request

<krisk> A number of issues are in the 'critic' tool - indeed some good tests that expose interop issues in IE and Chrome

paulc: some comments supplied by folks in the room

<krisk> https://critic.hoppipolla.co.uk/r/951

paulc: maybe Phillipe could give a review

phillipe: <discussing the review process>
... fixed link in one of the test -- Simon saying it needs to be fixed
... once it is addressed, people says whether is acceptable

paulc: was Aaron notified of each of the comments?

acolwell: hadn't been notified of some comments
... put saw when Kris posted to the pull request

paulc: next step is for Aaron to work with the critics and see what changes can be made

discussion of which email address should be used -- looks like Aaron was setup incorrectly

acolwell: ok -- did not know about the comments before

paulc: right -- I coped the folks sending comments and sent to you

<krisk> Until the critic email notification is fixed we can just make sure to make a comment in github when their is a status change

paulc: like to assign an action item to you for this

acolwell: ok

<scribe> ACTION: acolwell to Review the comments on proposed MSE test suites in two weeks [recorded in http://www.w3.org/2014/04/09-html-wg-minutes.html#action01]

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

acolwell: resolution may take longer to figure out what the right behavior is

paulc: if you need help with github -- ask

CR bug status of MSE

paulc: 5 of these bugs are fixed
... aaron sent out "cyril draft"
... going to second link in the email
... Aaron summarizes long thread about this problem
... some expressions of support for this direction
... in email

acolwell: David Singers resposne talks about one of the requests
... resolution for this I think is two remove some of the definitions MSE makes of language and time on the track objects

paulc: MSE proposed to make language and time mutable -- ie change in full flight
... lots of push back on this
... general conclusion is that those should be fixed during the track and should not change
... applies to audio, text, anything

?1: user can elect to change

acolwell: proposed changes is to remove the definitions from MSE
... MSE will conform to what HTML5 spec says does not add text for this
... if time needs to change within a track follow HTML5 guideline
... think that means removing the track and adding a new track
... second part -- one of orig. justifications is that time is not available in ISOBMFF file
... third thing - MSE spec should be more clear around language and time
... looking for input from David and others on how to change this MPEG spec

<joesteele_> pal: one #2 have a question

<joesteele_> ... are you syaing this cannot be communicated via HTML5?

<joesteele_> acolwell: no - saying we would defined boxes saying what the time attributes could be -- not communicated today

<joesteele_> pal: this might exist outside the ISOBMFF package?

<joesteele_> acolwell: if so then the app has to deal with it

<joesteele_> pal: then you are proposing to duplicate this rather than using it where is is today?

<joesteele_> pal: is there another way of communicating that information so it can be reflect back to the HTML attributes?

<joesteele_> acolwell: could probably define special docs? to do this

<joesteele_> paulc: pierre is looking for an API solution

<joesteele_> pal: trying to avoid having these boxes be a requirement

<joesteele_> acolwell: making time immutable seems to be most natural - but that creates a problem

<joesteele_> pal: would like to explore ways of doing this that do not require a new required box

<joesteele_> cyril: I proposed with CableLabs some extensions to the DASH manifest for new roles values that would map to HTML time

<joesteele_> ... I think would be a good idea to carry the time in the MP4 format for WebVTT for example

<joesteele_> ... I also agree with Pierre - maybe an API to set the time and language in some sort of constructor

<joesteele_> ... not at just any time -- would be useful

<joesteele_> markw: the kind needs to be in the manifest whatever manifest we use

<joesteele_> ... application needs to know before it is downloaded

<joesteele_> ... could also be in the MP4 file but must be in the manifest

<joesteele_> ... also agree that there is not need to change it after construction

<joesteele_> BobLund: agree it should be in the manifest and should not be mutable

<joesteele_> ... but not all media formats include thi sin-band

<joesteele_> glenn: if we add something to ISOBMFF need to add for other formats

<joesteele_> ... seems to have been added by WebVTT folks

<joesteele_> cyril: need to make my contribution public and then will send to the list

<joesteele_> paulc: sounds like this was made to imply it is mutable at any time

<joesteele_> ... but having a constructor to set this would be a good idea

<joesteele_> acolwell: have a chicken and egg problem - no point at which you can intercept construction of the track

<joesteele_> cyril: but when your source buffer is single track this is possible?

<joesteele_> acolwell: not sure what that buys us though

<joesteele_> paulc: sounds like we have concensus for #1

<joesteele_> pal: #2 is not sufficient

<joesteele_> paulc: #3 we need to get these changes made to HTML5 - and what she should do about it is the next step there

<joesteele_> ... pal - you need to respond to this and continue the dialogue

<joesteele_> ... we can get #1 and #3 started

<joesteele_> ... Aaron think that is enough for today

<joesteele_> acolwell: think we have concensus for #1 - is there an alternate proposed or should I just remove language?

<joesteele_> paulc: I am ok with leaving the bug open with note about waiting for concensus

<joesteele_> acolwell: since we are removing mutable language -- process issues?

<joesteele_> paulc: worry about that later

<joesteele_> .. .may be first of several items

<joesteele_> ACTION: paulc to make sure HTML5 bugs filed for item #3 [recorded in http://www.w3.org/2014/04/09-html-wg-minutes.html#action02]

<trackbot> Created ACTION-243 - Make sure html5 bugs filed for item #3 [on Paul Cotton - due 2014-04-16].

Editors draft

<joesteele_> paulc: Aaron published an editors draft that resolve 3 of the bugs - cyril should review

<joesteele_> cyril: will review

Audio bytestream format

<joesteele_> paulc: Aaron posted this in his email -- seemed to be some support

<joesteele_> cyril: yes I was about to submit something for that also

<joesteele_> cyril: question about byte range format - would work as expecte din sequence mode but not in segment mode - correct?

<joesteele_> acolwell: would act very similar

<joesteele_> s/expect din/expected in/

<joesteele_> cyril: will look more carefully then

<joesteele_> paulc: if Aaron posts the link in that email you can contiue to provide comments

<joesteele_> ... Aaron more to talk about?

<joesteele_> acolwell: are people ok with me putting the spec in the registry?

<joesteele_> paulc: any objections or more time needed?

<joesteele_> jdsmith: would like to review

<joesteele_> paulc: please add this to email

<joesteele_> s/?2: /jdsmith: /

<joesteele_> pal: question about Aarons concern - is the concern that when you do addfundbuffer, you don't know how many tracks will be created?

<joesteele_> acolwell: application has not information to uniquely identify tracks, so would be hard for application to target tracks

<joesteele_> pal: go it

<joesteele_> paulc: reviewing email again --

<joesteele_> ... Aaron will hold of on making changes until more dialog about API possibilities

<joesteele_> ... box format will wait for more feedback from David Singer

<joesteele_> ... Cyril will review spec updates

<joesteele_> ... Jerry will take time to review audio formats

EME discussion

<krisk> scribe: krisk

We are going to be going through a number of EME Bugs

See -> http://lists.w3.org/Archives/Public/public-html-media/2014Apr/0051.html

First bug is https://www.w3.org/Bugs/Public/show_bug.cgi?id=25199

EME should use promises

EME Should use Promises

Bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=25199

Which Blocks: 17750 21798 24081 24216 24771.

<MikeSmith> excellemente

All the bugs deal with async and promises are mechanism for async

At the last meeting April 1st people needed more time to think about using promises for this purpose

The main bug has the proposed IDL change

Any feedback?

joesteele: This is a good change and in the direction of the W3C tag
... are other changes like this going to be made in HTML5? Or will it wait until 5.1?

darobin: New apis are expected to use promises

paulc: Others have been changed in last call/WD status even before promises moved out of DOM4 and into ECMA script
... any objections?

adrianba: This is a good direction and change to make, but I have some detail questions
... for example I'm not sure how the promise works with the release method
... it's not clear when the promise completes
... The best approach maybe to make this change and then itterate on the details that comeout

ddorwin: Yes I added a comment in the bug about this.

paulc: Room agrees
... I'm concerned about not discussing the other bugs that are blocked

* Hi johnjan!

jdsmith: We have all replied back to these bugs

paulc: What I am asking for when is the next meeting and with enough next steps to know the overall status of the next meeting
... Maybe these 'blocked' bugs can be addressed or have progress on once the main bug is addressed (25199)

ddorwin: Some of these may just be fixed or need minor changes

paulc: Once the root bug is fixed can you send something to the TF on what needs to be done with the other bugs (maybe close/duped by the root bug)

<scribe> ACTION: ddorwin [recorded in http://www.w3.org/2014/04/09-html-wg-minutes.html#action03]

<scribe> ACTION: ddorwin to fix the main bug and propose a direction for the other 5 blocker bugs [recorded in http://www.w3.org/2014/04/09-html-wg-minutes.html#action04]

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

joesteele: Some of the bugs may not be fixed...

Bug 17750, Bug 24216

paulc: The right think to do is send an email that even with the async change these bugs won't be addressed

joesteele: OK

adrianba: I wonder if we can have this discussion now about these bugs

joesteele Sure

joesteele: Let discuss and email on the list

<joesteele_> http://lists.w3.org/Archives/Public/public-html-media/2014Apr/0004.html

joesteele: The issue I'm trying to raise here - a session is composed of licenses and keys
... Load session and release assume a single content key
... You can deliver keys at a higher level that a specific content stream
... if you impl release/session on a lower level it can impact a higher level

<joesteele_> https://docs.google.com/drawings/d/128iTMqVgI3gCPo7q1mB2RIq-iCV3og0FMfVlY0mRWOg/edit?usp=sharing

<joesteele_> this is the diagram I was talking about

joesteele: This is from a number of DRMs
... It more complex - device, player, content and wrapper keys
... The spec needs to allow the CDN manage these keys

The app need to just know about two keys

scribe: Mark has talked about an app releasing a specific key - so that a movie can then be played on another device

paulc: These are really about the API and not about the async

joesteele: Yes this orthogonal to the async bug

paulc: do we have a specific bug that covers supported a differenet model

ddorwin: I'm not aware of such a bug

<joesteele_> This is the bug -- https://www.w3.org/Bugs/Public/show_bug.cgi?id=25218

joesteele: Bug 25218 is close but not complete

paulc: Is this email linked to bug #25218

ddorwin: The goal is to make various systems interoperable

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

ddorwin: alot of other ways exist
... but EME is generic and simple
... the model is session based
... What happens if you load a key from another sessions, you should not do this...
... I understand the domain thing, but I don't think it's interoperable
... Likewise if it's built to support a specific device it won't work on other devices
... I'm worried that do this change will cause more interop issues
... We should fix the common case and then move to some other complex cases
... For example web crypto..

niels_t: We do see limits in EME

<joesteele_> +q

niels_t: allowing the CDM to contact the license server directly
... intitlal for legacy
... but now we see additional use cases (init)
... could be allowed by this change
... it could be more of a conceptual change in the abstract

glenn: To the comments about supporting exist solutions
... EME came about to support existing systems is an implicit goals
... from cox's perspect we do have intrest in various legacy systems (adobe, microsoft, etc.) would be a major issue for adopting EME

pal: At a very high level, encrypted media comes in, but I have a CDM
... I get a key and decrypt
... or a few others, so I create a connection to the CDM
... CDM can make a call to get the right keys to the client
... This part doesn't really matter - how the keys get created by the CDM
... I don't understand how this impacts apps

ddorwin: It comes down to wanting to release a single key driven by the app and impact the whole session

pal: doesn't the api support this?

joesteele: But this starts all over
... I'm done releaseing the license for a movie the only way is to release them all

ddorwin: joe wants to release some but not all keys

joesteel: The CDM can tell the app to release specific keys
... The spec says to release all keys

pal: I'm just trying to understand

ddorwin: I don't think the spec states this..

others agree in the room

glenn: But the app has no 'hints'

pal: The current spec doesn't block this..
... are we missing arguments in the release call itself?

boblund: If the you want to persist some information then the CDM needs some information

ddorwin: Their is ambiguity in this and they exploit this ambigutiy we have interop issues
... We are seeing this in real places that breaks interop
... This is even using the simple model that makes a Chrome, Microsoft and Adobe app not work when they should
... I want to point out that it's not just about API compliance, it's about the behaviour you get
... So we need to not have this ambiguity

<joesteele_> +q

ddorwin: I have seen in production this breaks interop and solve behaviour compliance and not just the API compliance

markw: I think that ddorwin if correct that removing complexity is the way to go

<joesteele_> my goal is to *hide* the complexity not to expose it

markw: The whole point about EME was to make this easy and simple which will address interop on various devices

<ddorwin> I agree with what Mark said above.

boblund: I agree with markw that EME should make things as simple as possible
... But if we don't suport uses cases that are used today we are not going to get broad adoption

niels_t: from my analysis side channel communication will help interop and enable broad adoption
... I don't know the limits where a specific interop issue will arise with side channel

ddorwin: This won't work with current EME and impacts privacy and security (CORS)
... part of the spec process is to respect normal web security and privacy

glenn: On a release issue - release is only advisory issue, correct?

ddorwin: correct

<gitbot> [13html] 15darobin pushed 1 new commit to 06CR: 02https://github.com/w3c/html/commit/043fcbf6006a8c540aedd8dad0a6cf57408bab07

<gitbot> 13html/06CR 14043fcbf 15Robin Berjon: trailing comma in enum SelectionMode...

glenn: So adding a hint doesn't seem to increase ambiguity

<gitbot> [13html] 15darobin pushed 1 new commit to 06master: 02https://github.com/w3c/html/commit/6af16dbb6b11ba3ba71a8696707ae78eaff62726

<gitbot> 13html/06master 146af16db 15Robin Berjon: trailing comma in enum SelectionMode

glenn: since we have not speced the UA to CDM nothing is preventing the UA to create issues
... maybe it's not a problem between CDM and UAs
... I think their are options here

pal: I'm trying get to the actual spec, let's talk about release
... is their a problem with release as spec'd

joesteele: Yes it needs to be more specific

pal: It's spec'd as a hint...

joesteele: I have seem that this has become more than a hint and impacts a CDM
... The last thing I wanted to point out was that adding support for domains increase complexity
... We just need text in the spec that either says this is OK or gets specific
... leaving this in the domain in the CDM

paulc: are their any specific bugs to change the release method?
... Because I don't see them..

joesteele: Not in the bug just in the email

paulc: Let's try to continue on the agenda and assume when we get to the related bug later to skip over since we had a good discussion about this issue

<joesteele_> q:

Bug 25267 - Remove ability for in-memory sessions to be re-used

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25267

paulc: are the dependancies correct?

ddorwin: It's to deal with interop issues

dorwin: I think we need to have more consistent behaviour
... when doing adaptive streaming you can get the same keys, over and over
... which will create new media sessions
... So this text was added to just re-use an existing session

Paulc: is related to 25268?

ddorwin: I'd like to find a new way other than this bug..basically if we fix bug 25268 it should resolve this issue

pal: can we bring up the text?

<ddorwin> 25267 is referring to the Otherwise branch of step 10 of https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#dom-createsession

ddrobin: basically remove all of the checks...
... or maybe refered to in the normative note

adrianba: I think it's section 6.2

ddorwin: I agree with adrianba (other than what we discussed earlier)

joesteele: I need more clarity

ddorwin: You would always expect a message to be fired

pal: TO understand the specific
... step 10 would be changed?

paulc: no in step 6 is where it will get done

adrianba: yes, at the end in step 10 you can move to ready
... basically you don't need to fire a message
... so step 6 part 2 make this required

pal: request variable, what is the variable type?

adrianba: the message attribute has this information

pal: the proposal is to always fire the message, but could be null

adrianba: could be an empty array
... I think having empty messages could cause more interop issues

ddorwin: I agree with adrianba

joesteele: I don't here is why..

one case is that the device has the key and not need to make a request

ddorwin: This is not interoperable

joesteele: I like the way the spec is today..

paulc: what should we do with these bugs?

ddorwin: I know what I'd like to do with these bugs...
... not take this change and accept 25268

adrianba: I don't understand why making firing the event optional makes writitng apps harder

ddorwin: This came from app devs...
... I'd like to solve the overall problem and then this goes away

pal: Do we have specifics from an app dev why making this change makes it easier

ddorwin: putting the app in control - maybe they want a new session is lost with this change

paulc: so their is no symetry

adrianba: why would you want this??

pal: is it that the app started a new session and didn't get a new key from the cdm
... on the new session?

ddorwin: yes that is what was presented to me
... it's really up to the CDM

joesteele: It really is that the CDM may or maynot provide a key
... maybe add another flag?

ddorwin: I'd rather move to the next bug which will fix this issue

paulc: will the editors take on these bugs?

adrianba: we have not reached concensus on 25267
... and have not discussed 25268 to set the scene

with 25268 ddorwin is describing a problem we have discussed a few times

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

scribe: basically you end up with multiple net requests...
... it doesn't sound like this woudl be a complete fix

ddorwin: 25268 is the biggest issue for EME app devs..

Bug 25268 - Reduce the burden on applications to dedupe initData from

ddorwin: what is an app to do? simplest is to ignore but is key system specific
... the goal is to allow the app to know what to do...
... The previous misses some cases
... It pretty complex for an app to deal with..
... and might break down with key rotation
... even in the previous bug you'll end up with hundreds of sessions which is not good

<paulc> Review previous bugs related to this: (bug 16553, bug 19208, bug 21855)

paulc: Please review the old bugs listed in 25268

Bug 25269 - Add a container-independent initialization data type for

see https://www.w3.org/Bugs/Public/show_bug.cgi?id=25269

ddorwin: nothing fundemental says that the keys must come from the media
... basically it's container independent structure for keys or psh systems
... the license request should not be restricted by a container format
... simple just need to make it accessible via javascript
... herry was asking why psh's are even needed?

<paulc> See historical email about PSSHs: http://lists.w3.org/Archives/Public/public-html-media/2013May/0018.html

ddorwin: but this is ortho to this issue

joesteele: The reason I brought this up - not that this is a bad idea
... How would one support this for content that exists
... the only mechansim for how I would support tihs would be to make a new request and I would get the actual psh
... which leads to what is in the session, since thie psh is now part of the session
... It's not a bad idea but I don't see how this would work for DRM's that use pshs

ddorwin: This is part of accepting using EME

joesteele: This is fundemental to how DRM exists today

ddorwin: If an app wants to do this then their key systems needs to support this but it's not required.
... We are not replacing PSSHs
... adrianba has a nice change in the spe

<ddorwin> initDataType registry: https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/initdata-format-registry.html

We would add a new item but all of these are optional, just like webm or cenc

paulc: any more need to discuss

joesteele: doesn't seem to do damage but doesn't seem to support my DRM system
... what is missing?
... we would need to have more information in the session

ddorwin: you can do this today

adrianba: The one question I had was the for the other intitData types, we talk about how they get called
... is this just for call createsession with?
... it sounds like a good solution when you get keys from a manifest
... so it seems reasonable

ddorwin: only need to figureout the best format

neils

neils: To support joe's view we have simalar need to persist the pshs

Bug 25092 - Need a way to inform script that resolution restrictions

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25092

Looks like Mark responded

paulc: what is the next step here

ddorwin: We don't have an agreed upon solution for this issue

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

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

markw: I'm looking right now..

pal: we discussed this in the past that was simalar
... for example some css transformation may not be available
... seems like we don't have a way to inform the app what is available, permitted or not permitted

glenn: no real way to do this in general - some terrible poor hueristics

markw: the multiple key thinks looks like a hack

paulc: we'll just continue the dialog in the bug, please add your comments to the bug

Bug 25200 - Add optional "licenseType" parameter to createSession()

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25200

<paulc> See clarification in https://www.w3.org/Bugs/Public/show_bug.cgi?id=25200#c6

ddorwin: I was going for the normal streaming case as well as persisted (offline on a plane)
... app needs to tell drm what it wants - save to play later (offline) for example
... The others are TBD or other session types...

paulc: we have a long email thread, is the related?

ddorwin: I tried to clarify that I am trying to solve the offline case, though other cases are being discussed
... I'm trying to get back to the main use case and then from their we could potentially build on the enum
... to support other use cases

adrianba: The message signature - I'd like a dictionary, since I'm worried we need to add another param later

ddorwin: the point of this is to make it obvious so as long as the dictionary is specific

joesteele: I wanted to add one more, I'm more conserned about persistance to not keep request access
... but I do support the dictionary proposal from adrianba

ddorwin: The type may have more information if it's persisted or no (flags)

markw: will the server need do anything differenent?

ddorwin: I'm aware of two cases...

joesteele: if it's an open device (kiosk) the app may want to NOT persist stuff
... it's really about providing a hint

ddorwin: the goal is to allow an app to make a specific request
... multiple systems have this in the request today

Markw: asking question...
... I don't disgree with the proposal, but I don't think in your case we want to use the persistance
... it might be temporary but you my still have a persistent session even though the license and keys were temporary

ddorwin: yes

paulc: Lets' see if we can talk about content editable during the IAB talk from 14:00 -> 15:00
... We need to discuss when EME TF wants to meet - maybe next tuesday

dorwin: we need people to respond first to make session

paulc: maybe the EME folks can meet today and work on these issues working F2F

room agrees to take advantage of F2F to discuss more about these EME issues and make more progress

paulc: It would be great to take simple notes and send to the group

We are now breaking for lunch and will meet back at 13:00 (DOM4 stuff)

<gitbot> [13validator] 15sideshowbarker pushed 2 new commits to 06master: 02https://github.com/validator/validator/compare/6d683741370f...ce09a2bf571e

<gitbot> 13validator/06master 144bf9182 15Michael[tm] Smith: Simplify the default version string for the CLI.

<gitbot> 13validator/06master 14ce09a2b 15Michael[tm] Smith: For warnings, "Bad value"⇒ "Potentially bad value"

<cyns> scribe: cyns

<darobin> https://www.w3.org/html/wg/wiki/HTML5.0AtRiskFeatures#DOM4_Features_at_Risk

DOM 4 test results and features at risk

<darobin> Elements interface (whole section), query/queryAll

<darobin> ArrayClass extended attribute

<darobin> append/prepend

<darobin> before/after/replace

<darobin> MutationObservers

robin: we have a small set of features at risk.
... I"m not sure that these aren't supported, but I'm sure that we don't have enough tests to prove it
... the first 2 are known failures
... the last 3 are new things where we don't have enough tests

<paulc> Based on analysis of: http://w3c.github.io/dom/test-results/less-than-2.html

<paulc> Test files with failures: 43; Subtests with fewer than 2 passes: 1719; Failure level: 1719/47132 (3.65%)

robin: I tried to err on teh side of including things in the at-risk list, so we are as safe as possible.

<darobin> http://w3c.github.io/dom/test-results/less-than-2.html#test-file-36

robin: if we test and they pass, we just keep them
... less than 2 list has not changed since yesterday.
... most are idl, many others are corner cases.

<paulc> Majority of failures are IDL failures whch we need to filter out to explain.

robin: overall test results are pretty good

pc: keeping track of our 10 different documents that express status

<krisk> MutationObservers is implemented in all browsers

<krisk> https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver?redirectlocale=en-US&redirectslug=DOM%2FMutationObserver

<krisk> Unlike the prepend and append https://developer.mozilla.org/en-US/docs/Web/API/ParentNode

pc: robin was to prepare a candidate cr, with changes to red text. we didn't set a date for that
... we proposed a min length of 30 days for cr. we also identified 5 items at risk
... we also need to have a meeting with the director. when do we want to do that, and do we want to do them together?

robin: don't think we need to coordinate publications, but a single meeting would be ok.

pc: a phone call with Ralph may be enough
... I will also send an announcement to the chairs list
... will you do a page, like we have for canvas, that explains the bad results?

robin: yes

<darobin> ACTION: Robin to draft a page explaining the failures in the DOM test suite [recorded in http://www.w3.org/2014/04/09-html-wg-minutes.html#action05]

<trackbot> Created ACTION-244 - Draft a page explaining the failures in the dom test suite [on Robin Berjon - due 2014-04-16].

kris: the features at risk, mutation observers are in a different class than append and prepend

plh: class?

kris: I don't think any browsers support append/prepend. we have some tests for mutation observers, and mozilla has an implementation
... if you write a test for mutation observers, you may find it exists. not so for append/prepend

<scribe> ACTION: krisk to submit mutation observer tests to webplatform [recorded in http://www.w3.org/2014/04/09-html-wg-minutes.html#action06]

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

<plh> trackbot, list users

<trackbot> Sorry, plh, I don't understand 'trackbot, list users'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

pc: when can you give us the draft document

robin: in a couple weeks

<plh> ACTION: kris to submit mutation observer tests to webplatform [recorded in http://www.w3.org/2014/04/09-html-wg-minutes.html#action07]

<trackbot> Created ACTION-245 - Submit mutation observer tests to webplatform [on Kris Krueger - due 2014-04-16].

content editable

<adrianba> scribe:jaymunro

<adrianba> http://oksoclap.com/p/extensible_content_editing

adrianb at the extnesible web summit break out session

editing in general

what'll improve interoperability. high level point of view

content edited should be done in detail, so all browser could do it the same

other - not necessary to do the same results in all browsers

Doesn't think that kind of precision is necessary

because of bugs in browsers, differences, there isn't good interop here. Most editing libs try to override all the browser does for you.

editors do it themselves.

some wanted rich html, some wanted different styles, etc...

discussed creating a new content editable.

very basic

last thing, had a good discussion about improving selection api. Robin mentioned overlap with webaps

Microsoft thinks it's key to the browser.

bi directional, consistent selection

like to focus on the selection API.

robin: the selection API is in web apps

the content editable could go in HTML

ade: the editing command would work better on a range.

robin; content editable = basic, would this work better.

ade:

we didn't spend time drilling down

from my perseptive the more basic ediable, it disables the intgeraction peices.

s/intgeration/interaction

discussion of whether pressing enter, what does it do.

what should hitting enter i- n a time element.

robin: web frameworks, feedback went 90%. composing characters can be wrong, customers just says give us events.

cyn: some people want full rich editor to do everything. people just want a tag for a rich editor

confusion on what basic means

pc: are we talking about having work split between working groups

robin: how much work is needed, how much work is needed for content editable

ade: feels to me that we should serialize the work. solving for selection api, will give us the frame work for how to change editing

<cyns> my point was more about a simple rich text editor that covers the simple cases, like blog posts and comments, that web authors could just drop in with an element, and not have to code.

<cyns> and that such and element would be wired up to accessibility api, and also create clean markup

pc: do we need a report back for webaps?

robin: no, we don't need extra coordination.

doing them one after the other is good

we don't need to do anything on the HTML front yet

cyn: is there any support in 5.1 and later ?

ted: a lot of the content editable, they want the controls fit in with the adds. there's a challenge to design the controls.

we did ok for video controls.

ade: almost everybody has diff requirements, like blog comments, what styles, use css, etc?

even for similar cases they have diff req..

ted: it worth considering that platform feature set, where content editing gets used heavily,

cyn: what Im thinkinmg about is not fancy, for the people who don't need to go searching for controls.

robin: it would be good to have a rich text area, like text area,
... even for trivial cases, like linking - a lot of small subtlities. need someone comes to ta ble with a good description

ade: we need a web component for this, if it satisfied it requirements, then we'll see if it goes into the platform.

ted: I'd extend my worry to the basic set, we don't want to make authors redo stuff.

mark: i could see dev doinig a markdown for a user.

robin: the advangtage over the min model over current model,-

some users using the json model to create markup

HTML5 Features at risk

<plh> scribe: plh

<darobin> robin: the substance.io people use a nicer MVC approach that doesn't mix editing the view with editing the model

Paul: appcache, we keep
... dialog, details, sumary, not decided
... color, keep
... we're on datetime now

<darobin> https://www.w3.org/html/wg/wiki/HTML5.0AtRiskFeatures#HTML_5.0_Features_at_Risk

Robin: I have a proposal
... things to remove, things to keep at risk
... DataCue, we don't have tests

Glenn: it's not in webkit or blink
... I'd prefer it to be at risk

Mike: it's likely that DataCue will change

Glenn: some features from texttrackcue attribute
... were removed and, in response, datacue was added

Robin: the feature can be removed easily

Ted: i'll write a proposal to modify datacue

Robin: details and summary should be killed

Sam: Steve Faulkner that implementation don't match the spec anyway

Robin: dialog?
... it's in a semi disrepaired state

Mike: they're still working on it

Ted: lots of questions around it, like focus management

Robin: we don't have implementation at all for it
... ok dialog will be removed

<tantek> also: dialog should go into an extension spec rather than 5.1

Robin: :dir, :invalid, :valid
... firefox does valid and invalid
... no one does :dir

<darobin> http://www.w3c-test.org/html/semantics/selectors/pseudo-classes/valid-invalid.html

Robin: let's drop :dir, and keep :valid, :invalid for the moment

<krisk> MDN has a nice example that seems to work fine in a few browsers

<krisk> https://developer.mozilla.org/en-US/docs/Web/CSS/:invalid

<hober> e.g. the WebKit bug is marked RESO FIXED https://bugs.webkit.org/show_bug.cgi?id=27357

Tantek: I thought we had interop on valid and invalid btw

Robin: iframe/seamless

<krisk> I agree with tantek...

Sean: it's tough to implement. I would move it out of 5.0
... it needs more work and use cases

<adrianba> here is our valid/invalid test drive; http://ie.microsoft.com/testdrive/HTML5/Forms/ - click on New PseudoClasses tab

Sean: I don't see how we can use this effectively

Robin: Chrome removed it

<tantek> Gecko bug for iframe seamless: https://bugzilla.mozilla.org/show_bug.cgi?id=631218

Ted: safari supports it

<JohnJansen> no one minuted paul?

Mike: the other feedback is that it doesn't match the needs fro the devs

Tantek: candidate for extension spec

Sean: agree

Robin: I'm ok for extension spec, but someone needs to pick it up

iframe/seamless is out

<hober> re: :invalid and :valid pseudoclasses, they seem to work fine for me in Safari 7: http://trac.webkit.org/browser/trunk/LayoutTests/fast/css/pseudo-invalid-001.html?format=raw

Robin: isContentHandlerRegistered/isProtocolHandlerRegistered aren't implemented
... ok removed
... input times+

Tantek: date ok?

Robin: yes

<adrianba> hober, that works in IE11 too

Tantek: don't understand why time doesn't have interop

Robin: we could put it at risk and keep time only

<tantek> plh no I said don't understand why *time* doesn't have interop

[short interrupt]

<tantek> tantek: it's also useful to keep input type=time as that then provides developers with a building block, along with input type=date, to build their own composite datetime UIs

<jaymunro> scribe:jaymunro

IAB

presenting: chris mejia IAB, sean snider yahoo, prabhakar goyal, microsoft.

<paulc> See http://lists.w3.org/Archives/Public/public-html/2014Apr/att-0036/IAB_HTML5_Security_Extension_Proposal.pdf

chrisM: here with sean and prabhaker.

brief intro what IAB is

<scribe> agenda: intro, use case, safeframe over view, html5 sandbox/csp, next steps

Interactive Advertising bureau

membership of online media companies

only ad group just digital

over 600 members

86% of ads in us are on IAB membersites

our interests - we develop digital ad standards

IAB recently part of W3C

ad content served from 3rd parties in real time

concerned with site and user security

most web content is paid ads, they belive in the free web (ad paid)

Prab: use case real time content serving

showing a diagram,

common case : goes to ad server

browser calls exchange, calls ad server, if no ad, returns. if ad served, advertiser are sent to be bid on, highest bidder wins

the publisher doesn't know what ad content is

you can't use a black or white list to control content.

publisher areas of concern:

isolation, separation between publsher and 3rd party

ad tag is usually a script. always done that way, sometimes an iframe

(intro into SafeFrame)

no way to monitor scripts in real time.

looking to control data leakage, content, cookies, data

prevent js and css collision

but allow rich interactions with out providing full access (covered by safeframe + iframe

controls auto play, restricts certain media types

allows rich interaction without full access.

Ability to control other attack surface areas - prefent downloads

sean: use case - Safe frame - a cross domain iframe

where we stick the content, but wrap it with a javascript library, each frame defines a lib the content can talk to

host decides whether actions are takein when iframe request info.

agnostic domain - hosts a base level doc.

some data sharing - events from browser , we send msgs to iframe -

SafeFrame APIs - agnostic origin, every safe fram e is in the same origin, talk to each other, but not top level

display ads are snippets of html, freeform js and html.

always delivered with script or iframe.

safeframe will let them show a display ad, it just works, doesn't need changes.

host creates an safeframe iframe, handles interaction between host and server.

HTML5 sandbox - similar to safeframe.

sanbox attributes are too coarse grain, additional areas of control that publishers want

IAB wants enhancements to allow finer controls, ie ability to restrict

safe frame sets up xdomain plus csp- can't whitelist individual content, but can restict certain plug ins, or downloads (eg)

showed a list comparing safeframe, sandbox, and csp

things like allow/block plugins, plugin types, media types, require user interactions.

one thing to controls that's desired is autoplay.

problem with nested scripts/iframes

very challenging

chris; trying to protect user and advertiser.

as publisher, they're always under attack by nefarious

persons

sean: we're trying to give more control

showing more features

that's our presentation in a nutshell - questions

greg: to what extent does tech rely on extensions addons.

sean: pure HTML, no plugins. one hack. undlying doc is cachable so you don't have a separate request for every piece of content

greg: the original site/webpage right,

sean: Yes. they way we set up the spec, there are rules where you can't embed this in other iframe or host in "evil.com"

chris: google is releasing safeframe in one area end of summer (DFP)

sean: because now you have a clear box, you have more options.

you couldn't do that before.

you have much more control.

chris: thank you for your time. we've talked with philip and others. Trying to find positive things to work on, and bridge the groups.

we should be not doing everything on our own.

we'd like to get your input.

questions?

robin: uses cases make sense. most of what you want are extension to sandbox?

sean: sandbox is too course, we need more fine grain.

csp - content security policy

csp is in w3 on rec track

white listing at a feature level might work.

but not at content level

robin: no rule of thumb of where this concept will live, sandbox or csp.

sandbox easier to implement for users.

maybe merge both

you don't need to block on where to solve thse things.

it's not a big deal to move features between the two (csp/sandbox)

at some point we'll figure the best way.

ade: there definitly needs to be coordination with web app security. the best way to get it goiong is to write a spec

pc: do you guys understand what an extension spec. just need to write it and post it to get discussion on the html-wg

robin: if it needs to move, we can do it later.

pc: the chairs and the team are very willing to work with you.

the web consortium encourages modularity

if it grows, we can give it a bugzilla component.

sean: if you have an origin in a sandbox, how does iframe know it's been sandboxed.

robin: don't believe it does.

ade: expectation is that these things are coordinated.

sean: a simpler case is a service provider spawns an iframe, - I don't know if they coordinate for a sandbox.

chris: you may have read about this recently, its estimated that ad insustry is being defrauded in 1-6 billion dollars. follow the money back to sophisticated crime blocks.

mostly eastern block with engineers that can't get legit work.

told story about callcenter of malicious ad center

bad guys using ads to launder money. biggest thing is using bots. best way to deliver a bot is through ads.

talked about bogus ads

sean: is it possible to know if it's in a browser and not a programmable user agent.

someone loads pages and fake clicks through.

robin: the only way is to put DRM on the browser engines.

Mike: is that a bad thing robin?

robin: the browser needs to be on a secure element.

sean: there are a lot of good uses for scripting access, but it also is used for bad things.

prak: it's a problem that is getting bigger.

robin: first thing is to ask webapps if it's in their scope.

then I'd go to the websecrity IG,

no promise for solution.

chris: is this a security issue or a fraud issue. usually to do the fraud, there's a security issue.

problem is that there's a symbiotic relationships in the industry, there's consequences .

greed rules, companies looking the other way.

sean: loading javascript into webpages can be really evil. but some are making money.

chris: these issues are being discussed at all levels, law inforcement, etc... if there are technical ways to work on this it would be good.

pc: interviews with michael lewis, about trapdoor in trading markets where the margin costs went down.

the fact that the stockmarkets sell their trading stream, they can take advantage.

chris: when we first talked about this, one of the sec firms told us where they follwed money to banks. they're all connected to ad networks

pc: although michael lewis makes money on the book, the iax exchange has passed on 800 tips to the FBI

the general point, the more public it is, the better it could be.

<plh> Topici: back to HTML5 features at risk

back to HTML5 features at risk

<plh> scribe: plh

Robin: reportValidaty fails everywhere
... ok removed
... <style scoped
... anyone supports it?

Ted: depends on work in the css wg. not ready.

Robin: ok removed
... XMLDocument.load
... firefox removed it
... ok removed

plh: editors might want to remove from HTML 5.1
... (for XMLDocument.load)

Robin: other bucket

<scribe> ... New Ruby Model

UNKNOWN_SPEAKER: webkit started work on it
... lots of failures on HTMLMediaElement.addTextTrack
... mostly failing at the moment

Paul: time should be input/time in the wiki
... also we have a couple of items missing:
... output and outline algorithm

Robin: I thought we discussed. sorry. output element seems to interop
... so no reason to remove
... , outline algo is supported by outside tools, so no good reason to drop it

[Paul goes through the full list to double check]

<rubys> http://blog.paciellogroup.com/2013/10/html5-document-outline/

Sam: Steve Faulkner thinks outline should be removed...
... can we close the loop with him?

Ted & Mike: sure

Paul: we should update the bug with the list btw, to make sure people see this

[side discussion to make sure the wiki gets updated]

Paul: how much to remove before the next heartbeat and how much for the LC?

Robin: I'll start removing thigs sooner rather than later. we can bring this back easily if needed
... so the heartbeat will have the stuff removed

<darobin> ACTION: Robin to produce a heartbeat with feature removals and at risk items taken into account [recorded in http://www.w3.org/2014/04/09-html-wg-minutes.html#action08]

<trackbot> Created ACTION-246 - Produce a heartbeat with feature removals and at risk items taken into account [on Robin Berjon - due 2014-04-16].

Paul: where do we stand on the test results?

Robin: still the same

<darobin> http://www.w3.org/html/wg/tests-cr-exit/

Robin: testing coverage ...
... we might need to revisit the cr page

Paul: if we don't test them, only two ways to move forward: passive permissive, drop the feature, or tell the director to hold his nose

Robin: section 5 is important
... I'm worried about section 5
... it's quite possible that some of those subsections are not testable.

<scribe> ACTION: Robin to go through section 5 to check which section is testable or not [recorded in http://www.w3.org/2014/04/09-html-wg-minutes.html#action09]

<trackbot> Created ACTION-247 - Go through section 5 to check which section is testable or not [on Robin Berjon - due 2014-04-16].

Kris: it will be difficult to test section 5

<scribe> ACTION: Kris to triage section 5 into hard and easy tests [recorded in http://www.w3.org/2014/04/09-html-wg-minutes.html#action10]

<trackbot> Created ACTION-248 - Triage section 5 into hard and easy tests [on Kris Krueger - due 2014-04-16].

close action-247

<trackbot> Closed action-247.

Kris: I'll come back with the list in 2 weeks

<krisk> * thanks johnjan

<JohnJansen> plh, did you just ask me something on the phone? my reception is not great...

Plh: are we missing anything in our list of features at risk?

[none heard]

Paul: would be useful to have a plan for a plan in 10 days

[...]

Paul: are we done for today?
... looks like it
... we'll be back in Santa Clara in November again
... we'll put the new work mode in action right away

- DRAFT -

HTML Working Group face-to-face

09 Apr 2014

Attendees

Contents