Re: [blink-dev] Intent to Deprecate non-standard declarative shadow DOM serialization

['Jason Robbins' via blink-dev]

If you intend to deprecate and remove, that is the "Prepare to ship" stage 
on your chromestatus feature entry.  You can use the review gate chips to 
access the intent preview and then copy and paste that to start the thread.
https://screenshot.googleplex.com/5GioLEtEnQBvTZu

The subject line will be "Intent to Ship: Deprecation of non-standard 
declarative shadow DOM serialization".  Using "Intent to deprecate and 
remove" should also work.  ChromeStatus doesn't actually look for the colon 
in the subject line, it just looks for keywords near the start of the 
subject line, and it looks for the body line "Link to entry on the Chrome 
Platform Status" and the link to your entry.

Thanks,
jason!

On Tuesday, February 6, 2024 at 8:08:54 AM UTC-8 mas...@chromium.org wrote:

> On Tue, Feb 6, 2024 at 1:26 AM Yoav Weiss (@Shopify)  
> wrote:
>
>> Is this thread meant for both deprecation and removal (given the short 
>> timelines)?
>>
>> Apologies for the delay in responding here. It might be worthwhile to 
>> re-send it with the right title, as it's currently not caught in the API 
>> owner's tooling (I suspect that's due to a missing ":").
>>
>
> Yes, I did hope to do both with this one intent. I’ve learned not to edit 
> the title of the email (e.g. to say “deprecate AND remove” because then the 
> tool definitely doesn’t pick it up. I’m not sure what happened to the :, I 
> didn’t edit it. Sorry for the trouble, and thanks for catching it.
>
> So I should re-send the entire thing?
>
>
>
>> On Fri, Jan 26, 2024 at 11:30 PM Mason Freed  wrote:
>>
>>>
>>> On Wed, Jan 24, 2024 at 8:10 AM Yoav Weiss (@Shopify) <
>>> yoav...@chromium.org> wrote:
>>>
 Also, what are the timelines you have in mind in terms of deprecation?

>>>
>>> I'd like to try starting to turn the feature off ASAP, in M123, to avoid 
>>> an effect I've discovered where usage spikes when I announce deprecations.
>>>
>>
>> That's odd..
>>  
>>
>>> I would very slowly enable, likely over about 2 months/milestones. Let 
>>> me know if that sounds ok. That's about the schedule I used for the 
>>> `shadowroot` attribute, and that was successful.
>>>  
>>>
>>> On Wed, Jan 24, 2024 at 4:51 PM Daniel Bratell  
 wrote:

> Unreliable use counters sound scary. We base a lot of decisions off 
> those. So far they have only been shown to over-count though? But still, 
> would be great if someone could get a grip on that bug and either fix it 
> or 
> make us understand what is going on.
>
 Yeah, I agree. In my experience (which tends to be a lot of 
>>> deprecations) the usage is always over-counted. My rough theory 
>>> ,
>>>  
>>> if correct, doesn't always mean usage will be over-counted though.
>>>
 For this feature, what is the status of getHTML()? Can we redirect 
> users to it already?
>
  It's implemented, and here's the chromestatus for that 
>>> . I haven't shipped 
>>> it yet, but my plan is to do that ASAP. Ideally I ship it in M123, to 
>>> coincide with this deprecation.
>>>
>>> On 2024-01-23 20:38, 'Dan Clark' via blink-dev wrote:
>
> I guess a theoretical risk is that someone feature-checks for 
> HTMLTemplateElement.shadowRootMode and then assumes the existence of 
> getInnerHTML() based on that check. But given the lack of usage in the 
> top 
> sites I agree that this seems to not be an issue in practice.
>
> I suppose that's a theoretical risk, yes. I bet (hope?) it's rare 
>>> though. 
>>>
 I saw that there's a support email listed at https://www.heap.io/auryc. 
> Maybe worth a ping?
>
> Thanks, I'll give them a ping. I'm not sure it's worth it, given that 
>>> the existing feature detection is already disabled by the lack of the 
>>> `shadowroot` attribute. But no harm.
>>>
>>> Thanks,
>>> Mason
>>>  
>>>
 -- Dan
>
> On Monday, January 22, 2024 at 8:42:43 AM UTC-8 mas...@chromium.org 
> wrote:
>
>> On Mon, Jan 22, 2024 at 8:05 AM Vladimir Levin  
>> wrote:
>>
>>> Yeah, I think the risk is low here.

>>>
>> Great, thanks!
>>  
>>
>>> FWIW, I couldn't find any relevant github or contact info for this 
>>> library but if you had better luck finding contact information, we 
>>> might as 
>>> well file an issue or send an email.
>>>
>>
>> I also tried to find it, but failed. It appears to be closed source.
>>
>> Thanks,
>> Mason
>>
>>  
>>
>>>
 Thanks,
 Mason
   



 *Gecko*: No signal

 *WebKit*: No signal

 *Web developers*: No signals

 *Other signals*:

 WebView application risks 

 Does this intent deprecate or change behavior of existing APIs, 
>>>

Re: [blink-dev] Intent to Deprecate non-standard declarative shadow DOM serialization

[Mason Freed]

On Tue, Feb 6, 2024 at 1:26 AM Yoav Weiss (@Shopify) 
wrote:

> Is this thread meant for both deprecation and removal (given the short
> timelines)?
>
> Apologies for the delay in responding here. It might be worthwhile to
> re-send it with the right title, as it's currently not caught in the API
> owner's tooling (I suspect that's due to a missing ":").
>

Yes, I did hope to do both with this one intent. I’ve learned not to edit
the title of the email (e.g. to say “deprecate AND remove” because then the
tool definitely doesn’t pick it up. I’m not sure what happened to the :, I
didn’t edit it. Sorry for the trouble, and thanks for catching it.

So I should re-send the entire thing?



> On Fri, Jan 26, 2024 at 11:30 PM Mason Freed  wrote:
>
>>
>> On Wed, Jan 24, 2024 at 8:10 AM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>> Also, what are the timelines you have in mind in terms of deprecation?
>>>
>>
>> I'd like to try starting to turn the feature off ASAP, in M123, to avoid
>> an effect I've discovered where usage spikes when I announce deprecations.
>>
>
> That's odd..
>
>
>> I would very slowly enable, likely over about 2 months/milestones. Let me
>> know if that sounds ok. That's about the schedule I used for the
>> `shadowroot` attribute, and that was successful.
>>
>>
>> On Wed, Jan 24, 2024 at 4:51 PM Daniel Bratell 
>>> wrote:
>>>
 Unreliable use counters sound scary. We base a lot of decisions off
 those. So far they have only been shown to over-count though? But still,
 would be great if someone could get a grip on that bug and either fix it or
 make us understand what is going on.

>>> Yeah, I agree. In my experience (which tends to be a lot of
>> deprecations) the usage is always over-counted. My rough theory
>> ,
>> if correct, doesn't always mean usage will be over-counted though.
>>
>>> For this feature, what is the status of getHTML()? Can we redirect users
 to it already?

>>>  It's implemented, and here's the chromestatus for that
>> . I haven't shipped
>> it yet, but my plan is to do that ASAP. Ideally I ship it in M123, to
>> coincide with this deprecation.
>>
>> On 2024-01-23 20:38, 'Dan Clark' via blink-dev wrote:

 I guess a theoretical risk is that someone feature-checks for
 HTMLTemplateElement.shadowRootMode and then assumes the existence of
 getInnerHTML() based on that check. But given the lack of usage in the top
 sites I agree that this seems to not be an issue in practice.

 I suppose that's a theoretical risk, yes. I bet (hope?) it's rare
>> though.
>>
>>> I saw that there's a support email listed at https://www.heap.io/auryc.
 Maybe worth a ping?

 Thanks, I'll give them a ping. I'm not sure it's worth it, given that
>> the existing feature detection is already disabled by the lack of the
>> `shadowroot` attribute. But no harm.
>>
>> Thanks,
>> Mason
>>
>>
>>> -- Dan

 On Monday, January 22, 2024 at 8:42:43 AM UTC-8 mas...@chromium.org
 wrote:

> On Mon, Jan 22, 2024 at 8:05 AM Vladimir Levin 
> wrote:
>
>> Yeah, I think the risk is low here.
>>>
>>
> Great, thanks!
>
>
>> FWIW, I couldn't find any relevant github or contact info for this
>> library but if you had better luck finding contact information, we might 
>> as
>> well file an issue or send an email.
>>
>
> I also tried to find it, but failed. It appears to be closed source.
>
> Thanks,
> Mason
>
>
>
>>
>>> Thanks,
>>> Mason
>>>
>>>
>>>
>>>
>>> *Gecko*: No signal
>>>
>>> *WebKit*: No signal
>>>
>>> *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
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?No
>>>
>>> Flag name on chrome://flagsNone
>>>
>>> Finch feature nameNone
>>>
>>> Non-finch justificationNone
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://crbug.com/1519972
>>>
>>> Estimated milestones
>>>
>>> No milestones specified
>>>
>>>
>>> Link to entry on the Chrome Platform Statushttps://chromestatus.com/
>>> feature/5081733588582400
>>>
>>> This intent message was generated by me, manually, because of this
>>> bug 
>>> .
>>>
>>> --

Re: [blink-dev] Intent to Deprecate non-standard declarative shadow DOM serialization

[Yoav Weiss (@Shopify)]

Is this thread meant for both deprecation and removal (given the short
timelines)?

Apologies for the delay in responding here. It might be worthwhile to
re-send it with the right title, as it's currently not caught in the API
owner's tooling (I suspect that's due to a missing ":").

On Fri, Jan 26, 2024 at 11:30 PM Mason Freed  wrote:

>
> On Wed, Jan 24, 2024 at 8:10 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>> Also, what are the timelines you have in mind in terms of deprecation?
>>
>
> I'd like to try starting to turn the feature off ASAP, in M123, to avoid
> an effect I've discovered where usage spikes when I announce deprecations.
>

That's odd..


> I would very slowly enable, likely over about 2 months/milestones. Let me
> know if that sounds ok. That's about the schedule I used for the
> `shadowroot` attribute, and that was successful.
>
>
> On Wed, Jan 24, 2024 at 4:51 PM Daniel Bratell 
>> wrote:
>>
>>> Unreliable use counters sound scary. We base a lot of decisions off
>>> those. So far they have only been shown to over-count though? But still,
>>> would be great if someone could get a grip on that bug and either fix it or
>>> make us understand what is going on.
>>>
>> Yeah, I agree. In my experience (which tends to be a lot of deprecations)
> the usage is always over-counted. My rough theory
> ,
> if correct, doesn't always mean usage will be over-counted though.
>
>> For this feature, what is the status of getHTML()? Can we redirect users
>>> to it already?
>>>
>>  It's implemented, and here's the chromestatus for that
> . I haven't shipped it
> yet, but my plan is to do that ASAP. Ideally I ship it in M123, to coincide
> with this deprecation.
>
> On 2024-01-23 20:38, 'Dan Clark' via blink-dev wrote:
>>>
>>> I guess a theoretical risk is that someone feature-checks for
>>> HTMLTemplateElement.shadowRootMode and then assumes the existence of
>>> getInnerHTML() based on that check. But given the lack of usage in the top
>>> sites I agree that this seems to not be an issue in practice.
>>>
>>> I suppose that's a theoretical risk, yes. I bet (hope?) it's rare
> though.
>
>> I saw that there's a support email listed at https://www.heap.io/auryc.
>>> Maybe worth a ping?
>>>
>>> Thanks, I'll give them a ping. I'm not sure it's worth it, given that
> the existing feature detection is already disabled by the lack of the
> `shadowroot` attribute. But no harm.
>
> Thanks,
> Mason
>
>
>> -- Dan
>>>
>>> On Monday, January 22, 2024 at 8:42:43 AM UTC-8 mas...@chromium.org
>>> wrote:
>>>
 On Mon, Jan 22, 2024 at 8:05 AM Vladimir Levin 
 wrote:

> Yeah, I think the risk is low here.
>>
>
 Great, thanks!


> FWIW, I couldn't find any relevant github or contact info for this
> library but if you had better luck finding contact information, we might 
> as
> well file an issue or send an email.
>

 I also tried to find it, but failed. It appears to be closed source.

 Thanks,
 Mason



>
>> Thanks,
>> Mason
>>
>>
>>
>>
>> *Gecko*: No signal
>>
>> *WebKit*: No signal
>>
>> *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
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?No
>>
>> Flag name on chrome://flagsNone
>>
>> Finch feature nameNone
>>
>> Non-finch justificationNone
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/1519972
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Link to entry on the Chrome Platform Statushttps://chromestatus.com/
>> feature/5081733588582400
>>
>> This intent message was generated by me, manually, because of this
>> bug .
>>
>> --
>> 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/CAM%3DNeDhpHobDUy1VwZ2rmy5DBUVfsm8
>> ijXOEtk%2B1eHjJgu6FRg%40mail.gmail.com
>> 

Re: [blink-dev] Intent to Deprecate non-standard declarative shadow DOM serialization

[Mason Freed]

On Wed, Jan 24, 2024 at 8:10 AM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

> Also, what are the timelines you have in mind in terms of deprecation?
>

I'd like to try starting to turn the feature off ASAP, in M123, to avoid an
effect I've discovered where usage spikes when I announce deprecations. I
would very slowly enable, likely over about 2 months/milestones. Let me
know if that sounds ok. That's about the schedule I used for the
`shadowroot` attribute, and that was successful.


On Wed, Jan 24, 2024 at 4:51 PM Daniel Bratell  wrote:
>
>> Unreliable use counters sound scary. We base a lot of decisions off
>> those. So far they have only been shown to over-count though? But still,
>> would be great if someone could get a grip on that bug and either fix it or
>> make us understand what is going on.
>>
> Yeah, I agree. In my experience (which tends to be a lot of deprecations)
the usage is always over-counted. My rough theory
,
if correct, doesn't always mean usage will be over-counted though.

> For this feature, what is the status of getHTML()? Can we redirect users
>> to it already?
>>
>  It's implemented, and here's the chromestatus for that
. I haven't shipped it
yet, but my plan is to do that ASAP. Ideally I ship it in M123, to coincide
with this deprecation.

On 2024-01-23 20:38, 'Dan Clark' via blink-dev wrote:
>>
>> I guess a theoretical risk is that someone feature-checks for
>> HTMLTemplateElement.shadowRootMode and then assumes the existence of
>> getInnerHTML() based on that check. But given the lack of usage in the top
>> sites I agree that this seems to not be an issue in practice.
>>
>> I suppose that's a theoretical risk, yes. I bet (hope?) it's rare though.

> I saw that there's a support email listed at https://www.heap.io/auryc.
>> Maybe worth a ping?
>>
>> Thanks, I'll give them a ping. I'm not sure it's worth it, given that the
existing feature detection is already disabled by the lack of the
`shadowroot` attribute. But no harm.

Thanks,
Mason


> -- Dan
>>
>> On Monday, January 22, 2024 at 8:42:43 AM UTC-8 mas...@chromium.org
>> wrote:
>>
>>> On Mon, Jan 22, 2024 at 8:05 AM Vladimir Levin 
>>> wrote:
>>>
 Yeah, I think the risk is low here.
>

>>> Great, thanks!
>>>
>>>
 FWIW, I couldn't find any relevant github or contact info for this
 library but if you had better luck finding contact information, we might as
 well file an issue or send an email.

>>>
>>> I also tried to find it, but failed. It appears to be closed source.
>>>
>>> Thanks,
>>> Mason
>>>
>>>
>>>

> Thanks,
> Mason
>
>
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *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
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> Flag name on chrome://flagsNone
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1519972
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Statushttps://chromestatus.com/
> feature/5081733588582400
>
> This intent message was generated by me, manually, because of this bug
> .
>
> --
> 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/CAM%3DNeDhpHobDUy1VwZ2rmy5DBUVfsm8
> ijXOEtk%2B1eHjJgu6FRg%40mail.gmail.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.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc371f9a-e39b-40cb-9941-c0b4dcc76342n%40chromium.org
>> 

Re: [blink-dev] Intent to Deprecate non-standard declarative shadow DOM serialization

[Yoav Weiss (@Shopify)]

Also, what are the timelines you have in mind in terms of deprecation?

On Wed, Jan 24, 2024 at 4:51 PM Daniel Bratell  wrote:

> Unreliable use counters sound scary. We base a lot of decisions off those.
> So far they have only been shown to over-count though? But still, would be
> great if someone could get a grip on that bug and either fix it or make us
> understand what is going on.
>
> For this feature, what is the status of getHTML()? Can we redirect users
> to it already?
>
> /Daniel
> On 2024-01-23 20:38, 'Dan Clark' via blink-dev wrote:
>
> I guess a theoretical risk is that someone feature-checks for
> HTMLTemplateElement.shadowRootMode and then assumes the existence of
> getInnerHTML() based on that check. But given the lack of usage in the top
> sites I agree that this seems to not be an issue in practice.
>
> I saw that there's a support email listed at https://www.heap.io/auryc.
> Maybe worth a ping?
>
> -- Dan
>
> On Monday, January 22, 2024 at 8:42:43 AM UTC-8 mas...@chromium.org wrote:
>
>> On Mon, Jan 22, 2024 at 8:05 AM Vladimir Levin  wrote:
>>
>>> Yeah, I think the risk is low here.

>>>
>> Great, thanks!
>>
>>
>>> FWIW, I couldn't find any relevant github or contact info for this
>>> library but if you had better luck finding contact information, we might as
>>> well file an issue or send an email.
>>>
>>
>> I also tried to find it, but failed. It appears to be closed source.
>>
>> Thanks,
>> Mason
>>
>>
>>
>>>
 Thanks,
 Mason




 *Gecko*: No signal

 *WebKit*: No signal

 *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


 Is this feature fully tested by web-platform-tests
 
 ?No

 Flag name on chrome://flagsNone

 Finch feature nameNone

 Non-finch justificationNone

 Requires code in //chrome?False

 Tracking bughttps://crbug.com/1519972

 Estimated milestones

 No milestones specified


 Link to entry on the Chrome Platform Statushttps://chromestatus.com/
 feature/5081733588582400

 This intent message was generated by me, manually, because of this bug
 .

 --
 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/CAM%3DNeDhpHobDUy1VwZ2rmy5DBUVfsm8
 ijXOEtk%2B1eHjJgu6FRg%40mail.gmail.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.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc371f9a-e39b-40cb-9941-c0b4dcc76342n%40chromium.org
> 
> .
>
> --
> 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/8357e80a-5b6b-4c73-83e7-de19e8ca1a37%40gmail.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.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKmPxizyAqwxuz5w-HwaULCX6x9yQv7sciwR7Yq2Rbeuw%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate non-standard declarative shadow DOM serialization

[Daniel Bratell]

Unreliable use counters sound scary. We base a lot of decisions off 
those. So far they have only been shown to over-count though? But still, 
would be great if someone could get a grip on that bug and either fix it 
or make us understand what is going on.


For this feature, what is the status of getHTML()? Can we redirect users 
to it already?


/Daniel

On 2024-01-23 20:38, 'Dan Clark' via blink-dev wrote:
I guess a theoretical risk is that someone feature-checks for 
HTMLTemplateElement.shadowRootMode and then assumes the existence of 
getInnerHTML() based on that check. But given the lack of usage in the 
top sites I agree that this seems to not be an issue in practice.


I saw that there's a support email listed at 
https://www.heap.io/auryc. Maybe worth a ping?


-- Dan

On Monday, January 22, 2024 at 8:42:43 AM UTC-8 mas...@chromium.org wrote:

On Mon, Jan 22, 2024 at 8:05 AM Vladimir Levin 
wrote:

Yeah, I think the risk is low here.


Great, thanks!

FWIW, I couldn't find any relevant github or contact info for
this library but if you had better luck finding contact
information, we might as well file an issue or send an email.


I also tried to find it, but failed. It appears to be closed source.

Thanks,
Mason


Thanks,
Mason



/Gecko/: No signal

/WebKit/: No signal

/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



Is this feature fully tested by web-platform-tests

?No

Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Tracking bughttps://crbug.com/1519972

Estimated milestones

No milestones specified



Link to entry on the Chrome Platform
Statushttps://chromestatus.com/feature/5081733588582400


This intent message was generated by me, manually,
because of this bug

.

-- 
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/CAM%3DNeDhpHobDUy1VwZ2rmy5DBUVfsm8ijXOEtk%2B1eHjJgu6FRg%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc371f9a-e39b-40cb-9941-c0b4dcc76342n%40chromium.org 
.


--
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/8357e80a-5b6b-4c73-83e7-de19e8ca1a37%40gmail.com.

Re: [blink-dev] Intent to Deprecate non-standard declarative shadow DOM serialization

['Dan Clark' via blink-dev]

I guess a theoretical risk is that someone feature-checks for 
HTMLTemplateElement.shadowRootMode and then assumes the existence of 
getInnerHTML() based on that check. But given the lack of usage in the top 
sites I agree that this seems to not be an issue in practice.

I saw that there's a support email listed at https://www.heap.io/auryc. 
Maybe worth a ping?

-- Dan

On Monday, January 22, 2024 at 8:42:43 AM UTC-8 mas...@chromium.org wrote:

> On Mon, Jan 22, 2024 at 8:05 AM Vladimir Levin  wrote:
>
>> Yeah, I think the risk is low here.
>>>
>>
> Great, thanks!
>  
>
>> FWIW, I couldn't find any relevant github or contact info for this 
>> library but if you had better luck finding contact information, we might as 
>> well file an issue or send an email.
>>
>
> I also tried to find it, but failed. It appears to be closed source.
>
> Thanks,
> Mason
>
>  
>
>>
>>> Thanks,
>>> Mason
>>>   
>>>
>>>
>>>
>>> *Gecko*: No signal
>>>
>>> *WebKit*: No signal
>>>
>>> *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
>>>
>>>
>>> Is this feature fully tested by web-platform-tests 
>>> 
>>> ?No
>>>
>>> Flag name on chrome://flagsNone
>>>
>>> Finch feature nameNone
>>>
>>> Non-finch justificationNone
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://crbug.com/1519972
>>>
>>> Estimated milestones
>>>
>>> No milestones specified
>>>
>>>
>>> Link to entry on the Chrome Platform Statushttps://chromestatus.com/
>>> feature/5081733588582400
>>>
>>> This intent message was generated by me, manually, because of this bug 
>>> .
>>>
>>> -- 
>>> 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/CAM%3DNeDhpHobDUy1VwZ2rmy5DBUVfsm8
>>> ijXOEtk%2B1eHjJgu6FRg%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc371f9a-e39b-40cb-9941-c0b4dcc76342n%40chromium.org.

Re: [blink-dev] Intent to Deprecate non-standard declarative shadow DOM serialization

[Mason Freed]

On Mon, Jan 22, 2024 at 8:05 AM Vladimir Levin  wrote:

> Yeah, I think the risk is low here.
>>
>
Great, thanks!


> FWIW, I couldn't find any relevant github or contact info for this library
> but if you had better luck finding contact information, we might as well
> file an issue or send an email.
>

I also tried to find it, but failed. It appears to be closed source.

Thanks,
Mason



>
>> Thanks,
>> Mason
>>
>>
>>
>>
>> *Gecko*: No signal
>>
>> *WebKit*: No signal
>>
>> *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
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?No
>>
>> Flag name on chrome://flagsNone
>>
>> Finch feature nameNone
>>
>> Non-finch justificationNone
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/1519972
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Link to entry on the Chrome Platform Statushttps://chromestatus.com/
>> feature/5081733588582400
>>
>> This intent message was generated by me, manually, because of this bug
>> .
>>
>> --
>> 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/CAM%3DNeDhpHobDUy1VwZ2rmy5DBUVfsm8
>> ijXOEtk%2B1eHjJgu6FRg%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDhTLf3qQU%2B%3DowEZUKxc5WfRmaDC%3D4pzdErLAHTa4xve-Q%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate non-standard declarative shadow DOM serialization

['Vladimir Levin' via blink-dev]

On Fri, Jan 19, 2024 at 7:54 PM Mason Freed  wrote:

>
>
> On Friday, January 19, 2024 at 12:27:50 PM UTC-8 vmp...@google.com wrote:
>
> Interoperability and Compatibility
>
> The use counter for getInnerHTML() (https://chromestatus.com/
> metrics/feature/timeline/popularity/3874) shows 0.04% of page loads using
> this function as of January 2024. That represents high usage for
> deprecation, however, the numbers were quite similar for the deprecation of
> the old `shadowroot` attribute, and the removal of that feature generated
> zero bug reports. It is my strong belief that since this feature is only
> shipped in Chrome, the vast majority of usage is guarded by feature checks.
> So this deprecation should be safer than it would seem from the numbers. My
> plan is to very slowly disable the API and monitor closely for bug reports.
> That approach was quite successful for the removal of shadowroot. If bugs
> are reported, I'll back off and make a new plan.
>
>
> I agree that I expect most uses to be feature checked. That being said,
> have you tried to figure out where the 0.04% is coming from? Is it a lot of
> small uses or a few big sites that keep using it? If it's the latter, it
> may be worth it to reach out.
>
>
> That's a good point. So I just took a look a the top 8 users from the use
> counter page
> . Of
> those, 2 do not contain any usage of getInnerHTML(). All 6 of the remainder
> come from one single library,  "Auryc JavaScript Client-Side Library". And
> that library a) already feature checks for declarative shadow DOM before
> using getInnerHTML(), and further b) feature checks the *old* `shadowroot`
> attribute. So I suspect the use counter is already overcounting the usage
> -  see this bug for why
> .
>

> Thanks for pushing on this - let me know if the above convinces you that
> the risk should be low.
>

Yeah, I think the risk is low here.

FWIW, I couldn't find any relevant github or contact info for this library
but if you had better luck finding contact information, we might as well
file an issue or send an email.


> Thanks,
> Mason
>
>
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *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
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> Flag name on chrome://flagsNone
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1519972
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Statushttps://chromestatus.com/
> feature/5081733588582400
>
> This intent message was generated by me, manually, because of this bug
> .
>
> --
> 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/CAM%3DNeDhpHobDUy1VwZ2rmy5DBUVfsm8
> ijXOEtk%2B1eHjJgu6FRg%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2PfrHxBnr_u6Cc1T7-TtVnQM7RUNKV47zcsvRr7-jUuGg%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate non-standard declarative shadow DOM serialization

[Mason Freed]

On Friday, January 19, 2024 at 12:27:50 PM UTC-8 vmp...@google.com wrote:

Interoperability and Compatibility

The use counter for getInnerHTML() (https://chromestatus.com/
metrics/feature/timeline/popularity/3874) shows 0.04% of page loads using 
this function as of January 2024. That represents high usage for 
deprecation, however, the numbers were quite similar for the deprecation of 
the old `shadowroot` attribute, and the removal of that feature generated 
zero bug reports. It is my strong belief that since this feature is only 
shipped in Chrome, the vast majority of usage is guarded by feature checks. 
So this deprecation should be safer than it would seem from the numbers. My 
plan is to very slowly disable the API and monitor closely for bug reports. 
That approach was quite successful for the removal of shadowroot. If bugs 
are reported, I'll back off and make a new plan.


I agree that I expect most uses to be feature checked. That being said, 
have you tried to figure out where the 0.04% is coming from? Is it a lot of 
small uses or a few big sites that keep using it? If it's the latter, it 
may be worth it to reach out.


That's a good point. So I just took a look a the top 8 users from the use 
counter page 
. Of 
those, 2 do not contain any usage of getInnerHTML(). All 6 of the remainder 
come from one single library,  "Auryc JavaScript Client-Side Library". And 
that library a) already feature checks for declarative shadow DOM before 
using getInnerHTML(), and further b) feature checks the *old* `shadowroot` 
attribute. So I suspect the use counter is already overcounting the usage 
-  see this bug for why 
.

Thanks for pushing on this - let me know if the above convinces you that 
the risk should be low.

Thanks,
Mason
  



*Gecko*: No signal

*WebKit*: No signal

*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


Is this feature fully tested by web-platform-tests 

?No

Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Tracking bughttps://crbug.com/1519972

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Statushttps://chromestatus.com/
feature/5081733588582400

This intent message was generated by me, manually, because of this bug 
.

-- 
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/CAM%3DNeDhpHobDUy1VwZ2rmy5DBUVfsm8
ijXOEtk%2B1eHjJgu6FRg%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1f18b37f-95e4-4901-a4cd-22a2220a8c26n%40chromium.org.

Re: [blink-dev] Intent to Deprecate non-standard declarative shadow DOM serialization

['Vladimir Levin' via blink-dev]

On Fri, Jan 19, 2024 at 3:13 PM Mason Freed  wrote:

> Contact emailsmas...@chromium.org
>
> Explainer
> https://github.com/whatwg/html/issues/8867#issuecomment-1856696628
>
> SpecificationNone
>
> Summary
>
> The prototype implementation (which was shipped in 2020 and then
> shape-changed in 2023) contained a method called `getInnerHTML()` that
> could be used to serialize DOM trees containing shadow roots. That part of
> the prototype was not standardized with the rest of declarative shadow dom,
> and only recently has it reached spec consensus (
> https://github.com/whatwg/html/issues/8867). As part of that consensus,
> the shape of the getInnerHTML API changed. This feature represents the
> deprecation of the old, shipped `getInnerHTML()` method. The replacement is
> called `getHTML()`: see
> https://chromestatus.com/guide/edit/5102952270528512.
>
> Blink componentBlink>DOM>ShadowDOM
> 
>
> Motivation
>
> The standardized method, getHTML(), has the chance at being interoperable,
> while this version (getInnerHTML) does not.
>
> Initial public proposal
> https://github.com/whatwg/html/issues/8867#issuecomment-1856696628
>
> TAG reviewNone
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
> The use counter for getInnerHTML() (
> https://chromestatus.com/metrics/feature/timeline/popularity/3874) shows
> 0.04% of page loads using this function as of January 2024. That represents
> high usage for deprecation, however, the numbers were quite similar for the
> deprecation of the old `shadowroot` attribute, and the removal of that
> feature generated zero bug reports. It is my strong belief that since this
> feature is only shipped in Chrome, the vast majority of usage is guarded by
> feature checks. So this deprecation should be safer than it would seem from
> the numbers. My plan is to very slowly disable the API and monitor closely
> for bug reports. That approach was quite successful for the removal of
> shadowroot. If bugs are reported, I'll back off and make a new plan.
>

I agree that I expect most uses to be feature checked. That being said,
have you tried to figure out where the 0.04% is coming from? Is it a lot of
small uses or a few big sites that keep using it? If it's the latter, it
may be worth it to reach out.


>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *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
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> Flag name on chrome://flagsNone
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1519972
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5081733588582400
>
> This intent message was generated by me, manually, because of this bug
> .
>
> --
> 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/CAM%3DNeDhpHobDUy1VwZ2rmy5DBUVfsm8ijXOEtk%2B1eHjJgu6FRg%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2P45gzFsjbBgpLpr3aNAYHH0HC%2BY7GEYfXSzw07L-tBkA%40mail.gmail.com.