Ok, so Chris reminded me that we'd already shipped a setter via `setHTMLUnsafe()` and that Mozilla has an intent out for this new version of the getter, which suggests to me that we should, indeed, handle the streams thing separately.
LGTM1. On Friday, April 5, 2024 at 3:31:10 PM UTC-7 Mason Freed wrote: > Thanks for the comments! > > On Fri, Apr 5, 2024 at 8:26 AM Vladimir Levin <[email protected]> wrote: > >> I think this is the case, but just to clarify: this is shipping a new >> function and not renaming/updating the previously shipped one, right? So, >> at least for the time being, there will be two similar functions shipped >> > > That's correct. This intent ships `getHTML()`. And then (after some time) > this > other intent <https://chromestatus.com/feature/5081733588582400> will be > used to remove the old `getInnerHTML()` function. But as you said, I'd like > the new one to be available for at least a few milestones to give folks > time to migrate. > > On Thu, Apr 4, 2024 at 9:27 PM Alex Russell <[email protected]> > wrote: > >> Drive-by API design comments: >> >> Was this run past the TAG? Did they ask this is not adding a way to >> return a stream? And was there a discussion of a setter API that supports >> streams? It would be disappointing if we added new surface of this sort >> without resolving the core data type issues. >> > > So yes, the original declarative shadow DOM feature was submitted for TAG > review <https://github.com/w3ctag/design-reviews/issues/494>, and its > explainer had a section about `getInnerHTML()` > <https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md#serialization> > > which is basically the same except for the name. The TAG review itself has > quite a bit of discussion about `getInnerHTML` and serialization (starting > roughly here > <https://github.com/w3ctag/design-reviews/issues/494#issuecomment-622007263>) > and doesn't bring up the stream-based API you mention here, which is too > bad. > > The original feature shipped in 2020 and this intent represents the > penultimate of a series of about eight chromestatus entries over 4.5 years > to finally get it standardized. I'm really hoping we can tackle stream > based serialization as a separate effort. :-) > > Thanks, > Mason > > > >> Best, >> >> Alex >> > > > >> >>> >>> Blink componentBlink>DOM>ShadowDOM >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EDOM%3EShadowDOM> >>> >>> Search tagsgetHTML <https://chromestatus.com/features#tags:getHTML>, >>> declarative >>> shadow dom >>> <https://chromestatus.com/features#tags:declarative%20shadow%20dom> >>> >>> TAG reviewNone >>> >>> TAG review statusPending >>> >>> Risks >>> >>> >>> Interoperability and Compatibility >>> >>> This is a new feature, so there should be no compat risks. And the spec >>> PRs got comments and support from multiple implementers, so I would expect >>> support coming soon from other browsers. >>> >>> >>> *Gecko*: Positive ( >>> https://github.com/whatwg/html/pull/10139#pullrequestreview-1966263347) >>> >>> *WebKit*: Neutral (https://github.com/whatwg/html/pull/10139) General >>> comments from annevk@ seem supportive, but no LGTM directly. >>> >>> *Web developers*: No signals >>> >>> *Other signals*: >>> >>> WebView application risks >>> >>> Does this intent deprecate or change behavior of existing APIs, such >>> that it has potentially high risk for Android WebView-based applications? >>> >>> None >>> >>> >>> Debuggability >>> >>> None >>> >>> >>> Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, ChromeOS, Android, and Android WebView)?Yes >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ?Yes >>> >>> >>> https://wpt.fyi/results/shadow-dom/declarative?label=master&label=experimental&aligned&q=gethtml >>> >>> >>> Flag name on chrome://flagsElementGetHTML >>> >>> Finch feature nameElementGetHTML >>> >>> Requires code in //chrome?False >>> >>> Tracking bughttps://crbug.com/41490936 >>> >>> Estimated milestones >>> DevTrial on desktop 125 >>> DevTrial on Android 125 >>> >>> Anticipated spec changes >>> >>> Open questions about a feature may be a source of future web compat or >>> interop issues. Please list open issues (e.g. links to known github issues >>> in the project for the feature specification) whose resolution may >>> introduce web compat/interop risk (e.g., changing to naming or structure of >>> the API in a non-backward-compatible way). >>> None >>> >>> Link to entry on the Chrome Platform Status >>> https://chromestatus.com/feature/5102952270528512?gate=5177496192679936 >>> >>> Links to previous Intent discussionsIntent to prototype: >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDjRLRyHkgo%3DwTF76uj5rA46xafYsEmh4G_m%2BAcXTUev%3Dw%40mail.gmail.com >>> >>> This intent message was generated by Chrome Platform Status >>> <https://chromestatus.com/>. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDgOWWoodXvvk7qYTNFMFhsbDxebc%3Dw%3D50nuq6y5jNhNag%40mail.gmail.com >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDgOWWoodXvvk7qYTNFMFhsbDxebc%3Dw%3D50nuq6y5jNhNag%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c4c21d51-25d6-405b-acb9-e34486e85b08n%40chromium.org.
