Meeting minutes
Agenda bashing
Paul: we have 9-10:15, 10:30- 12, 1-3, 3:15-5
Paul: we were approached for fixed timeslot on Wednesday 2pm
… from the IAB
Paul: Wednesday morning is EME and MSE
… from 9:00-12:00
… some of them will phone in tomorrow
… we'll to send a reminder for how to connect
… David Darwin sent a detailed list of outstanding bugs
… http://
… we'll start with MSE, then do EME
… [Paul going through the list]
… http://
… for date/time, we'll wait for Tantek
Robin: would be good to have Travis for those
Paul: Travis is away...
Adrian: I've got some note from him, would need input from i18n folks
Paul: [continuing through the list]
Paul: [trying to collect data on agenda items length]
Robin: 15 minutes for DOM4 update
Mark: 15 minutes for Canvas2D CR
Paul: anything to do on canvas2d level 2?
Jay: nothing to discuss on level 2 today
Paul: one hour + timeslot for testing, norm references, featurs at risk
Paul: datetime depends on Tantek
… also for divergence item
… I'll give that a 30 minutes slot
… Other specs: (extensions and LCs) 30 minutes
… (changing to 90 minutes for HTML 5.0)
… HTML 5.1 (60 minutes)
… let's start with DOM4 and Canvas2D
… {Paul edits the agenda]
… HTML 5.0 from 10:30 to 12:00 today
… divergence and WG culture and participation at 13:00-14:00
… 14:00-15:00 for other specs (extensions and LC)
… 15:15 to 16:15 for HTML 5.1
… 16:15 to 17:00 is overflow
… [folks should reload the agenda page]
… tomorrow at 1pm for datetime item
… tomorrow might be overflow for HTML 5.0 discussion
… at 3pm
Canvas 2D Level 1
Paul: lots of the heavy lifting has been done already, but let's get an update
… we have http://
… http://
… zero bugs outstanding
<paulc> waves
Mark: back in september, we looked at the CR document
… some things were missing
… focus ring and hit region
… focus is critical for keyboard user
… and hit region for a11y api
… so we formed a subgroup
… we made progress on a weekly basis
… we tried to achieve both
… drawFocusIfNeeded
… once we finished that, Mozilla attempted to implement and didn't like the approach
… so we worked ona hit region based solution
… was a rather complicated section of the spec
… Mozilla demonstrated a quick prototype
… we reduced hit regions to something easy to implement
… while maintaining forward compatibility
… and we're in a good shape
<paulc> Open Canvas2D CR Bugs - CR keyword - zero bugs http://
Mark: a few clarifications to make, will go over them with Jay today
… so should be able to move to LC next week
Paul: plan is to take it back to LC
… 4 weeks
… disclosure is a long pole
… won't be able to move to PR within 60 days
… we don't expect substantive comments on the LC
… current CR had several at risk features
… we got rid of them through a bug
… so adding the hit region material. they have at most one implementation currently. so hit region itself will be at risk.
… otherwise we would be blocked and have to go to LC again to remove it
… it's a standalone section
… Jay and Mark will give a stable draft this week
… then we'll do a CfC for LC
… targeting publication on or before April 22
<krisk> * test
Paul: this means LC ends May 20 or earlier
… since we won't skip CR, we won't say anything in the status
… on CR length, let's hold for that on the HTML 5 discussion
<krisk> * hint johnjan if you want to talk about webdriver and web platform tests at a certain time
Paul: most important item is the second implementation for hit region
… test results
… at a previous HTML Group meeting
… http://
<JohnJansen> I'm on IRC and would like to call in when the test status discussion starts
Paul: is there a plan to get these test results updated?
Robin: I can do that
ACTION: Robin to provide updated results for Canvas 2D Level 1
<trackbot> Created ACTION-238 - Provide updated results for canvas 2d level 1 [on Robin Berjon - due 2014-04-15].
https://
Paul: on canvas results, the sense was that we had enough data, modulo hit regions
… so Robin will just udpate the results
… so only thing on critical path is the second implementation of hit region
Glenn: and if we don't get it?
Paul: several possibility: extension spec, level 2 only, (I don't think we want to consider dropping it)
… then criteria will be trade-off between waiting or having the REC
… we'll mark hit regions at risk in the LC and the CR
DOM4 LC results
Paul: https://
… bugs are resolved
Robin: initially, I subsetted the DOM WHATWG spec to remove Promises
… but then it got removed from DOM WHATWG as well, so we're back in sync
[looking at http://
Robin: we have red in the status section
w3c.github.io/dom/test-results/less-than-2.html#test-file-44
… we have warnings in the spec
… I would expect to survive CR and be in the Recommendation
plh: DOMError will go away. What does it mean?
Tantek: +1
Robin: we can rephrasing it
ACTION: Robin to rephrase the warnings in DOM4
<trackbot> Created ACTION-239 - Rephrase the warnings in dom4 [on Robin Berjon - due 2014-04-15].
Tantek: "will go away" is confusing indeed for implementers
http://
ACTION: Robin to look at the WebIDL http://
<trackbot> Created ACTION-240 - Look at the webidl http://
Paul: DOM test suite results
http://
Robin: the situation improved a lot since I sent my messages
… 181/47132 (0.38%)
… this is a good test suite but of course not perfect
… some of the them are disputable
… like historical tests
… the spec doesn't require folks to remove features
… a bunch of interfaces that fail
… some alleged WebIDL bugs
… events related tests
… tests results are good enough
http://
Paul: is it an at risk feature?
Robin: yes, that's a candidate
Paul: any other?
Plh: both NodeList and Elements don't support Array :(
Robin: 5.2.6 might be dropped
[discussion on whether we can support ArrayClass]
[implementers are shaking their heads on making progress on this]
Paul: so, we'll need the list of at risk features, 5.2.6 and ArrayClass on 5.2.7
… we'll need the action items looked at
… what length for CR?
Plh: 4 weeks?
Paul: let's pick 4 weeks at the minimum
… we'll get an updated draft from Robin
… with cleanup text and at risk features
ACTION: Robin to provide an updated draft for DOM4
<trackbot> Created ACTION-241 - Provide an updated draft for dom4 [on Robin Berjon - due 2014-04-15].
Ted: Sylvia has limited ability to attend, can we talk about DataCue at 1pm?
[Paul updates agenda to include DataCue at 1pm today]
[break for 10 minutes]
<JohnJansen> trying to call in but 4865 is 'not a valid code'
<gitbot> [13html] 15darobin pushed 1 new commit to 06gh-pages: 02 https://
<gitbot> 13html/06gh-pages 140f2107d 15Robin Berjon: add canvas results
<gitbot> [13html] 15erikadoyle pushed 1 new commit to 06gh-pages: 02 https://
<gitbot> 13html/06gh-pages 14dd718c6 15Erika Doyle Navara: IE11 results for canvas and html suites
<jgraham> gitbot says WG calls break: work starts
<gitbot> [13html] 15darobin pushed 1 new commit to 06gh-pages: 02 https://
<gitbot> 13html/06gh-pages 149eb337b 15Robin Berjon: add WebKit results
<krisk> * test...
PC: moved datacue to 1:00 to accomodate Silva
PC: moved datetime to a 30 minute slot at the end of today, and added 30 minutes tomorrow for dom 4 test results.
<JohnJansen> 26632 worked, but I'm alone.
Philipe is crawling around fixing the phone :)
<JohnJansen> video?
<darobin> the new DOM4 results http://
HTML 5.0 status and time table, testing results
<darobin> http://
Robin: link to results report on tests with <2 passes
PC: document with all results is very large
<gitbot> [13html] 15darobin pushed 1 new commit to 06gh-pages: 02 https://
<gitbot> 13html/06gh-pages 14de6c91a 15Robin Berjon: updated results
<tantek> greetings from the IRC web interface
robin: 9% failure rate
PC: why did it change from 4% to 9%
robin: results for IE were actually results for firefox
testing chrome 36, ff30, ie11, presto engine from opera because it predates the blink fork
pc: couldn't use the current opera browser because it uses blink and isn't an independent implementation
robin: also webki
s/webki webkit
<paulc> Test files with failures: 480; Subtests with fewer than 2 passes: 13712; Failure level: 13712/142441 (9.63%)
PC: what does this tell us about our status?
<plh> 7.86% of the failures are due to WebIDL failures
PC: what is the likelyhood that an end user would ever trip across this corner case
kris: a lot of these are in reflection
robin: for example, set every value in the idl to infinity, and see if the error handling is right. If you fail that, you will fail thougsands of tests
mc: if these are testing webidl more than html, maybe we should remove it from this test suite
pc: specs sometimes mean implemenation defined or implementation dependent
s/ mc ms
pc: if we did that, then that might be grounds for taking the tests out.
sr: can we do that?
plh: webidl has 2 sections, one on syntax and one on how to bind in javascript
<plh> http://
plh: we had a problem like that for webstorage, we used a sentence in the seciton on dependencies
<plh> The IDL blocks in this specification are conforming IDL fragments as defined by the WebIDL specification. [WEBIDL]
plh: effectively in html5 we are using webidl syntax, but we're not doing well on binding those semantics
pc: i don't think the scenarios we were talking about have to do with javascript bindings. it's about failures in boundary test cases and that they are multiplicitive
pc: that doesn't have to do with the bindings, but about the values being past in the tests
plh: the windows bindings to javacript, for example, will never pass because they are 20 years old and yet are core to teh web
pc: if we take those 9 or 10 rows of test results out, then we are down 1.77% failure rate. What does that tell us?
robin: we're pretty close to home
pc: what do we tell the director about the number and bredth and number of tests?
robin: we have set a record for the number tests for a w3c spec. granted 2% of 150,000 tests is a lot of failures. However, many of these are corner cases or at-risk items that haven't been removed from teh test cases.
robin: list of at risk features is from when we entered cr, and needs update
robin: media element rows 62-144 has a lot of things that aren't implemented well.
PC: media is kind of important...
robin: yes, this needs more investigation. some of these are going to be problems with tests, but others are likely real faiures.
PC: plan 2014 has another last call, but not another CR.
plh: or marked at risk in last call.
PC: at risk and last call don't match for me
robin: I think it works process-wise
plh: +1
pc: need to identify all the sets of tests that are failing
<krisk> http://
robin: need to make sure that tests that are reporting false are correct
pc: can you point us to the html5 spec subsections that are the culprits?
robin: text tracks
ms: oncuechange
ms: that is part of text track
<jgraham> That query-encoding test is buggy
<jgraham> I pushed a PR today, although I'm not sure it fixes the whole problem
<plh> http://
glenn: text track cue constructor should not be supported... this is a questionable test, testing whether something from an earlier draft has been deprecated. row 62
glenn: this test is producing a lot of failures, but I don't know if it's essential to test. the old version could be there without impacting interoperability of new features
PC: we need a definitive list of features that we may need to cut. let's put that on the agenda for tomorrow.
robin: i will try to compile that list
<paulc> CR exit criteria: http://
ACTION: darobin to compile list of sections of html5 spec that are failing tests
<trackbot> Created ACTION-242 - Compile list of sections of html5 spec that are failing tests [on Robin Berjon - due 2014-04-15].
robin: this document reflects an up to date view of the quality of the test suite
pc: previous data tells us how we're doing on the tests we have, this one tell us where we need more tests
plh: this is from april 2013
pc: these show areas where we needed more coverage. where do we stand on this
plh: a year ago we thought we needed more testing, for example for 2.4.5. The checks say that we now thing we have enough tests.
robin: no, the green ones are where the group said we didn't need tests. green + check means we don't need tests but we have them. purple with check means we need and have tests.
pc: so I need to look for ones without checkmarks.
3.1.4 loading xml documents is priority, no check, needs tests and doesn't have them.
robin: in most of these cases, we have pull requests that need reviewing
pc: that will give us tests, but not results or implemenations
plh: section 5 is not well tests at all
robin: for most of these, I think we will be good soon. loading xml is a feature we're likely to drop. many others have open pull requests. section 5 is our weekness
glenn: a lot of these are new features to html5
robin: not necesarily
<plh> #769, #773, #660, #634, #521, #612
robin: obviously anything new needs to be tested, but a lot of the purple lines are things where we knew there were historical issues
robin: section 5 is about the window object. the rules were never written down before, and everyone does it differently.
plh: pasted in pull request numbers that are waiting.
pc: 38 rows that have the word 'priority' in them
robin: most in section 5
<krisk> 22 of the 38 are in section 5
<plh> #463
pc: these 38 rows, we need tests, we need results, and then we need to evaluate the results to see if we have implementations
pc: so, what are we going to about these? are we going to do anything?
robin: a number of section 5 items have tests that need reviewing
<plh> 660, 634, 521, 612
<plh> section 5.1, 5.2
<plh> section 5.7
<darobin> sections 5.1.6, 5.2, 5.2.3, 5.2.4, 5.5.2, 5.5.3, 5.6.4, 5.6.6, 5.6.11 have tests that need reviewing
pc: do these pull requests decrease the number from 38?
plh: yes, but not to 0.
plh: decrease by not more than 30%
pc: this seems like a high priority item
robin: section 5 is our ship problem, other things we have a clear plan
glenn: section 8?
robin: that's parsing, and it's well tested
<paulc> https://
<paulc> See Robin's response in https://
<paulc> https://
<rubys> > * Application Cache This is interoperably implemented and should not be removed.
<rubys> > * <dialog> There is movement on implementation, but it's not clear that it'll make the cut
<tantek> Deprecate appcache maybe?
<tantek> or is it already?
<krisk> * Test
<tantek> I see krisk * Test
plh: do we have any successful tests with dialog?
robin: show modal, also fail
plh: that will tell us how far we are. do we have even 1 implmentation
pc: when are you going to go into last call? how long will we wait? we want to go into last call in june
<MikeSmith> At Risk with Extreme Prejudice
pc: want to come out of this meeting with: no bugs, no issues (currently there?), minimum problems with normative references, ideally no at risk features. plan 2014 says rec in 4th quarter. tests, results and implemenations must happen over the summer. If we don't have that, then we are dead, or have to take out feature.
PC: with that in mind, we've said: let's remove app cache.
pc: what do we do with dialog?
robin: 2 options. take it out now, or at the last minute
plh: only 2 tests
robin: other tests in other places
<krisk> http://
pc: let's look at all the tests first. table dialog
<rubys> > * <details> and <summary> Irrespective of the source of the implementations, they still fail some pretty basic tests like html/semantics/interfaces.html.
pc: details and summary.
<tantek> btw re: dialog and Gecko - you can track "status" here: https://
ms: there was alate bug about interactive content inside summary element, which makes a problem about where the click is.
<tantek> details & summary are not implemented in Gecko. status here: https://
<rubys> > * <input type=color> Supported in both Chrome and pre-Blink Opera.
cyns: there is another issue around details/summary, which is that it was one replacement for the @summary attribute on table.
pc: input type color
<plh> 4.10.5.1.14 Color state (type=color)
<plh> pull request #773
<tantek> input type=color appears to be partially implemented in Gecko, status of what's implemented vs. what's left to be implemented can be found here: https://
pc: what are we going to do with the at risk items that need testing and don't have tests?
plh: we do have a pull request.
kris: color will either work or not work. it won't be complicated like app cache
<SteveF> re: summary details implementation - no implementations as defined in spec
<paulc> waves
DataCue discussion
<paulc> We are waiting for Sylvia.
hober: Here is a summary of the proposal
… it's in the spec section
… 4.7.10.12.6 Test Tracks exposing meta data
<hober> http://
<paulc> 4.7.10.12.6 Text tracks exposing in-band metadata
hober: The idea is that sites streaming media an stream custom metadata
hober: It can be text or custom for the page author
hober: Normally metadata is decoded by the browser(s)
hober; I3 for example has data about the show, or the teams playing and the score
Hober: We like to be a bit more like xhr where we can expose a document, or blob
hober: we don't want to have then take time to decode the data buffer
glenn: The generic use and specific should be seperate use cases
glenn: Having other metadata to help the user agent decode would be good
hober: The first case seems fine, I'm only talking about the latter
mjs: Does the user agent have a way to determine the data stream?
krisk: An attribute exists that has this information
hober: basically just change from arraybuffer to any
glenn: what is raw data? framing and payload?
glenn: what if we wanted to expose more than one type?
glenn: I though .text was kept for backward compat
The current is useful, if it's plain text you need to extract from arraybuffer
hober: data sticks around and replace text?
paulc: which version 5.0 or 5.1?
hober: it's in 5.0 4.7.10.12.6
glenn: It's worth mentioning that the WHATWG doesn't have this at all
hober: The next topic is part of talking about this..
hober: Ian thinks this is useless
glenn: Unless the useragent knows what it is and can decode this data
plh: How do you get a DataCue in HTML5 today
glenn: You need to know that this part of text track queues
glenn: Using typeOf or the track type itself
mjs: instanceOf will work
mjs: It's like getElementById - you need to check or know what type of element that is returned
hober: I wanted to raise the issue and do a sanity check on this issue
paulc: what is the elevator pitch?
hober: Add a new field which exposed the encode type
hober: glenn seems ok with replacing .text
hober: we could add some non-normative examples in the spec
hober: I'm open with the name of this
paulc: This item text is basically at risk no tests, no implementation
<hober> WebKit bug: https://
paulc: are we done?
hober: I can have an action item to add a bug for this issue
paulc: Next item on Agenda is HTML WG culture and participation and divergence from WHATWG specs
HTML WG culture and participation and divergence from WHATWG specs
paulc: first item is from tantek
second is robins spec diffs
third is the work mode document
paulc: Let's start with work mode document
rubys: It's been a while since we updated the decision policy
… a number sections are old, not used
… whatwg has a doc is this a better base for changes?
<paulc> Workmode document: https://
rubys: I sent this proposal to the list and had only one positive commit
<paulc> 'Proposal need to suggest one or more editors, be able to identify independent support, be within the scope of the working group, and not attract strong objections"
glenn: I'd propose removing the second sentance (see above)
It's not removing the second sentance...
paulc: Sam and I did a personal rude Q and A
<glenn> s/the second sentence/the last phrase "and not attract strong objections"/
paulc: Like why did we have this in the first place
paulc: We'd like to not have this but had to add this in the past to make progress on working group decision
<jaymunro> Possible wording: Proposal need to suggest one or more editors, be able to identify independent support, and be within the scope of the working group.
paulc: We'd like to have a lighter weight process, especially in pre-last call and last call
paulc: We would like to have the editors do this work and not have this heavy process in place to make progress
paulc: If we don't have any objections the chairs are going to impl this change
glenn: So basically we are going to a lighter weight process and if needed we can handle one off issues
rubys: Yes - with the current editiors we have had zero issues
paulc: the extension specs seem to have helped as well since it has taken pressure off and exists to get changes made to the spec for alternate solutions
glenn: quesiton about extension specs...
… would we move items at risk into an extension spec?
rubys: ruby got moved into 5.0 from an extension spec
glenn: my ask is the opposite - remove feature and move to an extension spec
paulc: Yes if it can be cleanly removed - canvas 2d hit testing is an example
<Zakim> MarkS, you wanted to ask what differentiates sections with a priority flag and without
paulc: One having a light process is much better
<gitbot> [13html] 15darobin pushed 1 new commit to 06gh-pages: 02 https://
<gitbot> 13html/06gh-pages 14f4eda02 15Robin Berjon: updated safari results
Though for the 1% having a process in place is helpful
rubys: I understand this point - other WG have this 1% issue, but so far this has not been the case
<MikeSmith> for the sake of being accurate here, the "original problem" really hasn't been solved. The problem that Hixie mentioned here just earlier here remains. Unless we somehow don't consider that a problem.
tantek: Seem that one needs to just escalate to the chairs like in other working groups
rubys: Or higher if needed
paulc: Art asked the chairs why we were doing CFC for heartbeat drafts for example
robin: moving this into the wiki woudl be good and keeping the work mode short is very helpful for new commers
tantek: New person comment is realy helpful since it will help people feel more welcome working/joining the group
tantek: The previous policy had the effect of turning people away from the HTML WG
tantek: This seems to undo some of this damage and better by moving to a wiki
paulc: That was one of our objections
paulc: We started to look at this after TPAC from feedback and now have this change in place for approval
tantek: If the group decides to copy move specs from whatwg we should try to minimize divergence
tantek: Keeping track of just the diffs is not enough
<Hixie> or, you know, the wg could STOP COPYING OUR WORK in the first place
paulc: The charter calls out that we can take work from other sources
rubys: Glenn made a suggestion - he should update the wiki
hober: We were talking about how the previous work mode came about from the failure mode we had at that time
hober: The opposite case is that editor has captured the consensus of the group, but one still objects
hober: The new document, talks about potentially changing the editor
hober: We should maybe protect the group from a DoS
paulc: It's possible to do this and needs to be done with extreem care
paulc: so we do have a way to protect the group from a DoS (both sides of the problem)
paulc: In the Ally TF we have had chairs attend this meeting to make sure all parties are being heard
<Zakim> MikeSmith, you wanted to point out that the decision about whether to copy specs from the WHATWG at all is ultimately an HTML WG decision, not some kind of unchangeable external requirement
tantek: Having a personal touch and not process is ideal
<Hixie> maybe that diff should instead just say "Editors of documents that have an independent existence outside of the working group SHOULD NOT exist"
mikesmith: I wanted to make the point that we have been talking around the issue..
… it's possible that we have an upstream spec under a diff license
… one that says you can republish, modify
… then we would not have this luxury
… so wanted to mention this that the circumstance we are in are not written in stone
<Zakim> tantek, you wanted to discuss one way convergence
tantek: rubys: made a point that I wanted to follow up on.
… tantek we are stuck with the w3c license to possible change
… the ab is working on this and is being worked on
… it's also published on the AB wiki as well
<Zakim> darobin, you wanted to bring up deforking
robin: we are moving to a new work mode and trying to faciliate document convergence
… editors talked (minus travis - he is on vacation)
… we wanted to re-visit some possible forks
… in case when a single person was the source and is no longer participating
… which would potentially unfork these parts of the spec
rubys: 5.0 or 5.1?
robin: 5.0
robin: it's alot of small tiny items
tantek: The smaller the list looks the better
rubys: I'm worried about the schedule - 5.1 seems much safer in terms of risk
paulc: 2014 has alot of pressure
robin: It's not just the chairs
paulc: I agree with sam that doing this for 5.0 seems dangerous
rubys: I think 5.1 is better, it's been a long time since w3c published a html spec
paulc: I encourage the editors to do this on the list
robin: fair enough as long as we get to do this
rubys: The new work mode really opens this up for the editors
tantek: last call comments can be made by anyone - including the editors
… if you see easy ones that have new information the seems reasonable for last call
paulc: I no longer need to be on the queue
tantek: Doing the human to human connection
… is the right approach as paul mentioned
Eliot: what about the twitter account? Should we use it more?
tantek: I'd suggest you give the 'keys' to the chairs
paulc: would having the chairs use this be helpful?
group - yes, good oppertunity for w3c
<Hixie> so... have the chairs even acknowledged that they should consider not copying another group's work? or has the discussion moved on to something else without the topic being discussed?
paulc: Group has agreed to move to this new work mode
tantek: At minimum we should cite where it comes from
tantek: we should be explicit
<Hixie> if the source doesn't want the text to be copied, that doesn't seem like the minimum.
tantek: Two very big diffs in work mode exists - living spec vs w3c mode
tantek: html5.0 and html5.1 is different than the living standard do to the diff work modes
marks: How do you feel we are doing with canvas? We know of differences and have action items to follow up.
paulc: As others mentioned we have the constrains we are bound to work in..
… In the case of canvas I would have recommend to use the extension spec process
Other spec updates - Extension specs, Polyglot and Image Description LC status
marks: Do you want to given an update to image description?
marks: We hope to have longdesc CR document ready in the next few weeks
marks: we were hoping to skip CR, but no won't be able to skip CR
paulc: Do you have a rough timetable?
paulc: so you have taken care of last call comments, so what is the general time for CR then?
marks: 4 weeks
paulc: and you do have tests as well
eliot: we have no bug but no test cases
paulc: we need a list of items that need to enter CR
paulc: I would think a list of items at risk and a list of tests to create so that multiple browsers pass each test
paulc: seems like the chairs just need to continue work with the editors on timeframes for each
paulc: plh do you think we should be doing these on the same schedule? Or have them get pushed faster?
plh: I think having longdesc shipped before html5 would be best
HTML5 tech for providing text alternates
This has been moved into html5 and will be published as a note
Next is using WAI-ARIA in HTML
<paulc_> http://
If you have any comments on this plan you should respond back and/or work with the editors
Next is HTML Forms JSON submissions
<paulc_> http://
robin: I have one issue that needs to be adressed - one or two paragraphs and then it can for to first pub working draft
robin
<paulc_> XML:ID extension spec: http://
Lief's xml spec will not move forwards at this point
hober: srcset has implementations in a few browsers
… so that I think we will have two+ implementation so that it can go to CR
paulc: We have 2 bugs and no heartbeats recently?
paulc: can we get an update or come back?
darobin: We can do a heartbeat that would be doable
darobin: The extension spec was crowd funded to be implemented!
<darobin> go give money! https://
hober: What I expect to happen is that srcset can go to CR with items not impl be marked 'at risk'
paulc: having both published at the same time would be great
<plh> http://
<paulc_> Summary:
plh: I wanted to make this group be aware - src set as well
<paulc_> a) Editors will work on publishing heartbeats of <picture> element and srcset attribute at the same time
<paulc_> b) XML:id extensions spec work is not going forward
There is an extension spec in webapps that may conflict
<paulc_> c) ARIA in HTML work is being refactored and will done in HTML 5.1 timeframe
<paulc_> d) Alt text alternatives in HTML has been folded in HTML 5.0 and will be published as a WG Note
<paulc_> e) Polyglot will go to CR
<paulc_> f) Image Description will go to CR
<tantek> <br>
<paulc_> g) JSON extension spec will go to FPWD when Robin can complete the current work
<paulc_> Correction: Early discussion of Using ARIA in HTML should have been about HTML to Platform A11Y API implementation Guide.
<gitbot> [13syntax] 15sideshowbarker pushed 1 new commit to 06master: 02 https://
<gitbot> 13syntax/06master 14e55cfdc 15Michael[tm] Smith: Warn for year < 1000 || year > 3000.
<paulc_> RE: c) ARIA in HTML work is being refactored and will done in HTML 5.1 timeframe
<paulc_> This should refer to the API Implementation Guide work.
HTML 5.1
<paulc_> The status of the ARIA in HTML work is under discussion in A11Y TF
rubys: First of is list of bugs - we have 235 bugs
darobin: Most of these have not been touched, as we have been pushing for CR
paulc: Have you looked to see if any of these are potentially for HTML5.0? Maybe editorial quick wins
<paulc_> HTML 5.1 timeline: See http://
<paulc_> HTMl 5.1 Last Call: 2014 Q3
darobin: When we have shipped 5.0 - we can tidy up and then look for items that are implemented
<paulc_> HTML 5.0 LCf: 2014 Q3
darobin: so that we have one source document and just remove items that are not stable is the optimal work mode
… shipping once a year would be my ideal schedule
rubys: working back on the dates would be intresting
darobin: I would hope for a .1 would not need 2 years
… we have a bunch of items in place that should help shorted CR periods
… even if we only have a few features
rubys: Maybe late 2015 early 2016
plh: what does it mean for CR, last call dates, etc...
darobin: in theory by then cr and lc will be merged so it'll be lcr which is shorter
darobin: Maybe late October we enter lcr?
paulc: Can we update the early deliverable on LC for HTMl5.1 by Q3 2014
Is it reasonable to shift focus later in summer to attack 5.1 (bugs) once other specs have progressed?
paulc: The goal was that HTMl5.1 would show progress when HTML5 ships
… in 2014
darobin: It makes sense to show progress on 5.1 when 5.0 ships..
I think the Q3 2014 for LC for 5.1
… knowning that their is alot more features in 5.1 and the LCR time dates are smaller
darobin: I would say Q2 2015 and skip CR so that rec occurs in Q4 2015
darobin: since the plan should be to just remove items that are not implemented
rubys: So then we need to start a 5.2 then right?
darobin: yes
rubys: I really think this removes pressure, for items at risk if we get into a yearly schedule
<adrianba> +1
<krisk> +2
plh: the charter ends at june 2015
darobin: I think this will not be an issue
paulc: I was thinking about how we communicate the changes
paulc: we don't have to update the charter, but we do need to inform the AC
<paulc_> Current schedule is in the charter: http://
rubys: Then we should communicate LC for 5.1 won't happen in Q3 and that we are going to ship HTML5.1 earlier
rubys: Editors should start to think about a date for 5.2 bugs
darobins: we can actually use the milestone field in bugzilla :)
paulc: Getting this list of bug and plan is important, especially with all the 5.0 work
darobin: I don't think it's reasonable to work on this until HTML5 gets to PR (can't speak about other editors)
paulc: maybe other editors can work on 5.1 bugs
hober: that seems reasonable
paulc: do we know the AB schedule for section 7 in the process document and when it will come into effect
paulc: Let me ask two qs
<tantek> Process improvement project: https://
In 5.0 we needed to go to no just last call, but pre-last call
Do we think we will need this for 5.1?
paulc: so are we ok that 5.0 is marching to be done...
we are just really asking for a review for 5.1 which is much smaller in scope than 5.0
… so that the model for 5.1 can be much differenet
darobin: yes
paulc: I think it's key to communicate this diff
paulc: Next is that I think the ally focus are thinking the 5.1 timeframe will be the same as 5.0
paulc: basically we have to communicate this outside an inside the group
rubys: In theory if we do ship yearly then it should not be problem, like other 'at risk features'
* krisk_ says goodbye to krisk
<plh> http://
paulc: that is my point, maybe do a paln 2016
<rubys> d/plan/plan/
plh: we can use new process if we are not in last call...
… if you are in last call then you can't use the new process
paulc: the only spec that this could impact I *think* is EME
<Zakim> tantek, you wanted to ask why are people considering "5.1 timeframe" for new features? not a good framing. new specs/features should go in extension specs which have their own timelines.
tantek: I was confused about extension specs and 5.1
paulc: you should read the ally TF work
paulc: I think they are really looking at 5.0 in 2014 and then 5.1 2016
tantek: I'm all for lining up to other schedules, though it goes against the spirt of extension specs
paulc: The api mapping document pre-dates the concept of extension specs
rubys: Their is a very human aspect to this...
… other people want to work with us and we should reach out
… I think the main purpose of this discusion was to get an idea on the schedule - 2016 may not make sense, or that we can get some agreement about moving to a new yearly schedule
… which will lead to a set of action items where stuff can land - 5.1, 5.2 etc..
rubys: did your point get covered?
tantek: I think so and it's matter of communicating and moving forward
marks: This really is not an extension spec, it's a series of documents one of which involves HTML, with a core spec published by PF,
rubys: I'm trying to decouple the labels - 5.1, 5.2, 5.005 and focus on the date
paulc: when we revist at risk features tomorrow we should leverage this as well
paulc: Do you think the json spec would rolled in or stay seperate
darobin: If a feature doesn't need to be in the main spec, especially if it has no other dependancies
darobin: so with JSON it should be seperate
rubys: The next item in topic is ally wishlist
http://
darobin: I think we need to talk about the content editable and the 5.1 timeframe
* br vs div vs p tag?
paulc: OK we can get 15 to talk about tomorrow
<adrianba> Extensible Web Summit home page: http://
plh: some are not part of HTML
darobin: having more details (use case) would be very helpful...not picking oh Haptic output,
… it's just that it doesn't have info on what exists today and where it fails, etc..
cynthia: menu has issue(s)
rubys: details and summary are just missing implementations
darobin: yes it's not about the spec, or if we have tests, just not enough implementation
marks: This is not a complete list and indeed needs more refinement
cynthia: content editable has accessibility issue
plh: yes content editable needs work
marks: I'll update the wish list with some details and use cases
darobin: thanks
Datetime input timezone issues
travil won't be able to discuss due to being on vacation (previously planned)
tantek: Is this about 5.0?
bug 16597
tantek: has this been fixed in 5.0?
<paulc_> https://
darobin: yes it has been moved to 5.0
paulc: note the keyword 'CR' - it means it was fixed in the 5.0 CR
tantek: What is health warning?
<paulc_> See https://
darobin: Basically is you use this input you might mess up...it's not normative
next bug is 16959
<paulc_> https://
* I was about to paste that in paul :)
paulc: Is this in 5.0?
tantek: Me too since it had the CR removed
darobin: why is it still open, it looks like the change was made and intl is happy?
edoyle: Kept open since it was part of the F2F
tantek: It raised the flag since it seems to have diverged?
tantek: maybe not an issue if it has not been implemented
darobin: what is the current status of datetime input types with this bug
tantek: Whatever the path is forward drop datetime-local, or has same functionality as datetime gets in back in sync
tantek: since this bug was just fixed, but was last talked about in june 2013
paulc: is the simple issue just change local to floating?
tantek: seems like this is confusing enough to drop for 5.0
darobin: Only pre-blink Opera has support for input type=datetime
tantek: Then indeed we should remove from 5.0
paulc: this is on the at risk list already
rubys: yes we will discuss tomorrow
paulc: darobin can you do quick check what changes have been made?
rubys: The bug(s) has links to the diffs
rubys: No real reason to worry about these bugs since indeed the whole section is at risk to be removed
tantek: The other reason was that it touches on two items...
one if this was actually well implemented we would have a big issue
… it raises the issue of new features that have no implemetations
… it could be that the idea is bad and the group could propose a different solution
… for example a extentsion spec that gets implementations