Chaals remove allow-presentation 893

[chaals]

This was a feature marked at risk, and is apparently not interoperably implemented yet.

(If it is - or sufficiently to be confident that it will get real adoption and interop, @tidoust please let me know)

[anssiko]

See #437 (comment) for the context and conditions under which this feature was added.

The work on the Presentation API is ongoing. The spec is at CR and will advance to PR as soon as the another implementation becomes fully conformant.

If the W3C HTML drops this feature the Presentation API will switch back to use the WHATWG HTML reference whatwg/html@0678e3d

[chaals]

@anssiko We fully expect this to be interoperable next year and to be in the next version of HTML, expected next year having become conformant. But we are ready to request PR transition now for HTML 5.2 (having delayed it some).

My expectation is that we will branch some time this month, and the next task will be to return those things we expect to become part of HTML while reconsidering those that have been there for some time and are not showing signs of being interoperable, like menu/menuitem.

[LJWatson]

Given that the Presentation API is under active development, I suggest we include a warning in HTML5.2 instead of pulling it out.

[chaals]

Looking at the tests https://w3c.github.io/test-results/presentation-api/receiving-ua/all.html and https://w3c.github.io/test-results/presentation-api/controlling-ua/all.html and especially

• Sandboxing: Creating a PresentationRequest from a nested context fails when allow-presentation is not set
• Sandboxing: Creating a PresentationRequest from a nested context succeeds when allow-presentation is set

It seems that (as noted in April) Firefox doesn't bother looking at the allow-presentation flag. Meaning there is really only one implmentation at this stage.

I'm all for leaving this in the Working Drafts, but without clear evidence that someone is actively working on a second implementation (and a quick hunt through Mozilla's bugzilla doesn't make that obvious), I think we should not request PR for the 5.2 version with this included.

[LJWatson]

There is an intent to implement, plus two issues tracking Firefox implementations: 1184036 and 11840732.

The Presentation API only went to CR in June, so perhaps @anssiko and/or @tidoust can provide some more information on intent to commit?

AIRC this is stronger than the evidence we had for including a warning about the Blink only implementation of Promise rejection handling with rejectionhandled and unhandledrejection events [in HTML5.1. With a warning I think we can (and should) leave this in HTML5.2.

[danbri]

+1 for keeping it in with warning (personal perspective, I have not had chance to talk with colleagues)

[cynthia]

This should be left in. It does bring up the process question of whether non-interoperable feature purging should happen in master in the first place.

For the deliverable to have any relevance (setting aside the political discussion, which I will gladly not partake in) some part of the editing/publishing process should ensure that no commit breaks cross references - which is worth a separate discussion.

[anssiko]

There seems to be consensus this feature should be left in.

Can we close this PR now, so that the Presentation API editors can stop worrying whether this cross-reference will break?

[LJWatson]

Agreed.