HTML Working Group face-to-face meeting -- 08 Apr 2014

Agenda bashing

<plh> scribe: nick

<plh> scribe: plh

Paul: we have 9-10:15, 10:30- 12, 1-3, 3:15-5
... we were approached for fixed timeslot on Wednesday 2pm
... from the IAB
... 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://lists.w3.org/Archives/Public/public-html-media/2014Apr/0051.html
... we'll start with MSE, then do EME
... [Paul going through the list]
... http://w3c.github.io/html/test-results/less-than-2.html
... 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]
... [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
... 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://tinyurl.com/pjbhuj3
... http://tinyurl.com/o6xb946
... 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://tinyurl.com/pjbhuj3

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://www.w3.org/html/test/results/2dcontext/

<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

<scribe> ACTION: Robin to provide updated results for Canvas 2D Level 1 [recorded in http://www.w3.org/2014/04/08-html-wg-minutes.html#action01]

<trackbot> Created ACTION-238 - Provide updated results for canvas 2d level 1 [on Robin Berjon - due 2014-04-15].

https://github.com/w3c/web-platform-tests/tree/master/2dcontext/drawing-paths-to-the-canvas

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

UNKNOWN_SPEAKER: https://www.w3.org/Bugs/Public/buglist.cgi?component=DOM4&list_id=34640&product=HTML%20WG&query_format=advanced
... 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://w3c.github.io/dom/]

Robin: we have red in the status section

w3c.github.io/dom/test-results/less-than-2.html#test-file-44

scribe: 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

<scribe> ACTION: Robin to rephrase the warnings in DOM4 [recorded in http://www.w3.org/2014/04/08-html-wg-minutes.html#action02]

<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://w3c.github.io/dom/#collections:-elements

<scribe> ACTION: Robin to look at the WebIDL http://w3c.github.io/dom/#collections:-elements [recorded in http://www.w3.org/2014/04/08-html-wg-minutes.html#action03]

<trackbot> Created ACTION-240 - Look at the webidl http://w3c.github.io/dom/#collections:-elements [on Robin Berjon - due 2014-04-15].

Paul: DOM test suite results

http://w3c.github.io/dom/test-results/less-than-2.html

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://w3c.github.io/dom/#interface-nodelist

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

<scribe> ACTION: Robin to provide an updated draft for DOM4 [recorded in http://www.w3.org/2014/04/08-html-wg-minutes.html#action04]

<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: 02https://github.com/w3c/html/commit/0f2107d4e61c82b0b324226137306d6c9f684787

<gitbot> 13html/06gh-pages 140f2107d 15Robin Berjon: add canvas results

<gitbot> [13html] 15erikadoyle pushed 1 new commit to 06gh-pages: 02https://github.com/w3c/html/commit/dd718c650eb596d5a29e9949ccff057fb39f1820

<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: 02https://github.com/w3c/html/commit/9eb337b756007a6c224075265a233cccfa406775

<gitbot> 13html/06gh-pages 149eb337b 15Robin Berjon: add WebKit results

<krisk> * test...

<cyns> scribe: cyns

PC: moved datacue to 1:00 to accomodate Silva
... 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://w3c.github.io/dom/test-results/less-than-2.html

HTML 5.0 status and time table, testing results

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

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: 02https://github.com/w3c/html/commit/de6c91af615e17e2ef5ea98767e3785ea7d04419

<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

<cyns_> scribe: cyns_

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://www.w3.org/TR/webstorage/#dependencies

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
... 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.
... list of at risk features is from when we entered cr, and needs update
... 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://w3c-test.org/html/infrastructure/urls/resolving-urls/query-encoding is another item to note for possible at risk feature

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
... 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://www.w3.org/html/wg/drafts/html/CR/embedded-content-0.html#timed-text-tracks

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
... 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://www.w3.org/html/wg/tests-cr-exit/

<scribe> ACTION: darobin to compile list of sections of html5 spec that are failing tests [recorded in http://www.w3.org/2014/04/08-html-wg-minutes.html#action05]

<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
... 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
... 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.
... 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://www.w3.org/Bugs/Public/show_bug.cgi?id=24812 Features at risk bug

<paulc> See Robin's response in https://www.w3.org/Bugs/Public/show_bug.cgi?id=24812

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

<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

<cyns> scribe: cyns

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.
... with that in mind, we've said: let's remove app cache.
... 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://w3c.github.io/html/test-results/less-than-2.html#test-file-285 dialog info

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://bugzilla.mozilla.org/show_bug.cgi?id=840640

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://bugzilla.mozilla.org/show_bug.cgi?id=591737

<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://bugzilla.mozilla.org/show_bug.cgi?id=547004

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

<krisk> scribe: krisk

<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://www.w3.org/html/wg/drafts/html/master/embedded-content.html#datacue

<plh> http://www.w3.org/html/wg/drafts/html/CR/embedded-content-0.html#text-tracks-exposing-in-band-metadata

<paulc> 4.7.10.12.6 Text tracks exposing in-band metadata

hober: The idea is that sites streaming media an stream custom metadata
... It can be text or custom for the page author
... 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
... 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
... 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?
... what if we wanted to expose more than one type?
... 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..
... 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
... Using typeOf or the track type itself

mjs: instanceOf will work
... 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
... glenn seems ok with replacing .text
... we could add some non-normative examples in the spec
... I'm open with the name of this

paulc: This item text is basically at risk no tests, no implementation

<hober> WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=123907

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://www.w3.org/wiki/HTML/wg/WorkMode

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
... 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
... We would like to have the editors do this work and not have this heavy process in place to make progress
... 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: 02https://github.com/w3c/html/commit/f4eda02f5c9456aa2045b21353889bd9bef3a385

<gitbot> 13html/06gh-pages 14f4eda02 15Robin Berjon: updated safari results

<krisk_> Though for the 1% having a process in place is helpful

<krisk_> 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.

<krisk__> tantek: Seem that one needs to just escalate to the chairs like in other working groups

<krisk__> rubys: Or higher if needed

<krisk__> paulc: Art asked the chairs why we were doing CFC for heartbeat drafts for example

<krisk__> robin: moving this into the wiki woudl be good and keeping the work mode short is very helpful for new commers

<krisk__> tantek: New person comment is realy helpful since it will help people feel more welcome working/joining the group

<krisk__> tantek: The previous policy had the effect of turning people away from the HTML WG

<krisk__> tantek: This seems to undo some of this damage and better by moving to a wiki

<krisk__> paulc: That was one of our objections

<krisk__> paulc: We started to look at this after TPAC from feedback and now have this change in place for approval

<krisk__> tantek: If the group decides to copy move specs from whatwg we should try to minimize divergence

<krisk__> 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

<krisk__> paulc: The charter calls out that we can take work from other sources

<krisk__> rubys: Glenn made a suggestion - he should update the wiki

<krisk__> hober: We were talking about how the previous work mode came about from the failure mode we had at that time

<krisk__> hober: The opposite case is that editor has captured the consensus of the group, but one still objects

<krisk__> hober: The new document, talks about potentially changing the editor

<krisk__> hober: We should maybe protect the group from a DoS

<krisk__> paulc: It's possible to do this and needs to be done with extreem care

<krisk__> paulc: so we do have a way to protect the group from a DoS (both sides of the problem)

<krisk__> 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

<krisk__> 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"

<krisk__> mikesmith: I wanted to make the point that we have been talking around the issue..

<krisk__> ..it's possible that we have an upstream spec under a diff license

<krisk__> ..one that says you can republish, modify

<krisk__> ..then we would not have this luxury

<krisk__> ..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

<krisk__> tantek: rubys: made a point that I wanted to follow up on.

<krisk__> ..tantek we are stuck with the w3c license to possible change

<krisk__> ..the ab is working on this and is being worked on

<krisk__> ..it's also published on the AB wiki as well

<Zakim> darobin, you wanted to bring up deforking

<krisk__> robin: we are moving to a new work mode and trying to faciliate document convergence

<krisk__> ..editors talked (minus travis - he is on vacation)

<krisk__> ..we wanted to re-visit some possible forks

<krisk__> ..in case when a single person was the source and is no longer participating

<krisk__> ..which would potentially unfork these parts of the spec

<krisk__> rubys: 5.0 or 5.1?

<krisk__> robin: 5.0

<krisk__> robin: it's alot of small tiny items

<krisk__> tantek: The smaller the list looks the better

<krisk__> rubys: I'm worried about the schedule - 5.1 seems much safer in terms of risk

<krisk__> paulc: 2014 has alot of pressure

<krisk__> robin: It's not just the chairs

<krisk__> paulc: I agree with sam that doing this for 5.0 seems dangerous

<krisk__> rubys: I think 5.1 is better, it's been a long time since w3c published a html spec

<krisk__> paulc: I encourage the editors to do this on the list

<krisk__> robin: fair enough as long as we get to do this

<krisk__> rubys: The new work mode really opens this up for the editors

<krisk__> tantek: last call comments can be made by anyone - including the editors

<krisk__> ..if you see easy ones that have new information the seems reasonable for last call

<krisk__> paulc: I no longer need to be on the queue

<krisk__> tantek: Doing the human to human connection

<krisk__> ..is the right approach as paul mentioned

<krisk__> Eliot: what about the twitter account? Should we use it more?

<krisk__> tantek: I'd suggest you give the 'keys' to the chairs

<krisk__> paulc: would having the chairs use this be helpful?

<krisk__> 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?

<krisk__> paulc: Group has agreed to move to this new work mode

<krisk__> tantek: At minimum we should cite where it comes from

<krisk__> tantek: we should be explicit

<Hixie> if the source doesn't want the text to be copied, that doesn't seem like the minimum.

<krisk__> tantek: Two very big diffs in work mode exists - living spec vs w3c mode

<krisk__> tantek: html5.0 and html5.1 is different than the living standard do to the diff work modes

<krisk__> marks: How do you feel we are doing with canvas? We know of differences and have action items to follow up.

<krisk__> paulc: As others mentioned we have the constrains we are bound to work in..

<krisk__> ..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

<krisk__> marks: Do you want to given an update to image description?

<krisk__> marks: We hope to have longdesc CR document ready in the next few weeks

<krisk__> marks: we were hoping to skip CR, but no won't be able to skip CR

<krisk__> paulc: Do you have a rough timetable?

<krisk__> paulc: so you have taken care of last call comments, so what is the general time for CR then?

<krisk__> marks: 4 weeks

<krisk__> 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
... I would think a list of items at risk and a list of tests to create so that multiple browsers pass each test
... seems like the chairs just need to continue work with the editors on timeframes for each
... 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

<krisk_> HTML5 tech for providing text alternates

<krisk_> This has been moved into html5 and will be published as a note

<krisk_> Next is using WAI-ARIA in HTML

<paulc_> http://lists.w3.org/Archives/Public/public-html/2014Apr/0007.html

<krisk_> If you have any comments on this plan you should respond back and/or work with the editors

<krisk_> Next is HTML Forms JSON submissions

<paulc_> http://darobin.github.io/formic/specs/json/

<krisk_> robin: I have one issue that needs to be adressed - one or two paragraphs and then it can for to first pub working draft

<krisk_> robin

<paulc_> XML:ID extension spec: http://lists.w3.org/Archives/Public/public-html/2014Jan/0157.html

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?
... can we get an update or come back?

darobin: We can do a heartbeat that would be doable
... The extension spec was crowd funded to be implemented!

<darobin> go give money! https://www.indiegogo.com/projects/picture-element-implementation-in-blink

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://w3c.github.io/webappsec/specs/subresourceintegrity/

<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

<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: 02https://github.com/validator/syntax/commit/e55cfdc11c4c1e1178ad1b87eeaa121390b95530

<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

Link -> https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=ASSIGNED&bug_status=NEW&bug_status=REOPENED&component=HTML5%20spec&list_id=32878&product=HTML%20WG

<paulc_> HTML 5.1 timeline: See http://dev.w3.org/html5/decision-policy/html5-2014-plan.html

<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
... 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

scribe: 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
... 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

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
... we don't have to update the charter, but we do need to inform the AC

<paulc_> Current schedule is in the charter: http://www.w3.org/2007/03/HTML-WG-charter.html

rubys: Then we should communicate LC for 5.1 won't happen in Q3 and that we are going to ship HTML5.1 earlier
... 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

<krisk_> paulc: Let me ask two qs

<tantek> Process improvement project: https://www.w3.org/wiki/Process

<krisk_> In 5.0 we needed to go to no just last call, but pre-last call

<krisk_> Do we think we will need this for 5.1?

<krisk_> paulc: so are we ok that 5.0 is marching to be done...

<krisk_> we are just really asking for a review for 5.1 which is much smaller in scope than 5.0

<krisk_> ..so that the model for 5.1 can be much differenet

<krisk_> darobin: yes

<krisk_> paulc: I think it's key to communicate this diff

<krisk_> paulc: Next is that I think the ally focus are thinking the 5.1 timeframe will be the same as 5.0

<krisk_> paulc: basically we have to communicate this outside an inside the group

<krisk_> rubys: In theory if we do ship yearly then it should not be problem, like other 'at risk features'

<krisk_> * krisk_ says goodbye to krisk

<plh> http://lists.w3.org/Archives/Public/public-w3process/2014Mar/0019.html

<krisk_> paulc: that is my point, maybe do a paln 2016

<rubys> d/plan/plan/

<krisk_> plh: we can use new process if we are not in last call...

<krisk_> ..if you are in last call then you can't use the new process

<krisk_> 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

<krisk_> tantek: I was confused about extension specs and 5.1

<krisk_> paulc: you should read the ally TF work

<krisk_> paulc: I think they are really looking at 5.0 in 2014 and then 5.1 2016

<krisk_> tantek: I'm all for lining up to other schedules, though it goes against the spirt of extension specs

<krisk_> paulc: The api mapping document pre-dates the concept of extension specs

<krisk_> rubys: Their is a very human aspect to this...

<krisk_> ..other people want to work with us and we should reach out

<krisk_> ..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

<krisk_> ..which will lead to a set of action items where stuff can land - 5.1, 5.2 etc..

- DRAFT -

HTML Working Group face-to-face meeting

08 Apr 2014

Attendees

Contents