See also: IRC log
<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.
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
<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>
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
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?
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
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
... 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:/// >
... <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
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
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
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 ]
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 ?
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 from WebApps WG meeting
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
<r12a> HTML5 TimeZone
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
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
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 ]
<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
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
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]
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
<paulc> EME outstanding bugs: http://lists.w3.org/Archives/Public/public-html-media/2014Oct/0101.html
paulc: good morning darobin
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
<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
<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
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
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
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
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
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
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
<ddavis> Accessibility Concerns
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
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27166
<adrianba> Paul's action
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27165
paulc: sounds like these bugs are very related
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:
<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
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.
paulc: editor's suggested a
different approach instead of top down
... but they're not ready
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
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
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 - 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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26887
<inserted> Comment 13 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
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 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
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?
<timeless> scribe: timeless
paulc: blocked w/ boblund (not here)
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"
paulc: lower priority
... it blocks Bug 26738
... can you raise priority
ddorwin: i want to do 26372 first
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
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
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
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
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
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23827
paulc: CR, checklist -- later
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
acolwell: Aaron Colwell, MSE spec
editor
... I support using git instead of hg
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
<MikeSmith> Open PRs for MSE tests
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 ]
<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
<inserted> 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
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Weekly Teleconference/F2F - TPAC2014/ Succeeded: s/rubys1/rubys/G Succeeded: s/has the meeting started or is it unminuted at this time?// Succeeded: s/AAA: aaa/Cyril: Cyril Concolato, Institut Telecom, interested in the Media TF work/ Succeeded: s/EEE: eee/zcorpan: Simon Pieters, Opera Software/ Succeeded: s/BBB: bbb/kurosawa: Takeshi Kurosawa, Mitsue-Links/ Succeeded: s/1pm/11am/ Succeeded: s/30m/30am/ Succeeded: s/darobin_:/darobin:/G Succeeded: s/ darobin_/ darobin/G Succeeded: s/ddorwin1/ddorwin/G Succeeded: s/.../../ Succeeded: s/Areas/ARIA Roles/ Succeeded: s/Areas/ARIA Roles/ Succeeded: s/.../paulc:/ Succeeded: s/RRR/how we maintain stuff/ Succeeded: s/CCO/CC0/g Succeeded: s/placs/places/ Succeeded: s/grimmaces/grimaces/ Succeeded: s/res/ress/ Succeeded: s/lik/like/ Succeeded: s|topic: Accessibility w/ PF WG|topic: Scheduling| Succeeded: s/Harrito/Haritos/ Succeeded: s/ibl/ible/ Succeeded: s/shepazu_/shepazu/G Succeeded: s/foreignContent/foreignObject/ Succeeded: i|where is that joining defined|-> http://d3js.org/ Data-Driven Documents Succeeded: s/ent/eign/ FAILED: s/forentObject/foreignObject/ Succeeded: s|s/forentObject/foreignObject/|| Succeeded: s/we'd like to have <svg:html>/we'd like to have an <html> element in SVG/ Succeeded: s/virtual/logical/ Succeeded: s/Visio/Visio - i worked on them/ Succeeded: i|we met|Topic: ComputedRole/ComputedLabel Succeeded: s/John Gunderman/Jon Gunderson/ Succeeded: s/ack me// Succeeded: s/jon:/jongund:/ Succeeded: s/ARAI/ARIA/ Succeeded: s/spec/page/ Succeeded: s/Process/Process TF is encouraging review requests to identify the areas which would be interesting to reviewers/ Succeeded: s/minutes/minutes from WebApps/ FAILED: 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| Succeeded: s|http://www.w3.org/2014/10/28-webapps-minutes.html#item08|-> http://www.w3.org/2014/10/28-webapps-minutes.html#item08 "Editing" from WebApps WG meeting| FAILED: s|https://darobin.github.io/modularity-slides/|-> https://darobin.github.io/modularity-slides/ "HTML Modularisation" slides| Succeeded: s/that/that (Extensible Web Manifesto)/ Succeeded: s/[ Modularisation ]/[ The Unix Philosophy ]/ Succeeded: s|https://www.w3.org/International/wiki/Locale-based_forms|-> https://www.w3.org/International/wiki/Locale-based_forms Locale-based forms in HTML pages| Succeeded: s|https://www.w3.org/International/wiki/HTML5TimeZone|-> https://www.w3.org/International/wiki/HTML5TimeZone HTML5 TimeZone| Succeeded: s/QQQ/Richard/ Succeeded: s/Richard/r12a/ Succeeded: s/tzivia/tzviya/ Succeeded: s/BBB/Tzviya Siegman/ Succeeded: s/AAA/Dpub Roles/ Succeeded: s/../.../ Succeeded: s/+q/q+/ Succeeded: s/mhakkinen/skramer/ Succeeded: s/skramer/dauwhe_/ Succeeded: s/say/se/ Succeeded: s/rel=/role=/ Succeeded: s/Dpub Roles/Dpub Roles and footnotes/ Succeeded: s/Sodecky/Sadecki/ Succeeded: s/Rick Am/Rik Cabanier/ Succeeded: s/spec/publication/ Succeeded: s/drawfocus/drawfocus:ifneeded/ FAILED: s/Sadocky/Sadecki/G Succeeded: s/jonny diggs/joanie diggs/G Succeeded: s/bug fixed in webkit/bug fixed in chrome/ FAILED: s/Rick Am/Rik Cabanier/ Succeeded: s/CCC/Hachette Livre/ Succeeded: s|... we're done w/ the api|| Succeeded: s|... we're done w/ algorithm|| FAILED: s|... we're done w/ the api|| Succeeded: s|... we're done w/ the api|| Succeeded: s/|||// Succeeded: s/fantasia/fantasai/ FAILED: s/fantasia/fantasai/ Succeeded: s/the spec templates/the spec tamplates, particularly reducing boilerplate in status section/ Succeeded: s| s/fantasia/fantasai|| FAILED: s|s/fantasia/fantasai|| FAILED: s/s|||// Succeeded: s|s/fantasia/fantasai|| Succeeded: s/not just LC, but developing your WD/want WGs to experiment with WD process that works for you, not just one-size-fits-all LC process/ Succeeded: s/we can communicate/we can communicate better the status of the document, expected timelines, and what kinds of reviews are solicited/ Succeeded: s/joanie diggs/joanie diggs/ Succeeded: i/XYZ/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) Succeeded: s/duct/ducts/ Succeeded: s/scope=/scoped=/ Succeeded: s/Yue_Min/Ping Wu/ Succeeded: s/Ping Wu/Ping_Wu/ Succeeded: s/pass-/parse-/ FAILED: s/pass-layout-pass-layout/parse-layout-parse-layout/ Succeeded: s/pass-/parse-/ FAILED: s|s/pass-layout-pass-layout/parse-layout-parse-layout/|| Succeeded: s/q=// Succeeded: s/jcraig/jgraham/ FAILED: s/WWW/Wu Ping/ Succeeded: s/crack/correct/ Succeeded: s/MMM/Wu_Ping/ Succeeded: s/crack/correct/ Succeeded: s/maybe we discussed/we'll discuss/ Succeeded: s/?P6, (SIP caller?) please identify yourself// Succeeded: s/s|||// Succeeded: s/s|||// FAILED: s|s///|| Succeeded: s|s///|| Succeeded: s/s|||// Succeeded: s/topic: EME Bugs// Succeeded: i/EME/topic: EME Bugs Succeeded: s/AAA/jdsmith/ Succeeded: s/Bill Hofmann/Bill_Hofmann/ Succeeded: s/Topic: Agenda for Friday// Succeeded: s/Mark Watson/Mark_Watson/ Succeeded: s/Topic: Agenda for Friday// Succeeded: s/Topic: Agenda for Friday// Succeeded: i/2014/Topic: Agenda for Friday Succeeded: s/people/people we are losing/ Succeeded: s/Glenn Adams/Glenn_Adams/ Succeeded: i/EME/Topic: EME Bugs Succeeded: s/XXX/plinss/ Succeeded: s/XXY/slightlyoff/ Succeeded: s/Dominic/Domenic/ Succeeded: i/do you want to introduce/Topic: Domenic joins the bridge Succeeded: s/WyPlay/Widevine/ Succeeded: s/to which they have rights/to which they don't have rights/ Succeeded: s/ECM/CDM/ Succeeded: s/Pal/Pierre/ Succeeded: s/keep your proprietary/keep your proprietary robustness solution and business arrangements/ Succeeded: s/an open thing too/open message formats/ Succeeded: s/folliet/foliot/ Succeeded: s/harry/hsivonen/ Succeeded: s/Wednedsayd/Wednesday/ Succeeded: s|topic: Bug 27093 Support for proprietary/system-specific formats in initData should be discouraged/deprecated|| Succeeded: s/MSPlay/MS PlayReady/ Succeeded: s/personsalization/personalization/ Succeeded: s/Story/Storage/ Succeeded: s/tep/step/ Succeeded: s/pal: the specific concern/pal, the specific concern/ Succeeded: s/stuff which are encrypted already/stuff which are encrypted already, per-origin, clearable/ FAILED: s/biz/bis/ Succeeded: s/BIZ/BIS/ Succeeded: s|s/biz/bis|| Succeeded: s/Not: /Note: / Succeeded: s/is strawman/as strawman/ Succeeded: i/48/[ Examples of what github can look like ] Succeeded: i|pre|-> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26776#c9 "Bug 26776 comment 9" Succeeded: s/form/from/ Succeeded: i|you|-> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372 "Bug 26372" - Report issues/events not related to a specific method call Succeeded: s/TAG/annevk/ Succeeded: s/fic/fics/ Succeeded: s/IETF/ISO/ Succeeded: i|Jerry|-> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26887#c13 "Comment 13" Jerry Smith 2014-10-30 22:32:25 UTC Succeeded: s/cae/case/ Succeeded: s/keyReleae/keyRelease/ Succeeded: s/RRR/the KeySystem specific initData/ Succeeded: s/load-by-ID/load-and-use-to-play-by-ID/ Succeeded: s/ing/ying/ Succeeded: s/ext/est/ Succeeded: s/MarkVickers_/MarkVickers/G Succeeded: i|bug|-> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24082#c14 "Comment 14" Jerry Smith 2014-10-31 15:21:33 UTC Succeeded: s/what we/do what you/ Succeeded: s/close/leave/ Succeeded: s/bug/bug closed/ Succeeded: s/timeless/scribe/ Succeeded: s/diffeent/different/ Succeeded: s/..../.../ Succeeded: s/trackbot, start meeting// Succeeded: s/item #24// Succeeded: s/arepotentially/are potentially/ Succeeded: s/scribe:/scribe: timeless/ Succeeded: s/i/i'll give you feedback/ Succeeded: s/markw_/markw/G Succeeded: s/add new text/figure out a new way to integrate with the new version of the spec/ Succeeded: s/of tha/of that/ Succeeded: s/were po/we're proposing is option #2/ Succeeded: s/Uchira/Uchida/ Succeeded: s/er/ere/ Succeeded: s|AAA|DOM4 implementation / status| Succeeded: s|topic: DOM4 implementation / status|| Succeeded: i|http|topic: DOM4 implementation / status| Succeeded: i|http|topic: DOM4 implementation / status Succeeded: s/http// Succeeded: s|topic: DOM4 implementation / status|| FAILED: s/i|||// Succeeded: i|Travis|-> http://www.w3.org/html/wg/wiki/ExtensionSpecifications ExtensionSpecifications Succeeded: s/leif/Leif H. Silli/ Succeeded: s/u/us/ Succeeded: s/ing/ing rel= to/ Succeeded: s/in REC/shipped in stable browsers/ Succeeded: s/is/is beginning of/ Succeeded: s/XXX/JC Dufourd/ Succeeded: s/JC Dufourd/jcdufourd/ Succeeded: s/XXX:/jcdufourd:/ Succeeded: s/XXX:/jcdufourd:/ Succeeded: s/XXX:/jcdufourd:/ Succeeded: s/XXX:/jcdufourd:/ Succeeded: s/tues/utes/ Found Scribe: timeless Inferring ScribeNick: timeless Found Scribe: joesteele Inferring ScribeNick: joesteele Found Scribe: timeless Inferring ScribeNick: timeless Found Scribe: joesteele Inferring ScribeNick: joesteele Found Scribe: timeless Inferring ScribeNick: timeless Scribes: timeless, joesteele ScribeNicks: timeless, joesteele WARNING: Replacing list of attendees. Old list: rubys paulc timeless MikeSmith darobin benjamp Baidu Baidu_AC_rep Yue_Min New list: BobLund paulc rubys timeless joesteele darobin Domenic ddorwin Aaron_Colwell Mark_Vickers +1.408.536.aaaa Default Present: BobLund, paulc, rubys, timeless, joesteele, darobin, Domenic, ddorwin, Aaron_Colwell, Mark_Vickers, +1.408.536.aaaa 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 Agenda: https://www.w3.org/wiki/HTML/wg/2014-10-Agenda#F2F_Topics Found Date: 30 Oct 2014 Guessing minutes URL: http://www.w3.org/2014/10/30-html-wg-minutes.html People with action items: - cfc concerning contact darobin dom4 moving paulc polyglot prepare proponents robin WARNING: Possible internal error: join/leave lines remaining: <darobin_> darobin has joined #html-wg <darobin_> darobin has joined #html-wg <darobin_> darobin has joined #html-wg WARNING: Possible internal error: join/leave lines remaining: <darobin_> darobin has joined #html-wg <darobin_> darobin has joined #html-wg <darobin_> darobin has joined #html-wg[End of scribe.perl diagnostic output]