See also: IRC log
<plh> https://github.com/w3c/html/issues/170
<arronei> Travis: integration of modules had helped us understand bikeshed
<arronei> Travis: modules work in Edge and released in a upcoming preview and also coming in Chrome
<arronei> chaals: should we add in something that isn't implemented yet?
<arronei> Travis: its for 5.1
<arronei> plh: what would I grep on to find tests?
<arronei> Travis: platform module is what you woudl search for
<arronei> Travis: could block CSP from getting to REC
<arronei> chaals: so they want to push a spec forward that isn't implemented?
<arronei> Travis: the dependancies are part of ES2016 and modules are part of Ecmascript
<arronei> Travis: script type module is the bootstrap for modules
<arronei> Travis: tests would be in test 262
<arronei> chaals: the basic problem mike west has is he want to point to some stuff
<arronei> chaals: are we in a position to provide a stable pointer?
<arronei> plh: we may need to ship a 5.2 sooner than we thought
<arronei> are you sure we can't put the hooks into 5.1
<arronei> Travis: it would be a couple of extra days to get the hooks in
<arronei> Travis: the CSP steps are really small
<arronei> chaals: do the csp hooks have implementation?
<arronei> Travis: it depends on what they are
<arronei> Travis: from mike I gather CSP 3 just clarifies CSP2
<arronei> plh: do you have the time?
<arronei> Travis: I can do it and I am already working on it
<arronei> Travis: I would like to have them in by Friday but let me confirm
<arronei> Looking at the list of CSP issues remaining https://github.com/w3c/html/issues/assigned/travisleithead
<arronei> chaals: do we have tests?
<arronei> plh: we do have tests for nonce= from google
<arronei> Travis: what should I do with the changes for 5.2?
<arronei> chaals: lets hold off on branching
<arronei> chaals: we aim to modularize html
<arronei> chaals: modularizing means we need to pull bits out bit by bit
<arronei> chaals: my idea is the html spec points to the module
<arronei> chaals: the goal is to try and get the linking
<arronei> adrianba: you want to modules to depend on the HTML core
<arronei> adrianba: I think its fine to create something like CSS
<arronei> adrianba: where the module points to the core
<arronei> chaals: lost of people go to the spec to learn how to use HTML
<plh> s|google/google, e.g. http://w3c-test.org/content-security-policy/blink-contrib-2/scriptnonce-basic-blocked.sub.html |
<arronei> adrianba: is a great example of all the bits that are all throughout the spec
<arronei> adrianba: the goal isn't to read the spec to be a teaching aid
<arronei> adrianba: state of HTML document, one is core and here is appcache
<arronei> Travis: do we extract the single line or lift out the entire algorithm?
<arronei> chaals: if you do that, aim for something in the middle
<arronei> chaals: this is where appcache needs to fit into the algorithm
<arronei> chaals: I would generalize the algorithm and provide links both ways
<arronei> chaals: its an editorial choice depending on the complexity of the algorithm
<arronei> Travis: do we disagree that appcache should be removed?
<arronei> All: in agreement it should go
<arronei> adrianba: but there is disagreement on what we shoudl do with it after we remove it
<arronei> adrianba: same with media controller
<arronei> plh: agree with Adrian. it's published in html 5.0, let's not waste cycles republishing a TR note.
RESOLUTION: We will not republish things that were already described previously and we removed from HTML 5.1
<arronei> chaals: for extension specs that are stable and done we put minimal required pieces in HTML spec and link off to spec
RESOLUTION: Add minimal info to HTML spec and link off to stable module spec
<arronei> plh: do we want to squash or merge
<adrianba> https://github.com/w3c/html/blob/master/TEAM.md
<arronei> if you want to merge you can throught he UI
<arronei> Travis: the reason you don't want to squash is someone is using change from your private repo
RESOLUTION: configure it to squash
<arronei> chaals: at some point we will ahve to make a branch.
<arronei> do we do it early to e.g. to put in Travis' giant patch
<arronei> or do we at CR
<arronei> or PR
<arronei> chaals: we will make editorial improments in 5.2 but 5.1 has already shipped
<arronei> chaals: at point of CR we branch
<arronei> AlexD: I think that makes sense
<arronei> adrianba: I think we should for as late as possible at CR and do travis' patch at 5.2
<arronei> plh: we doa CF for both
<arronei> plh: Travis needs to sit on his changes
<arronei> chaals: how long does it take you to publish?
<arronei> plh: it takes about 2 hours clicking on some link with some bikeshed changes
<arronei> chaals: and we do the changes list
<arronei> chaals: there is a little bit of flexibility
<arronei> chaals: the plan is about the time we call for consensus on CR we also call for 5.2?
<arronei> chaals: so travis your stuff doesn't work?
<arronei> Travis: I can show that is may be working
<arronei> Travis: is the 5.2 timeline about a year out?
<arronei> plh: yes unless we have to adjust due to other groups
<arronei> chaals: unlikely before next June
<arronei> plh: the TR page will point to 5.2 when we branch
<arronei> tr/html will point to the latest, tr/html5 points to 5.0, tr/html51 points to html 5.1
<arronei> plh: we do not want to recind the REC
<arronei> plh: what time to we want to put the note that points to the new document using obsolete note
<arronei> chaals: when we publish 5.1 as rec
<chaals> ACTION: PLH to document the process of branching and moving forward from one version to the next [recorded in http://www.w3.org/2016/05/10-html-editors-minutes.html#action01]
<arronei> chaals: for example appcache
<arronei> Travis: there are 16 so far
<arronei> chaals: it works in browsers but not what users want
<arronei> I do have changes for all the removals
<arronei> chaals: but we do have to get agreement
<arronei> <br data-time="10 minutes">
<Travis> Discussed removing AppCache:
<Travis> https://github.com/w3c/html/issues/40
<Travis> Need to raise the issue to the WG
<chaals> [We need to request review from various groups specifcially, point them to the drafts, timeline and changleogs to help them figure out how]
<chaals> ACTION: Léonie to start asking for review from horizontal groups - TAG, APA, PrivacyIG, SecurityIG, WebAppSec, I18n. [recorded in http://www.w3.org/2016/05/10-html-editors-minutes.html#action02]
<chaals> scribe: chaals
PLH: What's missing?
CMN: How to work with Bikeshed?
PLH: e.g. install and running bikeshed
TL: there are helpful shortcuts when you are editing that are useful to know
AE: I could write up that stuff
PLH: Took me hours to work out how the referencing is working.
CMN: Goal is that someone who wants to do a 20-minute patch doesn't need to spend 4 hours learning how.
<scribe> ACTION: Arron to document how to work with the spec and bikeshed. [recorded in http://www.w3.org/2016/05/10-html-editors-minutes.html#action03]
-> https://github.com/w3c/html/issues/361 361
CMN: looks sound
-> https://github.com/w3c/html/issues/361 360
Editorial, can be taken but not a blocker
-> https://github.com/w3c/html/issues/355 355
PLH: Not for 5.1
[Feature request, labeled]
-> https://github.com/w3c/html/issues/3552 352
[We want this, but it's informative, not crucial. labelled assigned]
<plh> scribe: plh
chaals: #343 is editorial
... assigned to chaals
#342
Travis: sounds like 5.2
Chaals: ideally would be 5.1 but might get dropped due to timeline
#341
Chaals: CSS provides more bullet types and has better i18n
Arron: we could leave it in for semantic
Chaals: suspect we'll say "generally, don't use it"
... not sure about obsolete
... I'll ask the WG
... assigned to chaals
#336
Chaals: assigned to Leonie
#335
Chaals: needs tests.
... assigned to Arron
#333
Travis: after 5.1
#330
Chaals: I'll take this one
#324
Chaals: incubate first
#322
Chaals: I'll ask the WG
... possibly close the issue after
#319
Arron: I'll take that one
#314
no change
#313
Arron and Leonie are on it
#312
#302
Chaals: most of it is incubation. when you make a metadata vocabular, it's good practice to reuse. that's the only change needed here. editorial.
#301
Travis: I'll figure that one
#293
plh: there is interest in webperf to define when rendering occurs
... but that's not a 5.1 item
<AlexD> scribe: AlexD
#281
Assigned to Travis
Arron: we know what the reality is
chaals: can you do this in time?
Travis: should be
#279
plh: should link to the outline algorithm issue we already have
chaals: It's editorial, leave for anyone to take
... this is not a priority
#278
chaals: who uses this?
Travis: Edge does it
plh: do we have tests?
... we have some old tests for it
chaals: according to caniuse, looks interoperable
#277
chaals: interop bug
... question for WG, leave for after 5.1
#274
Travis: Rbyers noted it's coming.
chaals: spec says void, reality says no. check with WG
#273
chaals: seems not urgent
Travis: does the use-case make sense?
chaals: does anyone in the real world need to do this? 90% of the time, not needed I'd expect
adrianba: seems reasonable to allow
... If you're building components, and it has a header, then when you bring in other components with a header, it makes sense. It shouldn't be a problem for a validator to flag
#272
chaals: should be more specific about caption
plh: I'd rather a whitelist than a blacklist
#271
LJWatson: one for Steve, it's editorial
#269
chaals: probably after 5.1
Travis; wouldn't see implementation changes until then
arronei: should we drop it?
#268
chaals: Assign to Steve
#266
chaals: Let's leave open until we've tested it
arronei: I think we'll find reality doesn't match
#264
#263
Travis: I started looking at this
chaals: needs tests, who's going to do it?
plh: Looks like after 51
#262
plh: flag this as security
... we need tests
#261
plh: historical reasons?
chaals: HTTP Content-Language is something browsers ignore
#260
LJWatson: this can be closed
#259
chaals: seems moderately unscary
plh: what do browsers do today?
... depends if implementation supports MathML
chaals: reality is a bit weirder, entities supported even if they don't support MathML
#258
#255
plh: do we have anything explicit about HTML mail?
adrianba: If you do this, then we've set a precedent...
chaals: we're not going to prioritize this for 5.1
adrianba: If someone wants to write an HTML mail doc, then that's fine. It's not relevant for this spec.
arronei: There's a TV profile too
plh: conformance for HTML mail should be in a separate document
#254
Travis: Edge will do what Mozilla does
adrianba: That's not the proposal
chaals; proposal says iframe will be rendered in no-quirks mode
plh: after 5.1
#253
arronei: love the idea
chaals: not enough implementation yet, match reality better...
#251
LJWatson: not as simple as it seems
chaals: spec says use figcaption as preference
#247
adrianba: I have a few concerns. There were a few people upset by this
chaals: I'm not going to delete people
... For 5.2, we may refine the list
adrianba: we shouldn't be flippant, people have contributed a lot of effort into the spec
plh: reasonable for people to make PRs to add their names
#246
chaals: we asked the WG, there's only one implementation
adrianba: we're thinking of implementing it
#245
chaals: file against workers & sockets spec
#242
arronei: fixed by PR #350
#236
chaals: poor interoperability, question for WG...
#235
Travis: similar to the active & focus issue
plh: it's not about rendering, it's about matching CSS
... probably an entire section that needs to be added
#234
LJWatson: makes sense if it's possible to do it
arronei: I think some browsers allow this
#233
adrianba: we can't pull out the protocol one, content one maybe
#230
chaals: needs tests, I'll do it
#227
Travis: this is extra documentation
... it'd be helpful, we need someone to do the research on those platforms
#226
AlexD: would only make sense for languages with different directionality. e.g. Italian->Spanish->English doesn't cause a BIDI change.
chaals: After 5.1
#225
chaals: feature request, needs incubation
arronei: I think it's match reality more than incubate
#224
#223
arronei: probably remove, support is getting dropped
#222
plh: Larry stopped working on it a long time ago due to no feedback
Travis: after 5.1
#221
plh: didn't make it into 5.0, lacking testing
#219
chaals: Looks like a feature request
#218
plh: looks like an incubate first
#216
#215
plh: another interaction with CSS one
#214
plh: After 5.1
#212
chaals: This is hard
Travis: After 5.1
... This is a feature request, we should incubate this :-)
#211
chaals: linking issue
#208
Travis: very closely related to inputmode mess
plh: After 5.1
chaals: If it's in Safari...
plh: should it need incubate first?
chaals: There is an implementation, if someone else decides to ship then put it in
#202
#201
#199
chaals: issue is a match reality, I have tests that work
#198
chaals: Needs tests
#197
#196
plh: Web App security if anything
chaals: Incubate it
#195
chaals: It's a feature request
... should be incubated
Travis: Goes into the bucket for a true tri-state checkbox
#194
chaals: poor real world interop.
#191
arronei: The next bunch are all CSP related
chaals: I'll put a due date on all these issues
(i.e. #183 through #189)
#178
#176
arronei: sounds like simple change
#173
plh: we need tests for that
chaals: this is best practice advice, right?
... I don't know that we can make it a must - can we guarantee they'll appear?
Travis: How do you test that?
#172
#171
chaals: test results show poor real world interop
#170
chaals: we decided this morning to add minimal hooks from HTML
plh: what about media capture stuff?
#167
chaals: yes
... This editorial, part of removal of AppCache effort
#166
#165
Travis: fixed by my changes in flight already
#163
Travis: kind of fallback to detecting that scenario, and doing something with it
chaals: It's hard to detect in many cases
Travis: minimal APIs impacted by this
#160
plh: this is the microformats wiki
#159
plh: It was moved into Web Performance
#154
arronei: this was a merge issue, I'll take care of it
#151
#149
plh: already a PR there
#148
chaals: 150 has been merged
plh: it was pretty easy from what I remember
#147
#132
plh: we can take the same position as 5.0
chaals: Did WhatWG test this section?
plh: testing that will be a nightmare
#121
arronei: there's a PR waiting
#120
Travis: keep it for the next milestone
#119
#118
arronei: I think this one is fixed, assign it to me
#114
chaals: Not part of HTML
#110
#109
#106
#105
chaals: Needs incubation
#104
chaals: I will change the example
#92
#91
chaals: incubate first
#90
#89
chaals: put to the WG
#68
#64
chaals: has been assigned to adrianba recently
#62
#58
#52
plh: incubate first
#44
plh: seems like an after 5.1
LJWatson: don't think anyone's implemented it
#43
plh: we have a PR
chaals: where does it still work?
arronei: Chrome still has it as of 51
Travis: Firefox doesn't have it
chaals: question for the WG
#40
chaals: We asked a week ago
#33
chaals: It's not useless, just the stuff about h1s. Let's keep it
... apart from h1s it works. Let's close. There's a clear warning that the top of the section saying it doesn't work in any browser
#28
arronei: this is ongoing
#19
chaals: incubate first
#6
#3
arronei: seems like it can be closed
chaals: That it for the issues
plh: we should go back through those assigned for the milestone
chaals: Everyone go through what's assigned to them and see if they can achieve them in time for next milestone
plh: we have one not assigned
chaals: It's marked as needing help, if we don't get it we'll just have to close.
Target date for HTML5.1 Rec: Sept 15th 2016
Interim dates:
June 2nd: WD update, CFC for CR; Branch for 5.1 in github
June 14th: transition to CR request
June 21st: HTML5.1 CR
July 19th: CFC for PR; implementation report
July 28th: HTML5.1 PR transition request
August 4th: HTML5.1 PR
September 1st: AC reviews end
September 15th: REC
chaals: We should run all of WPT tomorrow.
<plh> http://w3c-test.org/tools/runner/index.html
plh: cut-off date for substantive changes is May 31st
<LJWatson> http://w3c.github.io/html-aria/