- From: Paul Cotton <Paul.Cotton@microsoft.com>
- Date: Sun, 9 Nov 2014 17:47:58 +0000
- To: "public-html-media@w3.org" <public-html-media@w3.org>
- Message-ID: <1bd7be5c7953427c81823396b57fd14e@CY1PR0301MB1196.namprd03.prod.outlook.com>
Forwarding the minutes of the HTML WG F2F since we spent all of Fri Oct 31 on Media TF topics.
Note that several ACTION items were recorded in the TF tracker during this meeting and they do not show up in the WG minutes. See:
https://www.w3.org/html/wg/media/track/actions/open
/paulc
Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329
From: Paul Cotton [mailto:Paul.Cotton@microsoft.com]
Sent: Thursday, November 06, 2014 7:36 PM
To: public-html-wg-announce@w3.org
Subject: {minutes} HTML WG F2F, TPAC, Santa Clara, CA 2014-10-30 and 2014-10-31
See http://www.w3.org/2014/10/30-html-wg-minutes.html
Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329
[W3C]<http://www.w3.org/>
- DRAFT -
HTML F2F - TPAC2014
30 Oct 2014
Agenda<https://www.w3.org/wiki/HTML/wg/2014-10-Agenda#F2F_Topics>
See also: IRC log<http://www.w3.org/2014/10/30-html-wg-irc>
Attendees
Present
+1.408.536.aaaa, Aaron_Colwell, AdamB, BobLund, Cyril_Concolato, Domenic, Josh_Soref, Mark_Vickers, Sam_Ruby, darobin, ddorwin, joesteele, paulc, plh, rubys, timeless, David_Dorwin, Erika_Navara, Adrian_Bateman, Shane_Stevens, Ben_Peters, Addison_Phillips, Bill_Hofmann, hober, Mark_Watson, igarashi, MikeSmith, k_takabayashi, Tatsuya_Igarashi, Glenn_Adams, Peter_Linss, Yves_LAfon
Regrets
Chair
paulc, rubys
Scribe
timeless, joesteele
Contents
* Topics<http://www.w3.org/2014/10/30-html-wg-minutes.html#agenda>
* Introduction<http://www.w3.org/2014/10/30-html-wg-minutes.html#item01>
* Agenda Bashing<http://www.w3.org/2014/10/30-html-wg-minutes.html#item02>
* After HTML5<http://www.w3.org/2014/10/30-html-wg-minutes.html#item03>
* Scheduling<http://www.w3.org/2014/10/30-html-wg-minutes.html#item04>
* SVG and Graphics taxonomy<http://www.w3.org/2014/10/30-html-wg-minutes.html#item05>
* ComputedRole/ComputedLabel<http://www.w3.org/2014/10/30-html-wg-minutes.html#item06>
* EventHandler enumeration<http://www.w3.org/2014/10/30-html-wg-minutes.html#item07>
* Agenda Bashing<http://www.w3.org/2014/10/30-html-wg-minutes.html#item08>
* Editing TF<http://www.w3.org/2014/10/30-html-wg-minutes.html#item09>
* After HTML5<http://www.w3.org/2014/10/30-html-wg-minutes.html#item10>
* Dpub Roles and footnotes<http://www.w3.org/2014/10/30-html-wg-minutes.html#item11>
* Canvas TF<http://www.w3.org/2014/10/30-html-wg-minutes.html#item12>
* Process 2014<http://www.w3.org/2014/10/30-html-wg-minutes.html#item13>
* allow <link> in body + DOM position as a rendering hint<http://www.w3.org/2014/10/30-html-wg-minutes.html#item14>
* EME Bugs<http://www.w3.org/2014/10/30-html-wg-minutes.html#item15>
* Introductions<http://www.w3.org/2014/10/30-html-wg-minutes.html#item16>
* Agenda for Friday<http://www.w3.org/2014/10/30-html-wg-minutes.html#item17>
* EME Bugs<http://www.w3.org/2014/10/30-html-wg-minutes.html#item18>
* Bug 27053 - Platform Segmentation<http://www.w3.org/2014/10/30-html-wg-minutes.html#item19>
* Bug 25923 - The mechanism for checking key system support should be asynchronous<http://www.w3.org/2014/10/30-html-wg-minutes.html#item20>
* Bug 25966 - Use ArrayBufferView and ArrayBuffer instead of Uint8Array in APIs<http://www.w3.org/2014/10/30-html-wg-minutes.html#item21>
* Domenic joins the bridge<http://www.w3.org/2014/10/30-html-wg-minutes.html#item22>
* Bug 27053 - Platform Segmentation<http://www.w3.org/2014/10/30-html-wg-minutes.html#item23>
* Bug 27054 Accessibility Concerns<http://www.w3.org/2014/10/30-html-wg-minutes.html#item24>
* Bug 27055 Surfacing license to the user<http://www.w3.org/2014/10/30-html-wg-minutes.html#item25>
* Bug 27166 - All identifiers associated with a user should be clearable in the same way cookies are<http://www.w3.org/2014/10/30-html-wg-minutes.html#item26>
* Bug 27165 - User agents should warn users if they bring along unclearable identifiers<http://www.w3.org/2014/10/30-html-wg-minutes.html#item27>
* Bug 27166 - All identifiers associated with a user should be clearable in the same way cookies are<http://www.w3.org/2014/10/30-html-wg-minutes.html#item28>
* Bug 27165 - User agents should warn users if they bring along unclearable identifiers<http://www.w3.org/2014/10/30-html-wg-minutes.html#item29>
* Bug 26332 Applications should only use EME APIs on secure origins (e.g. HTTPS)<http://www.w3.org/2014/10/30-html-wg-minutes.html#item30>
* Updates to bugs w/ F2F<http://www.w3.org/2014/10/30-html-wg-minutes.html#item31>
* Media TF next F2F<http://www.w3.org/2014/10/30-html-wg-minutes.html#item32>
* Bug 26776 Diagnosing and resolving CDM errors needs a numeric systemCode (deleted with MediaKeyError)<http://www.w3.org/2014/10/30-html-wg-minutes.html#item33>
* Bug 26887 Allowing license servers and CDMs to control data persistence and secure release<http://www.w3.org/2014/10/30-html-wg-minutes.html#item34>
* Bug 24082 Several issues discussed in the TF point to the need for defined extensibility points in EME<http://www.w3.org/2014/10/30-html-wg-minutes.html#item35>
* Bug 27111 - Separate "persistent" session type into persistent license and presistent key release<http://www.w3.org/2014/10/30-html-wg-minutes.html#item36>
* Bug 26738 Add entry for MPEG-2 TS CENC to the Stream Format Registry<http://www.w3.org/2014/10/30-html-wg-minutes.html#item37>
* Bug 26372 Report issues/events not related to a specific method call<http://www.w3.org/2014/10/30-html-wg-minutes.html#item38>
* Bug 26811 Separate definitions of Initialization Data Types from Stream Format parsing<http://www.w3.org/2014/10/30-html-wg-minutes.html#item39>
* Bug 26573 Prepare for Last Call<http://www.w3.org/2014/10/30-html-wg-minutes.html#item40>
* Bug 24771 Provide guidance on object and CDM lifetime (including when events are guaranteed to be fired)<http://www.w3.org/2014/10/30-html-wg-minutes.html#item41>
* Bug 26838 Normatively address vulnerabilities related to initData contained in media data<http://www.w3.org/2014/10/30-html-wg-minutes.html#item42>
* Bug 25092 Need a way to inform script that resolution restrictions are applied<http://www.w3.org/2014/10/30-html-wg-minutes.html#item43>
* Bug 25268 Reduce the burden on applications to deduplicate initData from many needkey events<http://www.w3.org/2014/10/30-html-wg-minutes.html#item44>
* Bug 20944 EME should do more to encourage/ensure CDM-level interop<http://www.w3.org/2014/10/30-html-wg-minutes.html#item45>
* Bug 23827 Need to add features at risk prior to entry into Candidate Recommendation<http://www.w3.org/2014/10/30-html-wg-minutes.html#item46>
* Bug 24874 Positive isTypeSupported() may be misleading (MSE vs. .src=)<http://www.w3.org/2014/10/30-html-wg-minutes.html#item47>
* Introductions<http://www.w3.org/2014/10/30-html-wg-minutes.html#item48>
* MSE qqq<http://www.w3.org/2014/10/30-html-wg-minutes.html#item49>
* MSE CR Status<http://www.w3.org/2014/10/30-html-wg-minutes.html#item50>
* DOM4 implementation / status|<http://www.w3.org/2014/10/30-html-wg-minutes.html#item51>
* Extension Spec status<http://www.w3.org/2014/10/30-html-wg-minutes.html#item52>
* Summary of Action Items<http://www.w3.org/2014/10/30-html-wg-minutes.html#ActionSummary>
________________________________
<trackbot> Date: 30 October 2014
<timeless> scribe: timeless
<paulc> F2F topics: https://www.w3.org/wiki/HTML/wg/2014-10-Agenda#F2F_Topics
paulc: i'll be like the Baptist minister: "why are there no people in the front three pews?"
... can people move in
... we have a polycom, on this side
... please move in
... we're waiting for darobin
<tantek> good morning #html-wg - lurking here in IRC while in the AB meeting in person a few doors down.
Introduction
paulc: good morning
... i'm Paul Cotton, cochair WG
MikeSmith: Michael Smith, W3C
Josh_Soref: Josh Soref, BlackBerry, Scribe, Observer
Cyril: Cyril Concolato, Institut Telecom, interested in the Media TF work
kurosawa: Takeshi Kurosawa, Mitsue-Links
CCC: ccc
DDD: ddd
darobin: Robin Berjon, W3C
zcorpan: Simon Pieters, Opera Software
plh: PLH
rubys: Sam Ruby, cochair
FFF: fff
GGG: ggg
HHH: hhh
III: iii
JJJ: jjj
MMM: mmm
NNN: nnn
paulc: we're on #html-wg
... Josh_Soref is scribing, thank you josh
Agenda Bashing
<Santabarbara> https://www.w3.org/wiki/HTML/wg/2014-10-Agenda#F2F_Topics
paulc: first item, First Screen Paint in Advance
... discussed in Web Perf WG on Tuesday
... there's an email on public-html
<zcorpan_> <http://www.w3.org/mid/C99B14A348100349A457CD82738FB0AB1BCE0185@M1-MAIL-MBX03.internal.baidu.com><http://www.w3.org/mid/C99B14A348100349A457CD82738FB0AB1BCE0185@M1-MAIL-MBX03.internal.baidu.com%3E>
paulc: because proponents would like to have a remote participant from China
... and we're 15 hours behind China
... i'm proposing to do that at 5pm today
... that's 8am tomorrow morning
... we can't do it tomorrow, since that's Saturday in China
<rubys> http://lists.w3.org/Archives/Public/public-html/2014Oct/0062.html
paulc: that's locked
... fair amount of discussion in WebApps on Intentions (2 hours)
... i don't know if anyone here wants to discuss that
... Canvas TF, assume we'd want an update
... Media TF requested Friday morning
... i've stretched that through 1pm
... i've talked about starting at 8:30am tomorrow
... Charter schedule tells us we do HTML5.1 and Canvas 2D level 2
... there was at least a breakout session on After HTML5
... darobin started a discussion on public-html@ probably over a month ago
... chairs suggest doing it first
... i expect we should do it first, and also think about how much time we need for it
<SteveF> +1 to paul on doing first
paulc: i included a link to outstanding HTML5 bugs
... 288 of them
... that's just searching bugzilla for the component
... and it isn't obvious to me that that simple search is even right
... in the press briefings on Monday
... 40,000 emails
... lots of formal objections
... i didn't tell the press about outstanding bugs
... --
... 3 topics on Accessibility
... the first is locked to this morning
... it isn't obvious to me that we'll know how many accessibility people will be here to discuss
... i went to the SVG meeting @9am this morning
... to discuss this first topic after the break
... -- the item about PFWG
... Digital Publishing
... they asked for a slot 4-5pm today
... and we have a DOM4 status update: test failures
... not sure about how long/how much time
... Agenda...
... we're in "Unconference"
<darobin_> darobin has joined #html-wg
paulc: we have a 10:45-11:15 Coffee break -- technically, coffee is over at 11am
... I put our start inside the window,
... first item, Accessibility topics Part 1 (11:15-1am)
... slots 3 and 4 after lunch are open
... Tomorrow
... i've made some modifications already
... I sent Media TF a list of EME bugs
... I've suggested 3 slots for EME
... so many things outstanding
... w/ TAG's input we went from 19 to 26/27 bugs
... and in last two weeks, we've closed only 2
... we need to do MSE CR status/test suite review
... we need to decide
... where to put items
... anyone object to lockdown?
... plh ?
plh: glazou wanted to be around for HTML5 discussion
... but he's blocked until 11am
... and he's leaving today
... i'm guessing we won't be able to accommodate him
paulc: say we start After HTML5 discussion at 9:30am
... would we need a second block?
plh: probably
paulc: people could discuss over break/lunch
... and we could do a second slot after lunch, and glazou could come to that
... adrianba, is ben still here?
adrianba: he's left
darobin: without ben, it will be hard
paulc: it's going to be short
... put that item at 2pm for 15 mins today
... and maybe darobin can find the webapps minutes?
... Canvas TF, maybe 15 mins after that?
rubys: make sense to slice Accessibility slot to cover Canvas ?
paulc: not the first slot
... so add that to the 4-5pm slot today
[ hober spills coffee ]
hober: i'll remain anonymous for now
paulc: 2pm slot this afternoon, Editing TF
... plh, can we do DOM4 status in <15 mins?
darobin: if we want to discuss bugs, we need more
paulc: what about the 45 mins
darobin: we'd like to do DOM4 tomorrow to have time to run more tests
paulc: ok... look down for tomorrow
... paulc ddorwin , MarkS , others, can we start 8:30 tomorrow morning?
... everyone put up their hand if they'll be at tomorrow morning
... noon, 1pm, 2pm, 3pm
... 4pm
... that seems to say we can go pretty deep
... but since ddorwin is editor of EME
... and w/ children who want to go out for Halloween
... and people rant about Halloween -- TPAC
... change 09:00 to 8:30
... ddorwin leaves at 1pm
... do lunch until 2pm
... Session 11 - 2pm-3pm
... that can be DOM4
... (test failures)
... start EME bugs Part 1 at 8:30am tomorrow
hober: Ted O Connor, Apple
paulc: ddorwin did you confirm that acolwell
... move the MSE CR status to 12:30AM-1PM
... and expand Part to 11:00-12:30PM
... 4 hours of EME tomorrow morning
... break for lunch
... come back for DOM4
[ Agenda reloads ]
paulc: move back to Day 1
... I think we can shrink Editing TF to 2pm-2:30pm
... Session 4 should be After HTML5 part 2 2:30-3:30pm
... if Editing TF ends early, we'll segway straight to After HTML5
... what have we missed?
... Canvas2D level 2 -> after html5
... accessibility part one partly covered
... accessibility part 2 isn't covered
... did we know how we were going to cover this?
... SteveF ?
... name computation, access key, captcha ?
... was I overly zealous by adding this to the wiki?
SteveF: I can see, but I have no idea
paulc: since we'll see PF at 11:15am today
... we'll have to ask them what they want to do w/ A11Y-part2
... I know footnotes, roles, validation have to be today
... add A11y-part2 to 30min slot after DOM4 tomorrow
... session 12
... other comments on topics?
... i suspect tantek is interested in After HTML5 on maintenance
hober: AC meeting starts at 11am?
[ yes ]
Travis: did we want to discuss extension specs?
paulc: good point
... Longdesc from A11y
... Canvas if you want to treat it
... EME
... MSE
... i can give you an oral report on longdesc
... right now
travis: any other submissions to glance over
... we have a wiki of extensions
<rubys> https://www.w3.org/wiki/HTML/wg/2014-10-Agenda#F2F_Topics
paulc: move A11y topic to after Coffee (Session 13)
... and do status rundown of all extension specs tomorrow (session 12 before coffee)
... if a11y people don't want to meet tomorrow
... and we don't have overflow topics
... we might adjourn at coffee tomorrow
[ Refreshes Agenda ]
paulc: we could do URL (webapps) in Extensions
... other topics?
... ok, i think we have an agenda
After HTML5
paulc: darobin, shall i give you the floor?
... assume 1/2 the people know what you're talking about
darobin: hey, we finished HTML5, by the way
MikeSmith: Yay
<rubys> http://darobin.github.io/after5/
[ Applause ]
darobin: what's next, do we go home, and sip margaritas
... or do we keep doing some work
... not sure how much detail i should go
... maybe highlights, and then deeper w/ Qs
... rubys suggested "The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer."
... if you don't like it and don't speak up, it will become a decision
... it would be wonderful to increase participation
... the people who built the kittens... namely web developers
... we built the technology
... we should meet somewhere
... editors would agree that the way we managed publication of HTML5 was painful
... maybe learn from world of software development
... Nightly version, stabilize
... features
... try to avoid 120,000 lines of code in a single file
... orthoganalize features to make progress independently
... cut spec into smaller parts
... ship them
... focus on the bits
... adopt classic open source process
... pull request
... so people can join in
... not revolution
... try to rationalize
... no vibe of outrage at this point
paulc: some discussion here
... WG would have to come to a decision about what it does
... so, start w/ Qs
... 1. what do we do w/ the 300 outstanding bugs?
darobin: good Q. triage them
... i suspect quite a few have been fixed, but we haven't closed the bug yet
... figure out which ones can be closed as Errata to HTML5
... small bugs
... maybe a shame to do Errata once we publish REC
... but we have to, it's cycle of life
... last batch, new work, new modules
... for them, push to modules and focus on that
... in some cases highlight what to work on
travis: under previous process
... editors generated new content
... fixed bugs in our component
... we'd have bugs fixed by whatwg component
... a large portion of our job was to synchronize
... from shared source and push into our branch
... under this after5 plan
... what is the plan/philosophy to keep in sync/not-in-sync
darobin: you're an editor, what do you think?
travis: i'd love to see
... probably not realistic
... i'd love contributors from whatwg to participate in our process
... pull requests
... approved
... short of that, i don't really know
... i know we need to be sensisitive to their desires
... if they're ok w/ pulling relevant content across or not
plh: call a cat a cat
... hixie has said he wanted w3c to stop copying his work
... we agreed for the purpose of shipping html5
... we looked at whatwg as submission to html5 spec
... html5 spec shipped
... what do we do, he wants us to stop copying his work
MarkVickers: i don't have an answer to that Q
... i think, the idea that this would be modular, able to react to submissions
... is a much better way of going forward
... i think a large document approach is difficult for people to track inside/outside
... DataQ is hard
... it doesn't mean anything, quite arbitrary
... much better if you could look up where it is based on Tests/Implementation
... i think better by
... whatwg
... I think the whatwg doesn't like the current structure
... they did it to keep in sync
... perhaps we should have a joint conversation
rubys: comment on the way i work
... i don't work well on abstract things
... you mentioned DataQ
... what needs to be addressed in 3, 10, 12, 15 months
... maybe it makes sense to work on small things
... DataQ
... and we look at a resync w/ whatwg in 2-5 years
paulc: darobin, your original proposal said break up this 1300 page document into modules
... but as rubys implied, that's fairly abstract
... can we talk about how we'd do that
... rubys took MarkVickers 's suggestion
... all the things we took out of for CR
... "almost there"
... but if we told Editorial staff to break it up into modules, what would you do?
darobin: 2 things
... saner: focus on either things we cut out for CR / moved to 5.1
... or things that need updates
... SteveF's Area mapping
... that would make sense to keep progressing
SteveF: ARIA Roles ...
... i can't remember the number, ARIA native semantic buttons
... map ARIA Roles of abstract mapping tool
... that section
... but there's a number of other sections
... another, the alt= guidance
... in a more general sense, conformance requirements, + authoring advice
... but that covers a lot of the spec in discrete parts
... i don't see how that would be excised out
paulc: ARIA Roles
... containable
... 3rd Guidance, spread through document
... alt= guidance
... TextPP has work that's about to be published as a note
... is that containable?
SteveF: yes, that's containable, in a single section
paulc: the first two are examples
... modules
... but the third one?
darobin: i don't know about it...
... we'd have to discuss
... MikeSmith mentioned interleaving authoring conformance might not be a good idea
... perhaps have a separate document
SteveF: i agree
... it's unclear what the best path forward for it is
... but we need to work out that path
Travis: rubys got me thinking a bit about a more practical route
... thanks rubys
... as i look back over those bugs
... i recall one that jumped out at me
... implement a true tri-state checkbox
... not dual indeterminate
... that sounds like a great thing to be as a module
... hook it up
... then i thought, if you do that w/ bugs
... why not review what's in 5.1
... diff against 5.0
... look at things that are unique
... review, see if they could be moved out as modules
<plh> http://www.w3.org/html/landscape/#differences-between-w3c-html-5.1-and-w3c-html-5.0
Travis: not spend the effort to rip the document apart
... but work on the parts we want to progress
darobin: i think that makes sense
... we had a session yesterday as a breakout
... rubys suggested a continuously maintained
... 5.0.1 spec
... that shrinks as things move into modules
... we don't need to cut everything out
... maybe we don't need a new spec for <p/>
... <form>s are a mess
paulc: are they as bad as <ruby> ?
... scale of 1..<ruby>, how bad are <form>s?
darobin: <form>s are bad
... most new types are unusable
... developers scream, like <select multiple>
paulc: i wanted to ask question
... stemming from Travis's Q about linkage to WHATWG
... but link to Qs here
... we have ~300 bugs
... looking at those
... talked about modularization
... where we want to do work/where there is work
... Q-- Hixie said don't copy my work
... what items are different in WHATWG spec
... than 5.0/5.1ED ?
<plh> http://www.w3.org/html/landscape/#differences-between-whatwg-html-ls-and-w3c-html-5.1
paulc: enumerate places where we could find modules
... what are similar things in WHATWG that Hixie wouldn't want us to copy?
<rubys> http://www.w3.org/html/landscape/
Travis: looking at this document would help
... canvas-proxy
... move canvas controller to WebWorker
... and drive from off thread
darobin: we have that in 5.1
Travis: but what is in WHATWG that aren't in 5.1?
... 3 months of work
darobin: mostly bug fixes
paulc: so, bug fixes
... some might correlate w/ 288 bugs we have
... some might not correlate, things that Hixie has already fixed
... Hixie might have done new novel work on things in 5.1 or not
... maybe he moved canvas-proxy on substantially?
... then decide "do we want to work on canvas-proxy, or not?"
Travis: do we grandfather in things in 5.1 as "already copied?"
paulc: something WG has to decide, valid Q
... specs is like any software engineering project, we have to triage
rubys: we can walk through doc, or after 5
paulc: can you show me in Landscape
plh: click "2."
rubys: first bullet isn't workitem, second isn't, third isn't, fourth isn't
... fifth is
paulc: "Different ARIA role constraints"
... but SteveF already mentioned
[ Looser ]
darobin: not a work item
... it's done
paulc: longdesc, we know what's happening, extension spec
... tables, not a work item
... <main> element
... - not a workitem
darobin: table-border, please let us not work on that
paulc: chairs would agree
... SHOULD on <h..>
darobin: work item
... but...
... a lot of those are authoring document conformance things
... perhaps as a module
paulc: task to put in front of ourselves
<tantek> hello #html-wg - sitting in second U-ring behind rubys
paulc: take this content, have WG decide work on/isn't
rubys: precursor, i think this list needs an update
... last updated June
... update list, triage list, publish
SteveF: starting to get somewhat of a clearer idea
<darobin> ACTION: Robin to triage new WHATWG updates, HTML bugs, Landscape document in order to list priority content for modules [recorded in http://www.w3.org/2014/10/30-html-wg-minutes.html#action01]
<trackbot> Created ACTION-249 - Triage new whatwg updates, html bugs, landscape document in order to list priority content for modules [on Robin Berjon - due 2014-11-06].
SteveF: not really
... we have shipped HTML5.0
... we'll work on that
... in Errata
... that just includes non-normative bug fixes?
rubys: everything's open for discussion
... you could make that as a proposal
SteveF: we've got that document, do we maintain it
... or let it go?
paulc: i'll answer that (maybe w3meme)
... Tuesday memed speaking for directory
... now memed for CEO?
... at AC meeting he said how we maintain stuff
... how we do that, it's up to us
SteveF: part of maintenance is to continue to pull in fixes from whatwg source
... not features. but bug fixes
paulc: rubys can you find the text from Process document?
<tantek> hello #html-wg - sitting in second U-ring behind rubys
timeless: the Process document has an inconsistent set of topics
... for what updates are
... (Errata)
... there's work for Process 2015/2016
... but you're on an older Process
SteveF: we have 5.0, and 5.1
... we have a plan to ship 5.1 at some point
... why not see 5.1 as maintenance of 5.0
... pull things out of 5.1 as modules
... but continue to keep stuff current in 5.1
... that's currently in there
... but new work independently
darobin: several aspects
... i would not want to work off current 5.1 document
... if we can avoid it
... it has a million things we want to split out as modules
... a million things that will never be implemented
... i think it'd be saner to work from CR branch
... re: what we take in as Errata
... up to whoever does the work, how deep we go
... suggest we not spend too much time on non-normative
... focus on solid bugs
<tantek> +1 on focus on *normative* maintenance
darobin: make Errata for them and release that
... make job simpler by dropping entire Canvas from source document
... we aren't producing that, Canvas TF doesn't generate from that branch anyway
... and similar
... -- one thing i've been keeping in mind
<tantek> +1 to darobin points about 5.1 has too much in it. Saner to work from CR branch.
darobin: we can no longer merge from WHATWG/master -- too far away
... but might want to be notified about bug fixes
... various ways to be notified
... we can apply a similar fix
rubys: several people nodded
darobin: editors nodding (maybe falling asleep?)
<tantek> strong agreement with darobin's proposals
MarkVickers: "do not copy whatwg work" comment concerns me
... i see great opportunity
... but at some point, things have to come together as one spec
... in order to have one web
... it seems we have two specs, and we're splitting the web
... what i saw in what darobin wrote
... is very small modules
... software depo level, each numbered section is a small file
... check out 4.7.10.2
... add a new file for new number representing a new project
... instead saying what we think is 5.1
... and working
... instead have a clock-based
... what things have reached agreed upon threshold
... say 2 implementations
... say "April 1" release
... is those things
... have those things w/ same force of IP commitments
... just more clock driven
... each piece working independently
... some work by whatwg, some by groups in w3c
... but that would imply that they'd come back together as a document
<Zakim> tantek, you wanted to formally propose "maintenance" release should only be bug fixes, and thus a 5.0.1. Anything anyone wants to keep in 5.1 which is new from 5.0 should be split
tantek: Tantek Celik, Mozilla
... darobin covered what i wanted to say
... very reasonable
... maybe i should go back to AB meeting
... which is simultaneously discussing Errata Process
... apparent size
darobin: Differences or Landscape?
tantek: yes, Landscape
[ Projects Landscape ]
tantek: the more that can be shrunk by whatever means
... normative differences/purely informative differences
... the better
... look forward to features being added to HTML Spec via Extension
... preferably CC-by
darobin: we can
tantek: i'm expressing my preference
<tantek> given that CC-by is the most liberal option we have
rubys: we got a request to not-copy
... we have content under CC-0
... people are working out if that makes sense or not
... like people here
... if someone says "we should copy" "we should not copy"
<tantek> obviously I'd rather have CC0 but we're not there yet, and I'm actively working on trying to make that a possibility at the AB level
MarkVickers: i thought i was making concrete proposal
... if things are in small enough units
... we'd hopefully get to the point where people are two different groups working on checkouts from the same github
... and at some point it would be copied, and brought back in
<SteveF> +1 to tantek on CC0
MarkVickers: you'd have one build at the end
rubys: thanks, you said work together and copy
<tantek> Thank you SteveF - that's useful input for the AB.
rubys: another was work together and point
MarkVickers: work together
... at some point we want to be able to say "this is work recommended by W3C as HTML"
... implementer or using it
... whether you point or not
<SteveF> whatever tantek was referring to :-)
MarkVickers: the user needs the output
... all documents should be together at one place
... i don't want confusion
<paulc> Paul wants to point to http://www.w3.org/TR/html5/
rubys: thanks
[ Projects TR/html5 ]
paulc: plh and i discussed this before the meeting
... we have dated version, latest version
... latest version of html
... different from normal recs
... 1) we aren't the only WG working on Extensions to HTML5
... we have EME, MSE, longdesc, ...
... but WebPerf WG is doing extensions
... much of WebApps at API level are Extensions
... one thing we could do
... click on "latest version of html"
... instead of a single document
... take you to a page listing various modules
<plh> -q?
paulc: both from HTML WG and other places
<Cyril> +1, that's what CSS does
paulc: I have a terrible time speaking of what HTML5 is
... people think it's the Web Platform
darobin: lost battle
... we should admit defeat
paulc: thank you
... maybe HTML could take you to a list of modules, extension specs, whatever you'd want to work to
<glazou> glazou: as I said yesterday, you won't change journalists on that
paulc: could even point to things that whatwg were working on that we agreed that we weren't working on
... maybe the problem is that we don't have a definitive list
... to define what we're working on/what they're working on
... it's an idea that plh and I just talked about
... but maybe plh should speak to this
... maybe it was an insurance policy
plh: 2 years ago, one of the problems i was facing
... was "what does CSS3 mean?"
... my boss, jeff came in and said
... "i've been talking about CSS3 for a long time, but where is our CSS3 spec?"
... we don't have a CSS3 spec
<tantek> I note that glazou doesn't appear to be in the room. ;)
plh: and CSS WG knows what they're talking about
... problem is that the web doesn't understand
... If i said "CSS3 doesn't exist", people would look at me and say "what do you mean?"
... HTML, I thought, we'll have the same problem down the road
... i thought if we had a thing
... CSS had a CSS snapshot 2007, 2010
... it didn't really work
... not really interested in publishing a new snapshot
... I did Extensible Web Summit in September
... one of CSS Editors said
... I'd take the HTML spec and modularize
... and every time we updated a module
... i'd
... say "this is the module they should look at"
... that's why i said to darobin
... i don't know what it would look like
... but let's have a link
... and figure out what to put on that page later on
... i don't think it will point you to a W3C REC
... but to a ToC
<paulc> Response to plh: http://www.w3.org/TR/
plh: that tells you "this is what we know about HTML"
paulc: click on link to /TR/
[ Projects /TR/ ]
paulc: this page,
... was done at the last time the /TR/ page was reoganized
... and click on "HTML"
... you get this page
rubys: some relevant, some not as much
paulc: curious how this is similar/different to what you're proposing
... notice it's just a #frag off /TR/
[ /TR/#tr_HTML ]
plh: different
... i'm proposing a ToC
... some [here] are relevant, some are not
... if the group has one answer/how to have the best answer possible
<tantek> paulc: shows http://www.w3.org/TR/#tr_HTML
plh: this group should be the best answer
... and if someone asks what should it be
paulc: if you click on CSS
... that wasn't the answer to jeff's Q
... this was a reengineering of /TR/
... i tried to keep it up to date, it's a pain
darobin: back to MarkVickers 's point
... you mentioned collaboration
... and i'm in favor
... but collaboration takes two sides
... we can't say "hey, let's collaborate"
<tantek> would it be useful to comment on evolution of notions of CSS3 -> CSS Module Level 3 -> CSS Module Level 1 ?
darobin: my thinking is
... let's do this right
... if collaboration works, great
... if not, at least, we're doing things the way it should be done
... and maybe people will say "hey, they're doing the right thing"
... "and we should talk"
... hopefully we can remove as much friction as possible
... but it isn't something we can decree by fiat
... small modules, clock-based, i like both
... reluctant to split spec into lots of small modules
... no matter how good it would be in long term
... i'd rather do this organically
... anytime someone wants to work on the spec
... "sure, let me extract it, fork it, submit patches"
... some sections, may never touch
... <p>, <i>, <b>, <div>
[ grimaces ]
[ laughter ]
darobin: some will never be touched any-time soon
... clock based
... ties into One Web
... another fundamental is One-Test-Suite
... if you have two specs, how do you ...
... but Test-Suite is closer to metal
... informs you how implementers are making progress
... we've been pretty good at managing our test suite
... Test group pretty impressive given its utter lack of resources
... every year, run test suite, whatever passes sufficiently
<tantek> I see glazou running through the room!
darobin: say ~90% of very complete test suite
... anything passes test, goes to REC
... do every year
<MarkVickers> +1
darobin: instead of multi-year plans
... and specs that takes years to go to rec
SteveF: ok
... i like modularization
... i hate multiple amounts of boilerplate
... boilerplate **** that i don't want to read
... harder to understand
... using new features of HTML5/5.0
... <details>
... to make spec more usable
... not hugely popular
... an important audience of spec
... is developer audience
... people who use it
... primary audience appears to be browser vendors
... but everyone keeps telling us that they don't look at W3C spec
... if they don't
... (and it's not exactly true, it depends on which bits)
... if that's a separate audience, we should focus on making the spec good for the other audience
... other point
... idea of collaboration
... i don't see any collaboration
... i'd like to have it in the future
... but as long as we continue to work on HTML, i see the possibility is very small
... i'd like to work on it
... i see lots of people
... but we're not very engaging
... there needs to be some engaging
... i've tried many times
... but we need to continue
... we need to work something out
... we can't pretend things are working, because they're not
Cyril: i like the idea of /TR/html/ that points to modules/extensions
... TT WG is considering the same for TTML
... should be clear what "published versions" means
... because it isn't clear to public what it means
... might be helpful to clarify "latest published, latest version"
rubys: 1) we talked about a new landing for /TR/html/
... i didn't hear talk about versioning of that
... would we version it?
... last year, this year
... process for updating it?
... does WG come to consensus
... point to stuff outside WG
... 2) darobin, SteveF
... collaboration
... we need to figure out what we want to do
... SteveF pointed out difficulties w/ working w/ whatwg
... I work in IETF
... i'm trying w/ URL
... i'm going where work is
... in theory it's open
... if i can disprove that, it's useful knowledge
... if it's open, we'll learn from that
glazou: Daniel Glazman, Cochair CSS WG
<tantek> publishing snapshots and maintaining that was too hard
glazou: we tried publishing CSS snapshot page
... via REC track
... was too hard
<tantek> http://www.w3.org/Style/CSS/current-work is now maintained semi-manually
glazou: looking at dev.w3.org wgs
... to help doing that
... there are new publishing tools that whatwg is preparing
... plh mentioned single click to publish
... to publish WD
... in CSSWG we decided to base on WG consensus
... some Editors in the Group wanted to be able to publish at their own discretion
... there's some reluctance in the WG
... we prefer consensus
... discussion, review if needed, then reply
... 2) testsuites mentioned by darobin
... we have 60 docs on the radar in CSS WG
... that's a lot
... it's really good, not everyone is interested in every part
... each implementer is different
... some aren't browser vendors
... there's a batch-processor vendor
... they don't care about animations
... that modularization implies specifilization
... test suites are per spec
... we don't have a single suite
... darobin i don't think what you want is doable because of collisions
... one single light spec about replaced-elements in html
... don't care about collisions
... because otherwise, you'll have ETA of 2032
... it is not feasibile
... 3) fast track process in CSSWG
<tantek> replaced elements and not care about collisions? what about <input type=image> ?
glazou: when we have a module that does not progress fast enough
... but one or two features in the module are evolving faster than the rest
... w/ consensus of the group, that can be extracted from the document
... fast track that
... progress faster, and get it to the public
... you can say it creates another document, wrong, bad
... but it works really well
... even w/ large number of documents
... we have 30-40 active contributors
... this could help the HTML WG
paulc: time check
... 30 mins for coffee break
... i'll seek PF members from SVG WG
... we'll continue in second slot this afternoon
... maybe darobin we could try to make a scratchpad list of things we talked about doing
... sketch, figure out if we could assign to editorial team/chairs
... rubys "let's get practical"
... Josh_Soref 's notes are pretty good here
... things to do
<tantek> Aside: I'm happy to help provide history, guidance, answer questions about CSS modularization experience, as I'm sure glazou is as well. If you're curious how CSSWG has done modularization, please find either of us and ask us, happy to share publicly. Thank you.
paulc: let's build a plan here
... even if items aren't double-clickable
... thanks Josh_Soref as usual
[ Applause ]
[ Break until 11:15 am ]
<rubys> zalim, who is on the phone?
Scheduling
paulc: wiki has Part 1
... Joint w/ PF + SVG
... request for 60 mins
... taxonomy for 30-6 mins pref not on thu afternoon
... Part 2
... name computation and the like
janina: we don't have a need for that (drop)
paulc: accesskey improvements (shane)
... captcha wd update (janina)
janina: no
... drop mine
... not sure about shane
paulc: doesn't surprise me
... so i believe Fri Afternoon for A11y part 2 after Coffee gets dropped
janina: i believe so
paulc: third area
... joint PF w/ DpugID and CSS WG
... we've scheduled that for 4pm this afternoon
janina: we need that
paulc: we've added an update to that item an update on where the <canvas> TF is
... we were expecting that to be reasonably short
... we wanted the PF / A11y experts to be in the room
... that means we're on topic
... so, now to A11y Part 1
... 11:15am-1pm
... then we break to lunch until two
janina: thank you paulc, and html wg
... for PF
... our meeting w/ Dig, we'll meet in their space
... i don't know which cities in this hall
... we meet @2pm in their space
... SVG
SVG and Graphics taxonomy
Rich__: joint TF between SVG and PF
... i'll be chairing w/ Fred Esch
... we're creating API interop specs
... for HTML and SVG
... and name computation
... going
... moving to map semantics across both languages to A11y service layers
... and create taxonomy better suited for graphics
... A11y/ARIA has <widget>s
... <region>s, <landmark>s
... but we don't have a good way to describe graphics
... it hasn't been given attention in years
... do it right this time
... charts, STEM graphics
... also, Connector spec
... between different objects, a Flow diagram
... doing this for SVG
... also applicable to HTML5 <canvas>
... also developers create drawings w/ CSS+js on HTML
... taxonomy applicable to that area as well
... if UCs that we have for HTML that we haven't addressed, we'd like to hear about them
... also, Connector spec in SVG
... Connector between two objects
... explicitly declared for SVG
... not sure how to do for HTML
... also affects Navigation
... keyboard navigation in HTML tabindex=
... <tab>
... but sometimes you need to give users options of where to go
... we'll explore
... it's largely for SVG
... but how to apply to html
fred: ARIA flowto=
Rich__: <connector> in html?
... dual purpose
... author gets things for free?
... is that something to look to in HTML?
... in future versions
... or limit to SVG?
... bring up spec/drop link?
katie: Katie Haritos-Shea
... could that be used in context for 3D/navigation?
[ groans ]
Rich__: 3D is around WebGL
... it isn't declarative
... i know Google is using WebGL for maps.google.com
... another exploration area
paulc: lots of words, you need to give us pointers
... have you started discussing public-html@
Rich__: no, we just started discussing today w/ CSS
paulc: you had a meeting before this meeting
Rich__: Q1. specific semantics to include in taxonomy that people use in HTML today?
... Q2. create <connector> in HTML?
... or just focus on SVG?
... taking task for HTML
... specs are becoming closer and closer aligned
paulc: to Q1
... for what?
shepazu: Doug Sheppers, W3C, a Staff Contact for SVG
... i'm a were-- err, no i'm a simple villager
... look at a Bar chart
... axes, legend, bars (indicate values)
... other data visualizations have similar things
... breaking those things to constituent parts
Rich__: ARIA has Grid, Checkbox, Tree
shepazu: checkbox has element that is checkbox, mark for checkbox, label
... you can describe those in ARIA
... if you make your own checkbox rather than <input type=checkbox>
... similarly, if you make a barchart, you'd be able to identify tick-marks, ranges, in ARIA
... a taxonomy of data visualizations
... SVG can draw anything, but we're talking about a taxonomy
SteveF: comment to SVG/PF/...
... when we're discussing this stuff
... if this is brought to html wg
... i'd ask this be discussed on public-html@w3.org<mailto:public-html@w3.org>
... rather than the TF list
... the TF is a subset
... but we want to draw as many experts as possible
<shepazu> Connectors are here... http://dev.w3.org/SVG/modules/connector/SVGConnector.html and http://tavmjong.free.fr/SVG/CONNECTORS/index.xhtml
SteveF: but we want to draw people to it
janina: HTML A11y TF is not a TF at play
... this is a new TF between PF+SVG
... if we take all discussion to HTML list
... if that's what you're discussing
SteveF: just use public-html@ not a11y list when you bring things to HTML
Travis: we had a great meeting now that HTML5 is a REC
... 1. taking a more modular approach
... we welcome these contributions to the HTML family of language
... but we probably wouldn't be in the core document
... HTML's SVG is exclusively in the parser
... the rest of it probably wouldn't have a relation to the document
shepazu: there's another aspect of SVG/A11y
... larger, how we integrate <SVG> in <HTML>
... you can reference external an external .svg file w/ <img src=http:///<http://> >
... <SVG> is like <HTML> but for graphics
... you might have <path>, <circle>, <rect>
... it's markup
... just like <html>
... you can now include it inline in <html>
... right now, <svg> is treated as something very separate
... and <html> in <svg> has to be included in a wrapper called <foreignObject>
... we'd like to see <html> inside <svg> w/ a closer relation
... many people who use HTML and SVG together would like to see that
... SVG is often used w/ D3
<inserted> Data-Driven Documents<http://d3js.org/>
paulc: where is that joining defined?
shepazu: sort of defined
... it doesn't cover sizings
... but it needs more definition
paulc: where would that be done?
<Cyril> https://svgwg.org/specs/integration/
shepazu: we have a document called SVG Integration
... <object>, <iframe>, <img>, css background:()
... i used to have <embed>
... it doesn't have <html:svg>
paulc: scroll up to top
... FPWD from April
... what impact does this have on HTML spec?
shepazu: exclusively talking about SVG and its context
... we're proposing that it would also cover inline svg
dirk: it doesn't right now
paulc: at that point, it would interact more w/ the current hook
shepazu: the current parser hook
... we'd like to first class citizen <html>
... rather than have <foreignObject>
... we'd like to have an <html> element in SVG
... which would be an html root
... inside that you could put html content
... good idea? bad idea?
... possibly having <html:circle> merging HTML/SVG
paulc: if you're adding taxonomy to SVG
... and create more increasing link
... you'll inherit that
shepazu: yes
zcorpan_: Simon, KKW
... bring up a point Travis mentioned
<scribe> ... new attribute/element affects parser
UNKNOWN_SPEAKER: but it only applies if it has uppercase
... if it's just lowercase, it doesn't affect the parser
shepazu: and we will not use Uppercase
... we'll lowercase everything from now on
... we swear
[ he's lying ]
[ he's a werwolf ]
richardschwerdtfeger: we have declarative tabindex
... sharing
... more seemless
... we have <iframe>
shepazu: i don't remember current status
ed: i think we do have that
... we have a topic for SVG WG agenda to discuss that integration
... Eric Dahlstrom, SVG cochair
<gitbot> [13html] 15darobin pushed 2 new commits to 06whatwg: 02https://github.com/w3c/html/compare/c7b287ef2e8a...45d62861f2d1
<gitbot> 13html/06whatwg 1409c8c7a 15Ian Hickson: [e] (0) typo in :matches() argument...
<gitbot> 13html/06whatwg 1445d6286 15Robin Berjon: Merge remote branch 'origin/master' into whatwg
richardschwerdtfeger: let's try to coordinate
... we're doing it for A11y, but...
paulc: i've heard noone answer "Do we have a taxonomy?"
... i'll say "we don't"
shepazu: we know you don't have one
... we're wondering if you guys are open to the idea of merging <svg> elements into <html>
paulc: if we did that, we'd inherit that taxonomy
shepazu: taxonomy would be in ARIA
... you could do taxonomy w/ a barchart using divs/canvas
... flash
... silverlight
richardschwerdtfeger: taxonomy
... <connector>
... more specific to svg
... it'd be nice to have it as an element in <html>
<Santabarbara> http://tavmjong.free.fr/SVG/CONNECTORS/index.xhtml
shepazu: a connector is a thing that connects two things
... it's a graph
[ Applause ]
shepazu: thank you, i appreciate that, i'll be here all week
... it says "i am the connection between A and B"
... say you have an org chart/genealogy tree
... each would be a new connector between different elements
paulc: a) you're getting <rect>/<circle> more intimately into html
... b) you're also offering <connector> to connect a textbox to a list
shepazu: personally i think it's challenging
... one is visual
... there are ports
... also, when you move shapes around, the connector keeps those things connected
... there's also logical navigation
... there's also an opportunity to describe the nature of the connection
paulc: are there primitives?
... child?
shepazu: i don't think we should drill into that at this point
paulc: if we said "blow our minds"
... continue your work on inline-svg
... we'd get connectors for free
... using them with html could be a separate question
shepazu: also a bit on focusable:
richardschwerdtfeger: a number of discussions in PF
... on tabindex=
janina: another topic
richardschwerdtfeger: we'll run into this tomorrow
... CSS has flexbox
... changes flow of page
... tabindex doesn't follow that
... not sure if today/now
... big can of worms
paulc: taxonomy for graphics
... expanded to inline-<svg>
... expanded that to expanding set of objects in svg to include <connector>
... and told us we might be able to use it in HTML
... also event handler
SteveF: wrt <connector>
... how would it help
... what are UCs for <html>
... from looking at it
... it appears to be mainly accessibility info?
shepazu: no
... if you've seen a meme w/ a flow chart
... anyone would be able to use it
... navigation for sighted people as well
SteveF: advantage of this over additional attributes?
... rather than adding an element
shepazu: you don't want title=/label=
... you want it to be in different languages
... connector can have description as a child
... deeper information
SteveF: <div att=connector>
... a lot easier to add attributes than elements to html
shepazu: yes
... i'm not proposing <connector>s for html
richardschwerdtfeger: <connector> gives semantic and drawing
... two boxes drawn in html
... and then i can draw the actual connector
SteveF: i thought we were talking about HTML
shepazu: i'd rather you see the proposal + UCs first
cyns: Cynthia Shelly, Microsoft
... we have connectors in Visio - i worked on them
... they're pretty complex
... they'd be hard to do w/ attributes
paulc: have we done what you wanted to do?
... some talk of doing work w/o changing html
... sounds like you do things as long as you do it in lowercase, you just do your thing
shepazu: yes
paulc: when would you have a doc for review?
shepazu: 4 months?
[ Nods ]
paulc: WG Draft for review?
shepazu: yes
paulc: chairs make sure we're aware of document
... helps to identify what parts of document to look at
... or know what you've broken
... think you might break
... ask if other changes are needed
... asking us to just look at a dead cat
... "it's a dead cat"
shepazu: we'll try to avoid felinicide
paulc: -> Agenda
... we've covered graphics/taxonomy
ComputedRole/ComputedLabel
richardschwerdtfeger: we met w/ WebApps earlier in the week
... we're proposing reflected attributes
... roles
... on elements
... getComputedRole()/getComputedLabel()
... when we get to CSS discussion
... CSS injects content into the page
... name computation gets more involved
... for test/tools, we need the computed name/role of object
... we can't depend on the dom any longer
paulc: these are things in the dom
... which part of WebApps scope is impacted here?
richardschwerdtfeger: we went to WebApps
... chaals said submit it here
paulc: where in their family of specs would it land
richardschwerdtfeger: it would be on a DOM element
paulc: that's where i was going
... who owns DOM?
... you'd like additional methods on Elements
richardschwerdtfeger: yes
... not just for HTML, same things for SVG
paulc: best way to handle this
... when we talk about After HTML5
... we should add a sub-element
... sub-item
... that HTML WG had assigned to it DOM4
... has to clearly define its future for DOM
... chaals gave you a very good answer
... i gave the Indie-UI the same answer
... do the work, we'll figure out where it belongs
... i'm trying to give the same sentiment
richardschwerdtfeger: i wanted to give a headsup
janina: this seemed like the time
<SteveF> Element.getComputedRole() thread on PF list http://lists.w3.org/Archives/Public/public-pfwg/2014Oct/thread.html#msg120
EventHandler enumeration
janina: you've said no in the past
... maybe things have changed
... we understand you can get an enumeration of
... what's registered for each particular element platform by platform for particular element
... or with a plugin
... i'd like to ask Jon Gunderson to talk about it
jon: Jon Gunderson
janina: is shane in the room (to point to past requests)
jon: useful for a11y, in evaluation tools
... if someone has assigned a role=widget to an Element
... you expect keyboard/click handlers related to the role
... w/ Testing Tools, we need to look for things related to that node/its parent
... we need a special api for a particular browser
... or if we're on a server w/ HTMLUnit
... we need an extension
... maybe we just want to know "is there a keyup/keydown/mouseevent?"
... "are there mouseevents on this <div>?"
... then "this is something interactive"
... "are you using an ARIA role=?"
... "ARIA role=widget, is there a keyboard handler?"
... for Indie-UI
... "we're seeing key handlers, maybe you should use Indie-UI events"
... problem for me as a developer of an evaluation UI
... i develop specific test cases
... i can't use the DOM to get that event info
... in my unit test, i basically skip anything related to event handlers
... i can't build test pages that automatically test themselves
paulc: so you want a way to enumerate all event handlers?
jon: no, just are there any for a given type on a given node
... boolean is enough
... i don't know what it will do, just know that it will listen
paulc: anyone in the room receiving/sending side
janina: there was resistance to doing this in a standardized way
<SteveF> Report on event listener investigation http://lists.w3.org/Archives/Public/public-pfwg/2014Aug/0090.html
janina: easier to build MITM attacks
paulc: oh, you'd know an element had a particular event
... possibly a DoS? by using event over and over again
Travis: some event handlers are known already, onfoo
... what's the difference between that and addEventListener
jongund: rarely are inline events used
... it's pretty rare that people use onclick= on elements
SteveF: there's an email Shane did
... on event listener registration
... PF discussion
... background
adrianba: Adrian Bateman, Microsoft
... a bit confused about specific UC
... this might be helpful for those few times where you have an event handler attached to a specific element
... increasingly, control libraries developed
... event handlers tend to be on different elements
... events captured somewhere else
... seems it'd be hard to discern anything about how interactive an element is based on presence of an event handler
Cyril: not sure if it's sufficient for you
... you could overload addEventListener
... and setAttribute
... i've done it in an application
paulc: i've seen nods
... have you tried jongund ?
<adrianba> +1 to cyril - we do this for similar purposes
jongund: we have a sidebar in Firefox
... if you open the sidebar after you've loaded the page, you don't have a chance to overload
... also in a browser, there's no guarantee when your overload gets into the process
... for parent/child relationship
... we do look at all parent elements
... and child elements
... not definitive
... if i see there are mouse handlers, but no roles
... i don't know for sure, but i can probably tell him that you need to look at what you're doing
... maybe add ARIA
... and if you do add them, and i don't see keyboard, i can tell them they still aren't fulfilling ARIA
... people build a page
... they read spec, they add aria role=menu
... they add that all over
... look at aria evaluation
... it doesn't work because there aren't event handlers
... not supporting keyboard/managing focus
... i can use hooks to tell people that they need it
Travis: i have a resistance to a general purpose feature in the language
... i see it's a valid UC for testing/a11y
... when you want to prod it
... testing at load time is a small portion, if you don't exercise event handlers
... have you thought about asking the Web Driver folks to get it added there?
Josh_Soref: +1
jongund: I haven't looked into that
... we haven't looked in PF either
paulc: Web Driver is more recent
... more comprehensive testing than the last time PF/A11y asked for this
... UC is very Test oriented
... and as Travis said, we should figure out how to test these features post pageload
... maybe that's a possible route
cyns: UAAG WG was asking for a similar feature
... to track events/change input method of them
... MS said it wasn't feasible
... you didn't know if you got all the events
... I think Web Driver would work
... In a11y, we're often trying to change the input method
... i wonder if there's anything we could do to make it feasible
paulc: even if you collect some of them
... others could come up later
<Zakim> cyns, you wanted to say that UAAG was asking for a similar feature. I gave them feedback that it wasn't feasible to do this because the events could be bound at any time, and
paulc: potentially an infinite number
... i heard two implicit action items
... a11y should go look at Web Driver
... partial fix for the problem
... i didn't hear anyone speak to old reason
... i'll believe that's still a valid pushback
... maybe less so in testing case as Travis said
... and shepazu took an action item to make sure HTML WG progresses to a particular stage
... and include question in a review request
... include me in the to: field for public-html@ (technical) or public-html-admin@ (non-technical)
... if you send review request with technical review, use the former, if you don't have questions, use the latter list
... shepazu, you're invited to split the request into two
... questions in subject field
... we have another slot this afternoon
... 4pm for notes, footnotes, roles/validation for digital processing
... we have a hard stop at 5pm
... another agenda item, someone calling in from China
janina: that's fine
paulc: cyns, that's the slot you wanted?
cyns: mine was about events
paulc: confirming that we're dropping name computation, access key, captcha
shepazu: we in SVG ... in an obsolete version of SVG
... we have a focusable= attribute
... this serves the purpose
... most stuff in SVG isn't focusable
... we're thinking of re-adding that for SVG2
... we also have tabindex=
... we want to talk about that relationship
<Cyril> http://www.w3.org/TR/SVGTiny12/interact.html#focusable-attr
paulc: i'd recommend you divide it down to technical topic
... xpost to svg@ +public-html@
zcorpan_: tabindex=
... it's not necessary to have focusable, tabindex=0 means this is focusable
shepazu: we'll have a longer discussion someplace else
<Zakim> timeless, you wanted to note on Process TF is encouraging review requests to identify the areas which would be interesting to reviewers
<Zakim> timeless_2, you wanted to ask shepazu about css for focussable
paulc: recess for lunch
... back at 2pm
[ lunch until 2pm ]
Agenda Bashing
paulc: this item was meant to give us an update on the joint Editing TF
... not just HTML+WebApps, but lots of other people
... i'm not trying to replay the hours of discussion from earlier in the week
... i think it's important to make the HTML WG aware of that discussion
... after that is a Coffee Break
... and then After HTML5 discussion
... concrete, look at scribbled notes
... 4pm with PF WG and DpugIG + CSS
... also folded Canvas TF report -- probably first
... i may have had a request to do it first
... i haven't confirmed, i just sent an email to China
... it's 5am (China time) now
... planning to do 5:00-5:30pm on WebPerf proposal
... we still don't have anything after Coffee tomorrow
... I'm reordering EME bits
... I had a request about Bug 26332
... currently anchored @ 10am
... and a general pointer to EME bugs on first item
... still talking to TF participants about order
... darobin, under DOM4 test results, i just picked up pointers to documents we attempted to use for CfC and are ready to use for TransReq
... I think that's all the changes
... darobin ?
Editing TF
darobin: editing, contentEditable are major pains to everyone
... a few months ago we gathered people together
... we set up a TF
... there's a lot to fix, a lot of moving parts
... we tried to split into manageable chunks
... even if we don't solve editing, just improve a part
... it makes life easier for people
... we have several things in parallel
... 1. collaboration w/ Indie-UI -- Intention Events
... instead of having to intercept cmd-z + ctrl-z + ctrl-u (some locale) + shaking phone
... UA does transformation for you
... undo might not be part of the first batch
... text insertion, deletion, newlines, selections
... that's meant to abstract on top of what's going on
Travis: worth noting
... these are actions... Intentions... confused me
... these Intentions come after the classic device-events are fired
... you'd still, if copying/undoing via ctrl-z
... you'd get keydowns, etc
... if after all of that, nothing was done to upset the browser's intention for undo
... it falls at the end of the pipeline
rniwa: re: Intention, clear aspects of Selection
... there's IE getSelection(), but no spec
... trying to write a small spec to document what's implemented by browser
... some aspects are lacking
... e.g. in github
... caret positioning is underspec'd
... selection at end of previous line/beginning of next line
... if text wraps via soft-wrapping
... you can't tell from DOM if caret is at the end of the line, or after the line break
... or you can't tell if the caret is before/after text direction transitions
... some browsers render the caret in different locations
... knowing where the caret is enables you to position a toolbar correctly
darobin: there's also caret-direction
... which might influence selection
rniwa: ... in Firefox
darobin: it needs to be interoperable
rniwa: based on UCs
darobin: .contentEditable is problematic
... = true, you get a huge bags of behaviors
... browser starts handling bold, underline, undo
... first thing you do is stop browser from doing everything
... so we're working on X.contentEditable = "typing"
... when you set that on, you get the events related to editing, but the browser doesn't respond to the events
... this is a primitive people can use to build editors on top of
rniwa: the key point of X.contentEditable = "typing"
... is that it allows browsers to handle IME / spellcheck
... in some cases, if you have a round of CJK
... and you want to convert the text back to composing state
... you could
... the application specific logic would be handled by the app
darobin: it's more complicated than IME/spellcheck
... we'll also do compositing
... 'e -> é
... deadkeys, hebrew punctuation
paulc: it's one thing to scribe puns
... but another to scribe editing instructions into irc
darobin: editing options
... possibility to insert a Shadow DOM with the text before IME/compositing is done
rniwa: one aspect of Editing
... that i'm not sure of
... is selection, the way to serialize selection
... if you do getSelection().toString()
... you get the plain text of the selected content
... you get .innerText
... which isn't spec'd anywhere
... do we block the spec on this?
glazou: you can also say it's the .textContent
darobin: you don't want that
... because it gives you hidden text
... Travis has an action item on it
... "text events and keyboard events are *easy*"
rniwa: CSS generated content, i don't think any browser lets you select individual characters of a generated run
... i think there's a desire to be able to select it
darobin: i'd like to select generated content
... i want to get the numbers from generated list
glazou: it'd be impossible for the time being
paulc: seems like this is a module
... a direction for this TF
... i made that comment during the WebApps meeting
... i'll make the same recommendation to the TF
... probably much easier
darobin: welcome benjamp
... thanks for showing up
... contentEditable makes sense as an HTML module, even if it's a 5 line module
... it could be a good test
... makes for good practice
paulc: darobin, you said, your preference
... "not rip the spec apart, just to rip the spec apart"
... "just to create modules when we need them"
... maybe that's where it is
darobin: definitely one of the first ones
rniwa: helps that we're a small group of people
... html-wg has a lot of people
... maybe there are other parts of the spec that people can work on
darobin: i agree
... we started on public-webapps@
... a couple of people contacted me saying 1/2 the content was Editing
... please go to your own list
... and webapps is high traffic
benjamp: you were talking about X.contentEditable = "typing"
... there's a corollary
... WebKit has X.contentEditable = "plaintext"
... which is actually that
... it's 10 years old
rniwa: "plaintext" is slightly more complicated than "typing"
... it supports insertion/deletion
darobin: it's a textarea?
rniwa: that's what we internally use to implement it
darobin: when you find out how browsers work
... you wonder how the web holds together
[ "with crazy glue" ]
paulc: are there minutes from WebApps?
darobin: yes
... i'll find that
<rniwa> Editing minutes from HTML WG: http://www.w3.org/2014/10/27-webapps-minutes.html#item26
<rniwa> Editing<http://www.w3.org/2014/10/28-webapps-minutes.html#item08> from WebApps WG meeting
After HTML5
s|Editing minutes from HTML WG: www.w3.org/2014/10/27-webapps-minutes.html#item26|-> http://www.w3.org/2014/10/27-webapps-minutes.html#item26 "selection, editing and user interactions" from WebApps WG meeting|
<darobin> let's use an Etherpad: https://etherpad.mozilla.org/U16aQP4aQB
paulc: rubys and darobin went to the AC meeting to discuss this topic
<darobin> https://darobin.github.io/modularity-slides
s|https://darobin.github.io/modularity-slides/|-> https://darobin.github.io/modularity-slides/ "HTML Modularisation" slides|
darobin: overall positive
... questions about "how does this interact w/ PP"
... "what was your paper trail"
... no interesting questions
[ Cunningham's Law ]
[ Magic & Innovation ]
rubys: tantek challenged that (Extensible Web Manifesto)
[ Tooling & Agility ]
rubys: rat hole on github
... not actions here
... i characterized as WIP
[ Software Development ]
rubys: some challenged bleeding is only
... i don't think any wanted only old
... plenty in middle
[ The Unix Philosophy ]
[ Modularisation ]
rubys: perceived as a ding
... two people defended work they did
... XHTML modularization let you picked one of part A and one of part B
... hypothetically, if you split <table> out to a different document
... it wouldn't mean that you can not implement it
paulc: when we did the breakout on Wednesday
... I encouraged people to look at the Extension spec
... which says you can use HTML5 + others
... I think there were very few people beyond Noah Mendelson
... who raised the concern
... who read that spec
rubys: we made a change
... noah said "you can't say I'm an HTML5 client without being more specific"
... you have to say "conformant to HTML5+longdesc"
... Hixie said you can just say "conformant to HTML5"
... noah was saying you had to specify
... we tried on IP provenance
... we tried twice to say
... currently, someone sends IP to ML
... and it makes it to the spec
... we tried to track
... github does some tracking
... we said we could report various contributors
... tracking when people stop working for employers when ...
... we can't do
... more data is good news
... but it seems to rathole
MikeSmith: that argument doesn't make sense
... we're there already
... using outside systems won't make it any worse
[ Questions? ]
paulc: darobin, you're the only one w/ an action
action-249?
<trackbot> action-249 -- Robin Berjon to Triage new whatwg updates, html bugs, landscape document in order to list priority content for modules -- due 2014-11-06 -- OPEN
<trackbot> http://www.w3.org/html/wg/tracker/actions/249
paulc: hoping to make a more extensive list
... i know you were busy over lunch
<darobin> https://etherpad.mozilla.org/U16aQP4aQB
paulc: i don't know if we want to open up your scratch pad
... DnD was there
... what was the definitive list of things that failed to exit CR?
darobin: date and time related elements
paulc: categorize as "failed CR items"
... things to polish spec text, polish test suite, polish implementations
... we had a request from Addison and i18n
aphllip: Addison Phillips, chair of i18n WG
... i brought my cohorts here
... we have a couple of things we proposed in the past
... not a good fit for HTML5
... one was handling TZ values
... for time values on the web
... we have a proposal
... it was created
... it's in HTML.next bug space
<r12a> Locale-based forms in HTML pages<https://www.w3.org/International/wiki/Locale-based_forms>
<r12a> HTML5 TimeZone<https://www.w3.org/International/wiki/HTML5TimeZone>
aphllip: timezone
... calendar
... there's a Blink intent-to-implement
... we have good guidance there
paulc: things we tried to do in 5.0 + moved out, or only got to bug stage
aphllip: things we either didn't fit in the timeline from early on
... TZ is that
... or things which exist in HTML structure and were considered out-of-scope
paulc: is TZ the only item, or do you have a collection of items
... how many of wishes do you want?
... and if your third wish is for more wishes...
darobin: that's locale dependent
paulc: no, the number of wishes and when they occur is TZ dependent
aphllip: TZ is concrete
... forms affected by Locales
r12a: Locale varies
... we've identified issues we want to think through more
... possible security problems
aphllip: 3rd wish, we wished our issues list before we came here
[ laughter ]
paulc: generally thinking about doing
... if we have a subgroup, e.g. Editing TF
... pull it out into a module, then let them do a pull request
... and see their proposed replacement
... wondering if i18n WG would be willing to work like that
... high level Q
... would it suit your workmode?
... suit your direction?
aphllip: i think not
... although we do develop things like that
... we generally have our feedback on what others develop
... TZ is recommendation for an approach to solve a specific set of problems
... w/in the larger context of say, <form>s
darobin: you don't have to do all the work yourself
... we're not excluding people from outside the group contributing to modules
... we're making a list now
... but this isn't a finalized list
aphllip: we're not shy, not against helping
... but we come here not understanding how we'd do that yet
paulc: we come unprepared because we don't know what to ask you to do yet
[ mutual confusion ]
paulc: your desires to improve a part of html5+ would fit in w/ this model
... we might have to find someone to work w/ you
... set UC, Reqs, and go from there
... you provide commentary on that
... I mentioned i18n WG in the wiki
... have i met your needs?
rniwa: one thing, looking at the list
... Locale based forms + HTML timezone
... it'd be really nice to have concrete user scenarios
... user visits Citibank account from China
... maybe you want to show numbers in Chinese instead of Latin
... helpful to see scenarios
... potential problems you anticipate
... could be really helpful
paulc: is that all the failed items?
darobin: it's all the stuff that got pushed off
paulc: also missing are items from other groups
... e.g. whatwg
... if we're identifying modules
... we should identify what we're working on
... and what others are working on
darobin: this also includes our worklist
rniwa: if we're modularizing it
... the newer version of html draft should link to the module
... otherwise, a person reading html5 spec may not realize it's there
paulc: we haven't solved that problem at all
... but we recognized it
... we're thinking that we might use the extra link in html5 spec
... not current version, but latest version
... /TR/html could become a link of specs defining sum of html
darobin: as we move stuff to modules
... if things have modules, we'll cut things out of html5 core
... we haven't done it, and we might bump into issues, but we have a reasonably good idea
paulc: did i miss anything?
... any things in whatwg that aren't in 5.1 that aren't in this list?
MikeSmith: yes
... whatwg spec has WebWorkers, WebSockets, WebStorage
<plh> I heard canvasproxy this morning
MikeSmith: but we've already handled that
darobin: who mentioned <hgroup>?
paulc: i gave up months of my life to <hgroup>
... i want those back
... we need to update the landscape document (from June), then have definitive list -- and provide rationale, difference, additions <- what paulc is looking for.
... i want to start by looking backwards
... then turn 180 degrees and start looking forwards
... get definitive list, publicize it, get people to understand it
... we need an incredible list
... modules we'll work on, modules we think others are working on
darobin: <template> is in html5
... i think we dropped <input inputmode=>
plh: isn't there a spec in DAP?
... Hixie has been trying to solve
... one is script-dependencies
... i know Hixie is working on it
... so that, features that might be added to whatwg spec
... it's quite complex to solve
... i don't know where he is at getting to that
... another I see in WGs is ServiceWorker impact
... on the architecture
<darobin> https://whatwg.github.io/loader/
plh: we might want to think of impact to whole spec
... if SW is the future of AppCache
... then someone needs to look at that
... another that the WebApps WG is working
... is WebComponents
... they're impacting HTML as well
rniwa: from WebApps, when we worked on XHR
... there's a refactor for Fetch
... perhaps refactor of spec to have a better model for how HTML and DOM interact
... i think Hixie last year or two years ago added Tasks and MicroTasks
... so MutationObserver could work w/ those timings
... so things could be coherent
... Model changes could be important
plh: when we shipped HTML5, there are dark corners
... one is the Window object
... i'm not sure we want to take on that dragon
... since we're fixing HTML5 spec
rubys: another category, things no one is working on but should be
paulc: dark corner
... speced to a level that can be tested
... show certain amount of interop
... but multiple implementations do things that aren't in the spec/aren't tested
plh: yes
... or seeing only one or two do, and two others aren't doing it
... and no convergence in sight
Travis: referring to WebIDL, or things like .name, etc.?
rubys: I remember a specific one
... loading a document
... it's true every browser loads a document
[ laughter ]
rubys: spec says how you should do that
... but browsers don't do that
... there are observable differences
... i see heads nodding
paulc: Travis said don't take the bait
... simon's saying the same thing
... We have this list
... darobin made a suggestion this moring
... we shouldn't just take a butcher knife/cleaver to the spec and break it up
... but maybe disciplined
darobin: i'd never use disciplined
paulc: ok, ondemand
... SteveF suggested having a particular area to work on
... so we should show how we'd go about doing this
... start small
... set success bar low, overachieve
... find out what works/doesn't
... do one/two
... ask the question, how do we do maintenance on that section
... tantek_ made a strong point
... minor release of 5.0 w/ just errata
... think about that while doing new work in some of these areas
... ask some group of people, possibly editors to put together a concrete plan
... hesitant to say plan
... what are the next steps?
darobin: i'd like the next steps to be get to work and write specs
... need for higher level visibility, it ought to come from triage action
... things we could work on/open sores
... rather than planning, i'd rather do work writing spec text + publishing
... i heard SteveF would like to get to work
... lacking visibility prevented that
paulc: the only part that concerns me is a Q that SteveF asked this morning
... darobin you said, if you were to start new work, you'd rather do it off CR branch?
darobin: no, i'd rather do that for maintenance
paulc: i'm asking for a plan
... your action was to triage those 288 bugs
... landscape document will help
... some will involve cloning
... i believe we need to give the consortium members a plan on maintenance
... and how we're doing After HTML5
... i don't believe one of the editors w/ a favorite topic here can get started w/o part of the story written
darobin: i'm not sure if we'll keep master(5.1) alive at all
... we might not
... i need to think about it
... i haven't thought about it at all
... if we only do new modules in separate documents
... and only do maintenance on CR branch (which should be renamed)
paulc: i want that written down
darobin: i think we can do them in parallel
paulc: you can do them for some people
... but for other people
... all editors have a high pain threshold
... you want a bit of experimentation
... but we want to show progress
... bottom line is writing spec text
... if we want other people to do this, they have to understand the system
SteveF: WAI-ARIA section
... Hixie has said in the past, and quite recently
... said if someone were to take that, and turn it into a module
<gitbot> [13html] 15darobin pushed 1 new commit to 06CR: 02https://github.com/w3c/html/commit/1df5ac60e8c7e7ccfcbe1fce1b5cae074d756675
<gitbot> 13html/06CR 141df5ac6 15Robin Berjon: stray inputmode
SteveF: he'd be happy to point to it
... he did ask me
... i'm not sure if he'd be happy w/ it being in W3C
paulc: SteveF, really good characteristic, let's find out
SteveF: MikeSmith , you've seen the expressed sentiment
MikeSmith: no, we've talked about it
... whatwg is a do-ocracy
... and if you volunteer it, then that's ok
SteveF: and that's one of the sections where people look to W3C
zcorpan: what you described is something that has happened on a few occasions
... there are several parts that were in html5, and someone took over it
... and in several cases it moved to w3c
... one is DOM Parsing and Serialization, Travis is editing it
... when it became clear that W3C version is better maintained
... WHATWG redirected their url to w3c url
... there's precedent to being happy to move stuff to w3c
SteveF: seems like something we're going to do anyway
... Hixie will point to it
<darobin> http://domparsing.spec.whatwg.org/ now redirects to W3C DOM-TS
paulc: other examples of it
... Hixie pointed to zcorpan for the <img> element
zcorpan: also, WebSocket Protocol and WebVTT
... lots of other things
paulc: looking squarely in the eye of darobin here
... do you have direction
darobin: i can come back in a year and a half
paulc: when will you convene the editors
rubys: same question to SteveF
paulc: when do we see progress
rubys: SteveF , do you have enough direction
SteveF: yes
... some advice on splitting out
rubys: ok, but you're not gated on us?
SteveF: partially, if i ensure, if i pull it out, that it won't be consumed (absorbed, taken over) by someone else
paulc: thank you to our i18n friends
[ Applause ]
paulc: if darobin has enough data
... we've spent 2 hours on this topic, that's enough for now
... we'll reconvene at 4pm w/ PF WG
<darobin> edoyle, Travis, hober, SteveF: I'd like to take a pic of the editors together after the meeting :)
paulc: i still haven't received confirmation about 5pm slot
[ Coffee Break until 4pm ]
<rubys> http://lists.w3.org/Archives/Public/public-html/2014Oct/0068.html
<darobin_> darobin has joined #html-wg
Dpub Roles and footnotes
tzviya: Tzviya Siegman
dcramer: David Cramer, Hachette Livre
paulc: two topics PFWG wanted to talk about, overlapped w/ DpubIG and CSS
... support for notes/footnotes
... roles/validation
... and since Canvas TF is a11y related
... i'm going to overrule my original decision
... we'll do Canvas last
janina: PF is mushrooming
... we're thrilled to be working w/ DpubIG on enhancing access to books
... making that accessible
... desire of DpubIG is to leverage HTML5 to do this
... it doesn't quite meet their requirements
... a lot of our discussion just concluded was on what doesn't meet this
... wanted to share our approach w/ HTML WG
... 1. semantic markup
... need to know what's what when you publish a book
... what's a chapter, subsection
... might function like a chapter
... but it might be another word
... Dante's Inferno uses Canto's -- like chapters
... PF as gatekeeper
... community extensible vocabulary, PF manages to avoid collisions of definitions
... roles will help identify what's what
... and help assistive technology present it appropriately
... ARIA needs to change slightly, but not much
... footnotes we do need better support from HTML
... footnotes is best as an example of what's missing
... not the only thing that's missing
... #frag isn't enough
... want to know where it starts, and where it ends
... <p>...</p> don't have for footnotes
... what kinds these structures
... don't treat it as the full object
... hard to know where to end
... additional problems
... you came from somewhere, something referenced it
... you need to go back to where you came from
... but you could come from many places
... you want to go back to the right place
... i'd be remiss if i didn't touch on
... we had a Director's decision about a Formal Objection on longdesc=
... Dpub needs that, but it isn't enough
... different kinds of media
... braille + graphic + texted description as targets
... may be need for different description for image for different audiences
... want to work with them
... everyone who hates longdesc=, or those who like it
... help us build a better mousetrap
... for kids in schools, and professionals
... to be fairly tested on their knowledge, not lack of sensory ability
... what did i miss Tzviya?
Tzviya: vocabulary for role, would cover how long
... if i link to footnote
... we don't have a method to get back to the content
<Zakim> dauwhe_, you wanted to discuss Tzviya
Tzviya: it's really crappy to navigate through an eBook right now
... we see sexy manipulation, footnote pops up
... but for sighted readers,
... if i turn the page, it might not be there
... if i want to cite it, it's not there
... if i want to print it
... it's not there
... we need some method for maintaining these
... linking them
... maintaining a functional body
... one group exploring this is Annotations WG
... maybe
janina: how to build a better footnote
... how to treat that object in a publication
... we'll identify the structures that need it
paulc: you want the equivalent of the back button?
jfolio: increasingly complex if you have 3 refs to the same footnote in the document
... on the second instance, you jump down and read the footnote
... the requirement is to go back to the same resource that sent you
... there's memory capture
paulc: that's what the back reference does
... 3 refs to IBM quarterly results
... i can click on one of them, go to the content, and click back
darobin: if i click back twice accidentally, i've lost my place
... and yay footnotes
paulc: are people hypothesizing a <footnote> ?
[ No ]
rniwa: i think the back button not working seems like an Implementation issue
... more than a spec bug
... is back() spec'd ?
zcorpan: the behavior of the Back button depends on the
... navigation part of the spec
... which is a mess
darobin: in ebook navigation context, you might not be exactly in the same context as in the browser
... if you go from a footnote, and hit back twice, you might exit the book
Josh_Soref: that case, it will probably be better, since the book should remember the last place you were in
darobin: you might want to know where the footnote came from for something
dauwhe_: i've been working on print style footnotes in html+css
... people will code footnote at point of reference
... renderings involve moving that content to somewhere else in the document
... bottom of page, floated to margin as a marginal note
... sometimes we want to put something where it was
... larger problem
... if you float it, you might want a marker at point of origin
... might be able to use to create this
Tzivya: we have that need in many places
paulc: we've spent 4 hours today telling people who come to us to do it on their own
[ laughter ]
mhakkinen: Mark Hakkinen, Educational Testing Service (ETS)
... footnote
... we have test items, delivered in HTML
... reading task items
... going back and forth
... "in the following sentence"
... you want to go back / forth in the sentence
... we don't want to hard code
... really hard code
... hard to code for assistive technologies
rniwa: ebook reader
<MikeSmith> dauwhe_ is Dave Cramer
rniwa: if they have a special UI to get out of a book, that's outside the realm of html wg
... i have a hard time of reconciling that
... if the UC is inside the page
... if it's involving iBook content
... not really a web app per se
darobin: we need UCs
... to be pretty clear
... paulc said you'd be on your own
... obviously we'd be helping
... value: bring UCs
... explaining what the problem is
... what can't be solved w/ existing technologies
... with code examples
... we might come back w/ you could use this
rniwa: we also need to figure out which part of those problems that can be solved w/in HTML WG
... maybe some in other WGs, maybe government regulations
darobin: it might always be HTML, some may be CSS,
Tzivya: we came here to talk about ARIA
... the only ask of HTML is Validation of Role
... work is to provide information to PF
... i have time
janina: as long as you're ok w/ using role= as a model
darobin: if we start adding too many roles
... are there cases where you expect someone to want two roles?
Tzivya: no
... that's our task to prevent
janina: that's why we want a gatekeeper for role=s
paulc: you're the 3rd/4th WG that came in here, that i said the same thing
Canvas TF
MarkS: Mark Sadecki
... majority of recent work was a11y focussed
... a lot of work was Canvas subgroup, of HTML/a11y TF
... now it's Canvas TF under HTML
... public-canvas-api@
... we have Canvas Level 2 in CR
... currently writing tests
... identified 24 testable statements -- tests written for all but 3
... we need to use an a11y inspector for some conditions
... joanie diggs from igalia, contributor webkit gtk thinks we can automate it
... there's one where we need to get a bug fixed in chrome
... two may prevent us from exiting CR
... 2 changes to the spec, one is purely editorial
... one is an oddity, support in 2 browsers
... records of talking about this feature in our minutes
... actions to add this to the spec
... we looked into adding it to the spec
... but it isn't in the spec @CR
... we'll have to add that back to the spec
... we recently lost our editor from MS
... all editors are currently not actively editing
... i've talked to Rik Cabanier to pick up editing
... question to you, do we have to go back to LC?
rubys: if it's substantive
MarkS: yes
... then we'll have to go back
plh: you can go to LC, or switch to new Process
... and go to CR
paulc: summarize new process
plh: a lot easier to go to REC w/ new process
<cabanier> I thought we can stay in CR
plh: the new Process would let you update in CR, still need Director approval
paulc: doesn't the 90 day IP LC period still apply?
plh: maybe
paulc: new Process, if you're in CR, you can cycle in CR
... old Process, you were in CR, leave CR back to LC, then back to CR
... sometimes people would skip CR
... nowhere on the Agenda was whether we should switch to the new Process
plh: the Process applies on a per spec basis
... do whatever is simplest
hober: at the last CSS F2F (Sofia), we agreed to move to the new Process at publication time
paulc: their interpretation was one decision
... as soon as they republish a document, it's published under the new Process
... reality, we have a C&P/Delete error, it impacts implementations, and needs to be fixed
... when will it be fixed?
MarkS: next week
... and we have support in implementations
janina: test results, just not spec language
<paulc> http://dev.w3.org/html5/decision-policy/public-permissive-exit-criteria.html
paulc: model criteria for HTML WG
... apply to all our documents
Implementation
A user agent which:
(1) implements the "Web browsers and other interactive user agents" conformance class of the specification.
(2) is available to the general public. The implementation may be a shipping product or other publicly available version (i.e., beta version, preview release, or "nightly build"). Non-shipping product releases must have implemented the feature(s) for a period of at least one month in order to demonstrate stability, or be endorsed by their responsible
organization as sufficiently stable.
(3) is not experimental (i.e., a version specifically designed to pass the test suite and is not intended for normal usage going forward).
(4) is suitable for a person to use as his/her primary means of accessing the Web.
paulc: do your implementations pass this bar?
MarkS: i believe so
... hit region, drawfocus:ifneeded,
... Firefox Nightly, Chrome Canary, WebKit
paulc: i wanted to make sure i ran this by you
... other questions of Canvas TF?
[ Silence ]
Process 2014
<MarkS> s/Sadocky/Sadecki/G
<MarkS> s/Rick Am/Rik Cabanier
plh: the motivation for the new process
... was to resolve the case
... you're making a change to a CR
... you have to go all--the-way back to LC
... wait a while
... and then to CR
... we did that for HTML5 this year, despite the fact that we were in CR
... the AB decided to make it more agile
... we allow the group to update their CR
... just require Director approval
... additionally, the new process recognized that LC wasn't the best vehicle to do large review of documents
... wanted to give WG a more flexible way to do Wide-Review
... you have a WD
... you iterate
... then you go to CR
... then iterate
... once you're done, you go to PR
... don't be fooled -- thinking that you don't need review
... process says you need to demonstrate wide-review before CR
... there was a discussion yesterday
... and there's a wikipage
... if you make a substantive change in CR
... the Director will ask if you have wide-review for the change
... wide-review will depend on the change
... if it was a change of a function name,
<adrianba> TPAC break-out on wide review<https://www.w3.org/wiki/TPAC2014/SessionIdeas#What_is_Wide_Review_and_How_do_we_achieve_it>
plh: it will be if you got review from implementers
... from Patent Policy
... it changes LC to CR
... what does it mean if we make a change in CR and publish
... the answer is you trigger a 60 day period for IP
... if you go to Director asking to go to PR
... he'll want to wait for it to close
... when do you change Process
... it can be per-spec
... but CSS decided, for each publication, when they publish, they'll switch
... that's it
rubys: i interpreted it as an explicit endorsement
hober: that's correct
rubys: and i heard it as not saying there's a step back
paulc: the most common way of answering a Q in TR ->CR/ ->PR
... is to ask "did you get wide-review"
... is to answer with the link for bugzilla for LC
... that's what we did for HTML5
... that's what we did for Pre-LC and LC
... what plh is saying you still have to be able to demonstrate wide-review
rubys: we still put in the bugzilla link
paulc: the bugzilla link is to all bugs since you started the document
... i've not heard any mention of LC
... was LC wasn't required, many people were doing testing/review while they did spec work
... why should they do WD/testing,
... then you go to a public CR for implementations
... going to CR is an onus on Chairs to prove to the Directors that you have more implementations
rubys: i've heard no downsides
paulc: when i Chaired XML-Query WG
... a family of specs rivaling size of HTML5
... i couldn't reach LC
... because people wouldn't review the document as a WD
... until it got into LC
... so i had to do multiple LCs
... XQuery had 4 LCs
... the last had 120 comments
... the only w/ more was the Patent Policy itself
... having a stage saying it's functionally complete
... we want your comments on it before we do a call for implementation
rubys: does the new process get rid of LC
plh: you could "say it's a LC"
... but you can't call it W3 LC
rubys: it gets rid of the step
paulc: you move "LC" out of the Title, into the document
... you can always express your intent
... whether people understand that is open for judgement
fantasai: Elika J. Etemad
<inserted> Purpose of removing LC is to allow WG to break down review requests in more appropriate ways and help to solicit reviews earlier in the process (by not having LC be a fixed point in process where everyone comments)
fantasai: XYZ, different sets of features
s
scribe: we're done w/ the api
... we're done w/ algorithm
... i'm hoping we're doing better w/ the spec tamplates, particularly reducing boilerplate in status section
... so we can communicate better the status of the document, expected timelines, and what kinds of reviews are solicited
... mostly in the head
... to help you communicate what you're looking for in your reviews
... want WGs to experiment with WD process that works for you, not just one-size-fits-all LC process
rubys: i understand what paulc was saying
... i'll suggest that's a different problem than Canvas
... sounds like it's worth evaluating for Canvas
paulc: hypothetical
... i think i've convinced myself i'm neutral on this
... say we develop 10-15 modules
... and decide we need to publish a consolidated document
... would we want to give the community a chance to see that as a LC rather than as CR
... or do we feel confident today that we can choose how to handle the fact
... CSS can make a blanket decision that they'll say small
hober: small is not an attitude i've heard of CSS
paulc: you'll never do a union of CSS level 4 specs
... i'd opt to do it on a per spec basis
... it doesn't hurt us on a per spec basis
... as soon as we've made the decision a couple of times
... and have some experience
... the WG will tell us
plh: you have 2 years
... after 2 years, you'll be forced to the new Process
Josh_Soref: which new Process
plh: 2014
paulc: when we recharter, or a specific date?
plh: i believe it's 2 years after approval of Process-2014
paulc: if they've given us two years, let's try it for Canvas
... put a CfC in front of WG for Canvas, and see what happens
<jcraig> ?
fantasai: we're also asking for feedback on the new spec template for all WGs
paulc: fantasai please send a request to public-html-admin@
s//
<Santabarbara> http://lists.w3.org/Archives/Public/public-web-perf/2014Oct/0115.html
allow <link> in body + DOM position as a rendering hint
paulc: there's been active discussion in the last 24 hours on the topic
... i need someone to introduce the topic
... Context: Baidu made a member submission
... at WebPerf WG meeting Mon/Tue
... feedback to them was let's understand your UC, and talk to HTML WG
<myakura> http://www.w3.org/Submission/first-screen-paint/
<rubys> http://www.w3.org/Submission/first-screen-paint/
rniwa: i was an observer in that WG
... in most major browsers
... we have this behavior where
... if you have any pending stylesheets
... we'll block painting of the page
... until a timer fires, or all stylesheets load
... problem w/ their website, is they want to draw critical part of websites ASAP
... say page is 200k
... loads 4 50k stylesheets
... some aren't critical content
... say parts visible in phone
... we still block until those stylesheets are loaded
... we don't know if they have rules that apply to the top of the page
Travis: unstyled, or semi-styled content
rniwa: Amazon, you have product description
... then related products
... then comments
<MikeSmith> FOUOSSC!
paulc: and if you're going to that page to just see the product price
... and you're hoping price is near top of page
... I'll be really careful to ensure people use Q and mic
[ angel asks if Baidu is on irc ]
rniwa: they want to provide critical parts of the page that's immediately rendered
... and have the browser paint those parts
... w/o having to manually load the stylesheets via script
... you can work around this behavior
... but it's a big hassle
... have to do that on every single page
Travis: based on rniwa
... this sounds like defer'd styles, like defer'd scripts
... rniwa is nodding his head
paulc: something that already exists
... or <style defer> as an analog to <script defer>
rniwa: it's very similar to <script defer>/<script async>
<MikeSmith> timeless, Baidu_AC_rep is Yue Min
rniwa: but we also need the ability to block the painting of parts
... we don't want to paint related products while the stylesheets are still loading
... baidu wants to add a hint that it blocks painting of content after
<script> ...</script> <node>
<node> isn't inserted until after <script> is parsed
Travis: still trying to understand
... you have a dependency graph between <stylesheets> and subtrees in the DOM
... and you wan to tell the subtree that it depends on the stylesheet before it paints
zcorpan: currently the spec allows the <style> element if it has scoped=
Travis: in <body>
zcorpan: i don't know what the behavior is
... in theory you could put critical content
... and then have a <div> w/ <style scoped=> @import () </style> </div>
... not necessarily the best
darobin: a bit of a hack
paulc: zcorpan proposed a solution
... people nodding their heads, moving their shoulders
... yeah maybe
... worth investigating
... zcorpan is nodding
zcorpan: another point
... when you have <style> ... </style>
... it means you have to revaluate the earlier document
... bad for perf, can cause repainting
rniwa: I think zcorpan 's proposal would be workable
... if everyone implemented it
... i think that solution is better wrt not reevaluating elements outside of that
... the solution in WebPerf has a drawback
... even if the author meant not to affect elements above <style> elements
<MikeSmith> Browser support for style[scoped]<http://caniuse.com/#feat=style-scoped>
rniwa: if we did <style scoped=> we have a problem
<jcraig> http://caniuse.com/#feat=style-scoped
rniwa: in that Blink and WebKit removed <style scoped=>
<MikeSmith> yes, Firefox is the only browser that supports style[scoped]
rniwa: that's the one drawback
... if we use the <link rel=xxx> it would work for everyone
zcorpan: it's not a blocking problem if the scoped= attribute isn't implemented yet
... if the behavior is what we want
... then it should work ok w/, w/o scoped=
... even if it gets implemented later
... you said my proposal would be acceptable if scoped= was implemented
... i don't see why it needs to be implemented
... the important part is what the behavior is
... right?
paulc: i thought you said you could do this w/ <style scoped=>
... we're hearing that's not widely implemented
... is that not what you said
... please clarify
rniwa: i'm a bit confused
... it sounds like your solution does include <style scoped=>
zcorpan: the proposed spec change is not changing UA requirements
... it's changing authoring requirements
... this is in theory already possible w/ today's authoring requirements in the spec
... assuming the <style> element has the behavior you want in existing browsers
[ rniwa nods ]
Ping_Wu: i'd like to give some background introduction for this proposal
... we're the Baidu mobile browser team
... from experience
... by judging the first screen
... displaying th
... if this content can be shown quickly
... then user will think browser is very fast
... and will spend time reading
... and we propose this tag in the <head> tag
... it's not about layout speed
... it's first content speed
... this UX optimization
... may have some effect to overall loading page speed
... we think it isn't very important to UX
... that's the background to this proposal
... some colleagues from WebPerf introduced this
... critical-section
... we want to emphasize
... it's "above-the-fold" first screen
... in the first edition of this proposal
... we wanted to make the develop
... give a link
... a <div> w/ first screen paint
... but it may have some
... due to different devices/orientation
... this kind of solution may be hard
... also browsers can judge whether their layout size has reached this critical part
... at the same time
... some colleagues have mentioned that
... in the paint phase
... we're waiting for CSS/JS resources
... no matter if these are blocking or not
... we will try to wait until the first paint
... we will try to change the original browser implementation
... pass-layout-parse-layout
... until we detect that we've reached the full screen
... of first paint
<jamesx> should be parse - layout - parse - layout
Ping_Wu: before the first paint, we wait for downloading/non-blocking css
... background and implementation and introduction
<jcraig> s/pass-layout-parse-layout/parse-layout-parse-layout/
s|s/pass-layout-pass-layout/parse-layout-parse-layout/||
[ Project First Screen Paint in Advance ]
rniwa: first, we wait for stylesheets to load
... also have a timer
... basically a switch to turn this off
... i don't want to repeat the conversation from WebPerf
... so i'll be brief
... we talked to people in Perf group
... if we gave that switch to web developers
... we'll spend a lot of cpu time repainting content
paulc: until timer goes out or stylesheets load
rniwa: right
... terrible
... this is why WebPerf suggested link element
... and letting browser paint content above it
jgraham: to clarify
... before you (rniwa) were talking about arbitrary subtrees
... but w/ <link> you're talking about a specific point in the source
... but which is the requirement
... independent subtrees
... or just this much source to here?
rniwa: i don't know
... in terms of REQs and UCs
... people in other browsers said per sub tree is very hard
... binary bit is easier
paulc: member submission implies above the fold
... not multiple subtrees
rniwa: right
jgraham: that's fine, it sounds like it's a different solution to zcorpan 's previous discussion
<MikeSmith> the problem / use-case is what paul described
jgraham: sounds like it'd be useful to have clear understanding of UCs
... slightly concerned w/ how to know where the fold is
Travis: +1 to that
... putting a marker in HTML source code has little/no bearing at all on where that content will be positioned
... UA.css, user.css, page css
... hard to identified the fold
... w/o knowing the UCs
... on/off for painting, maybe it could work
... seems tricky
jgraham: seems like it'll work well on specific screen sizes, and like rubbish elsewhere
rniwa: the reason we came up w/ this solution is MS mentioned Amazon already does this
... send first part
... then later fetches the rest of the content
... first paint, fetch, second paint
paulc: so they've adapted their page construction to the way browsers work
... if browsers change
... they have a this-is-where-the-fold should be
jgraham: i think facebook is similar
... i remember reading a blog post
... i imagine they download the initial stuff
... paint that
... download and start inserting the gaps
... could be anywhere
paulc: angel, ask them if they have other questions
... sounds like feedback was that <meta> wasn't very useful
... maybe using a <link rel=> element
... sounds like we really want a clear understanding of the UC
... to make sure we don't end up solving something that isn't exactly what baidu wants
[ nods ]
paulc: as cochair
... having more and more dialog about the UCs
... is the best first step here
... things should be measured against specific UC
... first reaction was you could end up repainting the page over and over again
<Zakim> MikeSmith, you wanted to comment
MikeSmith: as far as i understand
... the problem case
... it's simply about the initial page load
... not anything beyond that
... first view-port chunk
... to make that load
... faster
... to have the user experience "page" load faster
paulc: people measure effectiveness of your mobile browser of how your first viewport is painted, the Business case?
MikeSmith: the problem you want to solve
... if people aren't going to your site, browser doesn't show your content, people give up/go away
... point to make here
... effect of this on HTML spec
... don't have to define the behavior
... i think it could be done in WebPerf
... for HTML WG, we could
... have some discussion about the right markup
... but in the end, probably
... say we go w/ this <link rel=...>
... <link rel=firstpaint>
... we make a minor change to specification for link element
... say that it could appear anywhere in the document
... right now, we say it has to be in the <head>
... microdata says it can be in the body
... RDFa says it can be in the body
... that's all we'd have to do in the HTML spec
zcorpan: rel=firstpaint wouldn't have a good backcompat story
... rel=stylesheet would
... if we think scoped= stylesheets is what we want to restrict authors to doing
... then we could add scoped= to linked
plh: the UC is all about above-the-fold
<hober> <link rel=stylesheet scoped href=...>
plh: how long it takes for the user to see something
... browsers have techniques to avoid flash
... browsers want to paint as fast, but not flash
... different techniques
... iirc IE if you wait 200ms and cpu doesn't do anything, it starts painting
... another is to put </html>
... when the browser sees that, it starts painting
... and continues parsing
... this is all ugly, can we find something else that allows you to do that
... <link rel=stylesheet> works in some browser already
... not specified, but it works
<Zakim> timeless, you wanted to ask if we couldn't survey Amazon and Facebook (and Gmail/Gmaps) about this
paulc: seems like a good question
jgraham: yes
... there's work going on for a script dependency for html
... Hixie 's working on it w/ TC39
... seems related script-loading/style-loading
... perhaps we shouldn't punt off to WebPerf
<darobin> for reference: https://whatwg.github.io/loader/
jgraham: it should be like other things in the platform
Wu_Ping: some people have mentioned we have wasted a lot of time
... we've only
... when we reach layout to the full screensize, we ...
... people have mentioned
... to avoid flash
... let's BBB
... correct
... this way, we may not correct result
<Zefa_> s/WWW/Wu Ping
Wu_Ping: during parsing
... 400,000
... tokens
... we may still see incorrect results
... we want a way for developers to direct to the browser
... if you have many dynamic resources
... first-screen-content
... you may tell the browser you don't want this optimization
... also mentioned Facebook may have similar techniques
... i don't know if i remember correctly
... sending first page content first
... this kind of thing could help
... but it requires a reorganization of the page
... in the optimization case, the browser can do it itself
... we also have UCs, like Data and Snapshot of high-speed-camera
... which captures displaying video of firstscreen content
... optimization can tell painting time from 2000ms to 1000ms
... most mobile site pages can now be restricted to 1s
... under this kind of optimization
paulc: we had a discussion in WebPerf
... we've exposed the problem to people around the table here
... heard some solutions
... maybe not all discussed in WebPerf/whatwg
... maybe what we require is a super-general solution
... relation of html page to script
... i don't know what to tell Baidu about where the next discussion
... by default, it's going on in WebPerf
... plh, you're the staff contact for WebPerf?
plh: yes
paulc: i'll put the ball in your court
... we have a UC, maybe it needs to be described in more detail
... maybe discuss isolated, or very powerful solution
... maybe some of us here, could put it on in WebPerf, i think the thread is copied to whatwg
... then that's where the discussion should continue
plh: i think there's an action in WebPerf
... we'll discuss how to move forward
rniwa: paulc's/jgraham's points on UCs
... their UCs are tied to their solution
... i think we need User Scenarios
... maybe we need UCs from other vendors
... Facebook/Gmail/Amazon/...
... and work forward in Web Perf
paulc: 5:45pm; we meet again tomorrow morning @ 8:30am
... to meet on EME
... I predict we'll adjourn at Coffee in the afternoon
... i think that's a pretty strong indication from the agenda
... thanks everyone
<trackbot> Meeting: HTML Weekly Teleconference
<trackbot> Date: 31 October 2014
EME Bugs
<paulc> EME outstanding bugs: http://lists.w3.org/Archives/Public/public-html-media/2014Oct/0101.html
paulc: good morning darobin
Introductions
paulc: i'll carry the mic around the room
... and we'll introduce new faces
adrianba: adrian bateman, microsoft
paulc: paul cotton, cochair
rubys: Sam Ruby, cochair
joesteele: Joe Steele, Adobe
jdsmith: aaa
MikeSmith: Mike Smith, W3C
[ Scribe did not transcribe the room, sorry ]
paulc: it'd help if people marked themselves as present
Agenda for Friday
<rubys> https://www.w3.org/wiki/HTML/wg/2014-10-Agenda
BobLund: this is Bob Lund, from Cable Labs
paulc: please be aggressive in q+'ing
... Morning is for Media TF
... this morning, i broke it up into three parts
... i suggest we attack ~25 open bugs
... i had a request from MarkVickers to time-anchor the discussion for bug-26332
... MarkVickers, you said you'd have someone call in for that
MarkVickers: correct, he may call in earlier, but i said then to him
paulc: Coffee break 10:30-11
... 12:30, acolwell will call in on MSE
... Lunch 1-2:00pm
... then darobin will give us an update on DOM4
... link is for test results
... we had a CfC to get to PR, and got a formal objection
... we're working on interop
... expected last session is to trawl through the Extension specs 3-3:30
... and yesterday, i predicted we'd break at Coffee
... a shown of hands yesterday showed one of the principle people we are losing is ddorwin at 1pm
... thus Media before 1pm
<paulc> EME bugs: http://lists.w3.org/Archives/Public/public-html-media/2014Oct/0101.html
EME Bugs
<paulc> EME bugs: http://lists.w3.org/Archives/Public/public-html-media/2014Oct/0101.html
paulc: i sent an email on Oct 19
... each of the lines in this list is from Oct 19
... 10 days later, I updated the status
... no-action may no longer be correct
... if someone did something after i sent this out
... my proposal is
... these are the outstanding bugs up to ... 19
... then there is a series of bugs filed after Oct 14
... then another range 24..29 filed after my Oct 19 email
... suggest we start at the top
... obviously, because of the time element, if we get to that one, i'll skip it
... we have 1 1/2, 1, 1 1/2
... 200-300 mins, 30 bugs, ~7 mins/bug
... some prep CR/LC, we'll skip
... some are more recent which we want to get to since we've never had substantial discussion
... i'll try to go broad rather than deep
... anyone w/ other suggestions?
[ None ]
paulc: because we have BobLund on the phone, we'll pass the mic around
... please use the q
ddorwin: we have TAG reps here
paulc: how long are TAG reps here for?
plinss: here to 11am
slightlyoff: same constraint
paulc: well, we could switch to those bugs right away
... lower down on the list, but newer
... ok if we did that?
ddorwin: yeah
paulc: ok, let's do that
[ Projected bugs 20-24 ]
paulc: three initial bugs from TAG: See 27053, 27054 and 27055 below.
... and then two additional spun out
Bug 27053 - Platform Segmentation
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27053
paulc: I asked for clarification on this bug filed by the TAG but so far none has been supplied. We will review the state of this bug at the F2F meeting.
... could a TAG rep present this?
ddorwin: trying to find Domenic
paulc: ok, he's not here, we'll go back to the list from the top
Bug 25923 - The mechanism for checking key system support should be asynchronous
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25923#c42
paulc: David is working is on the open issues and will request feedback when he makes more progress.
ddorwin: i updated the basic structure
... there's a Dictionary w/ some structure
... plan is to modify it, compare two shapes of the dictionary in the bug
... the bug just has the list of open issues
paulc: are you looking for input?
ddorwin: i need to redesign the Dictionary and get feedback
... but we completely changed how we create media keys
... we call requestMediaSystemAccess()
... which gives you a MediaSystemAccess object
... and you ask it for keys
paulc: a lot of these ddorwin assigned to you
... you can reject the request
... can we get an ETA/ordering?
ddorwin: technical spec writing one, top (high priority)
paulc: anyone have feedback to editor?
[ None ]
paulc: next
<ddorwin> Current state: https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#obtaining-access-to-key-systems
Bug 25966 - Use ArrayBufferView and ArrayBuffer instead of Uint8Array in APIs
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25966
paulc: This bug is editorial and David is awaiting IDL feedback due to a possible bug in IDL spec.
... Oct 29 status: RESOLVED FIXED. See https://www.w3.org/Bugs/Public/show_bug.cgi?id=25966#c5
Domenic joins the bridge
paulc: Domenic do you want to introduce yourself
Domenic: Domenic XXW, W3 TAG
... not @TPAC
paulc: introduce yourself/schedule
Domenic: mostly free this morning
... i realize i threw a lot of work at you guys, so i'm available
paulc: we were waiting for you to arrive
... we'll finish the one bug, and then switch back to the TAG bugs
... so this bug is done
Bug 27053 - Platform Segmentation
paulc: i asked for clarifications
... clarifications are at a minimum in Comment 2, and comment 7
... but could you introduce this bug briefly for us
... and then general discussion
Domenic: this bug came out of concerns from tbl
... we have a high standard of Web APIs and how they work
... how open they are to the web
... a lot of parties involved w/ DRM
... through open standards/standardization
... we want to allow independent content providers to be able to use EME
<scribe> ... new browser vendors of course
UNKNOWN_SPEAKER: you should be able to create new browsers from the spec and support EME
... but Desktop and Mobile browsers
... and new EME key implementers should be able to join the ecosystem
... not just standardizing Widevine, Adobe, or MS PlayReady
... but others should be able to join
... content providers/developers should be able to implement code that supports content from multiple systems
... developers / content providers shouldn't have to special case that
... concerns from tbl
... that we were standardizing the needs for specific companies
paulc: response from EME/Media TF?
... i noticed Sergey Konstantinov declined to give proposed change
joesteele: i have a clarifying question
... seems to be standardizing a protocol
... so servers can implement on backend
Domenic: seems like that's the most important part of achieving the objectives
... but i agree with your assessment
joesteele: Adobe wouldn't have a problem implementing such a protocol
... but there's another party who isn't in the room
... -- the studios --
... i don't know how to solve that
... from a standards perspective, we think it's great
... but implementing something which won't be used by anyone isn't practical
ddorwin: maybe signatures are opaque
... it's a big effort
... we're going to need approvals
... important to maintain robustness, features people want
... i'm not convinced the security is in the format so much
... have the experience of the people who know these things
MarkVickers: thanks
... i can't represent all the studios
... but we have a studio in my company
... studios don't want proprietary technology
... they evaluate/set criteria based on protection
... i don't think it would be negative
... we'd welcome it/evaluate it
... w/ EME, we can interface w/ the available technologies
... but the same interface could work for open-standards or standards-protocol based implementation
markw: similar comment to MarkVickers
... if DRM vendors want to get together and agree on open formats, that's great
... if that work is done here
... what does that really mean from an IPR perspective?
... various DRM vendors won't propose something to which they don't have rights
... maybe they have the right to use it
... but maybe not the right to grant licenses
... there are dragons there
... of going in this direction
... this would take some time
... time to get support into DRMs
... we wouldn't want to see EME held up for that length of time
... we'd like to see EME deployed w/ proprietary protocols
paulc: ddorwin, you said you were thinking of something on the table
... were you thinking of a place in EME for a hook to a second spec?
ddorwin: i don't know
... i was thinking of a second parameter
... we could have a second document in the same directory
... iterate on that
... i agree we don't want to block
... we want to ship, as well
... same approach as PSSH
... yes these exist, but people should be moving in this direction
glenn: not sure there's any bug, w/ EME documented here
... unless the presumption here is requesting excluding proprietary DRMs be excluded
... i'd suggest we close this bug as LATER/noaction now
... nothing in there that reads on EME, unless it's adding a note for future work
Domenic: i'd caution against pushing this work onto your future selves
... especially if ddorwin says he has an idea of how to get started on this
... it doesn't have to prevent these features from shipping in their more proprietary form
... but we should be able to get started on this to get it better
adrianba: clarifying question
... do you mean network protocols for exchange between clients and servers for messages
... or client protocol between CDM and Service
Domenic: lot of moving parts here
... my understanding is that the Server protocol would be important
... down to goals we have
... i guess we want anyone to be able to communicate w/ CDM
... i think the network protocol as well
adrianba: i think w/ current EME structure
... communication to License service is in the realm of the application owner
... nothing proprietary in that exchange
... i don't think we have an objection to standardizing that
... that would open up new scenarios
... you could have common code running a player knowing automatically how to get licenses from different service providers
... because the api could be the same
... for the common case, i don't think that's really blocking
... we abstracted that at the API level in the spec
... i don't see that as blocking interoperable implementation
joesteele: when i asked about network-protocol
... i was thinking not so much about App sending opaque to license server
... i was thinking what does a license look like
... how are keys included, things like that
... other comment was
... about Q on APIs, protocol between App and License Server
... as between CDM and Platform
... don't know if we could do that, i'd like to see work there
... not sure if W3C is right place for that, definitely long term proposal
... just negotiating such a spec would be a year
... and implementing it longer
... third? ... i'll have to think about other thing
markw: i think standardization of Opaque blobs
... license server might be something else, dealt w/ libraries
... Q of standard api for CDM
... is something, for browser vendors
... browsers created NPAPI
... something like that
... MS published CDMI
... i think, going towards that
... for things they wanted to do
... it isn't really in our scope, it'd be good
<adrianba> if it is the format of the blob then that is the protocol between the CDM and the client application that we're talking about not network at all
ddorwin: this is about the License Protocol
... CDMI is very narrow in what platforms may need
... platforms vary so much
... a fraction of what we have in Chrome for various things
... even the interface we provide in Chrome isn't what's used in Chrome, because we have a shim
... as long as you're clear about what you're expecting from a browser
<markw> http://download.microsoft.com/download/E/A/4/EA470677-6C3C-4AFE-8A86-A196ADFD0F78/Content%20Decryption%20Module%20Interface%20Specification.pdf
ddorwin: it's easy to shim
... Hardware, SSEs are implementing things over and over
joesteele: that's what i'd like to see standardized
pal: Pierre, MoviLabs
... struggling how EME doesn't support a fully open CDM
... unless EME doesn't do that
... i'm not sure there's a bug here
... what is the bug?
markw: that CDM doesn't exist
pal: that's orthogonal
... there is an open and fully specified DRM today
paulc: for fear of getting on w3-meme
... i don't want to speak for the Director
... when we call for implementations of EME
... one thing Director asks is to get new people to come with implementations
... the call is meant to demonstrate that the spec can be used by a third party who wasn't in the room, to implement
... pal, you're saying they could implement it
... could you put that they could in the bug?
pal: can we resolve this bug today
... if i write in the bug, can we resolve it?
paulc: two people said we might resolve this LATER/something else
... one person said they might make a proposal to add something to EME
... seems like we might need more discussion
Domenic: wanted to second interoperable implementations
... and Director's concerns there
... one of the best things to be done
... would be go beyond "hey, 2 browsers implement EME, and APIs exist"
... want to show multiple EMEs, content providers, interacting in an interoperable way
... that's what we're trying to get at
ddorwin: reiterating what Domenic said
... all EME does now is expose proprietary blobs
... they want to see interoperable
... instead of just a spec
... part of it is "what does it mean to have 2 interoperable"
markw: EME is operating today
... w/ multiple browsers, providers
... we need to support multiple key systems server side
... it's equally difficult for us as anyone else
... EME could support an open DRM CDM today if someone made it
... we could write something into the EME spec that CDMs support a specific thing
... different thing, go to DRMs saying you can keep your proprietary robustness solution and business arrangements
... but we want you to support open message formats
pal: i think some of the things said here
... were interesting suggestions
... Exit-Criteria
... things to put in the Spec
... but that isn't the bug
... how do we resolve this bug
... do we close this bug and open other bugs?
BobLund: wanted to respond to Domenic 's point about Interop
... we've demonstrated ability to take single piece of content
... encrypt w/ multiple keysystems
... and play back w/ multiple CDMs
... is that interop, because that exists
Domenic: how much code was keysystem specific?
... sounds like your comments and markw 's that there's a good start on interop
... sounds like on license that it isn't interoperable
<slightlyoff> that would be helpful
BobLund: we'd be happy to share the details
... tell us the right venue/mechanism
paulc: the bug
Domenic: largely a matter in showing interop to go to CR
... we're happy to help get involve
... happy to continue conversation sometime
joesteele: not clear on part of the goal of this bug
... same server on server side could service any key system on the client side
... i don't think that's possible
... since key encryption is hardware specific
... and requires specific stuff on the server side
... i think that might enforce proprietary code on server side
paulc: i've heard
... a) no issue
<Domenic> joesteele: I think that is pretty well covered by https://www.w3.org/Bugs/Public/show_bug.cgi?id=27053#c7
paulc: b) here's the proof
... that's what we want added into the bug
... and ddorwin you had something to propose
... i think people understand the direction TAG suggests we go
... think we should have some dialog
... i think it's presumptuous to close this bug
Bug 27054 Accessibility Concerns
<ddavis> Accessibility Concerns<https://www.w3.org/Bugs/Public/show_bug.cgi?id=27054>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27054
paulc: I asked for clarification on this bug filed by the TAG and then asked the A11Y TF to supply their view which was done in:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27054#c3
paulc: john foliot said he didn't see a problem
ddorwin: john said he didn't see a problem
... and then YYY said their interpretation wasn't right
... no one's done the wrong thing
... audio, i don't know the accessibility features there
... if that's over protected HDMI, there's a problem
... secure video path is a problem
... there are concerns there
... don't know the answer
MarkVickers: thanks paulc
... i read through this bug, i don't understand
... strong benefits of EME is accessibility
... if you want access for captions
... trick-plays
... any of those things are done by completely arbitrary interfaces
<scribe> ... done through proprietary means
UNKNOWN_SPEAKER: EME API provides HTML5 standard access for Caption, Trick Play, moving through media streams
... references to media streams
... huge improvements for Accessibilty
... strong driver for us to move our content to it
... i don't see downsides, i see all improvements
Domenic: largely agree w/ ddorwin 's assessment
... a11y came back w/ good review
... but hsivonen came back w/ points
... worth just watching
... i agree better-than-best
... goal should be as accessible as unencrypted
... not as-accessible-as-flash
paulc: MarkVickers is saying we're better rather than equal
<Domenic> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27054#c7 is what i was thinking of
paulc: ddorwin did you propose changes
ddorwin: John Foliot and i discussed
... i thought someone was going to file a bug and fill it in
... one problem area is high-contrast
paulc: you'll spin off bugs for audio/video/text
<MarkVickers> I'm believe that EME provides ALL the same HTML5 accessibility for encrypted content as for unencrypted content.
markw: biggest is video
... any accessibility function can be done in device
... can still be done w/ DRM
... but that's a QoI thing
... impact on a11y tools
... any tool that accepts HDMI can work
... but tools are reduced if they do HDCP will reduce a11y tool
Bug 27055 Surfacing license to the user
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27055
paulc: I asked for clarification on this bug filed by the TAG and this has generated new active discussion.
... who wants to introduce?
Domenic: not sure we'll be able to have a productive discussion on bug
... it's mostly Sergey Konstantinov, and he isn't in the room
... seems like a reasonable request to me
... to translate machine readable request
<slightlyoff> +1, I agree that we aren't going to make progress on this here
Domenic: machine readable 1 hour
... reasonable to give chance for human to understand
<markw> it's content providers who insist on HDCP and it is this insistence that reduces the set of a11y tools that could manipulate video to those that support HDCP not anything in EME
joesteele: when i read this, it seems like a restriction on the application
... we could expose it from the CDM layer
... but if the application chooses not to expose it
... and i don't know any application that would
... how useful would it be?
Domenic: you click the lock icon in your url bar
... 90% of users don't
... but some users do, to want to verify it
paulc: there could be guidance in the spec for UAs
... whether we could make it mandatory would be hard
Domenic: yeah, there's discussion in the bug
<joesteele> timeless:FCC Chair was here Wednesday regulations could happen -- whether we ask for them or not
<joesteele> ... this is not an unreasonable authoring encouragement
<joesteele> ... be aware that it might make sense to add a regulatory hook -- that FCC can point to
<slightlyoff> I don't understand that suggestion...is there a concrete proposal?
markw: perfectly reasonable for service providers to express
... and if they don't do it, it's outside of scope
... and w/o those, regulations may happen
... but that's different from Technical restrictions in the key
... unclear that those technical restrictions are meaningful
<MarkVickers> +1
adrianba: i agree w/ markw
... technical restrictions conveyed in licenses can vary considerably in various scenarios
... very time consuming to try to put together a technical API for the various restrictions
paulc: to bring this bug to a Media TF and get Sergey Konstantinov to attend
ddorwin: i'll action paulc to arrange meeting w/ Sergey
<scribe> ... done
Bug 27166 - All identifiers associated with a user should be clearable in the same way cookies are
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27166
<adrianba> Paul's action<http://www.w3.org/html/wg/media/track/actions/68>
paulc: TAG is asking that keys be flushable like cookies
Domenic: i understand it might not be robust
... hsivonen had some idea
... something to be exposed to users if it's that possible
Bug 27165 - User agents should warn users if they bring along unclearable identifiers
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27165
paulc: sounds like these bugs are very related
Bug 27166 - All identifiers associated with a user should be clearable in the same way cookies are
markw: if people agree to 27166, maybe we don't need 27165
... do it first and see
... for NetFlix, there's no requirement for browsers to have unclearable identifiers
... if the identifiers are clearable, it's fine by us
It would be ideal if we required that clearing ones cookies, history, etc. also cleared any such identifiers.
I am unsure this is possible for robustness reasons, and as such filed bug #27165 to explore mitigating strategies, but if there is even a chance of requiring they be clearable that would be much better, and would love to have that discussion in this bug.
ddorwin: you asked how are we going to address this
... probably a series of shoulds
... implementation guidelines
<markw> specifically, I a referring to identifiers that uniquely identify a device
paulc: do we have a security and privacy section?
ddorwin: yes, currently non-normative
... we could do it elsewhere or here (in this room, now)
... no id, clearable, reset this if i want
... various robustness
... i think ids are overused
... don't use an id unless you actually need
joesteele: Q, I agree w/ this bug
... but what do they mean by identifiers
... a list of things given
... what is the scope of the identifier being given
... if a key used by all CDMs for a keysystem
... is that an identifier
... this would be a permanent identifier, baked into the CDM client
... you're using the CDM
paulc: is TAG issue about whether a identifier can identify the person using the UA
Domenic: exactly
... it's a fingerprinting issue
... if you can identify the CDM/system in play
joesteele: answers my question
jdsmith: Jerry Smith, Microsoft
... in PlayReady
... we have an identifier in personalization of key system
... we looked at privacy aspect
... we felt it was a fairly low risk
... exploiting it
<joesteele> it would be great if the comment about what types of identifiers are concerned about (aka fingerprinting user versus KeySystems) could be added to the bug
jdsmith: took license servers, required them to retrieve it
... we concluded to allow users to delete it
... wouldn't object to recommending that in the spec
pal: is there a W3C spec that mandates/recommends clearing cookies?
... under what circumstances
slightlyoff: Alex Russel, Google
... there's no spec
... there's rough consensus of UAs
... users have consensus of expectations
... and as vendors, we understand that there's a third rail
... we're powerfully compelled to do this on their behalf
pal: all this is done w/o a spec
plh: Philippe Le Hégaret W3
<wseltzer> [Fingerprinting guidance being developed in the Privacy Interest Group: https://w3c.github.io/fingerprinting-guidance/ ]
<slightlyoff> pal: it's a good point, at the same time, the concern is that there might be specs that put undue constraints on impls in this way
plh: we have Web Storage, User Tracking
<plh> http://www.w3.org/TR/webstorage/#privacy
plh: so there's no reason this spec couldn't do this as well
... it's a REC actually
paulc: i guess it does matter
<slightlyoff> pal, the specific concern is that if impls are REQUIRED by some combination of tech and licenses to break these assumptions, it's very bad
<slightlyoff> and is likely to be unacceptable
ddorwin: clearly there's disagreement on what constitutes a privacy concern
... something to work out
... in interest of users if we work it out
... take steps to help them
... even w/ a permanent HW ID
<plh> http://www.w3.org/TR/IndexedDB/#privacy
ddorwin: mechanisms to protect them
... also, Desktop browsers have done good things here
... also have to remember devices
... also browsers/native apps exposing the same id
... browser vendors should take that seriously
... i don't think solving this fixes the previous one
... cryptographic cookie
... could rebuild firefox/chromium and put whatever
paulc: you just had pushback on closing this
markw: WebStorage spec
... text came from the same source
... into the EME privacy section
... i think i copied+pasted
... in WebStorage it says here are things you could do
... we could say these are required/should
... on cookie DRM ids
... if you can clear the identifier and make a new one
... you could make one device and look like multiple
... we don't care
... if you can make multiple devices look like one
... we care
<joesteele> +1
markw: you can copy cookies across devices
... that's a problem
paulc: updating 27166 to point to existing material
... and ask about whether it should be NORMATIVE is the next step
markw: it's Non Normative in the spec
... different to WebStorage (where it's normative)
... but neither have shoulds/musts
ddorwin: it's non normative
<pal> slightlyoff, can you elaborate on the specific concerns?
ddorwin: we could have "here's introduction"
... and then "here's the recommendations", and that's normative
paulc: an editor assigned to this bug?
[ Adrian ]
markw: i'll work on it
<slightlyoff> pal: consider a situation where we had a persistent identifier across browsers for a specific bit of hardware in some other way
<slightlyoff> pal: and where users couldn't clear it
paulc: ddorwin assign it to markw
... markw will bring it up to date
<slightlyoff> pal: (e.g., a CPUID)
paulc: I think that covers the TAG bugs
... we're going to switch to another item at 10am
<slightlyoff> pal: browser vendors are very likely to mask that and/or prevent it from being available
paulc: bug about https:
Bug 27165 - User agents should warn users if they bring along unclearable identifiers
<slightlyoff> pal: because privacy is a key component of what a browser promises to "be" in terms of an agent for the user's interests
<pal> slightlyoff, ok... so I am still no sure what is incorrect with the EME specification
paulc: we'll come back to this after 27166
Bug 26332 Applications should only use EME APIs on secure origins (e.g. HTTPS)
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332
paulc: Belongs in batch of security related bugs which also includes: Bug 26838 - Normatively address vulnerabilities related to initData contained in media data
... thirty five comments
... ddorwin made a change, people asked it to be changed
<slightlyoff> pal: perhaps nothing! The question from the TAG is roughly along the lines of "is it the case that users are likely to be able to control this in common implementations?"
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332#c130
markw: I discussed the spec change with David and we agreed to change the text for the moment so that it is clear the behavior on unauthenticated origins is an open issue.
... The procedures still describe the check for an unauthenticated origin, but the subsequent behaviour is noted as open with a reference to this bug.
... There is no disagreement that there is a problem to be solved here.
... The disagreement is about the solution and it requires continued discussion.
<slightlyoff> pal: the spec text has bearing on it, but what this room agrees to is more important because it'll help us understand the likely implications, which are what's important
[ from the bug ]
markw: it's been proposed that we require an authenticated origin from EME
... a bunch of problems it would resolve
... there are implications
... from serving the site, it would be great
<pal> slightlyoff, ok... I think it is very difficult for this group to make progress on these bugs without a clear proposal and/or pointers to specific areas that are broken.
markw: but for serving the content, we don't believe switching to https isn't great for privacy
... costs of actually serving media over https
... it would be 30-50% increase in server load
... $10s-100s millions / year
... best way forward
... look at what are the conditions
... in which it's reasonable to use http://
... if they're met, it's ok, if not, it's ok
... discuss in detail about the conditions
... look at those
paulc: does anything in the bug define those criteria?
markw: i think someone agreed to make one
<slightlyoff> pal: the way to think about it is a question: the TAG wants to understand what's likely as a way to understand how it'll impact the overall architecture. If the spec text needs stronger language to constrain impls, that's something we want to understand
markw: hsivonen?
<pal> slightlyoff, in other words, I am concerned with "perhaps nothing" since it is difficult to come up with a solution when the problem is not well scoped/understood
markw: for people who don't want to read all 130 comments, just reading hsivonen's comments would be good
<slightlyoff> pal: the TAG isn't going to dive in and require things of WGs which are acting in good faith and for which implementations conform to social and architectural norms
<slightlyoff> pal: so the goal is to understand
<slightlyoff> pal: and, based on that, come to some common agreement. If this process is adversarial, the TAG is doing it wrong
paulc: markw 's suggestion was to develop criteria for whether you use a secured origin or not
markw: booked on spectrum
<joesteele> Here is a related email -- but not distilled well -- http://lists.w3.org/Archives/Public/public-html-media/2014Oct/0092.html
markw: if you had a unique, non-clearable-id, in EME messages in the clear, and sent in the clear
... if that was allowed at all, that definitely need to be restricted to secure origin
... then there's stuff which are encrypted already, per-origin, clearable
... for that, i think http: is reasonable
ddorwin: might be disagreement of if that's reasonable
... 2 aspects
... 1. privacy
... 2. security
... the former is dealable
... the other is harder
... stuff that could be scrubbed
... always security until there's no robustness
... up to UAs on what they're willing to deal w/
... until w/ move to TLS
... then UAs
... if you provide options, the option will be "no", because they won't get Netflix
... platform segmentation, or no security/privacy
... even if someone has an unclearable ID in TV
... think they should use https: they add that, try to use it
... netflix doesn't work, they remove it
... it goes over the wire
... privacy, no-clearable-id
... security aspects are hard to define
... Venues proposed requiring sandboxing
... no normative ways to address security concerns
... this is an issue for...
... generally effort is to require TLS for powerful APIs
... what we know in historical implementations
... today ones
... those are Exceptional vs. anything else that can be implemented in OSS
joesteele: there's at least the bones of a proposal
... origin specific id, so leaking it isn't a risk
<glenn> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332#c123
joesteele: sandbox, normatively spec what it looks like
<glenn> see above for proposal by Henri
joesteele: proposal, what if we added a normative requirement to the spec
... that a CDM
... operating in UA
... that there need to be a Security Review (possibly source level)
... of the CDM
<slightlyoff> it seems likely to me that there's a composition problem; e.g., what's allowed in an iframe?
joesteele: that be available to Browser Vendor
... that's the one who has to make the security+privacy
... the browser can do whatever they want
... if the browser vendor isn't able to inspect CDM properly
... then there's a problem (possibly third party binary)
... concern for larger community
<ddorwin> slightlyoff: Not sure if this is what you're referring to, but yes, we probably need to check the full set of frames
joesteele: i want to remove that concern
... Adobe would be ok w/ that requirement
<glenn> another proposal by Anne https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332#c125
<ddorwin> the current text checks just the document that contains the MediaKeys
markw: i think what joesteele suggested would be a great improvement
... i'd like to hear if that would be acceptable of the other CDM vendors
... hsivonen points out that https: doesn't solve that
... if people wants to poke holes in CDMs, they can get a publicly trusted Cert and poke
... we can ensure methods are validated
... work on what sandboxing means
... privileges no greater than those of renders
... we need to do work, but there's a way forward
<ddorwin> HTTPS prevents injection (even of other HTTPS origins)
pal: i want to address markw
<joesteele> just to be clear the Security Review would need to cover both security and privacy concerns
pal: you can specify guidelines that lead to the right privacy/security attributes
... you can normatively specify attributes leading to the right requirements
<markw> @ddorwin: Henri explains it better than me, but it's not hard to an attacker to trick people into visiting their HTTPS site
ddorwin: i'd welcome those requirements
... i don't know them
... the problem is that the issue we have is robustness
... and robustness is out of scope
... normatively securing them would probably break most impls
pal: that's true for any technology integrated by UA vendor
... UA has to do due-diligence to ensure technology isn't nefarious
... video driver could be nefarious
jdsmith: in favor of Defense in Depth
... counter measure to ID
... may be difficult to anticipate all gaps
... but applying https: on the connection itself is more likely to be secure
... question is how secure do we want to be
... do what joesteele proposed
... some potential that https: could add additional protection
... over time, we should be trying to migrate our implementations toward
paulc: didn't annevk suggest that in a bug comments?
... ok to use today, but at some point in the future, a clock clicks
... and in order to conform you'd need to use https
markw: absolutely
... perfectly reasonable to discuss how that migration would happen over time
... one to have gradual migration switching over one-by-one
... frog doesn't notice water is getting warmer, problem is solved
... but migrating 10s of percent, video is US peak 50% of traffic
... can't happen overnight
... involves 10s of ISPs
... slight economic problem
... from browser's perspective, you've solved problems for all sites
<joesteele> ISPs and CDNs are involved
markw: but for a single site that's already solved it
... it's marginal benefit
... difference of who benefits, who pays
... needs some coordination
ddorwin: web in general is moving to secure origins
... that may happen w/in impls before any date we set
... not just in EME
... even though Geolocation and getUserMedia have shipped
... browsers will flip over
... sites need to adapt
... Domenic mentioned this
... annevk has a proposal w/ messages
... get security, while allowing sites to adapt
... markw mentioned 30-50% server hit
... that's not for all/most servers
... they've done a job of optimizing things
... we're not seeing nearly that
... i'm trying to get numbers released
... we're serving video traffic over https:, not un-doable
... things that need to happen
... let's try to solve those
... netflix can help lead the way there, we (google) would be happy to help
... saying we can't do anything will help us
joesteele: Adobe is generally in favor of moving the web towards more security
... not owning browsers ourselves, we'd like public by-when-date
... that would be useful from the viewpoint of talking to our customers
... to say "by-the-way, we won't be able to support your http server by XXXX"
paulc: HTTP-BIS in IETF had the opportunity to make https: mandatory
... they chose not to
... IETF to me, from a distance
... chose not to, which seems like it isn't the time
... statement that it's going to happen wholesale
... why didn't it happen in HTTP-BIS?
... i wish i had mark here
slightlyoff: game theory works against anybody but a particularly motivated vendor
... we'll pay a large price from a Chrome perspective when we try to move users away from http:
... because users will be unhappy
... it's a cost w/ low return in the short run
... i'm sympathetic to markw 's concerns
... maybe if we could identify privacy concerns
... content is encrypted
... parent page over https: isn't a concern
... serving media itself will cost large amounts of money
... can we discuss what mixed-content means in this scenario
... discuss goals in privacy design
markw: i agree w/ that
... serving parent page over https, we'd love to
... but then the media would have to come over https
wseltzer: Wendy Seltzer, W3C
... hearing about secure-origin discussion in several different groups
... concern
... particular threat model that i've heard most compelling
... connecting to an un-authenticated-origin
... and permitting active-content
... that's MITM'd
... allowing it to run content
... exposing client to risk from who knows where
... running on your network connection
... threat model that
... as W3C, looking to work w/ TAG, and Security Group
... to more broadly address it
... not just spec by spec basis
... unfortunately, discussion is just beginning
... when it came up earlier in WebAppSec
... i hope we can bring together the people to think wholistically on how to improve ecosystem
MarkVickers: two things
... I want to support adding things that mandate end-to-end security
... nothing wrong w/ when we plan to move to https
... we have to do this
... secure PII on the web
... to do that, we do very very detailed investigation of our CDMs/...
... supporting what markw said
... let's get them in there
... regardless of https: or not
... idea that there could be an exception to https: origin property
... problem is video data
... it isn't executable code
... it's already encrypted
... massive amount of (50%) Internet bandwidth
... in general, exceptions to rules are problematic
... it doesn't have privacy problems
... bandwidth-cost issue, if we could make an exception to that
... it'd make things go more quickly
<ddorwin> Note: Whether the video is already encrypted is irrelevant. It is still observable and fingerprintable
paulc: we agreed to break for coffee at 10:30am
... lots of concrete suggestions
... good to put a short summary of suggestions into the bug
... slightlyoff 's suggestion
... was along the lines of what markw said and what MarkVickers supported
... break for Coffee
... and switch over to the top of the bugs
[ Coffee break ]
<MarkVickers> Regarding drowns note above: I agree that there is privacy value in using HTTPS for encrypted content. I was making a crawl-walk-run argument. We could more quickly move the non-video content to HTTPS as an intermediate stage towards all content over HTTPS.
Updates to bugs w/ F2F
paulc: editor's suggested a different approach instead of top down
... but they're not ready
Media TF next F2F
paulc: does Media TF need another F2F?
... instead of waiting until next April
... if we spent a whole day somewhere
... maybe longer than one day
... would that get us to the point where
... maybe break down into groups
... and get progress
jdsmith: it'd be useful
pal: do you think it would be useful
paulc: if we identified people w/ proposals
... and/or dedicate time to develop on the fly
<joesteele> I think it would be useful
pal: exactly
... extremely helpful, going into that discussion
<ddorwin> domenic: That's probably okay. timeless: Thanks.
pal: if someone made a proposal on each open issue
ddorwin: this has been more productive and last fractured than email
... i'd prefer that as well
... i'm happy w/ a F2F
... one thing for the group, don't wait for milestones
... Tuesday morning is popular for bug updates
... i'd like something more fluid
... we don't need Tuesday morning (or Pacific time)
... but i'd like more continuous involvement
paulc: i won't disagree
... i've tried to get people off 6am Pacific bug fixes
... not sure how to push people to do what you wawnt
MarkVickers: i'm for another F2F
... anytime/anyplace
paulc: pal suggested spread them out
... and/or have time to develop proposals on the spot
... problem w/ allocating all morning on a discussion
... 90mins on TAG bugs
... we're still surface level
pal: hard for a group to just open a bug and get to a point w/o any prep
... key is to have strawman proposal
... even if it's horribly wrong
paulc: rubys, "the way to find and answer is to say something that's wrong"
ddorwin: trying to move forward in an iterative approach
... requestMediaKeySystemAccess
... we'll iterate
... i'd like smaller bugs
... yeah, that's a problem, file a bug
... please give me text to add
... discuss this small issue
... break things down into manageable things
... move forward, even if we have to change
pal: some of these bugs are incredibly broad and vague
... in discussion spawn three other issues
paulc: usually in bugzilla
... you have a bug, you file 3 bugs, mark dependencies
... and close the dependencies, and then revisit and close the original
MarkVickers: what's called for
... make clear text-change as strawman for "cunningham's law internet"
... spec changes for promoting discussion
... spec changes for completing discussion
markw: avoid doing things for obviously controversial
... what would it look like on github?
pal: branching
... or proposal in plain text in bugs
... problem is ddorwin is 99% right
... you have to lower your percentages
<inserted> [ Examples of what github can look like ]
https://github.com/w3c/mediacapture-main/pull/48
https://github.com/w3c/mediacapture-main/pull/49
paulc: html5 spec after html5 will probably be done in git
... github or similar
... i don't want to drill on that today
... great lunchtime conversation
... jdsmith responded to my list
... pal suggested dealing w/ proposals that are presented
Bug 26776 Diagnosing and resolving CDM errors needs a numeric systemCode (deleted with MediaKeyError)
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26776
paulc: jdsmith will submit a proposal in time for F2F meeting.
<inserted> Bug 26776 comment 9<https://www.w3.org/Bugs/Public/show_bug.cgi?id=26776#c9>
jdsmith: previously
... looking for key-specific-error-codes
... i know there was a discussion about key-status
... looking for aspect of it
... benefiting from specific error code
... talked to ddorwin about philosophical Q, not discussed as a group
... do we want CDM specific error codes
... or drive to standardized error codes?
... is my proposal reasonable/acceptable to support, or not
o "acquired",
o "expired",
o "notyetvalid",
o "renewalfailed",
o "playbacksexceeded",
o "authorizationfailed",
o "outputnotallowed",
o "downscaling",
o "released"
jdsmith: adding a specific code
... interested to flesh out the list
paulc: datatype of "systemcode"
jdsmith: it's a number
paulc: where does it come from?
jdsmith: it's out of band
<inserted> Bug 26372<https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372> - Report issues/events not related to a specific method call
jdsmith: you have a range of problems that can occur
paulc: so, do we want CDM specific error codes
... for debugging?
... for end user?
jdsmith: for initial implementation
... they were important for telemetry
ddorwin: 2 issues
... 1. how to report this (technical)
... 2. does the platform want to let us expose non-standardized values (annevk feedback)
... we have to deal w/ this
... 1st isn't worth dealing w/
... developer debuggability is in javascript-console
markw: we should be clear
... if we expose codes like this, they shouldn't drive client script
... if we want to let the script drive actions, that should be standardized
... then there's exposing system specifics
... that's an antipattern
... but explicit errors from IE etc was really important for us to debug
<ddorwin> Anne's comments: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25896#c5
markw: errors are specific to CDMs
joesteele: i'd like to have this
... system-code-level available for debugging purposes
... sensitive to the issue of not having a common way to use these
... keysystem specific, platform specific
... would it be good enough if this was in javascript console, but not programmatically to the application
[ markw shook his head -- no ]
paulc: in an open standard like EME
... returning a proprietary specific code is bad
... but i can point to ISO specs
... SQL state
... there's an implementation defined range
<ddorwin> I think Paul said ISO
paulc: and the SQL spec says "don't ever take action on one of those values"
... ISO standards say that because it's really useful
... if you get underflow in a phenomenally complex piece of code, it can be very very useful
... used by developers when they're developing their code
... i'm less worried about implementations exposing beyond the standard
... just paulc's personal opinion
ddorwin: argument is that should be the exception message
... not a number
... that's why i wanted TAG to be here
... i wanted declarative text
... is there a way that an application can't do this
... but the server needs to see the error code
paulc: sentiment of the room?
... straw poll, good facility to have?
[ 7 hands -- good ]
[ 0 hands for don't ]
paulc: jdsmith, make a concrete proposal
... and make sure annevk's aware of your proposal
<ddorwin> and the TAG
Bug 26887 Allowing license servers and CDMs to control data persistence and secure release
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26887
<inserted> Comment 13<https://www.w3.org/Bugs/Public/show_bug.cgi?id=26887#c13> Jerry Smith 2014-10-30 22:32:25 UTC
paulc: Jerry to update proposal based on previous TF discussions.
jdsmith: we had a discussion on a Tuesday call
... i listed feedback in comment 13
... strong input from apps to have influence over data storage
... apps in control over new keys/reuse
... we'd like to
... session-type temp/persistent, we can retain
... instead of app generate request for license w/ init data
... instead let app load local license w/ same info
... not exact
... it gives app control
... relatively transparent way
... they're not obligated to associate media-key-session-ids with the session itself
... there's more to it, and i can let others talk
... we retained retrieving keys/removing
... we also added remove key methods
ddorwin: thanks for taking that feedback, noting it, addressing it
... i like this better than the last one
... i commented on specific apis
... markw addressed... i didn't read through all of his comment
... markw indicated PlayReady doesn't let you have the whole id
... might be multiple sessionids
... what happens
... app might want to load specifically one id
... if we have retrieve-by-id, let you get whatever you want from that
... removeallkeys is odd
... removekeybykeyids seemed odd
... if a license has multiple key ids, it doesn't make sense
... you can't rip key ids out of licenses
... loading by init data seems fine
... in a more pure case, you might get session by init id
... but that's putting apps through extra work
... the remove stuff, the way keys are removed is redundant
... or do on sessions
... that you can't play back w/ session id is a problem
... iterate on this
jdsmith: we don't really believe session-id is a good way to map stored keys
... we'd like to get away from using session-id to manage/retrieve keys
... that's why new key management api is proposed
... remove key/session w/ one operation
... session-id is an arbitrary number
... happens to get coordinating messages
... could be multiple messages w/in a key experience
... not a great identifier for managing stores
... retained to support Secure-Release UC
ddorwin: we're storing something
... to retrieve, you need an index
... ~ IndexedDB, there's an id
... it's odd that if you had 2, you don't know which you'd get back
... index is not unique
... change meaning to clarify
... seems you should retrieve by id
... or people might want to
... more like rental case
... want to load things, and want to play it
... change model of EME?
<ddorwin> acc ddo
markw: when i looked at this
... and compare it to our existing api
... you can polyfil it either way
... functionally it's not very different
... they might look different, but they might be the same
... trouble deciding which is better
... no really strong reason for choosing one/other
... need to look for underlying principle
... polyfill just has a mapping
... doesn't need to be in a secure boundary
... could be in js
... perhaps, pull out keyRelease
... atm, we're overloading session-id thing
... from original approach to not define keyRelease
... now we seem to be moving toward explicit definitions
joesteele: specific example
... putting aside keyRelease
... just talking about load
... spec talks about proprietary PSSHs
... only way it can do this is via loadSession
... even if app stores all sessions it had previously acquired keys for
... app can't decide which session introduced the keys
... w/o being able to parse the KeySystem specific initData
... blob is not key system specific
... it can be passed down for playing offline content in a general way
... this lets app avoid trying to load a lot of sessions and trying each to see if it can play the content
... session-id for us doesn't make sense for us
... we don't manage content
... we could make a shim, as markw suggested
... to make an offline content player, i couldn't do it today
... very difficult
paulc: you could do it w/ jdsmith 's proposal
joesteele: specific piece from jdsmith 's proposal that's helpful is load()
... and clean way
... if i'm offline, unclear what loadSession
... can app assume no key request?
... in load() we could say, only load from keys we have, don't make key requests
ddorwin: CDM needs to know what load() is intended to do
... alg currently lets it send messages
... whether it does anything w/ that, who knows
... you can load things while on line
... playlimits
... if you want an "i'm offline boolean"
<ddorwin> I don't agree that the application does not know which session ID is associated with specific content.
ddorwin: you'd probably be ignored
... i don't agree app doesn't know which session-id's
... if you downloaded a movie, either got a manifest w/ init data
... either got need-key or similar events
... if it's aware of sessions, i don't see why it doesn't know session-ids
... apps might not want to track that, just want to play
<ddorwin> If we are going to remove load-by-ID, I think it should be a separate bug.
ddorwin: markw 's right, it seems you could polyfill both of these
... apps might want to do by id
... If we are going to remove load-and-use-to-play-by-ID, I think it should be a separate bug.
... verify w/ people that they don't need that functionality
... jdsmith added load-by-data, that i don't quite understand
... may be specific features we want to talk about
MarkVickers: two styles of interface
... at least two CDMs would prefer one way, i think that's a natural way to go that way
... all things otherwise equal
... i'd favor that, it seems there's agreement
... i'd favor UC joesteele 's offering on offline
... i think this is resolved
ddorwin: want to remind people that authors have a higher constituency concern than implementers
... know what authors want
markw: joesteele gave an example of a UC
... that he couldn't do
... you can store map of init to session-id
... in IndexedDB
... you can polyfill
... it's hard to distinguish
joesteele: a bit of confusion
... when i say the app doesn't know which keys are required
... not init-data to session-id
... application given that it could be operating on a number of key systems
... it doesn't know which keys were delivered in a given session
... load session could provide a number of keys at once
... but the app doesn't know which particular id
... if i can load by init data that i have
... i know that's supposed to result in a key
... it's a backwards mapping
... init-data i know will cause key to be satisfied
... i'm working through the argument
... i could scan through all the ones i've mapped
<ddorwin> We don't load by key; we load by session (i.e. license). The application could store a list of session(s) it has for the title.
joesteele: and assuming it matches exactly, then it will work
... but it's a proprietary format, an exact match may not be possible
ddorwin: are you assuming your application doesn't know what it's playing
... or what it played previously
... you got an encrypted event, now you're trying to find a license
<MarkVickers> I agree with David that we must prioritize application needs over implementation needs, what I said is that if either style of API is neutral for applications, then implementation preferences should be considered
joesteele: i have streams A, and streams B
... i play A, and then get a key that lets me play A+B
... i can do loadkey
... i have to do an exact match
... it may fail
ddorwin: not the model i've thought about
... i want to play Wizard of Oz
... i have it, metadata of it
... one requires one session, or a list
... user clicks play, puts media in
... calls load session
... handle encrypted
... or request session, preemptively loading
... that's the model i'm thinking of
... yes weird things w/ PSSHs
... not thought of that
... not clear to me, esp w/ proprietary PSSHs
... that even CDM knows
... PSSH doesn't need to have all the keys
... servers know
... potentially a flawed design
... --- what can you do
... if you're trying to load
... --- very different
... i want to parse init data, figure out which keys it needs, and try to find them
... different from retrieval by init data
... i think if we don't do that, we have other issues
paulc: next steps?
... beauty contest?
... markw suggested that
jdsmith: reloading license w/o cross mapping
... hadn't thought that init data might not be unique/match particular content
<joesteele> I am happy to support both models -- but if we only support one -- the initData model is more flexible
jdsmith: heard ddorwin that reloading based on session should be in a different bug
... didn't hear loading local licenses by init data
... as problematic
paulc: you heard support on that
<ddorwin> I'd argue the initData model is less exact and more difficult to reason about
paulc: refactoring so that's done in this, or another
<joesteele> we can add a separate bug for the "I am offline" issue
ddorwin: every time initData comes up, there are holes
... always problem we have
... a) why I support session-id
... why we should solve corner cases
... i recognize app doesn't want to store in indexedDB, just want to play it
... in those cases, the load you proposed makes sense
... yes broad support, still concerns
Bug 24082 Several issues discussed in the TF point to the need for defined extensibility points in EME
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24082
<ddorwin> also, you can map imprecise on top of precise but not vice versa
paulc: Jerry is to discuss this item with Adrian.
<inserted> Comment 14<https://www.w3.org/Bugs/Public/show_bug.cgi?id=24082#c14> Jerry Smith 2014-10-31 15:21:33 UTC
jdsmith: this bug
... currently WONTFIX
... websites might try to do extensions on top of EME
... we had a mechanism createCDMdata
... to allow passing license data back to license server
<ddorwin> It's an interoperable problem and layering problem.
jdsmith: viewed as an opportunity for interoperability problem
... haven't made a conscious choice to lock down
... so there are no viable ways to extend it
... so if they want to work around, it isn't support by us
... or try to offer a constrained mechanism
... so we could deprecate a specific thing and close the extension mechanism
... if done in an unspecified way, we won't have that ability
joesteele: apologize for reopening
<ddorwin> If you extend an API, you run the risk that you will be broken in the future. More incentive not to extend.
joesteele: it raises a concern to me, as jdsmith was saying
... even if we support all UCs as defined now
... there may be new UCs that require extension points
<scribe> scribe: joesteele
paulc: we would come back after CR
ddorwin: it will be hard to get through CR with a void* that is do what you want
... we have identified a few of these issue
... we should either do them or branch
... we want to make sure these things are defined -- know what they look like
... domains is an example
... impossible to know how folks are going to do it now
... there are specific points where if you want to ask for afeature you can
... explicitily defining key release is an example markw mentioned
... identifying these would allow us to move forward
... but would prefer not to have a blanket statement like "add your stuff here"
paulc: we will leave the bug closed
... those were the 3 I had in my list for you Jerry
... any other bugs nominated to bring to the top of the list?
... did not see any others where an explcit action since the 29th
ddorwin:
paulc: these came in after Oct 19th
Bug 27111 - Separate "persistent" session type into persistent license and presistent key release
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27111
ddorwin: markw alluded to this
... tried to have persistent sessions handle anything storage related
... for simplicity, issue like persistent and temporary
... and defining behavior
... this bug is mainly cosmetic, but addresses some of the confusion
... for persistent licenses which is ambiguous now
... some implementations might do key requests -- would be better to be explicit
... AFAIK we don't have anything that are are different type of license (other than domain keys)
markw: how do people think we should deal with key release?
... sessions were the only way of dealing with key release
... issue with no closing sessions gracefully
... should we really be using sessions for that?
... should we have a getKeyRelease()
ddorwin: ... would be more specific
... who or what would we be firing messages at
... I would say loadReleasedSession or something like that
... I would rather have an iterator model
... there is an ascpect to removing the session
... no matter how you get the session, it is valuable to have it
paulc: you said might be cosmetic
... other key types in the taxonomy
... ?
markw: persistence in the session question -- is it assumed that you are asking about both the key release and the keys in the session
ddorwin: I think we asked that -- does that really exist?
... generally it can expire - think you want key release with an offline license
... our implementation would do different things
... persistent licenses is a superset
<timeless> scribe: timeless
joesteele: i don't know if i'll be able to prove you wrong
... for key release
... the specific thing in this case
... in all the cases that i've seen key release used
... it's about (con?)current session counting on the server
... i don't think every server wants a notification about key-release
... we could require that
... i think some servers would drop it on the floor
ddorwin: what functionality are they using?
joesteele: they're saying; the local application is flushing the keystore
... they're trusting the app to do the proper thing
ddorwin: you can still load a session and release its keys
... key release is an online streaming license
... with persistance
... you want to retrieve the receipt later
joesteele: multiple UCs?
... some use offline licenses and don't care about the message to the server
... i don't care in this fight
... server could drop it on the floor
ddorwin: offline + don't care what happens
... fine to ignore
... but we were thinking offline would have an ack
... UCs where it is necessary (rentals)
... we can avoid these things, solve interop
... a) app could have trouble w/ that behavior
... i guess, app doesn't care, it could do that
... risk of malware, inject "delete all licenses"
... we should talk about that, my vision of offline was there was always a receipt
... CDM would not know to delete license/receipt
... talk about that, separate issue
<scribe> scribe: joesteele
UNKNOWN_SPEAKER: ?
paulc: so what is the next step
ddorwin: do folks think this is a step forward?
... joesteele just said that there are potentially other models for this
paulc: any objections?
... no -- then you can go ahead
... should we go to the top of the list?
Bug 26738 Add entry for MPEG-2 TS CENC to the Stream Format Registry
<timeless> scribe: timeless
paulc: blocked w/ boblund (not here)
Bug 26372 Report issues/events not related to a specific method call
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372
ddorwin: i'm going to implement something like we agreed, and iterate
... it's going to look "maplike"
Bug 26811 Separate definitions of Initialization Data Types from Stream Format parsing
paulc: lower priority
... it blocks Bug 26738
... can you raise priority
ddorwin: i want to do 26372 first
Bug 26573 Prepare for Last Call
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26573
ddorwin: questions around references
paulc: plh?
... i can't hit him
... ddorwin was asking current best normative reference to WebIDL
... MikeSmith ?
darobin: "reference it and say don't implement bindings"
ddorwin: we're adding things added to the living standard version last week
... but the URL is /TR/ (old)
pal: update TR
paulc: darobin, advice here?
darobin: nope
... we could try to get WebApps to update /TR/
paulc: action on me
... i sent plh an email
... i'll give you feedback
Bug 24771 Provide guidance on object and CDM lifetime (including when events are guaranteed to be fired)
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24771
ddorwin: i added new objects -- MediaKeyAccess
paulc: this needs to be expanded?
ddorwin: yes, but it isn't affecting compat, so lower priority
Bug 26838 Normatively address vulnerabilities related to initData contained in media data
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26838
paulc: we looked on Oct 14
... said "discuss at F2F"
... made change on Oct 17
ddorwin: that's the https: bug
... "data you can't validate is bad"
... "data you're passing that can't be sandboxed is bad"
... "inject random stuff, that's even worse -- network attack"
... left w/ "make it so you can sanitize it"
... some implementations can't
... they're working to improve
paulc: is this dependent on bug 26332?
ddorwin: yes
... both, it and bug 27093
paulc: so this is the nullset once those two others are done
ddorwin: i'm open to other ideas
... but that's what the analysis boils down to
paulc: given discussion on https:
... is that the only solution?
ddorwin: it depends on, influences 26332
... it's one of the reasons you want a secure-origin
paulc: markw, when you discussed things in 26332
... is this initData case one of those things?
markw: could be
... yeah, this was one of the
... in 26332, we talked about security + privacy
... are there different considerations for validating initData v.
... update messages in the update() method
... require UAs ensure those things are validated
... minimum standards for sandboxing etc?
... go through that, could allow unauthenticated storage
paulc: wanted you to think about it
joesteele: markw, you asked ddorwin if those types of data are different
... they are different
... getting to a place where initdata is in the media, is a common format which is validatable
... is easier than getting messages from server are validatable
... those messages are entirely encrypted w/ a key that the app won't have a way
paulc: so it depends on how you get the initData ?
joesteele: no
... initData can be common-format, or proprietary format
... getting everyone to use common-format is easier problem to solve
... other thing
... in initialization-data portion
... where it talks about what it may contain
... one minor nit to pick w/ it, ddorwin and i have talked
... i may file a bug to make the change required
... right now, the text there requiring validating initialization data
... requires being able to validate that
... initially i thought there was no way
... but after browser vendor discussion
... validation may be minimal, but if that's ok
... it's up to browser vendor
markw: validation requirements to put in place
... require that data must be validated
... in processes no-greater privs than rendering
... gives flexibility
... maybe UA validates
... maybe CDM does it (if it's reviewed)
<joesteele> +1 to that proposal
markw: ensures validation happens, but don't dictate where
Bug 25092 Need a way to inform script that resolution restrictions are applied
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25092#c23
paulc: i don't think URI has done anything about this?
markw: no progress i'm aware of
... still, CSS side people or other media people + browsers
... from which we need input
paulc: ok
... on my list of things to followup / find someone to help
Bug 25268 Reduce the burden on applications to deduplicate initData from many needkey events
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25268
paulc: We will close this at the F2F if no solution is provided.
... no proposal here
joesteele: i second
paulc: glenn said it was an optimization
... ddorwin reduced priority
... we agreed on Oct 14 to resolve this
... wontfix/later?
ddorwin: LATER
paulc: objections?
jdsmith: makes sense
joesteele: no objection
paulc: ddorwin do that now
ddorwin: done
Bug 20944 EME should do more to encourage/ensure CDM-level interop
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944
paulc: we'll skip -- probably last thing we do before LC
ddorwin: it has a formal objection
paulc: we don't need to deal w/ that until CR
... or we could change Process
Bug 25434 Remove unsupported informative text in Abstract regarding OOB communication.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25434
paulc: This bug was re-opened after the Editors closed it. We will discuss at the F2F meeting.
[ hg server is broken ]
[ randomly ]
ddorwin: i'm in favor of moving to git
... EME to be used to identify what's supported
... TAG stated that you send things through the application
... we can't enforce things if we can't control what goes through the UA
... this bug was opened claiming that the normative text doesn't enforce this
... this fixes this by additionally normally defining that you can't do out of band
... but i added an exception, individualization goes through the UA
... user clears id, you can do it again
... i added an exception for that
... debate over words, i've tried to clarify
paulc: status?
ddorwin: closed
Bug 23827 Need to add features at risk prior to entry into Candidate Recommendation
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23827
paulc: CR, checklist -- later
Bug 24874 Positive isTypeSupported() may be misleading (MSE vs. .src=)
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24874
paulc: David to update bug now based on how MediaKey get created -- bug 25923.
... ddorwin, did you do the update?
... yes, you did in comment 2
ddorwin: some implementations only support EME w/ MSE
... video.src=foo.mp4
... it doesn't work
... when we return it isn't supported
... there's no indication that it isn't supported, only w/ MSE
... maybe some TV type devices, won't put any effort in
... do we care?
... worth adding an extra attribute?
... how do we make default behavior correct?
... i'm turning into a pumpkin
MarkVickers: ddorwin mentioned he's working on git
... and then commiting to hg
... seems like busywork
... can we let it stay in git?
paulc: continue to use bugzilla for bugs?
MikeSmith: as the person who got stuck w/ maintaining the Hg server
... i'd like to get out of the Hg server
... you can move to github and keep using bugzilla
... maybe eventually you'd start using github issues
... but please do so as soon as possible
... i'll do the work to migrate you
paulc: as the rep of the company that bought the hg server
... do i get the money back?
MikeSmith: we'll repurpose the server for a more useful thing for the world
paulc: ddorwin, make a proposal to move to github
Introductions
acolwell: Aaron Colwell, MSE spec editor
... I support using git instead of hg
MSE qqq
paulc: we had a heartbeat
... that blew away the Streams object definition we were using
... first acolwell, do we have an MSE bug related to this?
... i know i had an action item
acolwell: i was planning to file two bugs
... one to remove the existing text
... one to figure out a new way to integrate with the new version of the spec
paulc: appendStream() ?
... needs to be redefined?
acolwell: one path forward is to completely remove it
... that didn't work out
... figure out a new way that's more natural
... to integrate w/ new Stream spec
... we could shoehorn, but it wouldn't be good
... Domenic 's spec
paulc: i expected that the w3c spec to tell me how do to things i was doing previously
adrianba: we talked about this
... for a fair amount of time as part of WebApps WG meeting
... 1st, from a spec status perspective
... there was a heartbeat publication of WebApps
... that describes the objects in Domenic 's spec
... ReadableStreams, WritableStreams
... those are the things we care about
... points to Domenic 's spec @ whatwg
... part of discussion for future of that spec
... is Domenic is interested in potentially having foundational pieces of Streams spec
... independent of browsers, really JS language features
... being moved to TC39
... incorporated in discussions @ECMA
... caveat is that he's not sure if the group would adopt that
... Microsoft's position is that we're supportive of that
... the next question is how to update MSE spec to use the new way that Streams are exposed to the platform
... previously we just had a Stream object
... we wanted to keep the concept of adding data from a stream
... take a dependency in the CR draft w/ a note understanding that we'd need to update to the new spec
... in WebApps, we talked about a couple of different options
... this is what acolwell meant
... to integrate w/ the new approach to Streams
... it's very different
... one approach is ReadableStream w/ bytes, or ReadableByteStream
... we could do that and be done
paulc: reference would be to Domenic 's current document
... w/ possibility that it might actually be an ECMA reference?
adrianba: i'd prefer to deal w/ technical aspect
... we could change appendStream to take a ReadableStream or ReadableByteStream
... call that good and move on
... but question is, whether that's really in the spirit of the new Stream API
... spectrum of things you might do beyond that
... in WebApps, we discussed "maybe that's good for now"
... and in v2 discuss changing things
... maybe change the MSE Stream API
... to expose a WritableStream API
... to let you build Pipes
... but there was a general consensus that it wasn't required
... given we've moved to CR
... called for implementations
... maybe this isn't the right time to do that
... that's a summary re: new [Streams] spec
... rewrite implementation to new design
... personally favoring small change rather than large change
paulc: your changes "2. small change" "3. future change"
... eliminating "1. remove feature from MSE"
adrianba: we discussed #1 twelve months ago and decided it wasn't a good idea
<Domenic> I am willing to submit a pull request with updated text if that would help
paulc: we kept it w/ a reference to the gone thing
... your preference is #2
adrianba: we discussed it twelve months ago
... right now favor #2
... but i might be persuaded
acolwell: adrianba did a good job of describing
... i'm in favor of 2
... less work for me, and implementations
... depends on how people feel about it not being as natural
... it would achieve the original intent of appendStream()
... from a platform perspective of everything hooking together, is this ok to have?
... it's kind of too late
paulc: can you re-iterate the two bugs?
acolwell: 2 bugs is if we take option #1 path and then immediately do option #3
... #3 -- figure out something more natural
... adrianba is pro #2
... and i don't object severely
paulc: Domenic are you willing to do that for option #2
... (or was that for #3?)
acolwell: if we take option #2, i don't think we need Domenic
... it's really just changing implementations to use Promises
... two people have said option #2 is the way to go
paulc: we're in CR
... is there a bug for change #2
acolwell: i can file one
adrianba: i think Domenic was probably proposing option #3
markw: original intention of putting this in here
... sounds like an optimization
<Domenic> yes, was proposing option 3
markw: media data doesn't need to flow up to js and then down again
... but sometimes, it might not be an optimization
... we have an implementation that does that
... using ArrayBuffers
... but there's another reason
... Q to browsers, do browsers have an optimization
... if they don't, then we want option #3, but do it later
acolwell: i haven't looked at what Chrome's implementation of the new stream api
... but based on the code for the old impl
... i wouldn't expect a big difference between old/new
... i don't think it really matters
jdsmith: in WebApps
... Domenic took an action to help us understand the capabilities of WritableStreams
... what specificaly we'd gain
... i think there's merit in embracing ReadableStreams
... how soon we'd want to pursue option #3
... how much we could optimize our impl
acolwell: when we implement a WritableStream
... both appendBuffer and appendStream could maintain backwards compat w/ the API
paulc: markw was asking if there was merit in maintaining the current
jdsmith: speaking for IE
... we've spent effort in implementing current
... but i don't think we've spent much to optimize
... we actually don't believe migrating to ReadableStream is difficult
paulc: Domenic, sounds like we're proposing is option #2
... redefine on top of ReadableStream/ReadableByteStream
... leave pending going to WriteableByteStream for a later version of the spec
Domenic: might be more awkward for some consumers
... but even if you started w/ the current stream spec
... you might want appendStream anyway
paulc: so, acolwell, you'll do #2
Domenic: i'm glad you guys are working to build on this
... i did similar w/ Promises
... i'm happy to help
... writing up how to use Streams in TAG,
... make pull requests
... etc.
paulc: we'll do this and then ask for your feedback
MSE CR Status
<MikeSmith> Open PRs for MSE tests<https://github.com/w3c/web-platform-tests/labels/media-source>
paulc: acolwell, you sent an email to the list about status
... i think your pull request to Chrome was accepted?
... and you submitted more tests?
... don't know offhand current status
... don't know if anyone else submitted
MikeSmith: Uchida
paulc: someone else submitting tests
... hoping someone would know overall status
... if that was me, i don't know the answer
acolwell: that's the current state
... i commented on all the other tests that were submitted
... most were included in my update
... i suggested waiving off a number since they were covered in my landing
... one-or-two not covered
... i'd like someone else from the TF to step up
... i know jerry-noble from Apple had TTT
paulc: this it the front end, people submitting tests
... i don't believe we've started to construct an implementation report
... to tell us coverage of tests
... or results for implementations
... we went into CR in Jan
... and we haven't made much progress 10 months later
plh: someone needs to step up
acolwell: i'd prefer it not be me
... we need understanding from chairs
... intent of providing Blink Tests
... was to get this started
... i'd like to see other implementers engaged
paulc: i guess that's not the kind of question between you and lunch
acolwell: i understand
paulc: i guess we need to find more tests
... and find someone from outside the TF
<acolwell> timeless: The Blink tests are Chrome's tests
paulc: we've had 3 separate submissions
... acolwell 's original blink tests
... independent tests that overlap
<plh> https://github.com/w3c/web-platform-tests/pulls?q=is%3Aopen+is%3Apr+label%3Amedia-source
paulc: acolwell 's second batch that need to be reviewed
... no one has done analysis of those tests against MSE spec
... it isn't a small task
... you could look to darobin
... you can look at our DOM implementation report
... team members, plh heavily involved in WebPlatform testing
... alright, Cyril maybe you can help prune off items
... and then maybe we can find other resources
[ rubys recorded action in Media TF ]
<Zakim> MikeSmith, you wanted to comment
MikeSmith: not a great situation
... we had a guy who went in, studied specification in enough detail
... put in several weeks of work
... writing testcases for your spec
... submitted the tests for review, many months ago
... and no one reviewed them
Cyril: i started reviewing them
MikeSmith: from his perspective
... he's pretty frustrated
glenn: we'll get around to it
MikeSmith: several months
paulc: connection between Pull-Request and MSE
... isn't obvious
MikeSmith: but i came to you
Cyril: critique system is hard to use
MikeSmith: i don't want to hand hold
paulc: MS volunteered to try to help
... but the staff was reassigned
... to other work
... it's on the agenda
... we have at least one person stepping up
... work w/ Team, Cyril, myself
plh: answer how we take
... we have 13 pull-requests
... each is at least 100 lines of code
... i'm assuming you're not familiar w/ the testing system
... at least a full week of work
... 1-2 days to get into the code
... 2-3 days to go through the tests
... i'm assuming you're somehow familiar w/ the spec
... if not, it'll take you longer
Cyril: i have implemented MSE in open source software
... i know a bit about the testing framework
... but it's so difficult finding which tests have been reviewed
... i wasn't aware of the Pull Requests
... where?
paulc: MikeSmith, that's the point I was making
... let's do lunch
... pointer to pull-requests?
plh: we improved thanks to jgraham
... the documentation
Cyril: i met jgraham in London in August
... huge step in understanding
... if you want other people to help
... you want them to not have to meet jgraham directly
paulc: slope to climb
... glenn before lunch
glenn: plh, status of support of https: in webplatform tests?
plh: we have a pull-request for it
paulc: acolwell, i think if you wanted to bring this up
... and your hope was to get a volunteer
... i think that actually happened (Cyril)
... maybe in 2-3 weeks we can schedule a test discussion on the MSE Tuesday call
... acolwell, please feel free to get Domenic 's help
acolwell: that's fine
paulc: recessed until 2pm
... darobin up then is DOM4 implementation / status
darobin: can we come back late?
paulc: let's try for 2pm
[ Lunch ]
DOM4 implementation / status|
<darobin> ://w3c.github.io/test-results/dom/less-than-2.html
s/i|||//
darobin: there are parts of the spec that don't represent reality
... HTML5 not withstanding
paulc: i have two more press interviews on Monday
darobin: bz's objection was the behavior of createDocument()
... if you create something that should be an xhtml document
... document has a type, either HTML, or xml
<paulc> Boris's objection: http://lists.w3.org/Archives/Public/public-html-admin/2014Oct/0014.html
darobin: the spec doesn't say if an xml document should have type=xml
... you could create an XML document object with type = html
... if you create an xml document from the html element
... it creates an document object w/ type=html
... we tried to review the tests
... to see if interop/spec issue
... to see if it's just impls that haven't caught up
... no need to go through all tests
... if people want to contribute, we can talk about that
... some situations are things where browsers haven't caught up
... WebIDL -- nothing to fix in DOM, problems go away when impls catch up
... createNodeIterator
... so many errors that it impacts scrolling
... spec isn't 100% clear
... Firefox has a behavior no one else has
<darobin_> darobin has joined #html-wg
darobin: if you look at less than two
... it's clear that the spec isn't clear
... the test follows Gecko's behavior
... no one else does
... spec probably needs to be clarified
... and the spec changed
... and then the others turn green
glenn_: doesn't mean it's correct
<plh> http://w3c.github.io/test-results/dom/less-than-2.html
darobin: you can pass three things, one is a node filter
... it's exposed as a node filter, but the spec isn't clear how to construct that object
... it's fairly clear that the spec doesn't define how to construct it
... i think that's a spec bug
... that's like createElement
... and i'd like to remind people to discuss on www-dom@w3.org
... not public-html@
... if there's no bug, create a bug
... if there is, make sure there's a discussion on ML / in bug
... whereever annevk is happy
zcorpan_: you said the spec doesn't define if createDocument should create Document w/ html flag set/not
... but that isn't true
... the ED says ...
... "a document is assumed to be an xml document unless it's flagged as being an html document"
darobin: if you follow the spec to the letter, you'll get clear behavior
... you have an XML Document interface, its flag could be set to html
zcorpan_: there's no API to create XML Document w/ html flag set
darobin: seems to be what chrome is doing
<zcorpan_> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3278
darobin: if seems to be doing
zcorpan_: i pasted a link, and it seems to not be set
darobin: my tests were ...
... wrong case
... createDocument w/ html namespace
<zcorpan_> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3279
<darobin_> http://jsfiddle.net/003c04ew/1/
<darobin_> http://lists.w3.org/Archives/Public/public-html/2014Oct/0007.html
<zcorpan_> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3280
<zcorpan_> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3281
darobin: the other thing is that only gecko supports XMLDocument.load
... so we could kill that feature
paulc: we used Gecko as a legacy implementation to get test results?
darobin: Gecko is pretty recent
... last time this was discussed... 3..5 years ago
... introduced by IE6? 5?
... Gecko emulated it
... 3..5 years ago, this had to be supported for compat
... then IE dropped it
... now, Gecko is the only one keeping it around
... so maybe we can drop thit
zcorpan_: the last two links test namespaceuri instead
... that shows a difference in chrome
... document w/ null namespace+tagname
... createElement creates an element in null ns
... if you do it w/ an html element, you get html ns
... that's bz's issue
... that's a known bug/change
... it's where we wanted implementations to go
darobin: bz seemed to disagree w/ that direction
zcorpan_: my opinion is that we should push impls in that direction
darobin: we're trying to find problems to actually help
zcorpan_: i want it to go in this direction
darobin: discuss on list
... XMLDocument.load is an example
... bz said we needed it for compat
... but no one supports it
... if we can update and dropping it
... we now have much better results than 6 months ago
... nodeIterator wasn't there, and it found problems
... which is why i don't think we need to dig deep in meetings
... that's the plan
paulc: schedule?
... priority list?
darobin: good to get it done not too long from now, in November
plh: what are exact steps?
... to understand exact steps
... we need to identify what is important, and file bugs? start discussion?
darobin: same thing
... just a triage operation
paulc: the spec is in CR
darobin: if we fix this, it'd go back
paulc: do we want to run this on the new Process?
<scribe> [ new Process avoids needing LC ]
<rubys> ACTION: paulc prepare CfC concerning moving DOM4 to the new process [recorded in http://www.w3.org/2014/10/30-html-wg-minutes.html#action02]
<trackbot> Created ACTION-250 - Prepare cfc concerning moving dom4 to the new process [on Paul Cotton - due 2014-11-07].
plh: nice to have a list of the failures that matter
paulc: triage list to ones we want to investigate
... identify those that need to change the specification
darobin: no cases we're sure of
... createDocument thing thought spec should match reality
... but there's pushback
paulc: i'll hold my CfC until you show me at least one
... i'd like to refer to that in my CfC
... quantify, 10 failures or 100?
darobin: like 30 something
[ ignoring IDL ones ]
darobin: 30 ... features
... the dom spec has a file per feature
plh: you have 1100 failures total
... less than two, we might want to look at complete-fails instead
... half from nodeIterator
... quarter from WebIDL
... 250-300 individual tests failing
darobin: good spec, decent interop
Josh_Soref: have you run a spell checker against your spec?
darobin: perhaps not
... different kind of lies
... lies, damn lies, spelling errors
paulc: steps
... look at failures
... determine significance
... determine spec/tests
... consider moving to new Process if we need to make a breaking change to CR
... get early feedback from bz
... discussion on www-dom@w3.org
... is that all?
darobin: yeah
Extension Spec status
<inserted> ExtensionSpecifications<http://www.w3.org/html/wg/wiki/ExtensionSpecifications>
paulc: Travis raised this
... EME/MSE, under dev in Media TF
... sourceset= and <picture> should have been moved down
... "former extension specs"?
rubys: yes, should have been
... moved
paulc: Public Identifiers for entity resolution in XHTML
<scribe> ... no progress made
UNKNOWN_SPEAKER: Form HTTP Extensions
<scribe> ... no progress made
UNKNOWN_SPEAKER: ACTION: chairs to contact proponents to ask what they plan to do w/ the specs
... Polyglot Markup: A robust profile of the HTML5 vocabulary
... it's in CR
... afaik, no one has submitted any TestCases
... Leif H. Silli promised to do that, even before CR
<rubys> ACTION: paulc to contact public identifiers and Form HTTP Extension proponents to ask what they plan to do w/ the specs [recorded in http://www.w3.org/2014/10/30-html-wg-minutes.html#action03]
<trackbot> Created ACTION-251 - Contact public identifiers and form http extension proponents to ask what they plan to do w/ the specs [on Paul Cotton - due 2014-11-07].
UNKNOWN_SPEAKER: chairs should look at what editors of spec say
plh: look at status of editors themselves?
paulc: yes
... Leif is very hard to contact
... pretty non-responsive to email
MikeSmith: he's been away
paulc: MikeSmith, if you have backchannel
SteveF: i tried to contact him
paulc: i know he physically moved residences
plh: is Eliot Graff still an editor?
<rubys> ACTION: paulc - Contact polyglot proponents to ask what they plan to do w/ the spec [recorded in http://www.w3.org/2014/10/30-html-wg-minutes.html#action04]
<trackbot> Created ACTION-252 - - contact polyglot proponents to ask what they plan to do w/ the spec [on Paul Cotton - due 2014-11-07].
paulc: HTML JSON form submission
... whose is this?
darobin: mine
paulc: status
darobin: large amount of developer interest
... emails weekly asking when it will ship
... no vendor interest
... traditionally vendors have no interest in developer ergonomics
plh: a few vendors around the table
darobin: stays in limbo
zcorpan_: are there bugs filed on browsers asking them to implement
darobin: i'm not aware of
... i could do that if you think it'd be the most helpful
zcorpan_: it's sometimes a working approach
darobin: i'll take an action item
paulc: ED is the most recent version?
<rubys> ACTION: darobin to file bugs on implementors re: HTML JSON form submission [recorded in http://www.w3.org/2014/10/30-html-wg-minutes.html#action05]
<trackbot> Created ACTION-253 - File bugs on implementors re: html json form submission [on Robin Berjon - due 2014-11-07].
darobin: i fixed a bunch of bugs before publishing
... a few since, nothing that would justify going for a WD at this point
paulc: longdesc
... - A11y TF
... latest news:
<paulc> Longdesc CFC to move to PR: http://lists.w3.org/Archives/Public/public-html-admin/2014Oct/0109.html
paulc: link to CfC i sent seconds ago
... that CfC closes next Friday
... HTML5/HTML4 differences document
... zcorpan_ 's document
<paulc> HTML5 to HTML4 differences CfC to WG Note: http://lists.w3.org/Archives/Public/public-html-admin/2014Oct/0110.html
paulc: we sent CfC to publish this document as a WG Note
... ideally we did it at the same time as publishing HTML5
... this closes Friday as well
... that closes off the work
... we should thank zcorpan_ for tracking the progress of HTML5 backwards against HTML4
... darobin has an action item to update the Landscape document
... recommendation of Editors+Chairs was to archive this as a WG Note
... both of those CfCs are open now
... Anything else we need to look at?
... SteveF, Text Alternatives document
... it was supposed to be published before the meeting
... what happened?
SteveF: yes, it got published
<plh> http://w3c.github.io/resource-hints/
plh: WebPerf WG published FPWD
... extending rel= to preload/preconnect
... wanted to raise it to the WG
paulc: in spirit of work yesterday
... when a WG like that asks this WG to review
... it would be really good to ask a pointed question
... so start leading by example here
... so if someone from WebPerf could send pointer to draft
... w/ pointer to concerns
plh: i called it an ad more than anything else
... we aren't saying it's READY
... not asking for a formal review
Cyril: this spec is under?
plh: WebPerf WG
... impls in at least 2 browsers
... experimental/deployed impls
... we expect that spec to move relatively fast
rubys: there are implementers?
plh: yes
... implementation won't be an issue for that spec
... it might be shipped in stable browsers in 6 months
... at least shipped in a stable browser by then
paulc: anyone else have any other Extension specs inside/outside WG?
<Cyril> http://dev.w3.org/html5/html-sourcing-inband-tracks/
Cyril: HTML Sourcing inband tracks
... as w/ plh, it's a WIP
... not final yet
... i'd like to ask people, in particular browser vendors, to review it
... if they could join the CG, that'd be helpful
... in HTML5 you can do src=mp4 file or
... mpeg-dash manifest
... if you want to build apps relying on tracks from the resource
... in an interoperable way
... we need a spec for that
... giving guidelines, normative text, for how that should be exposed
... Track has id property
... mp4 tracks have an id
... can we rely on them being the same?
... covers mp4, ogg, WebM, mpeg-dash, ...
... requests for HLS as well
... "Media Resource In-band Tracks Community Group"
... labels, languages, would be properties of tracks
<paulc> See http://www.w3.org/TR/html5/embedded-content-0.html#sourcing-in-band-text-tracks
paulc: does it relate to this material in html5?
Cyril: yes it does
... i'll take it that it should have an introduction
... pointing to that
paulc: yes, that'd be good
<Zakim> timeless, you wanted to ask why "Media Resource In-band Tracks Community Group" isn't in document
Cyril: and that it should identify the CG
paulc: darobin, didn't we give information about resources into html5
darobin: a registry, yes
paulc: similar thing
... can you whip up the ToC
Cyril: that was only applicable to MSE
paulc: no, it was in HTML5 as well
... we went to the Director w/ a question about non-normative references to things that sound like normative text
... you're right there are companion documents
... which say MUST
... but the origin pointer were non-normative
... If you have material that would be better for developers to see directly from html5
... if we could point directly, instead of backwards
darobin: if you look at html5 spec
... there are parts that link to inband tracks
<darobin> http://www.w3.org/TR/2014/REC-html5-20141028/single-page.html search for [INBANDTRACKS]
<Cyril> http://www.w3.org/TR/2014/REC-html5-20141028/single-page.html#sourcing-in-band-text-tracks
paulc: so this document is already referred to from html5
... yep
Cyril: what words should we use?
... MUST?
paulc: doesn't matter
... if you want to use rfc2119
... MUST
... we have a judgement from the Director
... that as long as the reference is non-normative
darobin: yes, write it like a real spec
rubys: yes
Cyril: and if someone claims conformance to HTML5 + INBANDTRACKS
... then rfc2119 must applies
paulc: pattern in the past has been to have a F2F in Spring May/April
... and then TPAC
... next year, TPAC is this week in Saporo Japan
... Chairs/Team were looking for hosts
... previously, PayPal hosted a couple of times
<rubys> http://www.w3.org/2015/11/TPAC/
paulc: Microsoft hosted it in Silicon Valley
... we usually hosted in Silicon Valley, we get better attendance
plh: difficulty
... we like to get WebApps to meet at the same time
... and when the two get together, others like to meet there then too
... Charter of this group runs out in June
... if you tell me in March you want to meet in April, not going to happen
paulc: when I made the arrangements, it was hard 4 months in advance
... 2+ rooms for 5 days
... not necessarily easy to find
... finding someone to Host+Pay is equally hard
... I don't want to wait until TPAC to meet
... in particular
... i'll be the person to throw a rock at
... if we don't meet
... and I'm concerned about attendance @TPAC
... there's movement for January for Media TF meeting
... many of us have budgets
... we need to think about it
... I'd generally say yes
rubys: anyone want to volunteer
jcdufourd: we might be able to host
Cyril: in Paris
... France
jcdufourd: we're a teaching institution
... we have trimesters
... school breaks around Christmas, Easter
... HTML meets Thu/Fri
... Wed, other groups piggyback
... or HTML meets Mon, Tue
... WebApps meets later
... sometimes they're more realistic on who stays Fri
... at least those two groups
... could be just four days
... in past, WebCrypto/WebAppSec
... because they want to overlap
Cyril: no problem, we've hosted hundreds
rubys: Paris in April doesn't sound bad
plh: AC meeting is beginning of May
... some people would like to have that meeting the week before/after
paulc: i think you've found one
rubys: May 5-7 AC meeting in Paris, France
Cyril: i'll take action to confirm availability
paulc: give us an offer
... Canadians will bring beer
plh: how late can you book those rooms?
... what would you recommend?
jcdufourd: reserve them now for both dates
paulc: high cost in losing
... not a high cost in giving them back
plh: now i have to ask other WGs
jcdufourd: room for 20 people?
plh: I need 1 rooms 4 days, 50 people
jcdufourd: that's difficult
... some rooms are teach classrooms, less comfortable, forward oriented, fixed tables
plh: we try to limit attendance of other WGs
... but i get slapped
... one room is certain
... in the past, i don't want them to meet, they insisted
paulc: plh, AC meeting is Tue-Thu
jcdufourd: Jean-Claude Dufourd
paulc: no complaints about Paris in spring
... anything else?
plh: none from me
paulc: round of applause for Josh_Soref
[ Applause ]
paulc: thank you
<joesteele> +1 -- Josh you are awesome
<rubys> +1
<myakura> +1
paulc: I know i'll benefit from a good minutes
... thanks to W3C for arranging / hosting us here at the Marriott
[ Adjourned ]
trackbot, end meeting
Summary of Action Items
[NEW] ACTION: darobin to file bugs on implementors re: HTML JSON form submission [recorded in http://www.w3.org/2014/10/30-html-wg-minutes.html#action05]
[NEW] ACTION: paulc - Contact polyglot proponents to ask what they plan to do w/ the spec [recorded in http://www.w3.org/2014/10/30-html-wg-minutes.html#action04]
[NEW] ACTION: paulc prepare CfC concerning moving DOM4 to the new process [recorded in http://www.w3.org/2014/10/30-html-wg-minutes.html#action02]
[NEW] ACTION: paulc to contact public identifiers and Form HTTP Extension proponents to ask what they plan to do w/ the specs [recorded in http://www.w3.org/2014/10/30-html-wg-minutes.html#action03]
[NEW] ACTION: Robin to triage new WHATWG updates, HTML bugs, Landscape document in order to list priority content for modules [recorded in http://www.w3.org/2014/10/30-html-wg-minutes.html#action01]
[End of minutes]
________________________________
Minutes formatted by David Booth's scribe.perl<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version 1.138 (CVS log<http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2014-10-31 22:15:15 $
________________________________
Attachments
- image/png attachment: image001.png
Received on Sunday, 9 November 2014 17:49:06 UTC