See also: IRC log
<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
... 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
paulc: maybe Phillipe could give a review
phillipe: <discussing the
... 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
... 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
<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
paulc: 5 of these bugs are
... 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].
<joesteele_> paulc: Aaron published an editors draft that resolve 3 of the bugs - cyril should review
<joesteele_> cyril: will review
<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
<krisk> scribe: krisk
We are going to be going through a number of EME Bugs
First bug is https://www.w3.org/Bugs/Public/show_bug.cgi?id=25199
EME should use promises
Which Blocks: 17750 21798 24081 24216 24771.
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
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
... 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
adrianba: I wonder if we can have this discussion now about these bugs
joesteele: Let discuss and email on the list
joesteele: The issue I'm trying
to raise here - a session is composed of licenses and
... 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_> this is the diagram I was talking about
joesteele: This is from a number
... 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
ddorwin: alot of other ways
... 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
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
... 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
... 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
... 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
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
... 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?
<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
... 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
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
... 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
... 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
... 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
... 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
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
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
... 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
... 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
... 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: To support joe's view we have simalar need to persist the pshs
Looks like Mark responded
paulc: what is the next step here
ddorwin: We don't have an agreed upon solution for this issue
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
<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
... 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
... 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
... 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
paulc: Lets' see if we can talk
about content editable during the IAB talk from 14: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> Elements interface (whole section), query/queryAll
<darobin> ArrayClass extended attribute
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.
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> 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
... 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
... 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?
<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
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].
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.
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.
we didn't spend time drilling down
from my perseptive the more basic ediable, it disables the intgeraction peices.
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
<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
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
... I'd prefer it to be at risk
Mike: it's likely that DataCue will change
Glenn: some features from
... 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
... 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,
... firefox does valid and invalid
... no one does :dir
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
<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
<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
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
... ok removed
... input times+
Tantek: date ok?
<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
<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
presenting: chris mejia IAB, sean snider yahoo, prabhakar goyal, microsoft.
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
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
chris; trying to protect user and advertiser.
as publisher, they're always under attack by nefarious
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.
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.
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
<plh> scribe: plh
Robin: reportValidaty fails
... ok removed
... <style scoped
... anyone supports it?
Ted: depends on work in the css wg. not ready.
Robin: ok removed
... 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]
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
... 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
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
... 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].
<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?
Paul: would be useful to have a plan for a plan in 10 days
Paul: are we done for
... looks like it
... we'll be back in Santa Clara in November again
... we'll put the new work mode in action right away
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/ar recess/at recess/ Succeeded: s/asl/ask/ Succeeded: s/pauc: /paulc: / Succeeded: s/and tie/and time/ Succeeded: s/time needs to be/kind needs to be/ Succeeded: s/needs to know when/application needs to know before/ Succeeded: s/markw: have a /acolwell: have a / Succeeded: s/aaron: /acolwell: / Succeeded: s/publishers/published/ Succeeded: s/Last two items/Editors draft/ FAILED: s/expect din/expected in/ Succeeded: s/?2/jdsmith/ FAILED: s/?2: /jdsmith: / Succeeded: s/nor/not/ Succeeded: s/adding/removing/ Succeeded: s/hit/hint/ Succeeded: s/whay/why/ Succeeded: s/spec/spec/ Succeeded: s/PSHs/PSSHs/ Succeeded: s/We don't have a good use case for this issue/We don't have an agreed upon solution for this issue/ Succeeded: s/para/param/ Succeeded: s/so you can actually persist this information/but you my still have a persistent session even though the license and keys were temporary/ Succeeded: s/operablity/interoperability/ Succeeded: s/cojuld/could/ FAILED: s/intgeration/interaction/ Succeeded: s/contentent edita ble/content editable/ Succeeded: s/ow/now/ Succeeded: s/die/dir/ Succeeded: s/datetime/time/ Succeeded: s/isd/is/ Succeeded: s/serverf/server/ Succeeded: s/alwyas/always/ Succeeded: s/desiared/desired/ Succeeded: s/thorugh/through/ Succeeded: s/Michel/Mike/ Succeeded: s/elementl/element/ Succeeded: s/securty/security/ Succeeded: s/source/fund/ Succeeded: s/actio/action/ Found ScribeNick: joesteele Found Scribe: krisk Inferring ScribeNick: krisk Found Scribe: cyns Inferring ScribeNick: cyns Found Scribe: jaymunro Inferring ScribeNick: jaymunro Found Scribe: plh Inferring ScribeNick: plh Found Scribe: jaymunro Inferring ScribeNick: jaymunro Found Scribe: plh Inferring ScribeNick: plh Scribes: krisk, cyns, jaymunro, plh ScribeNicks: joesteele, krisk, cyns, jaymunro, plh Present: Mike Eliot PAL adrian Erika MarkS Jay Bob Kris Robin Jerry Arnaud Zhihang Cindy Neils Cynthia Glenn plh Sam Paul Tantek Ted Jer David Aaron MarkW Cyril MarkV Joe Arnaud_Braud Prabhakar_Goyal JohnJansen Sean_Snider Regrets: Travis Got date from IRC log name: 09 Apr 2014 Guessing minutes URL: http://www.w3.org/2014/04/09-html-wg-minutes.html People with action items: acolwell ddorwin kris krisk paulc robin[End of scribe.perl diagnostic output]