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
<vmp...@chromium.org> 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
<slightly...@chromium.org> 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 component
Blink>DOM>ShadowDOM
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EDOM%3EShadowDOM>
Search tags
getHTML <https://chromestatus.com/features#tags:getHTML>,
declarative shadow dom
<https://chromestatus.com/features#tags:declarative%20shadow%20dom>
TAG review
None
TAG review status
Pending
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
<https://github.com/whatwg/html/pull/10139#pullrequestreview-1966263347>)
/WebKit/: Neutral
(https://github.com/whatwg/html/pull/10139
<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
<https://wpt.fyi/results/shadow-dom/declarative?label=master&label=experimental&aligned&q=gethtml>
Flag name on chrome://flags
ElementGetHTML
Finch feature name
ElementGetHTML
Requires code in //chrome?
False
Tracking bug
https://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
<https://chromestatus.com/feature/5102952270528512?gate=5177496192679936>
Links to previous Intent discussions
Intent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDjRLRyHkgo%3DwTF76uj5rA46xafYsEmh4G_m%2BAcXTUev%3Dw%40mail.gmail.com
<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
blink-dev+unsubscr...@chromium.org
<mailto:blink-dev+unsubscr...@chromium.org>.
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 blink-dev+unsubscr...@chromium.org.
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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c4c21d51-25d6-405b-acb9-e34486e85b08n%40chromium.org?utm_medium=email&utm_source=footer>.
