State of the Web App WG - 2019

Hi All,
Before TPAC we asked all the Editors to provide a summary of where their specs are at with respect to reaching CR (or generally making progress), which you can find below. Huge thanks to all the editors for helping us with those!

Feel free jump down to your favorite specs and get a nice update... if you'd like to ask a question of the editor or help out, please jump into the appropriate issue liked from each spec description.

## html-aria
> What progress has your spec made in the last 12 months?
37 commits made and 14 bugs closed.

> Is anything blocking your spec from moving to CR?
Lack of multiple implementations.

> If yes, what is your plan to unblock it and do you need any help?
Work with a11y tool vendors to get more than 1 implementation.

https://github.com/w3c/html-aria/issues/160


## Clipboard-apis
For Clipboard, we've been focused on defining appropriate image support for the API. We'd like to discuss this and support for other data types during TPAC.

https://github.com/w3c/clipboard-apis/issues/94

## File API

> What progress has your spec made in the last 12 months?

Added some convenience read methods to Blob (Blob.text(), Blob.arrayBuffer() and Blob.stream()), and cleaned up some of the spec text around the FileReader API. Implemented in Chrome and Firefox.

> Is anything blocking your spec from moving to CR?

(not entirely sure what consequences are from moving to CR, but) there is a bunch of work left cleaning up the spec text, particularly around Blob.type. And it would be nice to get feature requests such as #140 in as well. Other than that I think the spec is fairly stable and I don't anticipate any major changes.

https://github.com/w3c/FileAPI/issues/138


## Gamepad API
Work towards CR involved triaging issues valid for CR and v2 issues. Additionally, the spec has been circulated to the wider audience to raise concerns about privacy and security.
Need to gain consensus and close privacy/security issues to move forward.

https://github.com/w3c/gamepad/issues/99


## html-aam
> What progress has your spec made in the last 12 months?

Further rounding out expectations for elements and attribute mappings. Working on rectifying and clarifying accessible name algorithms. Many pieces are still in progress, but I've identified much of what I think needs to be completed and worked towards to move to CR.

> Is anything blocking your spec from moving to CR?

Issues I want to resolve before CR. There is nothing blocking these beyond time and resources to write tests and update the spec accordingly. While I have been doing work to resolve a good majority of these issues, any assistance in writing tests and contributing to the following is appreciated:

Updated naming algorithms and general guidance, which would resolve:
  - #231, #227, #225, #211, #210, #209, #205, #179, #160, #158, #148, #134, #100, #29, #25, #238

HTML element removal, updates and additions which would resolve:
  - #189, #188
Updating not mapped elements to indicate how they could map, if given attributes that are important for accessibility:
  - #151, #143

Completion of attribute table for AX API
  - #97

Complete or remove any notes in the specification that are marked as "to do"

> What do you want to achieve for your spec in the next two days (of breakout sessions)?
While I will not be able to attend TPAC, I'm hoping that any issues / solutions that may be discussed and are applicable to the HTML AAM will be logged and PRs will be submitted.

https://github.com/w3c/html-aam/issues/233


## Editing specs
Input Events level 1 - has obtained more tests. Has 2 implementations. Should be ready for CR. Need feedback from W3C on next steps.

Input Events level 2 - same tests apply, still only has 1 implementation. Need for one more implementer to implement this or for us to decide to continue with an alternative as a replacement (such as EditContext).

Contenteditable - The main spec has been in sleep mode since we started working on Input Events The plan has always to go back to it after finishing Input Events. Contenteditable-disabled was discussed at TPAC 2018 and the suggestions made there have subsequently been added. Needs feedback from implementers to see how to move forward with this. It should be relatively compatible with EditContext if we go for that, but it will still need some minor adjustments.

https://github.com/w3c/editing/issues/199


## Intersection Observers
I am scrambling a bit to finish some edits to the spec for settled issues, but that's just mechanical stuff, nothing that requires deliberation. Aside from the V2 proposal, the spec has been very stable for the past 12 months.

Aside from that, I believe the spec to be ready for CR, and I hope to make it official at TPAC. Beyond that, there are a few issues in the tracker which I have marked for discussion at TPAC, including the V2 proposal (which has shipped in chromium):

https://github.com/w3c/IntersectionObserver/issues/381


## PointerLock
> What progress has your spec made in the last 12 months?
Aside from some editorial changes and whatnot, we have started adding a new capability to the request API so that it matches more platform like features such as disabling mouse acceleration. We are still working on it to get more feedback from other vendors and also investigate how different underlying platforms could support the feature.

Aside from this new feature we wanted to clear the coordinate space for some of the attributes as part of this issue but we didn't make much progress on that due to the lack of feedback from others and some oppositions on more aggressive changes in the early proposals.

> Is anything blocking your spec from moving to CR?
Nothing actually. I believe we should be okay if we land the new capability above and also hopefully rewrite parts of the spec to make it more like a procedural/algorithmic spec it should be ready to go for V2. If we could also clear the coordinate space in this issue for V2 that will be fantastic.

https://github.com/w3c/pointerlock/issues/50


## Push API
> What progress has your spec made in the last 12 months?
No real changes over the last 12 months. The spec is in most ways stable. Editorial changes have been made, and alignment with updates in dependencies has been improved.

> Is anything blocking your spec from moving to CR?
A few things: resourcing, ambivalence, and churn.

The editors are quite busy with other more important tasks and so were unable to dedicate additional time. Getting to the point where we have good test coverage in WPT takes considerable investment that we can't currently justify, largely due to missing infrastructure. We believe that the spec is in good shape for the most part otherwise.

The ambivalence is over the perceived value of a candidate recommendation. Any such label is unlikely to be more useful than a spec that we can continue to update. We can prepare a document that could progress among the REC track as a snapshot by end of year if the Chairs prefer.

Finally, there has been a bunch of churn in areas that the spec depends on. WebIDL continues to make incompatible changes (e.g., #312) as does the service worker spec (e.g., #315). We've also seen a lot of changes out of Respec, though Marcos was kind enough to spend some time cleaning things up, which was very much appreciated. What limited resources we have are dedicated to managing this churn rather than in advancing the specification.

https://github.com/w3c/push-api/issues/316

## Selection API
> What progress has your spec made in the last 12 months?

Unfortunately, not much progress has been made other than some discussions in Github issues.

> Is anything blocking your spec from moving to CR?

In my view, there are two aspects of the selection API: the parts of the API that's needed for interoperability and more of future looking API to be added. I think we should focus on spec'ing the former first and put it out as L1 CR. In general, we need to get more active discussion & spec editing to be done.

https://github.com/w3c/selection-api/issues/111


## Screen Orientation API
> What progress has your spec made in the last 12 months?

Overhauled much of the spec to clarify various algorithm and examples - thanks to @Johanna-hub.
Added a significant number of web platform tests, and linked to within the spec - again, thanks to @Johanna-hub. However, we still need to go through #119 and check what's missing.

> Is anything blocking your spec from moving to CR?

Bugs and things that need discussion:

- lock() should not fail if another lock() is called in the change event #184
- double check lock(), event, re/unlock() behaviors #151
- Promise for unlock()? #104
- unlocking during event dispatching is undefined #173
- Reliability of angle #162

Cross spec integration. In particular the following need a bit of work:

 - Deal with fragment navigation
 - Clarify in which animation frame task events are fired
 - Improve hooks with Page Visibility.
 - Link Screen Orientation with Fullscreen more cleanly
 - Clarification on animation frame task
 - Page visibility transition can fire when false/true/false happens within a frame
 - Clarify how to initialize the screen orientation #145

iOS supports: Face up and face down #168 - not sure if we should add that without WebKit support.

https://github.com/w3c/screen-orientation/issues/185


## uievents
So, UIEvents is a bit of an odd spec since we're not adding new features,
but rather trying to properly document existing implementations.

As it stands, the UI Events spec is written in a very old informal style
and will not be accepted to move up to CR. I am working to address this by
modernizing the spec (to make it more algorithmic), but progress has been
slow.

I tried to advance some of these issues during the last TPAC, but due to a
scheduling conflict (grrr...) the discussion was placed opposite a timeslot
where many relevant participants could not attend. Because of that we only
had a limited (but still useful) discussion. Also, I have been able to work
on this far less that I wanted to over the past year, and I apologize for
this.

To unblock this, I plan on (once again) proposing breakout sessions to
discuss the issues that need to be included in these algorithmic
descriptions. For example, I know that hit testing needs to involve some
CSS experts so that it integrates appropriately with rounded corners, and
so on. There are many areas where I am not a domain expert and need to hook
up with them to describe the process adequately.

In addition, there is also the UI Events Key and Code specs, which need to
be Level 1 and Level 2 so that we can say that all implementations must
support Level 1 while Level 2 is optional.

https://github.com/w3c/uievents/issues/242


## Manifest
> What progress has your spec made in the last 12 months?
Limited. We are mostly waiting on implementation feedback.

Mozilla implemented the manifest processor around six years ago but it's only now making its way into products: namely Firefox Preview on Android. As part of that effort, we identified some non-blocking issues with icon's purpose (fixed), and also with CSS color parsing. Mozilla is hoping to provide further feedback as we gain implementation experience and put this out into products and and in front of real people.

The Manifest spec is also shipping in Safari, and we'd really like to get more feedback from Apple about their experience.

> Is anything blocking your spec from moving to CR?
Yes. Because the spec lacks any programmatic means to install a webapp, it makes the spec notoriously difficult to test: basically, we need to do a bunch of manual testing.

There is also some disagreement on the a BeforeInstallPrompt() event (BIP). Despite BIP having been in the spec for a few years, neither Safari nor Firefox have opted to support it. As it stands, Mozilla does not plan to support BIP. We are unsure what WebKit's plans are - @hober maybe could let us know? If WebKit doesn't plan to support it, then we should probably remove it from the spec.

We also made a mistake trying to use WebIDL to model the data structures of Web Manifest. Although it seemed like a good idea at the time, this turns out to not work well in practice: no implementation does processing of Web Manifest data through the a Web IDL binding layer. Some work is underway to change the spec to use Infra types instead.

There is also a proposal to add "shortcuts" to icons #768 from @aarongustafson, but lacks implementation interest from a second engine. We might need to move to incubation?

> If yes, what is your plan to unblock it and do you need any help?
To unblock, we might need to make some hard choices about BIP and new feature proposals. We should try to get agreement on a limited number of things (i.e., maybe 3) to work on over then next year.

Great summary of what we discussed at TPAC by Aaron Gustafson:
https://github.com/w3c/manifest/issues/782#issuecomment-533363985


## IndexedDB
Progress on "Indexed DB 3.0" in the last 12 months has included only 3 normative changes: Added IDBFactory databases() method; added IDBTransaction commit() method; added IDBCursor request attribute. Other changes to the spec text include refactoring algorithms to de-duplicate steps and using/referencing common "infra" terms.

I don't believe the spec has warranted enough changes to justify the effort to move to CR. We don't have multiple implementations of some of the new additions (commit() method, request attribute). We are planning to discuss several other potential additions at TPAC 2019. (See #288).

Worth mentioning here: one possible future for KV Storage is to merge it into the IDB spec; some of us think it is the best solution to the "make IDB more ergonomic" goal expressed for IDB 3

Apparently this was expressed as the "plan of record" at TPAC 2018. It is currently held up on the future of built in modules IIRC.

## Web share API
> What progress has your spec made in the last 12 months?

* Implementation in Safari on iOS and macOS.
* Addition of Level 2 spec that allows sharing of files.
* Implementation of Level 2 in Chrome on Android.
* Migrated from WICG to W3C as an Editor's Draft.
* Firefox implementation close to landing.
* Full test suite in WPT.

> Is anything blocking your spec from moving to CR?

The Level 1 spec is reasonably mature and has two separate implementations (Chromium and WebKit). It hasn't been through a formal process, having just been migrated to W3C.

Notable things from TPAC:
 - Nod from WebKit to integrate Files support into the spec.
 - Plan to drop levels in the spec.

Received on Thursday, 3 October 2019 07:14:12 UTC