IRC log of webapps on 2016-09-23

Timestamps are in UTC.

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