01:40:49 rniwa has joined #webapps 04:09:50 kawai has joined #webapps 04:44:33 jungbin has joined #webapps 05:58:18 ericc has joined #webapps 06:41:26 tantek has joined #webapps 07:06:36 jungbin has joined #webapps 07:23:48 xiaoqian has changed the topic to: TPAC Web Platform WG meeting - https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-09-23TPAC-4.md 07:27:49 kawai has joined #webapps 07:37:37 ericc has joined #webapps 07:43:08 wilsonpage has joined #webapps 07:48:19 jsbell has joined #webapps 07:53:17 dom has joined #webapps 07:56:23 cabanier has joined #webapps 07:57:44 tantek has joined #webapps 07:59:10 tantek has joined #webapps 08:02:48 Florian has joined #webapps 08:04:14 dcooney has joined #webapps 08:04:38 present? 08:04:42 present+ 08:05:33 RRSAgent, listen 08:06:24 chaals has joined #webapps 08:08:19 Florian has joined #webapps 08:08:26 present? 08:08:29 plh has joined #webapps 08:08:37 Zakim: present? 08:08:46 present+ dcooney 08:08:56 weinig has joined #webapps 08:08:56 scribenick: dcooney 08:09:00 present+ Florian 08:09:00 present+ 08:09:00 olivier has joined #webapps 08:09:01 SteveF has joined #webapps 08:09:06 AlexD has joined #webapps 08:09:14 dsinger has joined #webapps 08:09:22 scribe: dcooney 08:09:24 tomalec has joined #webapps 08:09:24 zakim, who is here? 08:09:24 Present: Yves, Chong, GaryK, OlliP, Enrica, Chaals, Léonie, Johannes, Kochi, DomC, Yoshi, Yoisho, Hayato., dcooney, MarkV, Travis, MarkVickers, Glazou, AnnevK, david_wood_, Navid, 08:09:27 RRSAgent, pointer? 08:09:27 See http://www.w3.org/2016/09/23-webapps-irc#T08-09-27 08:09:28 ... Joshua, Florian, plh 08:09:28 On IRC I see tomalec, dsinger, AlexD, SteveF, olivier, weinig, plh, Florian, chaals, dcooney, tantek, cabanier, dom, jsbell, wilsonpage, ericc, kawai, rbyers, NavidZ, kenneth_, 08:09:28 ... RRSAgent, Zakim, heycam|away, schuki, falken, shane, iank_, nolanlawson, koji, annevk, sangwhan, logbot, dveditz, hsinyi, wanderview, asuth, jyasskin, timeless, cwilso, 08:09:29 ... bigbluehat, othree, tobie, scheib, Domenic, Travis, krit, jeffcarp, adrianba, kochi, Josh_Soref, hayato, ojan, jkomoros, esprehn, dfreedm, plinss, leaverou, slightlyoff, flaki, 08:09:29 ... decadance 08:09:39 Present+ OlivierThereaux 08:09:43 garykac has joined #webapps 08:09:54 good morning (from IRC) 08:10:11 chairing #social web wg this morning, will lurk here 08:10:22 rniwa has joined #webapps 08:11:03 AlexD: notes domenic and annevk are absent 08:11:08 topic: whatwg 08:11:23 anssik has joined #webapps 08:11:46 AlexD: We want to talk about whatwg HTML, W3C html, and compatibility and what the editors are doing. 08:12:00 the similarities are larger than the dissimilar between whatwg and w3c 08:12:05 we love HTML and the web 08:12:11 and we want the best specs possible 08:12:16 but the process is differeent 08:12:21 developers want low-friction 08:12:38 But we as company representatives need the W3C protections--patent exclusion periods. 08:12:49 Has anyone here in the W3C process had anything to do with patents? 08:12:54 smaug has joined #webapps 08:12:58 Whether someone has blocked a feature or been involved in a panic. 08:13:09 (Note 5 hands.) 08:13:22 chaals: 6 maybe didn't rais their hands. 08:13:41 AlexD: W3C specs get the royalty free commitment from other companies. This isimportant so Google can ship chrome. 08:13:56 q+ 08:14:01 Steve, Travis, Aaron (absent) have to manually triage changes to the spec, decide if it is relevant and manually edit. 08:14:11 It would be nice if the community sent us pull requests. 08:14:17 So we don't have to manually do the work. 08:14:25 The living standard does not reflect reality. 08:14:34 Present+ Travis 08:14:38 The WHATWG is aspirational future; the W3C spec is what's interoperable. 08:15:17 For example, mkwst and a lot of the media stuff he's working on is based on fetch and he can't port his changes into the W3c version of the spec as a result. 08:15:23 Browsers don't ship that interoperably. 08:15:28 How can we do this better? 08:15:49 Present+ chaals, Tomek, GaryK, Florian, Tess, SamW, DaveS, Cwilso, MarkV, Joshua, AlexD, SteveF 08:15:52 Edtiors have a montthly meeting to triage changes. It's time consuming, formalizing what's in W3C, and doesn't improve HTML per se. 08:15:55 q? 08:15:55 q? 08:15:57 q+ 08:16:02 MarkVickers has joined #webapps 08:16:05 q+ 08:16:14 SteveF: I'm also one of the editors, since before HTML5 was pushed to REC. 08:16:21 I work on the HTML5 spec and iterations differently. 08:16:50 q+ 08:16:59 I do some of the work to pull whatwg changes but I also work on making the stuff that the browser vendors aren't interested in--conformance aspects, language around guidance, information about what the semantics of elements represent... 08:17:00 q- 08:17:15 hjlee has joined #webapps 08:17:17 I work on modifying and updating that to reflect reality and provide guidance to authors to benefit users. 08:17:24 ack st 08:17:35 I have in the past filed bugs against the whatwg spec; I've had limited success in getting changes made in the whatwg spec. 08:17:38 q+ 08:17:44 Because there's philosophical differences. 08:18:10 The sort of changes that I see as a priority aren't necessarily a priority of the browser vendors because I'm looking at interoperability. 08:18:35 I also work on normative conformance requirements for validators; for example with mike smith on the W3C valiadter. 08:19:02 For example the outline algorithm that has been around for years to order headings in section and content elements but has not been implemented in a reasonable way. 08:19:09 s/valiadter/validator/ 08:19:15 Rebeca has joined #webapps 08:19:20 The whatwg and w3 specs were similar recently but with a warning that it was not implemented. 08:19:47 Between 5.1 and missing I filed bugs on W3c and Whatwg specs and made changes to the outline algorithm to bring it into line with what browsers od. 08:19:48 do. 08:19:55 That is reflected in the W3C validator. 08:20:09 There's quite a bit of variance in this information in the W3C spec and whatwg spec. 08:20:28 It's not necessarily bad, but it is not my job to follow the WHATWG spec because it does not reflect reality. 08:20:42 Florian: There seems to be multiple kinds of differences. 08:20:50 q? 08:20:53 ack flo 08:20:56 ack fl 08:21:09 kinjim has joined #webapps 08:21:20 Some of it is exploratory work. Within that, there's the "good or bad" but isolated idea of the editor, somewhat reflective of the consensus of the right way to do it and it is a problem of priority. 08:21:24 q+ Two docs, one target audience? 08:21:24 That is not of interest to W3C. 08:21:45 q+ 08:21:57 WHere things don't reflect reality as it already exist, I'm confused because the WHATWG says they want to match reality. 08:22:10 Why can't we agree on what reality is, excluding the reality. 08:22:17 chaals: What WHATWG is out of scope. 08:22:34 Florian: If we were starting from scratch I prefer W3C for patent and process reasons. 08:22:51 It's key to understand what they do to see if we can agree, should try, who's irrelevant. 08:23:01 The charter says we should minimise the difference. 08:23:22 MarkVickers: The opening statement was the most succinct summary I've heard of the motivations and situation. 08:23:26 q+ 08:23:41 Having low friction makes decision easier and W3C provides the pattern protection. I see why Google would want that. 08:24:14 As someone who represents friction, why would someone give patent protection for something they're not participating in? We just have an editing and rubber stamping responsibilty. 08:24:22 chaals: There are aspects beyond IPR. 08:24:23 ack ma 08:24:27 ack chaa 08:24:37 Technical compatibility with things WHATWG do that are interoperable as a priority. 08:24:45 WHATWG has things that aren't interoperable. 08:24:57 We have incubation for that; we don't put it into a HTML recommendation. 08:25:16 It's odd to lose it. If WHATWG does things that aren't interoperability that's outside our purview. 08:25:25 THere are reasons outside IPR, such as antitrust. 08:25:32 That's important part of the process. 08:26:00 We have been striving to maintain compatibliity, there's a pile of stuff that goes into the spec and we watch when it is interoperability and then put it in the spec. 08:26:02 LJWatson has joined #webapps 08:26:08 WE would do that in incubation. 08:26:28 rrsagent, make minutes 08:26:28 I have made the request to generate http://www.w3.org/2016/09/23-webapps-minutes.html LJWatson 08:26:39 AlexD: At past companies, we donated our royalty free patents into the standards for the purpose of building products that used the W3C standards. 08:26:47 It provided an effective defense. 08:26:53 rrsagent, set logs world-visible 08:26:57 rrsagent, make minutes 08:26:57 I have made the request to generate http://www.w3.org/2016/09/23-webapps-minutes.html LJWatson 08:27:24 Take JPEG for example, a submarine patent came along and (company) had 700 million dollars extracted from them. 08:27:36 jamesn has joined #webapps 08:27:50 s/had/extracted/ 08:27:58 If you're a company building WebRTC servers for example, your business is enterprise video, the fact it is built in a W3C spec, the patents for realtime video, noise cancellation, etc. are licensed to you for free. 08:28:05 s/extracted from them/from others/ 08:28:10 That's why people participate. Is that why you're asking? 08:28:12 MarkVickers: No. 08:28:28 We vere a member of HTML5 for years and other groups, but we have some participation with some other groups. 08:28:54 q? 08:29:07 I'm happy to be a second class citizen; browser vendors have to be first class because they're shipping products. But we need to have an advisory, requirements role. I have no problem being a second class citizen. 08:29:15 I have a problem being no citizen and having no input. 08:29:30 chaals: That doesn't happen. It used to maybe be a bit like that but we exercise editorial control now. 08:29:37 Travis: I will not talk about patents. 08:29:43 ack Travis 08:30:21 One of the concerns I hear regularly primarily from browser vendors: they have a choice between going to WHATWG or W3C to implement something, primarily because both specs are targeting implementers. 08:30:36 That creates a tension for implementers and the community. They have equivalent content.= 08:30:59 WHATWG proceeds faster and is further ahead and the algorithm/code level, step 5 of such and such algo to make it precise when implementing. 08:31:14 q+ 08:31:14 Is there an opportunity to differentiate the WHATWG and W3C version by changing the focus/target audience. 08:31:31 q+ 08:31:54 q+ 08:31:55 For example, target web developers and start to "un-codify" the spec, keeping the same level of concepts but explain them in more web developer friendly terms so there's less work porting minute details but to capture the essence and document that. 08:32:08 That allows the vendors to focus on one spec and web developers to focus on another. 08:32:11 q- 08:32:21 q+ to talk about target audiences and spec. style 08:33:00 jnurthen has joined #webapps 08:33:02 garykac: I want to comment on the characterization that W3C is what we have shipped and WHATWG is aspirational. UI Events, the keyboard events and focus in, focus out, doesn't reflect what the browsers do; it is aspirational. So mozilla has to look and decide, it's a bit more complicated. 08:33:11 chaals: Pretty much nothing is entirely true in the details. 08:33:21 ack gary 08:33:29 ack cha 08:33:35 ack Steve 08:33:51 SteveF: To follow up on Travis, one idea I put forward when we were talking about 5.1 was similar to Travis' idea to take the implementation information of WHATWG but leave out the interpretive stuff. 08:34:02 q+ 08:34:07 Look at what's implemented, going to be implemented, and give focused advice to developers on how to implement. 08:34:12 I think it is a good idea. 08:34:35 One thing I don't understand, if we do it that way without incorporating the implementation stuff, then what happens to the IP protections? 08:34:45 ack dsinger 08:34:45 dsinger, you wanted to talk about target audiences and spec. style 08:35:13 dsinger: I have also wondered why it was optimized for the smallest audience--implementers--and not the large audience of developers. 08:35:22 Pseudo-BASIC is unreadable. 08:35:32 q+ 08:35:40 q+ 08:35:47 If we were to change it so it is readable for web authors I don't think we would be doing the industry a service by having two specs with different approaches. 08:35:54 q+ 08:35:57 ack Florian 08:36:17 q? 08:36:19 Florian: (missing) makes it difficult to contribute to the WHATWG specs or other working groups, what spec do they raise issues against? It creates confusion and friction. 08:36:28 Probably the W3C spec etc. 08:36:41 chaals: THere are two orgs working on HTML. Our only solution for that is to stop working on HTML. 08:36:45 We could easily do that. 08:36:54 q+ 08:37:10 The likely outcome is unpleasant. A lot of people who did work on HTML will be sent off to work on antittrust which is no fun. 08:37:34 To answer dave's q, where there are differences--technical differences--we need to provide the implementer and developer facing parts of the spec. 08:37:36 q+ 08:37:40 astearns has joined #webapps 08:37:59 What I understood from travis was developer oriented text instead of implmenteer oriented algorithms would be easier. 08:38:20 Essentially implementers would go to WHATWG, unless there's a technical difference which we'd have it our spec. 08:38:36 q? 08:38:38 ack chaals 08:38:40 For people who want to know what a list element does and how you use it is easier to read ... 08:38:40 q+ mkwst 08:38:47 q+ Mike 08:38:54 q- Mike 08:38:55 chaals: queue will be closed 08:39:14 q+ 08:39:23 zakim, close the queue 08:39:24 ok, chaals, the speaker queue is closed 08:39:46 SteveF: When I was thinking about this circa 5.1, I was thinking about the HTML spec having the algorithm in the spec but changing the inf. arch. and styling so that would be available to anybody who wanted to see it, including implementers, but it would not be in everyone's face who didn't want to see it. 08:40:17 Having the same information in the HTML spec at the W3C spec, faithfully rendered, but not displayed to everyone. 08:40:27 AlexD: The incubation process is a solution to thisp roblem. 08:40:28 ack ste 08:40:35 ack ale 08:40:35 WHATWG runs along with new stuff every day. 08:40:53 But if they are new features, they should be incubated, then ported over to the W3C spec. 08:41:05 s/(missing) makes it difficult to contribute to the WHATWG specs or other working groups, what spec do they raise issues against?/When people working in other w3c working groups need to raise an issue against HTML, knowing which HTML to talk to is difficult. The first guess is w3c, since we're in a w3c wg already, but browser vendors in the same group will often say that what they look at is the other one. This create confusion./ 08:41:11 So chunking via incubation may be the way to go instead of porting small patches. 08:41:35 olivier: One of the things I heard earlier is that the value that W3C creates is about interop, testing, licensing and outreach. 08:41:36 ack oli 08:41:44 I note that none of this is related to editing a spec on a daily basis. 08:41:45 ... 08:41:55 (sic) 08:42:31 plh: My problem is I have 38 groups, chairs, team contacts coming to me wanting to know which specs to reference. 08:42:39 Some groups can reference a W3C spec they need. 08:43:03 Director approved a spec called secure context that can reference both specifications. 08:43:21 +1 to plh's points 08:43:26 Thoughts on “Notes from the future of HTML session at TPAC” (2015) https://www.paciellogroup.com/blog/2015/10/thoughts-on-notes-from-the-future-of-html-session-at-tpac/ 08:43:27 It's different for me to go and tell other working groups you can reference this or that spec. It's confusing. What answer should we provide to the other 37 working groups. 08:43:58 mkwst: A lot of my work touches HTML in one way or the other, hooking into navigation which is deep and detailed and critical to understanding the feature operation. 08:44:08 It's admirable to helping web developers understand. 08:44:20 But vendors need a way things work to make it interoperate. 08:44:55 These are separate to user manuals, analogous to word manuals. The "basic" is very important for me as an implementer to ensure the same thing happens in every browser. I look at WHATWG 08:45:46 for two reasons: it moves quickly and it is easy to get patches in. On on interpersonal level and technical level, doing find and replace in one document instead of w3c's multiple documents which is annoying to find let alone change. 08:45:58 On a technical level, W3C documents are harder to work with. 08:46:31 The initial commit on W3C and change from WHATWG mechanism to bikeshed is problematic--features have been incompletely removed, for example noopeneer that is referenced but not defined. 08:46:51 That impairs trust because I'm not sure if the changes mean the same thing because all the features are interrelated 08:47:00 Even if the changes are just moving a section to a new document. 08:47:11 So changes are hard. As a result I work in WHATWG. 08:47:34 That has political and interpersonal implications. It's not personal, but it is easier to work with WHATWG. 08:47:53 Multiple documents for different audiences is a good idea but don't replace the technical documentation. 08:48:06 All W3C documents would be easier to change if we only had one or two companies in W3C. 08:48:16 chaals: Some of the assumptions and ideas we're testing--should we strive for compatibility with WHATWG spec? 08:48:23 IanPouncey has joined #webapps 08:48:46 Of those who responded, it's a goal. 08:48:59 q+ to say that's the wrong question. 08:49:08 Should we strive to make a more web developer oriented document? Or try to keep the algorithms? 08:49:18 Florian: Is that a dichotomy? 08:49:30 chaals: Not necessarily, just want a sample of interested people. 08:49:38 We will take guidance from this. 08:49:49 dsinger: replace our normative document with something for the web developer? 08:50:14 chaals: We're not going to throw away our document. But moving forward, should editor's focus be explaining the steps and how you use them? 08:50:39 Florian: I would vote for the first option if it means on a daily basis work on a developer oriented document but still have regular snapshots. 08:50:42 chaals: Not relevant 08:50:50 Florian: Relevant! It's a twist on your question. 08:51:04 chaals: Is throwing away the algorithm stuff a step backwards? 08:51:12 Everyone thinks it is a step backwards. 08:51:17 garykac: With caveats 08:51:31 chaals: Should we be putting focus on a web developer focused document? 08:51:52 cwilso votes it is a waste of time, others vote editors should do this. 08:52:02 SteveF: Why do you object, cwilso? 08:52:18 cwilso: The question you were asking is the wrong one. 08:52:52 How many people think it is a sane thing to have two documents that pupport to define approximately the same technical specification? Regardless of the color of the ink. 08:53:00 Sooner or later this has to resolve. 08:53:25 The answer isn't pulling the technical information out of one. I could write a book that is the technical guide to HTML. 08:53:39 The question has to be, where do web devs and browser engs go to understand the spec? 08:53:53 chaals: W3C has one mechanism available today: unilaterally stop work. 08:53:57 Who thinks that is a good idea? 08:54:16 It's not like nobody thinks it's a good idea. Who thinks it's a bad idea? A number. 08:54:24 Florian: Who thinks something inbetween? 08:54:30 (hands) 08:54:41 chaals: So the question is how do we minimize the pain of this insane situation. 08:54:48 We could come back to this topic later. 08:54:56 Let's look at incubation. 08:55:17 Topic: incubation 08:55:50 SteveF: What we have now, instead of WHATWG, we have Y community group where things are being incubated, not only from HTML but CSS and other WG and that is working well with wide participation from vendors and developers. 08:56:03 q? 08:56:05 zakim, open the queue 08:56:05 ok, chaals, the speaker queue is open 08:56:13 nainar has joined #webapps 08:56:13 ack me 08:56:16 Rebeca has joined #webapps 08:56:18 ack plh 08:56:19 ack plh 08:56:21 ack mk 08:56:41 q+ 08:57:03 Most if not all of the incubation either goes directly to WHATWG and then gets pulled across, or is starting to flow from YWG. In W3C we have minor changes to features, should we do that in HTML or send that to YCG. That is what we have been doing when people file bugs. 08:57:16 s/YCG/WICG/ 08:57:31 crosstalk about pronuciation 08:58:30 chaals: Chair hat off, if you have a crazy idea incubating it to get traction is a sound idea. When I want to make small tweaks to the spec but it takes a demonstration of consensus and browser interest, which is obvious, it is hard to demonstrate consensus in WICG. 08:58:44 HTML has a formal consensus mechanism but no experimental playground. 08:58:47 q+ 08:58:52 q+ 08:58:53 We need to find a way to do this. 08:59:14 ack me 08:59:40 cwilso: That's by design. The WICG is intended to be everyones' experimental playground. Gave a preso to AC about when to use wicg, it's convenient because people are there already. 09:00:00 Don't incubate crazy experiments in a WG. Transition from CG to WG is when you demonstrate consensus. 09:00:28 You may walk into the WG and meet opposition; that's what the consensus process is for. CG can experiment in a light weight way. 09:00:28 ack c 09:00:46 Florian: The transition from incubation into WG is not automatic. 09:00:56 The CG membership may not transition into the WG. 09:01:10 q+ 09:01:17 I'm concerned we will create specs outside the WG and they keep working there together and we have the HTML problem again and again. 09:01:41 q- 09:01:42 chaals: Am I hearing as HTML chairs, what you should be doing, is push people ready to make the transition against the consensus wall. 09:02:01 cwilso: Your concern is not unfounded. To prevent that there's two things it the design: 09:02:15 It's better than the status quo because there's some IP commitment from contributiors. 09:02:28 jcraig has joined #webapps 09:03:15 1. Incubations aren't intended to be specs; you wouldn't incubate SVG 3 or HTML. Something in a charter. You might incubate a feature. There's no rule to say you can't but maintenance is the challenge when your WG may go away. An interesting one to solve with SVG in particular. 09:03:30 What will happen is we'll have groups manage and maintain specifications. 09:03:52 So we can maintain an ongoing large spec withou polluting that with whacky new stuff but take that stuff with consensus at the right time. 09:04:10 I don' think you'll end up with top down forever specs in WICG because you want the patent commitments. 09:04:42 chaals: The other concern I get to with consensus and implementation, there's one model for stuff to get into HTML, vendors decide it's a great idea and just do it. 09:05:07 If the incubation model we have is too implementer gated, the alternative model where 50^10 web developers go, hey can we have this please. 09:05:35 How you follow that path is not clear. It could be incubation, we could look at it that way, but my experience taking odd accessibility features it's not immediately obvious that's a path. 09:06:00 We, the HTML group, need to help deal with that. We individuals working on incubation stuff need to wake up and ask why people aren't doing that. 09:06:07 Break time. 09:06:20 Back in 15 minutes. 09:06:58 s/Florian: Is that a dichotomy?/Olivier: Is that a dichotomy?/ 09:07:33 s/Florian: I would vote for the first option if it means on a daily basis work on a developer oriented document but still have regular snapshots./Olivier: I would vote for the first option if it means on a daily basis work on a developer oriented document but still have regular snapshots./ 09:08:04 s/Florian: Relevant! It's a twist on your question./Olivier: Relevant! It's a twist on your question./ 09:08:43 s/Florian: Who thinks something inbetween?/Olivier: Who thinks something inbetween?/ 09:10:54 olivier thank you for pointing out that error, I think I fixed them but please sanity check me 09:11:10 RRSAgent, makeminutes 09:11:10 I'm logging. I don't understand 'makeminutes', dcooney. Try /msg RRSAgent help 09:11:45 RRSAgent, make minutes 09:11:45 I have made the request to generate http://www.w3.org/2016/09/23-webapps-minutes.html dcooney 09:24:46 Florian has joined #webapps 09:29:16 IanPouncey has joined #webapps 09:30:26 tomalec_ has joined #webapps 09:34:16 SteveF has joined #webapps 09:36:34 LJWatson has joined #webapps 09:37:00 scribe:garykac 09:37:22 Florian has joined #webapps 09:37:33 plh: I don't want to spend more than 10 min 09:37:58 editors made changes to spec, and some people were surprised and we had drama. 09:38:34 how do we make sure that the commnunity is aware of the changes being made 09:38:36 we have many repos 09:39:00 anyone following github, knows that it is a firehose of info 09:39:31 dsinger: would like a way to track what is going on 09:39:39 easy to miss big decisions 09:39:48 q? 09:39:58 ack c 09:40:16 q+ 09:40:17 q+ 09:40:20 chaals: (referring to specific decision) did not feel that it was a big decision 09:40:29 don't feel that we've made a lot of big decisions 09:40:43 i'm aware that we need to make sure people are aware of what we're doing 09:40:55 yes, we know we need to do better 09:41:04 concrete ideas for improvement would be great 09:41:35 dsinger: a small decision that took months to arrive at, it not really a trivial decision. 09:41:49 don't want to rat-hole. that decision is done and over 09:42:05 travis: i18n had a similar concern 09:42:15 they want to be aware of relevant changes 09:42:24 they added a label so they can track changes across repos 09:42:29 q? 09:42:54 garykac has joined #webapps 09:43:17 q? 09:43:18 chaals: more on that topic? 09:43:28 q+ 09:43:53 stevef: regarding that particular issue: I think it was me that did the commit. that was purely on the basis that we went through all that discussion. 09:44:02 present? 09:44:07 it wasn't done out of malice. just part of the job as editor 09:44:15 ack SteveF 09:44:17 ack me 09:44:24 leonie: how can bwe make CSE more obvious 09:44:25 we have emails 09:44:26 ack LJWatson 09:44:40 how can we surface them more to give visibility? 09:44:44 ack Travis 09:44:50 ack me 09:44:59 travis: we (editors) have wondered how long to wait for additional commentary with PRs 09:45:12 as a rule of thumb, decided on about a week 09:45:22 is there more of a process that we could follow? 09:45:24 q+ 09:45:31 about the longdesc issue 09:45:38 chaals: DONT TALK ABOUT LONGDESC 09:46:17 chaals: for 5.1 , we assigned issues to milestones to make them easier to track 09:46:24 instinct is that we should do that again 09:46:41 its useful for editors to organize their work but also for people following at home 09:46:43 let' 09:46:49 s kill this discussion 09:46:54 now... modulatization 09:47:06 travis: all right 09:47:23 i've been asked to talk about elephants in the room 09:47:37 differences between WHATWG and W3C will cause strain for anyone reading 09:47:46 putting that aside 09:47:57 we still have interesting things to discuss 09:48:15 (1) is modulatization stiil a good idea? 09:48:23 chaals: show of hands... 09:48:49 majority in favor, with some dissent 09:49:03 sam: not easy question to answer as asked 09:49:21 when making any change you nee to look at the goals, and the effects on the process 09:49:25 we don't want to have 2 specs 09:49:47 having any discussion on this topic needs to start with goals and how it relates to reality 09:49:55 travis: thanks, that relates to why 09:50:14 we need to put aside notion that we can chop it into chapters and publish each one 09:50:34 it's a lot of work refactoring with contracts between the different parts 09:50:50 the current spec is kinda like spaghetti code with the inter dependencies 09:51:05 out goal should be to publish the stable parts as stable documents 09:51:11 q? 09:51:12 and non-stable stuff in different documents 09:51:18 q+ 09:51:39 q+ 09:51:39 aboxhall has joined #webapps 09:51:55 script is another example where we're still digging into how/why it works, so it's more likely to change 09:52:02 we should pull out the stable parts 09:52:13 to shrink the cognitive load for people reading the spec. 09:52:24 dsinger: agree 09:52:26 q? 09:52:34 ack me 09:52:35 doing modularization has a fair amount of homework 09:52:55 there's also political work to do. 09:53:03 we should talk to the WHATWG groups as well 09:53:13 if they could do some modulatization, then we could just refer to that 09:53:23 and simplify work for everyone 09:53:25 q? 09:53:33 ack LJWatson 09:53:37 leonie: i'd like to head from steve since he's been through some of this with aria 09:54:01 steveb: the bit I did was fairly simple to do because it was self contained 09:54:07 also it was something that I understood 09:54:10 what I' 09:54:21 ack me 09:54:45 we are struggling to keep up with the main HTML spec 09:54:56 this additional work will require additional reqources 09:55:09 no point talking about it if we don't assign resources 09:55:22 kinjim has joined #webapps 09:55:40 ack me 09:55:54 oliver: if it's a lot of work and we're not sure about the benefit, then we probably shouldn't do it 09:56:14 q+ to ask a statistics question 09:56:14 (doesn't seem to really benefit either web devs, nor editors... maybe implementors?) 09:56:17 chaals: in principle I like it because 500 page specs are hard to manage 09:56:44 "cutting spaghetti with scissors doesn't change it being spaghetti" 09:56:54 q+ 09:57:09 as steve sez: without resources, it doesn't matter if it's a good idea or not. 09:57:26 q+ 09:57:30 dspringer: how often to people use the single-page version vs. multi-page version 09:57:34 that would be useful info 09:57:46 ack dsinger 09:57:46 dsinger, you wanted to ask a statistics question 09:58:14 alexb: I support modularization because the burden on editors is massive. this would help manage the problem 09:58:31 travis: agree with dsringer, it would be nice to get that info 09:58:45 dominic: I always use the single page 09:59:16 hypothecally, let's say we modularize and we have stable and non-stable parts 09:59:55 how will smaller unstable specs (which require unstable hooks into stable parts) get added without making the stable parts unstable? 10:00:04 travis: we have that problem already 10:00:07 q? 10:00:17 dominic: that sounds like a problem 10:00:18 ack al 10:00:22 ack dc 10:00:43 alexb: we have that with canvas, and we just have to be pragmatic. we can "almost modularize" 10:00:55 s/alexb/AlexD/ 10:01:06 rniwa has joined #webapps 10:01:13 dominic: this is the reason thy modularization doesn't sound appealing 10:01:24 alexd: if we didn't have 2 versions, then this would be a lot easier 10:01:56 jungkees has joined #webapps 10:01:59 chaals: this sounds theoritical 10:02:06 dsinger: except it's the top deliverable 10:02:27 then we should update the charter 10:02:29 chaals: done 10:02:37 dsinger: it is in the current charter 10:02:51 chaals: yes, and we failed to deliver. the new charter doesn't mention it. 10:03:01 dominic: modularization does have appealing aspects 10:03:26 dom has joined #webapps 10:03:57 in the html spec, there is an algorithm that collects inputs for a fomr submission, and it would have been easier if things had been modulatized 10:04:14 sam: that's factorization, not modularization 10:04:23 aliams has joined #webapps 10:04:25 we can do a lot of that and improve the spec 10:04:37 we don't have to modulatize in order to get a more readable spec 10:04:46 there are other actions you can take to get to the same result 10:04:50 present+ Ali_Alabbas 10:05:29 chaals: drop mike on carpet 10:05:41 s/mike/mic/ 10:05:42 audience reacts with shock 10:06:05 propose 20 min break 10:09:07 s/it would be nice to get that info/it would be nice to get that info, but note that WHATWG default is single-page, but W3C default is multi-page. 10:10:19 Florian has joined #webapps 10:16:53 marcosc has joined #webapps 10:26:04 Travis has joined #webapps 10:30:18 chaals has joined #webapps 10:31:36 scribe: chaals 10:31:40 Topic: IndexedDB 10:31:51 agenda is on: https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-09-23TPAC-4.md 10:32:23 LJWatson has joined #webapps 10:33:05 Meeting: TPAC HTML, IndexedDB, Directory Upload, UI Events & WebPlat 10:33:07 JB: early last year v1 got shipped. Been quiet waiting for implementations. There are some exploratory features in WICG and github for v2 10:33:17 q? 10:33:21 rrsagent, make minutes 10:33:21 I have made the request to generate http://www.w3.org/2016/09/23-webapps-minutes.html LJWatson 10:33:35 … want to look at those, bugs, feature requests. 10:33:54 Meeting: TPAC HTML, IndexedDB, Directory Upload, UI Events, WebIDL & WebPlat 10:33:57 rrsagent, make minutes 10:33:57 I have made the request to generate http://www.w3.org/2016/09/23-webapps-minutes.html LJWatson 10:34:01 astearns has left #webapps 10:34:52 … What changed? First spec was "old-style", not algorithmic. There are interop issues, so I rewrote a bunch to algorithm style. Hopefully those are done right, but feedback is welcome. 10:35:00 … there is a revision history in the spec. 10:35:52 … biggest change is the addition of getAll / getAllKeys - feedback from Mozilla, Chrome, who are shipping. 10:36:25 … those are the biggest. There are convenience features, binary keys, arrayBuffers as keys, some internal cleaning. 10:36:50 … e.g. what happens if the user destroys a storage the script thinks exists. 10:37:37 … types of data for keys includes dates, arrays, some stuff. WebIDL can't express all the things indexedDB does, which produced a bunch of bugs. 10:38:06 … Feedback on all of this is appreciated. 10:38:39 AA: We would love you to walk through changes and make sure it still makes sense. 10:39:08 JB: Additions are all implemented in at least Firefox and Chrome. Not everything has WPT tests but that is planned. 10:39:28 kinjim has joined #webapps 10:39:45 … Spec relied on DOMErrors, but those are unpopular so we changed to DOMExcpetion, that shipped in Chrome with no breakage. 10:40:06 [ \o'/ ] 10:40:55 SteveF has joined #webapps 10:41:08 … DOMStringList - turns out a contains() method cannot be added successfully :( 10:41:47 … we would like to use frozenArrays, but need a .contains() there. 10:42:17 … some methods should be able to consume DOMStringList but only take sequence. What do we do? 10:42:39 Chrome's usage indicator for DOMStringList contains in IndexedDB: https://www.chromestatus.com/metrics/feature/timeline/popularity/848 10:42:55 JB: The big exploratory features are observers and promises. 10:43:00 https://github.com/wicg/indexed-db-observers 10:43:14 DC: why not add includes to DOMStringList to give people a way forward? 10:43:39 JB: We weren't sure whether to expand DSL while trying to get rid of it. We would prefer to have frozenArray with contains. 10:44:05 … patching the method onto an object was hard work so we skipped it for now, but no strong principled objection to the idea. 10:44:59 … Observers. Being able to register one would allow any connection making changes to be watched. Like changed event from DOMstorage but for IDB's increased possible set of stuff. 10:45:46 … We are discussing in WICG. The shape of the API is modelled on e.g. intersectionObserver, with IDB-specific features 10:46:02 … Observation starts in the scope of a transaction. 10:46:26 … after that transaction completes you get the observations, so within the transaction you can get the state. 10:46:42 … You get a replay of changes. 10:47:22 … additional discussion about collapsing changes to minimum diff or replaying all changes. Collapsing seems cooler but nobody thinks it matters enough to worry. 10:47:46 … Also discussed - do you see the keys changed, or the values as well? 10:48:19 … exploring opt-in to get the value, or a read-only transaction as the state of the database if you ask. 10:49:05 … This is cheap to implement, we are not committed either way but planning to try both of them and get feedback. 10:49:56 … Next thing is promise support. 10:50:01 https://github.com/inexorabletash/indexeddb-promises 10:50:20 … IndexedDB predates promises, but has things that look promise-like. 10:50:43 … but uses events rather than true promises. 10:50:52 … So what should we do in the future? 10:51:12 Present+ Jatinder, Nolan, ALi 10:51:31 … The rest of the platform is getting promises, it would be nice. 10:52:18 … Issues - transactions commit automatically when there is no more work - measured by events and what happens. That's hard with promises. 10:52:43 … Naive wrapping in promises would have surprising consequences for developers. 10:53:07 … Look at the issues - documentation has them noted. 10:54:05 … Feedback on making requests thenable says that you either throw or return error, not both. 10:54:24 DC: Wouldn't pattern be "return rejected promise"? 10:54:49 JB: This would be the current version, that throws the wrong error instead. 10:55:42 … So this is not so controversial… 10:56:00 DC:If I pace a thenable to race or all does it work? 10:56:10 JB: yep. 10:56:55 … doesn't look like we have other things that have thenables in the platform. 10:57:50 … How do you extend around the promise chain. Idea was to look at things that have .waitUntil - this seems feasible for transactions 10:58:05 … adds additional states but that's plausible. 10:58:31 The design of transactions ws meant to stop holding one open forever 10:58:42 s/The/… The/ 10:59:04 … we would be making it far more likely that you could make the mistake. 10:59:21 … Is this a non-starter? Do we need to worry? 10:59:38 AA: What is the use case? 11:00:14 wilsonpage has joined #webapps 11:00:23 Nolan: FileReader. This is common and awkward now - done outside the transaction. 11:00:23 AA: What's the alternative 11:00:28 Nolan: Can be done. 11:00:48 JB: No atomicity. You invent it.. 11:01:50 … harder - you can have a series of HTTP transaction waiting for something 11:02:29 AA: Does waituntil + promise fit naturally? 11:03:04 Nolan: It is surprising the transaction would commit automatically. 11:03:20 … but think the explanation is reasonable. 11:03:20 q+ dcooney 11:03:35 … what's the use for .ready? 11:03:47 JB: It was a way to get around not making things thenable. 11:04:11 Nolan: reads better without it... 11:04:22 ack dc 11:04:49 DC: You're copying service worker and it has a @@ event. 11:05:14 … what about another overload for transaction, turning them into a promise… 11:05:32 … would a single promise be a feasible approach? 11:05:46 s/@@/extendable/ 11:06:05 SW: doesn't take a promise in SW? 11:06:32 DC: No, you disclose something to the system, you can call an event or return a promise. Is there a difference in ergonomics? 11:06:51 JB: No immediate reaction… 11:07:24 … that would be an alternative to create a transaction and call waituntil… 11:07:39 … so pass function to transaction? 11:07:43 DC: Yep 11:07:59 JB: Interesting. Will play with this. 11:08:24 Nolan: #6 - handling errors but avoid aborting. Seems bad design 11:09:15 … we put things and handle an error. Here we have to handle each error which is a pain 11:09:27 … could you opt out of transactions auto-aborting? 11:09:45 JB: Not sure we wnt to do that - other bugs will get lost. 11:10:01 AA: What about resolving the promise? 11:10:09 … with the error catchable. 11:11:05 JB: Where there is an error we reject and say there is an error. SO how do you want to get that info and react to it? 11:11:39 AA: Is this a deal-breaker? 11:11:48 Nolan: Think it is a serious question… 11:12:11 … adding promises might be putting lipstick on a pig. 11:12:33 … developers just want key values in many cases without blocking. 11:13:09 JB: This is a common enough request that there are libraries. 11:13:40 AA: IDB is pretty low level - does it make sense to build promises on it? 11:13:54 SW: We have not got requests to add promises. 11:14:12 … most people using IDB aren't using it diretly and don't want to. 11:14:35 AA: Original idea was frameworks would build on this. Didn't happen early on, but now we see a ton of them. 11:15:08 Nolan: People who do database-stuff are frustrated that IDB is too *high*-level. 11:15:35 AA: We should see if frameworks are enough for people. 11:15:54 … seems like we are forcing this - perhaps better not to do that. 11:16:15 JM: What if we started again? 11:16:24 AA: Developers get grouchy… 11:16:43 JM: I mean instead of improving IDB, we do sometning else, 11:17:12 Josh: Your async proposal look easier and simpler than indexDB. 11:17:13 https://github.com/w3c/IndexedDB/issues/91 11:17:24 Topic: Issue 91 11:17:55 … feedback brings requests. 11:18:47 JB: What if we had anonymous object store for free, said Jonas... 11:18:52 … in parallel, this: 11:18:52 https://gist.github.com/inexorabletash/280016e79188b6a28247 11:19:23 … (not a serious proposal yet) 11:20:06 … can complicate everything by having two ways to do everything. 11:20:32 AA: in favour of this we see people use caches instead of IndexedDB 11:20:48 … because it is transactionless. 11:21:06 … So it looks like people want that 11:21:27 Nolan: Agree. In service workers, devs will use the cache API instead of IDB 11:21:44 JB: Looking forward to the implementation and feedback :) 11:21:48 AA: Looking at it. 11:23:30 https://github.com/w3c/IndexedDB/issues?q=is%3Aissue+is%3Aopen+label%3A%22spec+issue%22 11:23:39 JB: Issues are on github, tagged [nicely - ed.] 11:24:24 … made a v2 milestone. Trying to get v2 done early next year, not planning on making additions like observers/transactionless/promises and get to something like a yearly cadence on the spec. 11:24:41 Are any issues OK to leave unresolved in v@ 11:24:49 s/v@/V2 11:24:56 s/Are/… Are 11:26:45 [step through issues] 11:27:03 SW: on #85 making DSL iterable is the more forward-thinking approach. 11:27:57 JB: Spec didn't say which errors to test in what order. Not critical most of the time, but we wanted to fix that. 11:28:22 … think we have ordering pretty much aligned. But they can be changed if someone has an objection 11:28:28 SW: Are there WPT for ordering? 11:28:38 JB: Some, we are planning to give more. 11:28:59 … Issue #10 is potentially puntable. 11:29:45 … it's handwavy and feedback would be nice. 11:30:14 smaug has joined #webapps 11:30:18 TL: This was discussed in WebIDL session, maybe something coming to help describe a private slot. 11:30:55 AA: Please look at the feature requests and comment on them. 11:31:01 https://github.com/w3c/IndexedDB/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3A%22feature%20request%22%20 11:38:17 smaug has joined #webapps 11:59:24 smaug has joined #webapps 12:10:39 dom has joined #webapps 12:16:53 smaug has joined #webapps 12:26:06 RRSAgent, make minutes 12:26:06 I have made the request to generate http://www.w3.org/2016/09/23-webapps-minutes.html xiaoqian 12:31:04 chaals has joined #webapps 12:31:57 jamesn has joined #webapps 12:32:34 aliams has joined #webapps 12:36:13 Topic: Directory… 12:36:21 Present+ Smaug 12:36:26 agenda recap: https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-09-23TPAC-4.md 12:36:53 AA: History recap - MS and Mozilla were looking at something for directory upload. 12:36:55 https://wicg.github.io/directory-upload/proposal.html 12:37:18 … option on the table then was filesystemAPI, implemented in blink. But a year before that we had decided to discontinue that. 12:37:40 rniwa has joined #webapps 12:37:56 … had security issues, no traction, nobody was sure it was needed, … 12:38:03 Present+ Sangwhan 12:38:28 … So we thought about a new API, put Directory Upload into WICG. 12:39:11 … Tried to modernise it, promises, fix some sync issues from the filesystem API… 12:40:34 … About 10 months ago MS were getting internal heat to support this. Spec hadn't reached consensus. 12:40:48 kawai has joined #webapps 12:40:53 … We implemented subset of filesystem API in blink, Mozilla has done that too. 12:41:24 … We started looking at documenting that, in Entries API. 12:41:24 https://wicg.github.io/entries-api/ 12:41:58 JB: We had a spec that had gone through Webapps / platform, it didn't provide details. But given 3 implementations we should have a spec. 12:42:28 AA: So we can start by documenting what is there, and solve some more problems. 12:42:51 … plan is to discontinue work on the new API and work on the thing we actually implemented. 12:43:02 JM: makes sense 12:43:47 … we saw issues with existing API, tried to evolve it. Sounds like we can now freeze this solid which sounds bad, continue the other spec with two implementations, or evolve the existing implementation. 12:44:00 Smaug: We basically implement both, so we don't mind. 12:44:30 tomalec has joined #webapps 12:44:34 JM: Implementing the new one is pretty much the same under the cover for most code. 12:44:46 Smaug: The new one is a way nicer API 12:44:55 JM: Would there be any issues with that? 12:45:02 jcraig has joined #webapps 12:45:20 Smaug: Maybe we can improve entries enough to be nice. 12:45:29 JB: Nobody has a proposal for that yet. 12:45:41 AA: Fear is maintaining two different API surfaces. 12:45:58 Smaug: it really didn't take time to write entries on top of the other one. 12:46:16 JM: I am not concerned as implementor. More interesting question on the developer side. 12:46:32 … there are other examples of doing that before. 12:47:00 … no strong pref but we may get limited in how we can evolve the existing one. 12:47:22 AA: We were aware of that. So is it easier for developers if there are not two versions? 12:47:57 [is there enough transition benefit?] 12:48:13 JM: Can we evolve the existing one to be async? 12:48:21 AA: maybe, but it would be hard. 12:49:22 JB: .files is a small, but unfortunate part of the API - can we make a parallel piece for that and steer developers away from it? 12:50:26 ericc has joined #webapps 12:50:36 Smaug: we have a webkit-prefixed API - but webkit doesn't implement it. 12:50:44 kinjim has joined #webapps 12:51:02 AA: The idea is that if you're abandoning the name, you can move to a different API anyway. 12:52:26 JB: Can leave prefixes there, we can ship a non-prefixed version and commit to it, or we can improve the behaviour by reserving the unprefixed names for a better future… 12:52:51 LJWatson has joined #webapps 12:53:05 Smaug: people expect the webkitdirectory attribute should work the same as directory. 12:56:33 JB: We could move this into File API 12:57:15 … we need hooks in there, because we monkey-patch it a bit. 12:58:09 … If people think a separate spec is fine, that's fine. 12:58:22 Smaug: This thing is very difficult to test. 12:59:05 AA: Tried building webdriver tests for this, and you have to fake some stuff. You can't drag around the file system. 13:01:01 CMN: Are manual tests reasonable to do? 13:01:13 JB: I actually have that for most stuff. 13:02:03 Smaug: [horror stories of corner cases - that will happen to people] 13:03:04 JB: Please feedback on the bugs, but maybe we should just go-ahead and add non-prefixed aliases 13:03:25 AA: Are we going to ahead with this API, or do we want to take on a new one. 13:04:03 RESOLUTION: Let's hold off on unprefixing until we decide whether to evolve the current API or move to the new spec. 13:04:24 AA: I will look at whether we can make the old spec either nicer, or let us implement the new spec on top. 13:04:41 … main problem will be .files - although we may have that problem in the new one too. 13:05:04 … we were looking at not populating .files unless called. 13:05:13 AlexD has joined #webapps 13:05:23 jcraig has joined #webapps 13:05:46 plh has joined #webapps 13:06:15 Topic: Directory download 13:06:22 https://github.com/drufball/directory-download 13:06:39 JB: came out of a chat to Jonas (hi Jonas! -ed.) 13:06:50 … today you get zip files for downloading. 13:07:26 … haven't done any implementation work, but we have a proposal for navigator.saveDirectory([files]) 13:08:17 … This is a frequent request from developers… 13:08:34 Smaug: I like the first proposal - the other one doesn't quite work. 13:09:16 … How to show the user what is happening - clarify that you're getting a whole directory structure, not just a file. UI issue. 13:09:29 JB: Not sure about how to do this where there is no folder system. 13:10:17 Smaug: Would be good to get some feedback from Apple 13:11:09 https://github.com/WebAudio/web-midi-api/issues/165 13:11:38 oops, wrong channel 13:12:05 CMN: a lot of the use cases for directory do require the structure to be preserved :S 13:12:23 Topic: Writable files 13:12:24 https://github.com/wicg/writable-files 13:13:31 JB: So it makes it hard to make an editor… 13:14:06 tantek has joined #webapps 13:14:12 … technically not that hard. There was one in Chrome Filesystem, but we probably want a nicer newer one. 13:14:33 … the interesting bit here is the permission model. And the UI for that. 13:14:51 … should permission be persistent 13:17:05 CMN: Opera had one of these a long time ago - as part of Unite. You don't want to give permanent permission, and long-standing permission is scary for security. The UI stuff is indeed complex compared to the functionality. 13:17:17 Smaug: I do think we need the feature. 13:17:41 JB: Not expecting to solve this here... 13:17:43 present? 13:18:26 nainar has joined #webapps 13:18:43 AA: We only have this on app platforms - you give implicit permission by deliberately associating actions with an app, and we think that's probably OK for the Web 13:19:31 JB: What happens in the case where you edit the file in between two accesses from the Web - does that block permission? 13:19:41 DC: Are there performance issues? 13:20:14 [write time, and access permission] 13:21:37 JB: Are there other things in the filesystem space? 13:21:52 Smaug: Sometimes you want to create a new file, this doesn't cover that. 13:23:30 [Break until 2.45] 13:24:23 Also the "writable directories" scenario, i.e. to let you implement a git client 13:25:31 [or a photo manager or a zillion other things…] 13:28:33 tantek has joined #webapps 13:45:19 chaals has joined #webapps 13:45:54 Topic: The exciting bit! 13:46:04 LJWatson has joined #webapps 13:46:27 Topic: charter 13:47:03 LJWatson has joined #webapps 13:47:17 CMN: We have a charter open for review until the end of the month. 13:47:39 Charter: http://w3c.github.io/charter-html/group-charter.html 13:47:45 ... we have dropped some specs like Fetch, URL and XHR. 13:48:07 ... DOM remains, but it is an interesting challenge. 13:48:16 TL: Will we publish? 13:48:20 CMN: Yes, probably. 13:48:38 JB: We should replace File System with Entries API. 13:48:48 ACTION: chaals update the references around Filesystem in the charter 13:48:49 CMN: Yes. 13:48:59 bkardell_ has joined #webapps 13:49:24 DC: We should leave HTML Imports. 13:49:55 Smaug: Don't think we're likely to have that spec ever. 13:50:22 TL: There are conceptual similarities. 13:50:38 CMN: Names are not important but if we're on the hook to work on it, that's ok. 13:51:02 rrsagent, make minutes 13:51:02 I have made the request to generate http://www.w3.org/2016/09/23-webapps-minutes.html LJWatson 13:51:42 BK: So no objection to the thing? 13:51:54 Smaug: No, but calling it HTML Imports seems unlikely. 13:52:07 DC: It's a way to use HTML documents in HTML documents. 13:52:33 JB: No interest in pursuing Quota Management API. 13:52:38 ... Can be removed at no harm. 13:52:41 dbaron has joined #webapps 13:52:52 DC: No interest in Find Text? 13:53:00 CMN: No. Interest but no traction. 13:53:58 CMN: We can also recharter... proposed charter runs until 2018, but if something new comes up we can recharter before then. 13:54:15 scribenick: LJWatson 13:54:36 CMN: PubStatus... 13:54:58 https://www.w3.org/WebPlatform/WG/PubStatus 13:55:31 ... specs divided between the three chairs. 13:55:56 ARIA in HTML is ok 13:56:05 HTML AAM is a recent transfer into WebPlat. 13:56:23 HTML Extensions Note is a collecting place for things relating to HTML. 13:56:30 HTML5.1 in PR, nearly done. 13:56:45 HTML5.2, FPWD, need to kick it into action. 13:57:06 Using ARIA in HTML Note, is ok. 13:57:21 LW: Have filed issues to change the name of the note to avoid confusion with ARIA in HTML. 13:57:53 BK: ARIA specs are confusing. 13:57:59 CMN: DOM, is a problem child. 13:58:16 DOM Parsing and Serialisation, needs a kick. 13:58:26 TL; It's ok, have some issues and a test suite. 13:58:40 CMN: File API, hasn't been a success. 13:59:08 ... Recently have a new editor to help Marin. 13:59:27 rrsagent, make minutes 13:59:27 I have made the request to generate http://www.w3.org/2016/09/23-webapps-minutes.html LJWatson 14:00:12 JB: Open issues against File API are gnarly. 14:00:25 ... Not about defining new behaviours. 14:00:33 ... just spcifying the way things are. 14:01:03 CMN: File System API, bounced to incubation. 14:01:11 Find Text API, off to incubation. 14:01:39 Gamepad API, ok, but looking for an editor. 14:01:46 IndexedDB, discussed earlier. 14:01:54 Packaging on the Web, off to incubation. 14:03:22 Pointer Lock, in PR. 14:03:43 Push API, ok. 14:03:51 LW: Swapping out editors. 14:04:18 CMN: Screen Orientation API, needs attention. 14:04:26 Service Workers, is ok. 14:04:32 Streams, dropped. 14:04:44 UI Events, discuss later. 14:04:52 URL, dropped. 14:05:01 Manifest, is ok. 14:05:07 Web Sockets, sitting there. 14:05:26 Web Workers, new editor and it's been kicked into life again. 14:05:34 WebIDL-1, in PR. 14:05:39 XHR, is dropped. 14:05:48 rrsagent, make minute 14:05:48 I'm logging. I don't understand 'make minute', LJWatson. Try /msg RRSAgent help 14:05:56 rrsagent, make minutes 14:05:56 I have made the request to generate http://www.w3.org/2016/09/23-webapps-minutes.html LJWatson 14:07:03 Custom Elements and Shadow DOM are ok, but need attention, HTML Imports is in incubation. 14:07:19 Clipboard API is ok. 14:07:45 Static Range needs adding to PubStatus. 14:08:05 GK: It's too generic for Input Events. 14:09:21 Then the old tings in maintenance with nothing happening. 14:09:37 TL: Canvas? 14:09:48 CMN: Tried to hand it off to someone/anyone during charter. 14:10:00 ... Possible it should be updated. 14:10:09 ... We'd need a volunteer. 14:10:36 Communication... 14:10:46 Using Github, the email list. 14:10:58 If we do send things to email people complain, and others complain if we don't. 14:11:05 We'd like to know what we can do better. 14:11:40 ... We don't do many CFCs because the general model has been implement, then revert if there is a problem. 14:12:05 ...We've been experimenting with using a GH issue on the spec to gather responses to the CFC. 14:13:10 LW: Anyone here think using GH issues for CFCs is a bad thing? 14:13:16 ]silence] 14:13:35 rrsagent, make minutes 14:13:35 I have made the request to generate http://www.w3.org/2016/09/23-webapps-minutes.html LJWatson 14:14:06 garykac has joined #webapps 14:14:42 Topic: WebIDL 14:15:11 Tobie: started working on the WebIDL spec, spent summer putting it into bikeshed and now it looks nice. 14:16:04 AlexD has joined #webapps 14:16:05 … had a good session on Wednesday going through the work to prioritise. I expect to be on this about 50%, if you have things that you need, ping me. 14:16:23 … and wait for me to learn the spec and understand what you are talking about ;) 14:16:52 … would like to have continuous publishing for this. 14:17:26 ljw: need to move to W3C repo 14:17:40 YL: We can set that up without that. 14:18:07 Tobie: Hopefully I will have the publishing set up soon. 14:19:45 Florian has joined #webapps 14:20:00 … FPWD should be feasible more or less now. 14:23:54 [break until 4pm] 14:24:47 ericc has joined #webapps 14:25:31 Florian has joined #webapps 14:35:54 jcraig has joined #webapps 14:39:46 Florian has joined #webapps 14:46:38 jcraig has joined #webapps 14:55:00 jamesn has joined #webapps 14:58:54 wilsonpage has joined #webapps 15:01:01 chaals has joined #webapps 15:01:56 IanPouncey has joined #webapps 15:09:29 Topic: UI Events -- what we need to know. 15:09:36 Scribe: Travis 15:09:36 MichielBijl has joined #webapps 15:09:43 present+ 15:10:21 gary: we broke out two specs: key and code from UI events. 15:10:31 .. They are basically done. 15:10:40 .. UI Events still needs work 15:10:44 .. to formalize 15:10:49 .. fix a few bugs 15:11:03 .. do some testing 15:11:31 .. we have a lot more testing to do. Will stick with manual test for the keyboard. 15:11:42 .. Webdriver won't support what we need in the near tearm 15:11:47 s/tearm/term 15:12:09 .. any Qs? 15:12:23 chaals: are you confident that you have sufficient tests? 15:12:37 gary: focused on keyboard tests and only English & French. 15:12:58 .. mouseevent tests are coming (someone else at Google) 15:13:06 .. we think we will be in good shape. 15:13:25 .. I don't believe we have enough tests now, but we will... 15:13:32 .. I'll stop when I get tired. 15:13:43 .. Almost everything in UIEvents has shipped. 15:13:53 .. Can we convince browsers to normalize when necessary. 15:14:18 .. If it's too much change, we may need to fallback to documenting odd behavior. 15:14:32 .. hopefully not though. 15:14:58 .. Next 1 year will focus on testing and re-writing. 15:15:14 .. If not wholly algorithmic, then much closer. 15:15:34 .. By next TPAC would like to say "we have god test coverage" 15:15:52 smaug: I need to ask Masayuki if he can add more tests 15:16:08 AlexD has joined #webapps 15:16:13 gary: yes, you have so many dependencies (keyboard layouts, etc.) 15:16:17 .. mobile is easier. 15:16:23 JFSIII has joined #webapps 15:16:31 bkardell_: haven't been following, but 15:17:14 .. person I mentored was pointed at MDN for some keyboard event handling. 15:17:35 .. said don't use keyCode; but key isn't implemented everwhere. 15:18:29 gary: key has lots of shims, waiting for Edge to get their act together and fix key and add code. 15:18:40 s/code/the code property 15:19:15 bkardell_: It's weird to say things are deprecated but there's no replacement. 15:19:39 Florian has joined #webapps 15:19:42 .. MDN shows cross browser tables. 15:20:00 .. was wondering if there was a reason for the omission. 15:20:33 chaals: Agenda:... 15:20:44 gary: system keyboard lock.. what is it? 15:20:56 .. want web platform to do more desktop app stuff 15:21:03 .. OS consumes a bunch of keys. 15:21:18 .. some web apps need to get all the keys to work properly. 15:21:24 .. like in remote access. 15:21:36 .. like having access to the ESC key. 15:21:51 .. This proposal lets the web dev request the set of keys that are desired. 15:22:00 .. Current version is only for full-screen. 15:22:32 wilsonpage has joined #webapps 15:22:43 travis: smart alek remark about blocking full-screen escaping... 15:22:54 gary: [rolls eyes] 15:23:32 smaug: not sure long key press can be discovered... 15:23:42 gary: OK, I guess you need a dialog. 15:24:03 chaals: seems bad for accessibility, esp. if restricted to full-screen. 15:24:23 gary: idea is that you've entered into the app and you don' want to leave. 15:24:57 .. immersed in the game, with pointer lock, etc. You don't want to fall-out on accident. 15:25:15 .. you don't want to think about local user controls. 15:25:25 [chaals thinks... slowly] 15:25:50 chaals: If you go into gmail, the fullscreen and take over your keyboard... 15:26:01 gary: You'd need to grant permission of course. 15:26:17 chaals: I'm worried that apps start doing this as a default thing. 15:26:33 s/slowly/sloooooooooowly/ 15:26:33 gary: this is why we're restricting to full-screen. 15:26:57 smaug: you want some keys to get you out (like Alt-Tab) (app switch) 15:27:32 gary: if you're on a mac, remote-ing to a PC, you want to use PC commands. 15:27:56 chaals: we this, we encourage folks to mess up their keyboard accessibility! 15:29:04 gary: ctrl+alt+del -- yeah, you'll probably never get that. 15:29:34 [side conversation about how to kill mac apps] 15:29:53 gary: the API is made to request which keys you want. 15:30:05 .. earlier version let you request them all. 15:30:28 .. we opted to specify so that it could be more opt-in. 15:31:09 travis: is there a use case for the reverse scenario. 15:31:11 ? 15:31:48 .. like not getting keys? 15:31:59 gary: that's ridiculous. 15:32:04 travis: yeah. 15:33:01 smaug: it is a proper permission? or more like fullscreen, where it just allows it? 15:33:15 gary: well, it could default either way... 15:34:11 .. we think providing the key list is best. 15:35:03 smaug: I suspect users may not want to see so many permission requests for fullscreen + this feature--will lead to more fullscreen use, which will be worse for accessibility. 15:35:13 chaals: new idea: (you'll hate) 15:35:24 .. when you request the keys you have to give them a label. 15:35:31 .. the label is "what you want the key for" 15:36:45 .. a map that redirects one key to another. 15:36:52 gary: not sure it fits with this. 15:37:01 .. or how it affects the concerns 15:38:25 gary: what else could we do to reduce abuse? 15:38:31 chaals: make it work sometimes only. 15:38:44 gary: well, permission (up to UA on style)... 15:39:00 .. how to discourage use unless there is a need? 15:39:54 .. we want to secure this so it doesn't get abused. 15:40:28 chaals: seems very useful; scares me to death. 15:42:59 gary: use case for windowed--huge monitor, don't want to go full-screen. 15:43:13 smaug: the security concerns here may be troubling. 15:43:25 chaals: makes it more easy to "phish" 15:44:28 gary: any other comments? 15:44:36 chaals: If you put it out there... 15:45:04 .. it's 1) either crap, or it 2) works and everyone implements and its ubiquitous. 15:45:20 .. there's a world where I want to be able to do this. 15:45:37 gary: we want our web-based native-like apps do this. 15:47:14 .. for mobile it may be more tenable to send the right keys across; desktop is harder due to people's muscle-memory. 15:52:23 wilsonpage has joined #webapps 15:53:27 smaug: I think it's less-scary in non-fullscreen mode (the user can switch apps and escape) 15:54:31 .. also, how do you escape from fullscreen on mobile? 15:54:46 gary: there's a persistent UI affordance 15:55:03 .. but you're thinking of the non-nice people... 15:55:30 .. with permissions, e.g., allow-listing certain sites by default. 15:55:53 .. that concern mitigation could be applied. 15:56:05 .. wouldn't prefer that. 15:56:11 .. and not reasonable to spec. 15:57:33 travis: make sure its behind secure context. 15:58:37 chaals: I think it's worth playing with. (I'm thinking of other problems.) 15:59:30 [chrome has tried various features that their security team shot down] 15:59:41 gary: I think permissions does everything you need. 15:59:54 smaug: please consult Mozilla security folks too. 16:00:47 garykac has joined #webapps 16:00:55 Link to system keyboard proposal: https://github.com/jondahlke/system-keyboard-lock/blob/master/EXPLAINER.md 16:01:02 https://w3c.github.io/uievents/ 16:01:53 ^ UI Events spec :) 16:03:04 WICG discussion: https://discourse.wicg.io/t/proposal-system-keyboard-lock-api/1594 16:09:51 chaals: Thanks everyone! We are done. 16:10:22 IanPouncey has joined #webapps 16:28:30 wilsonpage has joined #webapps 16:37:26 smaug has joined #webapps 17:12:04 RRSAgent, make minutes 17:12:04 I have made the request to generate http://www.w3.org/2016/09/23-webapps-minutes.html xiaoqian 17:12:08 RRSAgent, bye 17:12:08 I see 1 open action item saved in http://www.w3.org/2016/09/23-webapps-actions.rdf : 17:12:08 ACTION: chaals update the references around Filesystem in the charter [1] 17:12:08 recorded in http://www.w3.org/2016/09/23-webapps-irc#T13-48-48