TPAC HTML, IndexedDB, Directory Upload, UI Events & WebPlat -- 23 Sep 2016

<dcooney> present?

<dcooney> Zakim: present?

<dcooney> scribenick: dcooney

<scribe> scribe: dcooney

<tantek> good morning (from IRC)

<tantek> chairing #social web wg this morning, will lurk here

AlexD: notes domenic and annevk are absent

whatwg

AlexD: We want to talk about whatwg HTML, W3C html, and compatibility and what the editors are doing.

the similarities are larger than the dissimilar between whatwg and w3c

we love HTML and the web

and we want the best specs possible

but the process is differeent

developers want low-friction

But we as company representatives need the W3C protections--patent exclusion periods.

Has anyone here in the W3C process had anything to do with patents?

Whether someone has blocked a feature or been involved in a panic.

(Note 5 hands.)

chaals: 6 maybe didn't rais their hands.

AlexD: W3C specs get the royalty free commitment from other companies. This isimportant so Google can ship chrome.

Steve, Travis, Aaron (absent) have to manually triage changes to the spec, decide if it is relevant and manually edit.

It would be nice if the community sent us pull requests.

So we don't have to manually do the work.

The living standard does not reflect reality.

The WHATWG is aspirational future; the W3C spec is what's interoperable.

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.

Browsers don't ship that interoperably.

How can we do this better?

Edtiors have a montthly meeting to triage changes. It's time consuming, formalizing what's in W3C, and doesn't improve HTML per se.

SteveF: I'm also one of the editors, since before HTML5 was pushed to REC.

I work on the HTML5 spec and iterations differently.

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

I work on modifying and updating that to reflect reality and provide guidance to authors to benefit users.

I have in the past filed bugs against the whatwg spec; I've had limited success in getting changes made in the whatwg spec.

Because there's philosophical differences.

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.

I also work on normative conformance requirements for validators; for example with mike smith on the W3C validator.

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.

The whatwg and w3 specs were similar recently but with a warning that it was not implemented.

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.

do.

That is reflected in the W3C validator.

There's quite a bit of variance in this information in the W3C spec and whatwg spec.

It's not necessarily bad, but it is not my job to follow the WHATWG spec because it does not reflect reality.

Florian: There seems to be multiple kinds of differences.

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.

That is not of interest to W3C.

WHere things don't reflect reality as it already exist, I'm confused because the WHATWG says they want to match reality.

Why can't we agree on what reality is, excluding the reality.

chaals: What WHATWG is out of scope.

Florian: If we were starting from scratch I prefer W3C for patent and process reasons.

It's key to understand what they do to see if we can agree, should try, who's irrelevant.

The charter says we should minimise the difference.

MarkVickers: The opening statement was the most succinct summary I've heard of the motivations and situation.

Having low friction makes decision easier and W3C provides the pattern protection. I see why Google would want that.

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.

chaals: There are aspects beyond IPR.

Technical compatibility with things WHATWG do that are interoperable as a priority.

WHATWG has things that aren't interoperable.

We have incubation for that; we don't put it into a HTML recommendation.

It's odd to lose it. If WHATWG does things that aren't interoperability that's outside our purview.

THere are reasons outside IPR, such as antitrust.

That's important part of the process.

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.

WE would do that in incubation.

AlexD: At past companies, we donated our royalty free patents into the standards for the purpose of building products that used the W3C standards.

It provided an effective defense.

Take JPEG for example, a submarine patent came along and (company) extracted 700 million dollars from others.

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.

That's why people participate. Is that why you're asking?

MarkVickers: No.

We vere a member of HTML5 for years and other groups, but we have some participation with some other groups.

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.

I have a problem being no citizen and having no input.

chaals: That doesn't happen. It used to maybe be a bit like that but we exercise editorial control now.

Travis: I will not talk about patents.

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.

That creates a tension for implementers and the community. They have equivalent content.=

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.

Is there an opportunity to differentiate the WHATWG and W3C version by changing the focus/target audience.

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.

That allows the vendors to focus on one spec and web developers to focus on another.

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.

chaals: Pretty much nothing is entirely true in the details.

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.

Look at what's implemented, going to be implemented, and give focused advice to developers on how to implement.

I think it is a good idea.

One thing I don't understand, if we do it that way without incorporating the implementation stuff, then what happens to the IP protections?

<Zakim> dsinger, you wanted to talk about target audiences and spec. style

dsinger: I have also wondered why it was optimized for the smallest audience--implementers--and not the large audience of developers.

Pseudo-BASIC is unreadable.

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.

Florian: 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. It creates confusion and friction.

Probably the W3C spec etc.

chaals: THere are two orgs working on HTML. Our only solution for that is to stop working on HTML.

We could easily do that.

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.

To answer dave's q, where there are differences--technical differences--we need to provide the implementer and developer facing parts of the spec.

What I understood from travis was developer oriented text instead of implmenteer oriented algorithms would be easier.

Essentially implementers would go to WHATWG, unless there's a technical difference which we'd have it our spec.

For people who want to know what a list element does and how you use it is easier to read ...

chaals: queue will be closed

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.

Having the same information in the HTML spec at the W3C spec, faithfully rendered, but not displayed to everyone.

AlexD: The incubation process is a solution to thisp roblem.

WHATWG runs along with new stuff every day.

But if they are new features, they should be incubated, then ported over to the W3C spec.

So chunking via incubation may be the way to go instead of porting small patches.

olivier: One of the things I heard earlier is that the value that W3C creates is about interop, testing, licensing and outreach.

I note that none of this is related to editing a spec on a daily basis.

scribe:

(sic)

plh: My problem is I have 38 groups, chairs, team contacts coming to me wanting to know which specs to reference.

Some groups can reference a W3C spec they need.

Director approved a spec called secure context that can reference both specifications.

<Florian> +1 to plh's points

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

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.

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.

It's admirable to helping web developers understand.

But vendors need a way things work to make it interoperate.

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

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.

On a technical level, W3C documents are harder to work with.

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.

That impairs trust because I'm not sure if the changes mean the same thing because all the features are interrelated

Even if the changes are just moving a section to a new document.

So changes are hard. As a result I work in WHATWG.

That has political and interpersonal implications. It's not personal, but it is easier to work with WHATWG.

Multiple documents for different audiences is a good idea but don't replace the technical documentation.

<MarkVickers> All W3C documents would be easier to change if we only had one or two companies in W3C.

chaals: Some of the assumptions and ideas we're testing--should we strive for compatibility with WHATWG spec?

Of those who responded, it's a goal.

Should we strive to make a more web developer oriented document? Or try to keep the algorithms?

Olivier: Is that a dichotomy?

chaals: Not necessarily, just want a sample of interested people.

We will take guidance from this.

dsinger: replace our normative document with something for the web developer?

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?

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.

chaals: Not relevant

Olivier: Relevant! It's a twist on your question.

chaals: Is throwing away the algorithm stuff a step backwards?

Everyone thinks it is a step backwards.

garykac: With caveats

chaals: Should we be putting focus on a web developer focused document?

cwilso votes it is a waste of time, others vote editors should do this.

SteveF: Why do you object, cwilso?

cwilso: The question you were asking is the wrong one.

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.

Sooner or later this has to resolve.

The answer isn't pulling the technical information out of one. I could write a book that is the technical guide to HTML.

The question has to be, where do web devs and browser engs go to understand the spec?

chaals: W3C has one mechanism available today: unilaterally stop work.

Who thinks that is a good idea?

It's not like nobody thinks it's a good idea. Who thinks it's a bad idea? A number.

Olivier: Who thinks something inbetween?

(hands)

chaals: So the question is how do we minimize the pain of this insane situation.

We could come back to this topic later.

Let's look at incubation.

incubation

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.

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 WICG. That is what we have been doing when people file bugs.

crosstalk about pronuciation

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.

HTML has a formal consensus mechanism but no experimental playground.

We need to find a way to do this.

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.

Don't incubate crazy experiments in a WG. Transition from CG to WG is when you demonstrate consensus.

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.

Florian: The transition from incubation into WG is not automatic.

The CG membership may not transition into the WG.

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.

chaals: Am I hearing as HTML chairs, what you should be doing, is push people ready to make the transition against the consensus wall.

cwilso: Your concern is not unfounded. To prevent that there's two things it the design:

It's better than the status quo because there's some IP commitment from contributiors.

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.

What will happen is we'll have groups manage and maintain specifications.

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.

I don' think you'll end up with top down forever specs in WICG because you want the patent commitments.

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.

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.

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.

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.

Break time.

Back in 15 minutes.

olivier thank you for pointing out that error, I think I fixed them but please sanity check me

<garykac> scribe:garykac

plh: I don't want to spend more than 10 min

editors made changes to spec, and some people were surprised and we had drama.

how do we make sure that the commnunity is aware of the changes being made

we have many repos

anyone following github, knows that it is a firehose of info

dsinger: would like a way to track what is going on

easy to miss big decisions

chaals: (referring to specific decision) did not feel that it was a big decision

don't feel that we've made a lot of big decisions

i'm aware that we need to make sure people are aware of what we're doing

yes, we know we need to do better

concrete ideas for improvement would be great

dsinger: a small decision that took months to arrive at, it not really a trivial decision.

don't want to rat-hole. that decision is done and over

travis: i18n had a similar concern

they want to be aware of relevant changes

they added a label so they can track changes across repos

chaals: more on that topic?

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.

<dcooney> present?

it wasn't done out of malice. just part of the job as editor

leonie: how can bwe make CSE more obvious

we have emails

how can we surface them more to give visibility?

travis: we (editors) have wondered how long to wait for additional commentary with PRs

as a rule of thumb, decided on about a week

is there more of a process that we could follow?

about the longdesc issue

chaals: DONT TALK ABOUT LONGDESC
... for 5.1 , we assigned issues to milestones to make them easier to track

instinct is that we should do that again

its useful for editors to organize their work but also for people following at home

let'

s kill this discussion

now... modulatization

travis: all right

i've been asked to talk about elephants in the room

differences between WHATWG and W3C will cause strain for anyone reading

putting that aside

we still have interesting things to discuss

(1) is modulatization stiil a good idea?

chaals: show of hands...

majority in favor, with some dissent

sam: not easy question to answer as asked

when making any change you nee to look at the goals, and the effects on the process

we don't want to have 2 specs

having any discussion on this topic needs to start with goals and how it relates to reality

travis: thanks, that relates to why

we need to put aside notion that we can chop it into chapters and publish each one

it's a lot of work refactoring with contracts between the different parts

the current spec is kinda like spaghetti code with the inter dependencies

out goal should be to publish the stable parts as stable documents

and non-stable stuff in different documents

script is another example where we're still digging into how/why it works, so it's more likely to change

we should pull out the stable parts

to shrink the cognitive load for people reading the spec.

dsinger: agree

doing modularization has a fair amount of homework

there's also political work to do.

we should talk to the WHATWG groups as well

if they could do some modulatization, then we could just refer to that

and simplify work for everyone

leonie: i'd like to head from steve since he's been through some of this with aria

steveb: the bit I did was fairly simple to do because it was self contained

also it was something that I understood

what I'

we are struggling to keep up with the main HTML spec

this additional work will require additional reqources

no point talking about it if we don't assign resources

oliver: if it's a lot of work and we're not sure about the benefit, then we probably shouldn't do it

<olivier> (doesn't seem to really benefit either web devs, nor editors... maybe implementors?)

chaals: in principle I like it because 500 page specs are hard to manage

"cutting spaghetti with scissors doesn't change it being spaghetti"

as steve sez: without resources, it doesn't matter if it's a good idea or not.

dspringer: how often to people use the single-page version vs. multi-page version

that would be useful info

<Zakim> dsinger, you wanted to ask a statistics question

alexb: I support modularization because the burden on editors is massive. this would help manage the problem

travis: agree with dsringer, it would be nice to get that info, but note that WHATWG default is single-page, but W3C default is multi-page.

dominic: I always use the single page

hypothecally, let's say we modularize and we have stable and non-stable parts

how will smaller unstable specs (which require unstable hooks into stable parts) get added without making the stable parts unstable?

travis: we have that problem already

dominic: that sounds like a problem

AlexD: we have that with canvas, and we just have to be pragmatic. we can "almost modularize"

dominic: this is the reason thy modularization doesn't sound appealing

alexd: if we didn't have 2 versions, then this would be a lot easier

chaals: this sounds theoritical

dsinger: except it's the top deliverable

then we should update the charter

chaals: done

dsinger: it is in the current charter

chaals: yes, and we failed to deliver. the new charter doesn't mention it.

dominic: modularization does have appealing aspects

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

sam: that's factorization, not modularization

we can do a lot of that and improve the spec

we don't have to modulatize in order to get a more readable spec

there are other actions you can take to get to the same result

chaals: drop mic on carpet

<Travis> audience reacts with shock

propose 20 min break

<chaals> scribe: chaals

IndexedDB

<jsbell> agenda is on: https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-09-23TPAC-4.md

JB: early last year v1 got shipped. Been quiet waiting for implementations. There are some exploratory features in WICG and github for v2
... want to look at those, bugs, feature requests.

<LJWatson> Meeting: TPAC HTML, IndexedDB, Directory Upload, UI Events, WebIDL & WebPlat

JB: 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.
... there is a revision history in the spec.
... biggest change is the addition of getAll / getAllKeys - feedback from Mozilla, Chrome, who are shipping.
... those are the biggest. There are convenience features, binary keys, arrayBuffers as keys, some internal cleaning.
... e.g. what happens if the user destroys a storage the script thinks exists.
... 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.
... Feedback on all of this is appreciated.

AA: We would love you to walk through changes and make sure it still makes sense.

JB: Additions are all implemented in at least Firefox and Chrome. Not everything has WPT tests but that is planned.
... Spec relied on DOMErrors, but those are unpopular so we changed to DOMExcpetion, that shipped in Chrome with no breakage.

[ \o'/ ]

scribe: DOMStringList - turns out a contains() method cannot be added successfully :(
... we would like to use frozenArrays, but need a .contains() there.
... some methods should be able to consume DOMStringList but only take sequence. What do we do?

<dcooney> Chrome's usage indicator for DOMStringList contains in IndexedDB: https://www.chromestatus.com/metrics/feature/timeline/popularity/848

JB: The big exploratory features are observers and promises.

<jsbell> https://github.com/wicg/indexed-db-observers

DC: why not add includes to DOMStringList to give people a way forward?

JB: We weren't sure whether to expand DSL while trying to get rid of it. We would prefer to have frozenArray with contains.
... patching the method onto an object was hard work so we skipped it for now, but no strong principled objection to the idea.
... 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.
... We are discussing in WICG. The shape of the API is modelled on e.g. intersectionObserver, with IDB-specific features
... Observation starts in the scope of a transaction.
... after that transaction completes you get the observations, so within the transaction you can get the state.
... You get a replay of changes.
... additional discussion about collapsing changes to minimum diff or replaying all changes. Collapsing seems cooler but nobody thinks it matters enough to worry.
... Also discussed - do you see the keys changed, or the values as well?
... exploring opt-in to get the value, or a read-only transaction as the state of the database if you ask.
... This is cheap to implement, we are not committed either way but planning to try both of them and get feedback.
... Next thing is promise support.

<jsbell> https://github.com/inexorabletash/indexeddb-promises

JB: IndexedDB predates promises, but has things that look promise-like.
... but uses events rather than true promises.
... So what should we do in the future?
... The rest of the platform is getting promises, it would be nice.
... Issues - transactions commit automatically when there is no more work - measured by events and what happens. That's hard with promises.
... Naive wrapping in promises would have surprising consequences for developers.
... Look at the issues - documentation has them noted.
... Feedback on making requests thenable says that you either throw or return error, not both.

DC: Wouldn't pattern be "return rejected promise"?

JB: This would be the current version, that throws the wrong error instead.
... So this is not so controversial…

DC: If I pace a thenable to race or all does it work?

JB: yep.
... doesn't look like we have other things that have thenables in the platform.
... How do you extend around the promise chain. Idea was to look at things that have .waitUntil - this seems feasible for transactions
... adds additional states but that's plausible.
... The design of transactions ws meant to stop holding one open forever
... we would be making it far more likely that you could make the mistake.
... Is this a non-starter? Do we need to worry?

AA: What is the use case?

Nolan: FileReader. This is common and awkward now - done outside the transaction.

AA: What's the alternative

Nolan: Can be done.

JB: No atomicity. You invent it..
... harder - you can have a series of HTTP transaction waiting for something

AA: Does waituntil + promise fit naturally?

Nolan: It is surprising the transaction would commit automatically.
... but think the explanation is reasonable.
... what's the use for .ready?

JB: It was a way to get around not making things thenable.

Nolan: reads better without it...

DC: You're copying service worker and it has a extendable event.
... what about another overload for transaction, turning them into a promise…
... would a single promise be a feasible approach?

SW: doesn't take a promise in SW?

DC: No, you disclose something to the system, you can call an event or return a promise. Is there a difference in ergonomics?

JB: No immediate reaction…
... that would be an alternative to create a transaction and call waituntil…
... so pass function to transaction?

DC: Yep

JB: Interesting. Will play with this.

Nolan: #6 - handling errors but avoid aborting. Seems bad design
... we put things and handle an error. Here we have to handle each error which is a pain
... could you opt out of transactions auto-aborting?

JB: Not sure we wnt to do that - other bugs will get lost.

AA: What about resolving the promise?
... with the error catchable.

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?

AA: Is this a deal-breaker?

Nolan: Think it is a serious question…
... adding promises might be putting lipstick on a pig.
... developers just want key values in many cases without blocking.

JB: This is a common enough request that there are libraries.

AA: IDB is pretty low level - does it make sense to build promises on it?

SW: We have not got requests to add promises.
... most people using IDB aren't using it diretly and don't want to.

AA: Original idea was frameworks would build on this. Didn't happen early on, but now we see a ton of them.

Nolan: People who do database-stuff are frustrated that IDB is too *high*-level.

AA: We should see if frameworks are enough for people.
... seems like we are forcing this - perhaps better not to do that.

JM: What if we started again?

AA: Developers get grouchy…

JM: I mean instead of improving IDB, we do sometning else,

Josh: Your async proposal look easier and simpler than indexDB.

<jsbell> https://github.com/w3c/IndexedDB/issues/91

Issue 91

UNKNOWN_SPEAKER: feedback brings requests.

JB: What if we had anonymous object store for free, said Jonas...
... in parallel, this:

<jsbell> https://gist.github.com/inexorabletash/280016e79188b6a28247

JB: (not a serious proposal yet)
... can complicate everything by having two ways to do everything.

AA: in favour of this we see people use caches instead of IndexedDB
... because it is transactionless.
... So it looks like people want that

Nolan: Agree. In service workers, devs will use the cache API instead of IDB

JB: Looking forward to the implementation and feedback :)

AA: Looking at it.

<jsbell> https://github.com/w3c/IndexedDB/issues?q=is%3Aissue+is%3Aopen+label%3A%22spec+issue%22

JB: Issues are on github, tagged [nicely - ed.]
... 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.
... Are any issues OK to leave unresolved in V2

[step through issues]

SW: on #85 making DSL iterable is the more forward-thinking approach.

JB: Spec didn't say which errors to test in what order. Not critical most of the time, but we wanted to fix that.
... think we have ordering pretty much aligned. But they can be changed if someone has an objection

SW: Are there WPT for ordering?

JB: Some, we are planning to give more.
... Issue #10 is potentially puntable.
... it's handwavy and feedback would be nice.

TL: This was discussed in WebIDL session, maybe something coming to help describe a private slot.

AA: Please look at the feature requests and comment on them.

<jsbell> https://github.com/w3c/IndexedDB/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3A%22feature%20request%22%20

Directory…

<jsbell> agenda recap: https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-09-23TPAC-4.md

AA: History recap - MS and Mozilla were looking at something for directory upload.

<jsbell> https://wicg.github.io/directory-upload/proposal.html

AA: option on the table then was filesystemAPI, implemented in blink. But a year before that we had decided to discontinue that.
... had security issues, no traction, nobody was sure it was needed, …
... So we thought about a new API, put Directory Upload into WICG.
... Tried to modernise it, promises, fix some sync issues from the filesystem API…
... About 10 months ago MS were getting internal heat to support this. Spec hadn't reached consensus.
... We implemented subset of filesystem API in blink, Mozilla has done that too.
... We started looking at documenting that, in Entries API.

<jsbell> https://wicg.github.io/entries-api/

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.

AA: So we can start by documenting what is there, and solve some more problems.
... plan is to discontinue work on the new API and work on the thing we actually implemented.

JM: makes sense
... 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.

Smaug: We basically implement both, so we don't mind.

JM: Implementing the new one is pretty much the same under the cover for most code.

Smaug: The new one is a way nicer API

JM: Would there be any issues with that?

Smaug: Maybe we can improve entries enough to be nice.

JB: Nobody has a proposal for that yet.

AA: Fear is maintaining two different API surfaces.

Smaug: it really didn't take time to write entries on top of the other one.

JM: I am not concerned as implementor. More interesting question on the developer side.
... there are other examples of doing that before.
... no strong pref but we may get limited in how we can evolve the existing one.

AA: We were aware of that. So is it easier for developers if there are not two versions?

[is there enough transition benefit?]

JM: Can we evolve the existing one to be async?

AA: maybe, but it would be hard.

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?

Smaug: we have a webkit-prefixed API - but webkit doesn't implement it.

AA: The idea is that if you're abandoning the name, you can move to a different API anyway.

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…

Smaug: people expect the webkitdirectory attribute should work the same as directory.

JB: We could move this into File API
... we need hooks in there, because we monkey-patch it a bit.
... If people think a separate spec is fine, that's fine.

Smaug: This thing is very difficult to test.

AA: Tried building webdriver tests for this, and you have to fake some stuff. You can't drag around the file system.

CMN: Are manual tests reasonable to do?

JB: I actually have that for most stuff.

Smaug: [horror stories of corner cases - that will happen to people]

JB: Please feedback on the bugs, but maybe we should just go-ahead and add non-prefixed aliases

AA: Are we going to ahead with this API, or do we want to take on a new one.

RESOLUTION: Let's hold off on unprefixing until we decide whether to evolve the current API or move to the new spec.

AA: I will look at whether we can make the old spec either nicer, or let us implement the new spec on top.
... main problem will be .files - although we may have that problem in the new one too.
... we were looking at not populating .files unless called.

Directory download

<jsbell> https://github.com/drufball/directory-download

JB: came out of a chat to Jonas (hi Jonas! -ed.)
... today you get zip files for downloading.
... haven't done any implementation work, but we have a proposal for navigator.saveDirectory([files])
... This is a frequent request from developers…

Smaug: I like the first proposal - the other one doesn't quite work.
... How to show the user what is happening - clarify that you're getting a whole directory structure, not just a file. UI issue.

JB: Not sure about how to do this where there is no folder system.

Smaug: Would be good to get some feedback from Apple

<cwilso> https://github.com/WebAudio/web-midi-api/issues/165

<cwilso> oops, wrong channel

CMN: a lot of the use cases for directory do require the structure to be preserved :S

Writable files

<jsbell> https://github.com/wicg/writable-files

JB: So it makes it hard to make an editor…
... technically not that hard. There was one in Chrome Filesystem, but we probably want a nicer newer one.
... the interesting bit here is the permission model. And the UI for that.
... should permission be persistent

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.

Smaug: I do think we need the feature.

JB: Not expecting to solve this here...

<dcooney> present?

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

JB: What happens in the case where you edit the file in between two accesses from the Web - does that block permission?

DC: Are there performance issues?

[write time, and access permission]

JB: Are there other things in the filesystem space?

Smaug: Sometimes you want to create a new file, this doesn't cover that.

[Break until 2.45]

<jsbell> Also the "writable directories" scenario, i.e. to let you implement a git client

[or a photo manager or a zillion other things…]

The exciting bit!

charter

<LJWatson> CMN: We have a charter open for review until the end of the month.

<dcooney> Charter: http://w3c.github.io/charter-html/group-charter.html

<LJWatson> ... we have dropped some specs like Fetch, URL and XHR.

<LJWatson> ... DOM remains, but it is an interesting challenge.

<LJWatson> TL: Will we publish?

<LJWatson> CMN: Yes, probably.

<LJWatson> JB: We should replace File System with Entries API.

<scribe> ACTION: chaals update the references around Filesystem in the charter [recorded in http://www.w3.org/2016/09/23-webapps-minutes.html#action01]

<LJWatson> CMN: Yes.

<LJWatson> DC: We should leave HTML Imports.

<LJWatson> Smaug: Don't think we're likely to have that spec ever.

<LJWatson> TL: There are conceptual similarities.

<LJWatson> CMN: Names are not important but if we're on the hook to work on it, that's ok.

<LJWatson> BK: So no objection to the thing?

<LJWatson> Smaug: No, but calling it HTML Imports seems unlikely.

<LJWatson> DC: It's a way to use HTML documents in HTML documents.

<LJWatson> JB: No interest in pursuing Quota Management API.

<LJWatson> ... Can be removed at no harm.

<LJWatson> DC: No interest in Find Text?

<LJWatson> CMN: No. Interest but no traction.

<LJWatson> CMN: We can also recharter... proposed charter runs until 2018, but if something new comes up we can recharter before then.

<LJWatson> scribenick: LJWatson

CMN: PubStatus...

<dcooney> https://www.w3.org/WebPlatform/WG/PubStatus

CMN: specs divided between the three chairs.

ARIA in HTML is ok

HTML AAM is a recent transfer into WebPlat.

HTML Extensions Note is a collecting place for things relating to HTML.

HTML5.1 in PR, nearly done.

HTML5.2, FPWD, need to kick it into action.

Using ARIA in HTML Note, is ok.

LW: Have filed issues to change the name of the note to avoid confusion with ARIA in HTML.

BK: ARIA specs are confusing.

CMN: DOM, is a problem child.

DOM Parsing and Serialisation, needs a kick.

TL; It's ok, have some issues and a test suite.

CMN: File API, hasn't been a success.
... Recently have a new editor to help Marin.

JB: Open issues against File API are gnarly.
... Not about defining new behaviours.
... just spcifying the way things are.

CMN: File System API, bounced to incubation.

Find Text API, off to incubation.

Gamepad API, ok, but looking for an editor.

IndexedDB, discussed earlier.

Packaging on the Web, off to incubation.

Pointer Lock, in PR.

Push API, ok.

LW: Swapping out editors.

CMN: Screen Orientation API, needs attention.

Service Workers, is ok.

Streams, dropped.

UI Events, discuss later.

URL, dropped.

Manifest, is ok.

Web Sockets, sitting there.

Web Workers, new editor and it's been kicked into life again.

WebIDL-1, in PR.

XHR, is dropped.

Custom Elements and Shadow DOM are ok, but need attention, HTML Imports is in incubation.

Clipboard API is ok.

Static Range needs adding to PubStatus.

GK: It's too generic for Input Events.

Then the old tings in maintenance with nothing happening.

TL: Canvas?

CMN: Tried to hand it off to someone/anyone during charter.
... Possible it should be updated.
... We'd need a volunteer.

Communication...

Using Github, the email list.

If we do send things to email people complain, and others complain if we don't.

We'd like to know what we can do better.

scribe: We don't do many CFCs because the general model has been implement, then revert if there is a problem.
... We've been experimenting with using a GH issue on the spec to gather responses to the CFC.

LW: Anyone here think using GH issues for CFCs is a bad thing?

]silence]

WebIDL

<chaals> Tobie: started working on the WebIDL spec, spent summer putting it into bikeshed and now it looks nice.

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

<chaals> … and wait for me to learn the spec and understand what you are talking about ;)

<chaals> … would like to have continuous publishing for this.

<chaals> ljw: need to move to W3C repo

<chaals> YL: We can set that up without that.

<chaals> Tobie: Hopefully I will have the publishing set up soon.

<chaals> … FPWD should be feasible more or less now.

<chaals> [break until 4pm]

UI Events -- what we need to know.

<Travis> Scribe: Travis

gary: we broke out two specs: key and code from UI events.
... They are basically done.
... UI Events still needs work
... to formalize
... fix a few bugs
... do some testing
... we have a lot more testing to do. Will stick with manual test for the keyboard.
... Webdriver won't support what we need in the near term
... any Qs?

chaals: are you confident that you have sufficient tests?

gary: focused on keyboard tests and only English & French.
... mouseevent tests are coming (someone else at Google)
... we think we will be in good shape.
... I don't believe we have enough tests now, but we will...
... I'll stop when I get tired.
... Almost everything in UIEvents has shipped.
... Can we convince browsers to normalize when necessary.
... If it's too much change, we may need to fallback to documenting odd behavior.
... hopefully not though.
... Next 1 year will focus on testing and re-writing.
... If not wholly algorithmic, then much closer.
... By next TPAC would like to say "we have god test coverage"

smaug: I need to ask Masayuki if he can add more tests

gary: yes, you have so many dependencies (keyboard layouts, etc.)
... mobile is easier.

bkardell_: haven't been following, but
... person I mentored was pointed at MDN for some keyboard event handling.
... said don't use keyCode; but key isn't implemented everwhere.

gary: key has lots of shims, waiting for Edge to get their act together and fix key and add the code property.

bkardell_: It's weird to say things are deprecated but there's no replacement.
... MDN shows cross browser tables.
... was wondering if there was a reason for the omission.

chaals: Agenda:...

gary: system keyboard lock.. what is it?
... want web platform to do more desktop app stuff
... OS consumes a bunch of keys.
... some web apps need to get all the keys to work properly.
... like in remote access.
... like having access to the ESC key.
... This proposal lets the web dev request the set of keys that are desired.
... Current version is only for full-screen.

travis: smart alek remark about blocking full-screen escaping...

gary: [rolls eyes]

smaug: not sure long key press can be discovered...

gary: OK, I guess you need a dialog.

chaals: seems bad for accessibility, esp. if restricted to full-screen.

gary: idea is that you've entered into the app and you don' want to leave.
... immersed in the game, with pointer lock, etc. You don't want to fall-out on accident.
... you don't want to think about local user controls.

[chaals thinks... sloooooooooowly]

chaals: If you go into gmail, the fullscreen and take over your keyboard...

gary: You'd need to grant permission of course.

chaals: I'm worried that apps start doing this as a default thing.

gary: this is why we're restricting to full-screen.

smaug: you want some keys to get you out (like Alt-Tab) (app switch)

gary: if you're on a mac, remote-ing to a PC, you want to use PC commands.

chaals: we this, we encourage folks to mess up their keyboard accessibility!

gary: ctrl+alt+del -- yeah, you'll probably never get that.

[side conversation about how to kill mac apps]

gary: the API is made to request which keys you want.
... earlier version let you request them all.
... we opted to specify so that it could be more opt-in.

travis: is there a use case for the reverse scenario.

scribe: like not getting keys?

gary: that's ridiculous.

travis: yeah.

smaug: it is a proper permission? or more like fullscreen, where it just allows it?

gary: well, it could default either way...
... we think providing the key list is best.

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.

chaals: new idea: (you'll hate)
... when you request the keys you have to give them a label.
... the label is "what you want the key for"
... a map that redirects one key to another.

gary: not sure it fits with this.
... or how it affects the concerns
... what else could we do to reduce abuse?

chaals: make it work sometimes only.

gary: well, permission (up to UA on style)...
... how to discourage use unless there is a need?
... we want to secure this so it doesn't get abused.

chaals: seems very useful; scares me to death.

gary: use case for windowed--huge monitor, don't want to go full-screen.

smaug: the security concerns here may be troubling.

chaals: makes it more easy to "phish"

gary: any other comments?

chaals: If you put it out there...
... it's 1) either crap, or it 2) works and everyone implements and its ubiquitous.
... there's a world where I want to be able to do this.

gary: we want our web-based native-like apps do this.
... for mobile it may be more tenable to send the right keys across; desktop is harder due to people's muscle-memory.

smaug: I think it's less-scary in non-fullscreen mode (the user can switch apps and escape)
... also, how do you escape from fullscreen on mobile?

gary: there's a persistent UI affordance
... but you're thinking of the non-nice people...
... with permissions, e.g., allow-listing certain sites by default.
... that concern mitigation could be applied.
... wouldn't prefer that.
... and not reasonable to spec.

travis: make sure its behind secure context.

chaals: I think it's worth playing with. (I'm thinking of other problems.)

[chrome has tried various features that their security team shot down]

gary: I think permissions does everything you need.

smaug: please consult Mozilla security folks too.

<garykac> Link to system keyboard proposal: https://github.com/jondahlke/system-keyboard-lock/blob/master/EXPLAINER.md

<MichielBijl> https://w3c.github.io/uievents/

^ UI Events spec :)

<garykac> WICG discussion: https://discourse.wicg.io/t/proposal-system-keyboard-lock-api/1594

chaals: Thanks everyone! We are done.

- DRAFT -

TPAC HTML, IndexedDB, Directory Upload, UI Events & WebPlat

23 Sep 2016

Attendees

Contents

whatwg

incubation

IndexedDB

Issue 91

Directory…

Directory download

Writable files

The exciting bit!

charter

WebIDL

UI Events -- what we need to know.

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output