Specification status report for TPAC 2019

[LJWatson]

Please can you respond to this comment with a brief specifications status report for the WebApps meeting at TPAC. The report should address the following:

• What progress has your spec made in the last 12 months?
• Is anything blocking your spec from moving to CR?
• If yes, what is your plan to unblock it and do you need any help?
• What do you want to achieve for your spec in the next two days (of breakout sessions)?

We're tracking these status reports in WebApps issue #19

Thanks.

[marcoscaceres]

@mgiuca, @dominickng, would be great to hear your perspectives also...

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.

What do you want to achieve for your spec in the next two days (of breakout sessions)?

Decide what's in scope, and what is not. Hopefully hear from @hober or other folks from WebKit about what they would like to see in the spec. At this point, Mozilla is happy with the base set of manifest members.

[tomayac]

There’s actually a lot of interest from developers for Apple to implement icon support (https://bugs.webkit.org/show_bug.cgi?id=183937) and beforeinstallprompt support (https://bugs.webkit.org/show_bug.cgi?id=193959).

[dominickng]

Thanks @marcoscaceres. Your summary looks pretty good to me. It would be a bit sad to remove BIP since it's a pretty core part of what we're doing on Chrome, and we've seen a lot of demand from developers for it (as @tomayac has pointed out, so have other vendors).

[marcoscaceres]

We've not removed it yet :)... we just need to see if we can sell it better and get other folks to understand the utility of it.

[mgiuca]

There’s actually a lot of interest from developers for Apple to implement icon support (https://bugs.webkit.org/show_bug.cgi?id=183937) and beforeinstallprompt support (https://bugs.webkit.org/show_bug.cgi?id=193959).

I don't know if any of the replies on those bugs are from Apple / WebKit engineers. Having a handful (tens) of +1s from external developers doesn't really give us much of a signal.

It would be good to hear from Apple on this.

We (Chrome) would be open to deprecating BeforeInstallPrompt in favour of a different programmatic install API (I don't think there's a lot of love for the API we settled on), but it is fairly heavily entrenched on the open web, having been available in Chrome (and I believe other browsers like Samsung and Opera) for around 5 years.

Chrome's usage metrics for BIP show that this is currently used on 1.5% of all page loads (though I'm not exactly sure what we're measuring here; possibly just any mention of the global object BeforeInstallPromptEvent), which is too high to remove outright.

[aarongustafson]

Perhaps we can chat with Apple @ TPAC. Are you here @mgiuca?

[mgiuca]

No I'm not. Happy to hear about the results of any discussions.

[kenchris]

Me and @marcoscaceres are here

[aarongustafson]

I spoke with a bunch of folks with Samsung at lunch and they seem very interested in Shortcuts. Kicking off some deeper conversations with them.

[aarongustafson]

A brief rundown of what we talked about at TPAC based on my recollection. Please correct if I messed anything up.

• Shortcuts (#582) - Achieved agreement on the format & tacit TAG approval; bug filed with Firefox & Webkit to (potentially) get commitments; @slightlyoff had some interest in bringing back alternate HTTP verb support and params (which we can do later); PR ready for merge. Some discussion around adding a new rel value for link elements to the Microformats registry for inline declaration of shortcuts (browser interest and UI exposure TBD).
• File Handling (#626) - General discussion of file association proposal and agreement on the approach; some questions about what the launch looks like and how the payload is delivered. @marcoscaceres brought up some parallels with drag & drop resolution.
• ImageResource - Agreed to break out ImageResource to a separate spec which would be referenced by Web App Manifest (and other specs). ImageResource will be extensible in context to allow for manifest-specific features (and other specs, naturally). Once the new spec is in place, we will migrate ImageResource issues to that repo. Agreed to add description (#773) and color_scheme (#758) members to ImageResource upon migration.
• beforeInstallPrompt - moving this feature to optional (PR inbound: #797)
• Badging - Discussed the badging proposal at WICG and came up with a plan to address badging app icons and tabs/windows independently. Review from @hober was supportive.
• allow_list - Discussed bringing the concept of Feature Policy-esque capabilities declaration into the Manifest for auditing, user awareness, etc. @aarongustafson took an action item to write an explainer. (#798)
• getInstalledrelatedApps() - Agreed to move forward with this
• Service Worker Launch Event - General intro/overview & discussion around how launch could allow for better UX in terms of APIs like Share Target, Shortcuts, etc. No action taken (apart from general agreement that it’s worth pursuing).
• isInstalled() - Into to the idea of a window being able to determine if a PWA for that domain & scope is installed so that it may be launched. Seems to overlap some with prefer_related_application (where that app is the PWA), Chrome Apps’ url_handlers, and Windows’ web-to-app-link concept. General agreement that we need to solve this. @raymeskhoury to look for more use cases.
• Defining "PWA" - @beverloo brought this up and we agreed to join the current discussion around revising PWA docs on MDN.
• 3D Favicons - Proposal for spatial icon types for 3D/XR scenarios. We can’t speak to favicons, but we’re cool with adding support in manifest for defining them. ImageResource is already set up to handle the MIME types, but leans on HTML for sizes definition. Suggested that the proposal for a third dimension be taken to the WhatWG and, once cleared, we can look to add it into the spec.
• Screen enumeration - General walkthrough by Mike W; we like the idea of being able to control window placement.
• Projections - Idea @aarongustafson posted to WICG for enabling apps to advertise widgets, cards, and similar for use in other surfaces (e.g., Live Tiles, Google Now, Samsung Daily, home screen widgets, macOS dashboard widgets, etc.). @beverloo & @slightlyoff working on a similar idea leveraging notification templates. Collaboration & an explainer to come.

[christianliebel]

Agreed to break out ImageResource to a separate spec which would be referenced by Web App Manifest (and other specs).

@aarongustafson ImageObject from Payment Handler API (https://www.w3.org/TR/payment-handler/#imageobject-dictionary) could be changed to ImageResource.