Intent to Deprecate: -webkit-user-modify

Xiaocheng Hu

unread,

Feb 1, 2017, 2:39:32 AM2/1/17

to blink-dev

Primary eng (and PM) emails

xiaoc...@chromium.org

Summary

Deprecate the non-standard -webkit-user-modify CSS property.

Motivation

1. Interoperability. Historically, -webkit-user-modify was introduced to define editability on elements. However, CSSWG rejected to standardize it [1]. Since we already have the HTML5 contenteditable attribute to define editability, it is time for -webkit-user-modify to leave the stage.

2. Performance. With -webkit-user-modify, we need clean style to check whether an element is editable, and we know that style update is expensive. On the other hand, editability defined by contentEditable is much cheaper to obtain --- a bottom-up search in the DOM tree suffices.

3. Correctness. The current implementation sometimes checks editability during style update [2], for which it is impossible to get a correct result. While the existing code should not do that, fixing it directly can be over-complicated and error-prone. Decoupling editability from style avoids the issue completely.

Compatibility And Interoperability Risk

Low, as the property is non-standard and not supported by all other browsers.

Edge: Supported.

Firefox: Not supported.

Safari: Supported, but has considered deprecation [3].

Web developers: No signals.

Alternative implementation suggestion for web developers

Developers should use the contenteditable attribute for better interoperability and performance.

Usage information from UseCounter

1.6231%.

https://www.chromestatus.com/metrics/css/popularity#webkit-user-modify

OWP launch tracking bug

crbug.com/687462

Entry on the feature dashboard

https://www.chromestatus.com/feature/4725222129270784

Requesting approval to remove too?

No, for the following reasons:

1. The usage is still too high;

2. In the current implementation, -webkit-user-modify is used to implement contenteditable, so we need to reimplement contenteditable before removing -webkit-user-modify.

[1] https://lists.w3.org/Archives/Public/www-style/2015May/0051.html

[2] http://crbug.com/667685

[3] https://bugs.webkit.org/show_bug.cgi?id=52025

fri...@gmail.com

unread,

Feb 1, 2017, 3:58:06 AM2/1/17

to blink-dev

Hi,

I'm the editor of the spec user-modify would go into if it were standardized (CSS-UI Level 4).
I'm supportive of deprecating this, and of trying eventually to get rid of it entirely (and if we fail, eventually we'll have to standardize it despite the original unwillingness to do so).

However, before removal can happen, there are some subtle behavior differences in Chrome's implementation that make -webkit-user-modify desirable over contenteditable in some cases. Dealing with that seems like it would help both with the deprecation and the possible eventual removal.

Here's one difference I am aware of and which I plan to report soon: http://jsbin.com/vuladoz/edit?html,css,output

By the way, a better links to the CSSWG's decision to not spec it would be:
https://lists.w3.org/Archives/Public/www-style/2015Apr/0406.html
and https://lists.w3.org/Archives/Public/www-style/2015May/0101.html

—Florian

PhistucK

unread,

Feb 1, 2017, 4:32:50 AM2/1/17

to Xiaocheng Hu, blink-dev

Though it is not a complete replacement. For example, it was used to avoid typing issues in the Android browser of Android 2.3 (Gingerbread) in transformed/transitioned fields by using the read-write-plaintext-only value.

I realize it was a workaround that should not affect current browsers and systems, but the point is that it is not a boolean property like contenteditable sort of is. Does contenteditable has a plain text value?

Example -

data:text/html,<!doctype html>Plaint text only -<div style="-webkit-user-modify: read-write-plaintext-only;border: 1px solid black"></div>Formatted content -<div style="-webkit-user-modify: read-write;border: 1px solid black"></div>

Copy the content of this e-mail or page into the first box and then to the second box and you will see the difference.

I suggest that before the deprecation (due to the current very high usage), you will count the usage per scenario. Example -

read-write-plaintext-only on a form control (which means it is already in plain text only mode) will be counted separately (and can probably be removed anyway, since it does nothing except maybe changing the computed style).

read-only on non readonly/disabled form controls (this does change things, I believe).

And read-write (and friends) on elements without contenteditable (neither HTML and IDL or on their ancestors). Those will have a significant effect.

Same goes for elements with contenteditable (in HTML or IDL or on their ancestor) and read-only value.

Also, does the user-agent-stylesheet originated use (as a result of having contenteditable on an element) participate in this use counter?

Having frequent warnings will just be spam, so the usage must be isolated to cases where it actually affects something first and reported mostly for those cases.

☆PhistucK

--
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+unsubscribe@chromium.org.

Xiaocheng

unread,

Feb 1, 2017, 4:36:40 AM2/1/17

to blink-dev, fri...@gmail.com

Hi Florian,

On Wednesday, February 1, 2017 at 5:58:06 PM UTC+9, fri...@gmail.com wrote:

Hi,

I'm the editor of the spec user-modify would go into if it were standardized (CSS-UI Level 4).
I'm supportive of deprecating this, and of trying eventually to get rid of it entirely (and if we fail, eventually we'll have to standardize it despite the original unwillingness to do so).

Thanks!

However, before removal can happen, there are some subtle behavior differences in Chrome's implementation that make -webkit-user-modify desirable over contenteditable in some cases. Dealing with that seems like it would help both with the deprecation and the possible eventual removal.

Here's one difference I am aware of and which I plan to report soon: http://jsbin.com/vuladoz/edit?html,css,output

This should be a bug. I haven't investigated much, but guess it has the same root cause as crbug.com/583631, since pasting and drap&drop share a lot of code.

Anyway, this is a blocking issue and should be fixed.

fri...@gmail.com

unread,

Feb 1, 2017, 4:42:13 AM2/1/17

to blink-dev, fri...@gmail.com

Hi Xiaocheng,

On Wednesday, February 1, 2017 at 6:36:40 PM UTC+9, Xiaocheng wrote:

On Wednesday, February 1, 2017 at 5:58:06 PM UTC+9, fri...@gmail.com wrote:
However, before removal can happen, there are some subtle behavior differences in Chrome's implementation that make -webkit-user-modify desirable over contenteditable in some cases. Dealing with that seems like it would help both with the deprecation and the possible eventual removal.

Here's one difference I am aware of and which I plan to report soon: http://jsbin.com/vuladoz/edit?html,css,output

This should be a bug. I haven't investigated much, but guess it has the same root cause as crbug.com/583631, since pasting and drap&drop share a lot of code.

Anyway, this is a blocking issue and should be fixed.

I agree, this seems to be the same bug, thanks for looking into it. If I find other differences between contenteditable and -webkit-user-modify, I'll report them and mark the as blocker to Issue 687462 as well.

—Florian

Xiaocheng

unread,

Feb 1, 2017, 5:22:07 AM2/1/17

to blink-dev, xiaoc...@chromium.org

Hi PhistucK,

On Wednesday, February 1, 2017 at 6:32:50 PM UTC+9, PhistucK wrote:

Though it is not a complete replacement. For example, it was used to avoid typing issues in the Android browser of Android 2.3 (Gingerbread) in transformed/transitioned fields by using the read-write-plaintext-only value.
I realize it was a workaround that should not affect current browsers and systems, but the point is that it is not a boolean property like contenteditable sort of is. Does contenteditable has a plain text value?

The preferred approach to plain-text editing is <input> and <textarea>.

Btw, Blink has a non-standard contenteditable="plaintext-only", for which I'm also considering deprecation...

Example -
data:text/html,<!doctype html>Plaint text only -<div style="-webkit-user-modify: read-write-plaintext-only;border: 1px solid black"></div>Formatted content -<div style="-webkit-user-modify: read-write;border: 1px solid black"></div>
Copy the content of this e-mail or page into the first box and then to the second box and you will see the difference.

I suggest that before the deprecation (due to the current very high usage), you will count the usage per scenario. Example -
read-write-plaintext-only on a form control (which means it is already in plain text only mode) will be counted separately (and can probably be removed anyway, since it does nothing except maybe changing the computed style).
read-only on non readonly/disabled form controls (this does change things, I believe).
And read-write (and friends) on elements without contenteditable (neither HTML and IDL or on their ancestors). Those will have a significant effect.
Same goes for elements with contenteditable (in HTML or IDL or on their ancestor) and read-only value.

Thanks for the idea!

Also, does the user-agent-stylesheet originated use (as a result of having contenteditable on an element) participate in this use counter?

If I understand correctly, US stylesheets are not counted:

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/parser/CSSPropertyParser.cpp?rcl=ab70c862d2b27087dd382a65a00001c666550cdd&l=127

Having frequent warnings will just be spam, so the usage must be isolated to cases where it actually affects something first and reported mostly for those cases.

Agreed.

PhistucK

unread,

Feb 1, 2017, 5:37:04 AM2/1/17

to Xiaocheng, blink-dev

But it is nonstandard for <input> and <textarea> to receive document.execCommand commands (if I remember correctly), while contenteditable elements do get them (standard), so there is either a functionality loss (if you go by the standard), or an encouragement of nonstandard APIs.

☆PhistucK

PhistucK

unread,

Feb 1, 2017, 5:48:46 AM2/1/17

to Xiaocheng, blink-dev

They also do not accept ::before and ::after, if I remember correctly.

There is also internal usage as well (it is not longer counted as of Chrome 57 if I am not mistaken) that should be removed.

https://cs.chromium.org/search/?q=plaintext-only+-layouttests+-file:src/out/Debug/gen&type=cs

Also, read-write-plaintext-only does not allow the user to add formatted content, but the author of the page can still use and add formatting -

data:text/html,<!doctype html>Plaint text only -<div style="-webkit-user-modify: read-write-plaintext-only;border: 1px solid black">Foo<b>baz</b>bar</div>Formatted content -<div style="-webkit-user-modify: read-write;border: 1px solid black"></div>

So it is not strictly equivalent, there is much functionality loss (especially if you also remove contenteditable="plaintext-only").

To summarize, specific use counters should be added for plain text cases, as most of the functionality loss hides there.

☆PhistucK

Xiaocheng

unread,

Feb 2, 2017, 1:05:36 AM2/2/17

to blink-dev, xiaoc...@chromium.org

Hi PhistucK,

We will add usage counter for each value of -webkit-user-modify. See crbug.com/687843 for tracking.

Thanks for your comments!

Chris Harrelson

unread,

Feb 2, 2017, 8:42:27 PM2/2/17

to Xiaocheng, blink-dev

Hi Xiaocheng,

We have a policy of only deprecating features when we are very confident that we can remove them after a certain amount of time (and to specify that time in advance). At 1.6%, and with other questions raised in this thread already about differences from contenteditable, I don't think we yet have that clear path, so I think we should wait on deprecating this feature before we have a better plan.

Gathering more data (and sending this thread in the first place - lots of good feedback) sounds like a good first step though to reach such a plan.

Thanks,

Chris

Rick Byers

unread,

Feb 2, 2017, 11:12:47 PM2/2/17

to Chris Harrelson, Xiaocheng, blink-dev, Bogdan Brinza

Note also that the fact that Edge has shipped this API is a pretty strong signal that it's really required for web compat (at least when sending a UserAgent string with WebKit in it). The Edge team only ships webkit APIs when it's really important for their user experience. Perhaps Bogdan can comment on how important this particular one was for them? Is there really any hope for removal or should we just standardize it? If not in CSS UI, then in the compat spec where other webkit CSS properties required by web compat end up (when their more natural home prefers to prioritize spec cleanliness over documenting web platform reality).

Florian Rivoal

unread,

Feb 3, 2017, 1:30:53 AM2/3/17

to Rick Byers, Chris Harrelson, Xiaocheng, blink-dev, Bogdan Brinza

If we need to spec this, I'm happy to take it into CSS-UI and to try and convince the WG that we should do that if there's resistance. I much prefer documenting web platform reality over cleanliness. The fact that Edge did implement it is indeed a strong signal that we may need to do that. The fact that they had not done so last time the question was raised was an argument against specifying it, but as that has changed, we may need to revisit.

However, 1.6% seems suspicious. This seems to be an incredibly high number for such an obscure feature, and it is probably worth looking into how it is being used. Maybe some common css-reset or framework uses it by default even when it isn't meant to do anything. If it is a popular library, we should contact the authors to see why they can't use contenteditable instead, and fix whatever showstopper they have first, to see if that makes things better.

I believe this really is something we should try and kill. If we cannot, we'll need to spec it, but think we should give a honest try first.

—Florian

You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/8gZ2qhCOAoc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.

Rick Byers

unread,

Feb 3, 2017, 1:36:39 AM2/3/17

to Florian Rivoal, Chris Harrelson, Xiaocheng, blink-dev, Bogdan Brinza

+1 - agreed on all points. Thanks Florian!

To unsubscribe from this group and all its topics, send an email to blink-dev+unsubscribe@chromium.org.

PhistucK

unread,

Feb 3, 2017, 1:47:40 AM2/3/17

to Rick Byers, Florian Rivoal, Chris Harrelson, Xiaocheng, blink-dev, Bogdan Brinza

Much, much usage in GitHub -

https://github.com/search?l=CSS&q=%22-webkit-user-modify%22&ref=searchresults&type=Code&utf8=%E2%9C%93

I guess many developers enjoys the capability to make something writable (toggled) by changing a class rather than changing the contenteditable attribute.

☆PhistucK

Xiaocheng

unread,

Feb 3, 2017, 8:10:18 AM2/3/17

to blink-dev, rby...@chromium.org, fri...@gmail.com, chri...@chromium.org, xiaoc...@chromium.org, bbr...@microsoft.com

+1 on everything Florian said.

Before further pushing the deprecation, I do need a better understanding of the usage, which should be done before sending this intent. Sorry for my lack of experience.

Now the per-value counters for -webkit-user-modify are already landed. I hope the usage of read-write-plaintext-only is not too high, otherwise the functionality loss is a thing.

I also gut checked the GitHub search result today. Though the number is huge, my intuition is that there are many duplicates and most of them are just setting up a text editor. Some of them even set -webkit-user-modify and contenteditable on the same element/class, or set read-write-plaintext-only on <input> and <textarea>. Besides, some of them are actually Chrome's internal usage (e.g., DevTools' textprompt.css), which we can get rid of.

Anyway, GitHub seems a good entry point for usage study. I will do a more careful usage study later.

Thanks to all advice in this thread!

Rick Byers

unread,

Feb 3, 2017, 10:13:16 AM2/3/17

to Xiaocheng, blink-dev, Florian Rivoal, Chris Harrelson, Bogdan Brinza

Thank you! Perhaps as a first step you may want to remove the usage from DevTools? Often trying to update our own code teaches us something of what web developers may need to deal with :-).

Would it be hard to have UseCounters that trigger only when the property is not redundant with contenteditable? We should be able to ignore those cases when considering the compat impact.

Another potentially useful source of information is the Mozilla bug tracker. If this property is required for web compat (beyond just code looking for WebKit in the UserAgent) then Mozilla folks have likely already debated the pros and cons of adding it.

PhistucK

unread,

Feb 3, 2017, 11:43:19 AM2/3/17

to Rick Byers, Xiaocheng, blink-dev, Florian Rivoal, Chris Harrelson, Bogdan Brinza

While Mozilla may not have -webkit-user-modify (I have not checked), they do have -moz-user-modify, so they may have their own problems here. :(

(It does not have the plaintext thingies, though)

I verified that Edge has implemented the plaintext thingies (it also implements contenteditable="plaintext-only" :().

☆PhistucK

Bogdan Brinza

unread,

Feb 3, 2017, 3:22:37 PM2/3/17

to PhistucK, Rick Byers, Xiaocheng, blink-dev, Florian Rivoal, Chris Harrelson, Grisha Lyukshin

I looked at the Edge history for this feature and some more data on declared values: https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/-webkit-user-modify/

The exact issue we fixed (in May 2015 during large WebKit interop effort) by adding this property was the following:

m.anjuke.com :After click the searching box, it stops responding:

The root cause is that anjuke.com uses a <div> with flag -webkit-user-modify:read-write-plaintext-only to implement the search box where in the <div>'s focus event handler, it displays the search page. In IE the webkit-user-modify flag is not supported, so the <div> is not editable, so there is no focus event, hence no response after clicking the search box.

Some further observations:

Site rank is relatively high, about Top 400 in China – I suspect that was the motivation
I don’t see indication of this being pattern

What’s more interesting is that I found evidence of original implementation creating more problems, than it solved :-). I could find about 10 issues duped to the master bug “Don't allow user-modify styles to propagate through component boundary to match Chrome”.

Basically in the following repro - http://jsfiddle.net/boggydigital/d04n30c4/ we were propagating -webkit-user-modify to intrinsic control contents. For completeness here are the bugs that were resolved by further matching Chrome:

Phone: amazon.com: Keypad does not launch for the fields "Name on Card" and "Enter Code"
edreams.it: Unable to enter text in Departure and Destination
pearsonvue.com:Unable to enter username and password.
leedsunited.com:"SIGN IN" button is not working.
wsr.theorytest.direct.gov.uk: None of the text fields can be selected so no text can be entered
www6.pearsonvue.com : Cannot type in the text boxes
viaggiatreno.it:"Cerca" (Search) button is not working
comprar.eset.es : Unable to write text in text box

I get the feeling we wouldn’t get those bugs if we didn’t implement -webkit-user-modify the way we did or never supported it, so personally I’d say supporting it was net negative for us.

Generally we would be happy to help do some more data analysis on our end. From the platform perspective it doesn’t seem like the right solution – so we would be happy to coordinate any change here.

I’m adding Grisha, who is our resident editing expert who should be able to help further!

☆PhistucK

Thanks for your comments!

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.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+...@chromium.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+...@chromium.org.

--

You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/8gZ2qhCOAoc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.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+...@chromium.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+...@chromium.org.

Florian Rivoal

unread,

Feb 5, 2017, 8:16:47 PM2/5/17

to PhistucK, Rick Byers, Xiaocheng, blink-dev, Chris Harrelson, Bogdan Brinza

On Feb 4, 2017, at 01:42, PhistucK <phis...@gmail.com> wrote:

While Mozilla may not have -webkit-user-modify (I have not checked), they do have -moz-user-modify, so they may have their own problems here. :(
(It does not have the plaintext thingies, though)

Despite what MDN claims, Mozilla's implementation of -moz-user-modify is not a real one. It dates back (waaay back) to when they had separate teams working on the parser and the engine. The parser team would add properties that the engine did not (yet) support, and in this case, the engine team never followed up. Besides confusing people, -moz-user-modify does not actually do anything. See https://logs.csswg.org/irc.w3.org/css/2015-04-01/#e538914

—Florian

PhistucK

unread,

Feb 6, 2017, 2:11:08 AM2/6/17

to Florian Rivoal, Rick Byers, Xiaocheng, blink-dev, Chris Harrelson, Bogdan Brinza

After verifying with the latest Firefox as well as Firefox 3, I fixed that claim, thank you.

☆PhistucK

Xiaocheng Hu

unread,

Apr 17, 2017, 4:40:09 AM4/17/17

to blink-dev

Hi everyone,

I'm reviving this thread since a blocker is gone: the editing-tf has decided to standardize contenteditable=plaintext-only [1].

Given that all engines supporting -webkit-user-modify (Blink, Edge and WebKit) also supports contenteditable=plaintext-only, the functionality loss with the deprecation will be extremely low. Unless one would like to set editability dynamically via CSS selectors, which doesn't seem to be an important use case, a simple replacement of -webkit-user-modify by contenteditable=plaintext-only has no functionality loss at all -- if there is, it's a bug.

However, the current usage is still too high to start deprecation: 1.8%. We will work on decreasing this number.

[1] https://lists.w3.org/Archives/Public/public-editing-tf/2017Mar/0004.html

--

Regards,

Xiaocheng Hu

Rick Byers

unread,

Apr 17, 2017, 9:14:34 AM4/17/17

to Xiaocheng Hu, blink-dev

Given that the Firefox implementation is a no-op, and Bogdan suspects that Edge doesn't actually need this API I'm optimistic that the high usage may not actually represent high compat risk. Here is a list of the 1440 sites in the Alex top 500k sites from HTTP Archive that trigger this use counter. Perhaps you want to go through (eg.) the top 10 and try to understand what exactly breaks? Eg. this rule on alipay.com is suggestive:

textarea.fixAndroidKeyboard:focus, input.fixAKeyboard:focus {

-webkit-tap-highlight-color: rgba(255, 255, 255, 0);

-webkit-user-modify: read-write-plaintext-only;

}

Perhaps it was used as a work-around for an Android bug that no longer applies in current Chrome?

Also I noticed several hits (eg. att.com) used a rule like this:

html.fsrMobileCompat input {
-webkit-user-modify: read-write-plaintext-only!important;
margin: 0!important;
padding: 0!important
}

Which appears to come from forsee-dhtml.css in this "foresee" package. Searching the JS I find this code which I think sets up this fsrMobileCompat class:

var m = "Android" == u.X.name && 3 > u.X.version;

m && n.va(f, "fsrMobileCompat");

I.e. the rule is only actually active prior to Android version 3! So this indeed looks like a workaround to an old Android browser bug. The CSS UseCounter triggers on parsing, so it's really a false positive in this case.

Perhaps you want to add a UseCounter that triggers only when -webkit-user-modify actually does something to filter out cases like this? If we're lucky we'll see the usage drop extremely low at that point, and then we can just give removal a try...

Hope this helps!

Rick

Xiaocheng Hu

unread,

Apr 17, 2017, 7:21:04 PM4/17/17

to Rick Byers, blink-dev

Thanks a lot for the list!

Guess we want to measure the valid usage, i.e., if the property is applied, in a non-inherited way, to an element:

- without contenteditable attribute

- not <input> or <textarea>

We (editing-dev@) will try to find a clean way to instrument this counter.

Something that can be done simultaneously is, we should contact site developers to stop using this property. Hope the counter is going to drop after some top sites stop using it.

--

Regards,

Xiaocheng Hu

Rick Byers

unread,

Apr 17, 2017, 8:37:17 PM4/17/17

to Xiaocheng Hu, blink-dev

On Mon, Apr 17, 2017 at 7:20 PM, Xiaocheng Hu <xiaoc...@chromium.org> wrote:

Thanks a lot for the list!

Guess we want to measure the valid usage, i.e., if the property is applied, in a non-inherited way, to an element:
- without contenteditable attribute
- not <input> or <textarea>

We (editing-dev@) will try to find a clean way to instrument this counter.

Sounds great, thanks!

Something that can be done simultaneously is, we should contact site developers to stop using this property. Hope the counter is going to drop after some top sites stop using it.

If you can find some sites which are really depending on it (i.e. break when it's removed) then yes I agree trying to contact them (or better, the owners of any libraries) is worthwhile. Though in practice, for all but the biggest sites, we tend not to have much success with doing this. It's almost certainly a waste of time to reach out to sites on my list which aren't obviously broken by removing it (eg. they may actually still want the workaround for old Android browser users).

Xiaocheng Hu

unread,

Apr 17, 2017, 9:41:47 PM4/17/17

to Rick Byers, Xiaocheng Hu, blink-dev

On Tue, Apr 18, 2017 at 9:37 AM Rick Byers <rby...@chromium.org> wrote:

On Mon, Apr 17, 2017 at 7:20 PM, Xiaocheng Hu <xiaoc...@chromium.org> wrote:
Thanks a lot for the list!

Guess we want to measure the valid usage, i.e., if the property is applied, in a non-inherited way, to an element:
- without contenteditable attribute
- not <input> or <textarea>

We (editing-dev@) will try to find a clean way to instrument this counter.

Sounds great, thanks!

Something that can be done simultaneously is, we should contact site developers to stop using this property. Hope the counter is going to drop after some top sites stop using it.

If you can find some sites which are really depending on it (i.e. break when it's removed) then yes I agree trying to contact them (or better, the owners of any libraries) is worthwhile. Though in practice, for all but the biggest sites, we tend not to have much success with doing this. It's almost certainly a waste of time to reach out to sites on my list which aren't obviously broken by removing it (eg. they may actually still want the workaround for old Android browser users).

Didn't know about that experience...

So it seems to be a good plan to start with:

- The counter for valid usage

- Remove internal usage

With the counter, we can contact sites that really depend on this property.

--

Regards,

Xiaocheng Hu

Reply all

Reply to author

Forward