Thanks for driving this, it's important to find a path to removal for Shadow DOM v0, as otherwise the APIs may be used by accident or deliberately in a way that could eventually put pressure on other to implement v0 as well.Usage here is very high. Lately we have preferred to set a removal date at deprecation time and include that in the deprecation message. Is that feasible in this case, what would need to happen before attempting a removal?
On Thu, Nov 24, 2016 at 6:14 PM Philip Jägenstedt <foo...@chromium.org> wrote:Thanks for driving this, it's important to find a path to removal for Shadow DOM v0, as otherwise the APIs may be used by accident or deliberately in a way that could eventually put pressure on other to implement v0 as well.Usage here is very high. Lately we have preferred to set a removal date at deprecation time and include that in the deprecation message. Is that feasible in this case, what would need to happen before attempting a removal?Thanks. Including a removal date would be a good idea to decrease the usage. I can include a removal date in the Shadow DOM v0 deprecation message, but is that a commitment to remove? For example, if the usage is still high enough at the removal date, we would remove it unconditionally? If so, I have to be careful to set a removal date, one year later or more than it.What need to happen before attempting a removal is:- Chrome/Blink itself has to remove the internal usage of Shadow DOM v0. I guess devtools and setting pages are still using Shadow DOM v0 (please correct me if I am wrong). They have to rewrite it if they are still using v0.- Regarding Polymer, Polymer has not used native Shadow DOM v0 by default recently. I do not worry much about it.- Maybe there are other users which use Shadow DOM v0, outside of Blink, like an AdBlock Extension, ATOM Editor (which is removing Shadow DOM). They have to stop using v0.Starting to deprecation would reveal hidden users, and encourage them to switch to v1, I expect.As of now, I can not think of any better way to decrease the usage of Shadow DOM v0, other than deprecating it (with a removal date).
On Thu, Nov 24, 2016 at 12:10 PM Hayato Ito <hay...@chromium.org> wrote:On Thu, Nov 24, 2016 at 6:14 PM Philip Jägenstedt <foo...@chromium.org> wrote:Thanks for driving this, it's important to find a path to removal for Shadow DOM v0, as otherwise the APIs may be used by accident or deliberately in a way that could eventually put pressure on other to implement v0 as well.Usage here is very high. Lately we have preferred to set a removal date at deprecation time and include that in the deprecation message. Is that feasible in this case, what would need to happen before attempting a removal?Thanks. Including a removal date would be a good idea to decrease the usage. I can include a removal date in the Shadow DOM v0 deprecation message, but is that a commitment to remove? For example, if the usage is still high enough at the removal date, we would remove it unconditionally? If so, I have to be careful to set a removal date, one year later or more than it.What need to happen before attempting a removal is:- Chrome/Blink itself has to remove the internal usage of Shadow DOM v0. I guess devtools and setting pages are still using Shadow DOM v0 (please correct me if I am wrong). They have to rewrite it if they are still using v0.- Regarding Polymer, Polymer has not used native Shadow DOM v0 by default recently. I do not worry much about it.- Maybe there are other users which use Shadow DOM v0, outside of Blink, like an AdBlock Extension, ATOM Editor (which is removing Shadow DOM). They have to stop using v0.Starting to deprecation would reveal hidden users, and encourage them to switch to v1, I expect.As of now, I can not think of any better way to decrease the usage of Shadow DOM v0, other than deprecating it (with a removal date).There are indeed calls to createShadowRoot in chrome/, extensions/ and third_party/WebKit/Source/devtools/. UseCounter::countIfNotPrivateScript is used, but I wouldn't assume that all of these cases are excluded, so usage could be inflated by internal usage. Rewriting all of those would be a good first step.
Beyond that, if the true usage is anywhere near 2%, then it's probably used on some pretty big sites. As an experiment, can you make it crash and browse some of http://www.alexa.com/topsites? With any luck, fixing just one case will cause usage to drop sharply.
There's also httparchive, where there's >100k hits for 'createShadowRoot'. It's a lot of work, but categorizing those results should tell you what the problematic usage out there is, and give you a list of sites to reach out to. Happy to provide some tips off-list.
When usage is this high, I think you're right that just deprecating will reduce usage, but if anything like 0.1% would currently be broken by removal and if it's in the long tail of sites, then I wouldn't expect deprecation alone to drive down the breaking usage to a significant degree.
Thank you for the advice. I appreciate it. Let me follow the advice to figure out what is causing 2.2% at first.I agree that 2.2% is too high to deprecate. We would hesitate to deprecate it because that would spam the console. People are likely to ignore the spam.Given the usecounter chart (https://www.chromestatus.com/metrics/feature/timeline/popularity/456), I think 2.2% number is coming from a limited big sources. There are two big spikes in the chart; Sep 2014 and Jun 2016.Regarding a spike at Jun 2016, it could be caused by twitter (https://twittercommunity.com/t/upcoming-change-to-embedded-tweet-display-on-web/66215). But this is just a guess. I have not tried to figure out the details of the usage so far.It sounds that there is no silver bullets to analyze the details. Let me start with http://www.alenxa.com/topsites and httparchive at first.I have one question; Does a usecounter include a usage from a chrome extension? I am afraid that AdBlock Plus occupies the majority of the number.
The harder case is extensions that inject code into pages. I don't think there's anything practical to do about those - just continue treating them the same as code on the page. Do you know if AdBlock Plus does that?
On Fri, Nov 25, 2016 at 2:11 AM, Hayato Ito <hay...@chromium.org> wrote:Thank you for the advice. I appreciate it. Let me follow the advice to figure out what is causing 2.2% at first.I agree that 2.2% is too high to deprecate. We would hesitate to deprecate it because that would spam the console. People are likely to ignore the spam.Given the usecounter chart (https://www.chromestatus.com/metrics/feature/timeline/popularity/456), I think 2.2% number is coming from a limited big sources. There are two big spikes in the chart; Sep 2014 and Jun 2016.Regarding a spike at Jun 2016, it could be caused by twitter (https://twittercommunity.com/t/upcoming-change-to-embedded-tweet-display-on-web/66215). But this is just a guess. I have not tried to figure out the details of the usage so far.It sounds that there is no silver bullets to analyze the details. Let me start with http://www.alenxa.com/topsites and httparchive at first.I have one question; Does a usecounter include a usage from a chrome extension? I am afraid that AdBlock Plus occupies the majority of the number.
Yes, I believe they do today. I'm working to eliminate cases like chrome-extension://. These are still a type of compat risk of course (could break a lot of page views for users that have popular extensions installed) but I argue that the risk is of an entirely different form (which we shouldn't conflate with "web compat risk") because the user can uninstall the extension, popular extensions would likely be updated quickly, etc.The harder case is extensions that inject code into pages. I don't think there's anything practical to do about those - just continue treating them the same as code on the page. Do you know if AdBlock Plus does that?Another way you can get some idea of where the usage is coming from is by slicing the UMA data along different axes. Eg. here's (internal only - sorry) a breakdown of the metric by OS and low and behold we see ~2.5% on windows but 0.015% on Android! That is some strong evidence supporting your AdBlock Plus theory ;-)
On Thu, Nov 24, 2016 at 6:14 PM Philip Jägenstedt <foo...@chromium.org> wrote:Thanks for driving this, it's important to find a path to removal for Shadow DOM v0, as otherwise the APIs may be used by accident or deliberately in a way that could eventually put pressure on other to implement v0 as well.Usage here is very high. Lately we have preferred to set a removal date at deprecation time and include that in the deprecation message. Is that feasible in this case, what would need to happen before attempting a removal?Thanks. Including a removal date would be a good idea to decrease the usage. I can include a removal date in the Shadow DOM v0 deprecation message, but is that a commitment to remove? For example, if the usage is still high enough at the removal date, we would remove it unconditionally? If so, I have to be careful to set a removal date, one year later or more than it.What need to happen before attempting a removal is:- Chrome/Blink itself has to remove the internal usage of Shadow DOM v0. I guess devtools and setting pages are still using Shadow DOM v0 (please correct me if I am wrong). They have to rewrite it if they are still using v0.
I would like to add, though, that we don't need to wait until usage actually drops before going ahead with deprecation and removal, we just need to have a fairly good idea that the removal will work out. So, if AdBlock (Plus) is very slow to update, but httparchive shows very low risk in web content, I think it's fine to go ahead. Console spam isn't great, but leaving Shadow DOM v0 around is also not without risk.