Intent to Remove: InsertAdjacentText

[sudar...@samsung.com]

Primary eng (and PM) emails

sudar...@samsung.com

Summary

Remove support for non standard interface InsertAdjacentText from Element.

Motivation

- This is a non standard IE extension.

- This is part of the list @ http://crbug.com/332191 for features with low usage numbers.

Usage information from UseCounter

This is part of the list of features that have low usage numbers. The Use counter for this has been

added for sometime now (crbug.com/286321)

Compatibility Risk

???

Row on feature dashboard?

No

Requesting approval to remove too?

Yes

[Zlip792 .]

Gecko didn't yet implemented it:

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=811259

[Eric Seidel]

I just confirmed. This was seen in 0.00034% of page views for windows
Stable Chrome yesterday.

LGTM to remove.

[Ojan Vafai]

I'm not sure there's value in removing this API if we can't also remove insertAdjacentHTML and insertAdjacentElement. We have a UseCounter for insertAdjacentElement that shows it's used on 0.036% of pageviews. I think that's probably too high to remove. Although, presumably those pages have some fallback code for Firefox that they must be hitting, so maybe the impact of removing all the insertAdjacent* APIs isn't as bad as it seems it would be.

We don't have a useCounter for insertAdjacentHTML.

[Tab Atkins Jr.]

On Mon, Feb 3, 2014 at 2:17 PM, Ojan Vafai <oj...@chromium.org> wrote:
> I'm not sure there's value in removing this API if we can't also remove
> insertAdjacentHTML and insertAdjacentElement. We have a UseCounter for
> insertAdjacentElement that shows it's used on 0.036% of pageviews. I think
> that's probably too high to remove. Although, presumably those pages have
> some fallback code for Firefox that they must be hitting, so maybe the
> impact of removing all the insertAdjacent* APIs isn't as bad as it seems it
> would be.
>
> We don't have a useCounter for insertAdjacentHTML.

FF implements *HTML, so we probably can't remove it anyway.

(They don't implement *Element.)

~TJ

[Ian Hickson]

insertAdjacentHTML() is specced: http://domparsing.spec.whatwg.org/

The other two don't seem to be specced.

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

[David Vest]

Ojan Vafai <oj...@chromium.org> writes:

> I'm not sure there's value in removing this API if we can't also remove
> insertAdjacentHTML and insertAdjacentElement. We have a UseCounter for
> insertAdjacentElement that shows it's used on 0.036% of pageviews. I think
> that's probably too high to remove. Although, presumably those pages have
> some fallback code for Firefox that they must be hitting, so maybe the
> impact of removing all the insertAdjacent* APIs isn't as bad as it seems it
> would be.

The discussion is getting a bit fragmented. Here's an attempt at summing
up where this has been brought up. Only insertAdjacentText and
insertAdjacentElement are talked about here, not insertAdjacentHTML.

* Blink bug about removal: "Remove insertAdjacentText and
insertAdjacentElement"

https://code.google.com/p/chromium/issues/detail?id=286321

* Spec bug about adding them: "Add insertAdjacentText and
insertAdjacentElement?"

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19962

Has a dependency on the above mentioned Blink bug.

* Proposed CL from Ojan (yesterday) for explicitly keeping them by
moving them from HTMLElement to Element:

https://codereview.chromium.org/147993006/

* Mozilla bug "implement insertAdjacentText":

https://bugzilla.mozilla.org/show_bug.cgi?id=811259

No support from Mozilla for implementing them yet.

David

[Ojan Vafai]

On Tue, Feb 4, 2014 at 1:37 AM, David Vest <da...@opera.com> wrote:

Ojan Vafai <oj...@chromium.org> writes:

> I'm not sure there's value in removing this API if we can't also remove
> insertAdjacentHTML and insertAdjacentElement. We have a UseCounter for
> insertAdjacentElement that shows it's used on 0.036% of pageviews. I think
> that's probably too high to remove. Although, presumably those pages have
> some fallback code for Firefox that they must be hitting, so maybe the
> impact of removing all the insertAdjacent* APIs isn't as bad as it seems it
> would be.

The discussion is getting a bit fragmented. Here's an attempt at summing
up where this has been brought up. Only insertAdjacentText and
insertAdjacentElement are talked about here, not insertAdjacentHTML.

 * Blink bug about removal: "Remove insertAdjacentText and
   insertAdjacentElement"

   https://code.google.com/p/chromium/issues/detail?id=286321

 * Spec bug about adding them: "Add insertAdjacentText and
   insertAdjacentElement?"

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=19962

   Has a dependency on the above mentioned Blink bug.

 * Proposed CL from Ojan (yesterday) for explicitly keeping them by
   moving them from HTMLElement to Element:

   https://codereview.chromium.org/147993006/

FWIW, I don't think moving them to Element necessarily means we have to keep them. I just want all the insertAdjacent* methods to be consistently implemented. 

[Eric Seidel]

0.036% is right around our previous most-common removal:
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/bs3NIiqnc8Q/2kF7HNr4kSAJ

I don't think removing it is completely out of the question.

On Mon, Feb 3, 2014 at 2:17 PM, Ojan Vafai <oj...@chromium.org> wrote:

[Alex Russell]

Agree. Mozilla implementing and the spec including them is much less weighty than de minimus usage.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Anne van Kesteren]

On Tue, Feb 4, 2014 at 9:37 AM, David Vest <da...@opera.com> wrote:
> * Mozilla bug "implement insertAdjacentText":
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=811259
>
> No support from Mozilla for implementing them yet.

Given that the DOM now has after() / before() that include an easy way
to create Text nodes, I would really like to avoid adding these legacy
methods to the platform. If Chrome could kill insertAdjacentElement
and Text forever that'd be great.


--
http://annevankesteren.nl/

[David Vest]

Ojan Vafai <oj...@chromium.org> writes:

>> * Proposed CL from Ojan (yesterday) for explicitly keeping them by
>> moving them from HTMLElement to Element:
>>
>> https://codereview.chromium.org/147993006/
>
>
> FWIW, I don't think moving them to Element necessarily means we have to
> keep them. I just want all the insertAdjacent* methods to be consistently
> implemented.

Fair enough. Sorry for making assumptions. I conflated the "I think
that's probably too high to remove."-thing with the "Element vs.
HTMLElement"-inconsistency thing.

David

[Ojan Vafai]

We never actually followed through with trying to remove mutation events. Also, I think there's a pretty big difference there. Mutation events have a high implementation cost. insertAdjacentText/Element are pretty much free if you already have insertAdjacentHTML.

I don't feel strongly about this. We can try removing them and see what happens, but personally I'd err on the side of leaving them as is. The benefit of removing them just seems really low to me.

[Eric Seidel]

I would err on the side of removing all 3. We've seen very few compat
bugs from historical removals, and we've removed up to at least 0.03
w/o issue. 0.036 is only 20% more. :)

[Ojan Vafai]

I won't stand in the way of trying to remove these and see what breaks.

For future reference, what APIs have we removed that have 0.03% usage? I thought all the things we had removed were less than that by at least an order of magnitude.

[Simon Pieters]

On Tue, 25 Feb 2014 21:21:24 +0100, Eric Seidel <ese...@chromium.org>
wrote:

> I would err on the side of removing all 3.

I don't think insertAdjacentHTML should be removed.

* It is widely implemented, unlike the other two.
* It has a spec.
* It is much faster than innerHTML which people will turn to instead if
insertAdjacentHTML is removed.
https://hacks.mozilla.org/2011/11/insertadjacenthtml-enables-faster-html-snippet-injection/

--
Simon Pieters
Opera Software

[Ojan Vafai]

Ah. Right, I forgot that we don't even have a UseCounter for insertAdjacentHTML. 

[sudar...@samsung.com]

As per the latest usage stats InsertAdjacentElement & InsertAdjacentText have very low usage (0.0143% & 0.0003%)

InsertAdjacentHTML has a usage above the threshold (0.5704%). I don't think we can remove InsertAdjacentHTML because of the high usage, but we can go ahead and remove the other 2 non-standard interfaces. 

[PhistucK]

So - for future reference - is the general direction to remove insertAdjacentHTML?

What is the direct alternative for it?

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[sudar...@samsung.com]

One of the opinions voiced was to remove all insertAdjacent* APIs. But there was no metrics for insertAdjacentHTML at that time. Now with the metrics data a call has to be made. We need more opinions to make any call.

As far as the alternative for insertAdjacentHTML, I am not aware if there is any other than innerHTML.

[PhistucK]

innerHTML (on the parent element, I guess that is what you mean) is not a direct alternative, it recreates the entire element and 'removes' event handlers.

☆PhistucK

[Anne van Kesteren]

On Mon, Jun 23, 2014 at 8:32 AM, <sudar...@samsung.com> wrote:
> As far as the alternative for insertAdjacentHTML, I am not aware if there is
> any other than innerHTML.

insert*HTML is actually in a standard of sorts and implemented by
other browsers. Mozilla has no intent to implement the other two APIs,
but we do plan on keeping insert*HTML.


--
http://annevankesteren.nl/

[PhistucK]

Exactly my thoughts - insertAdjacentHTML cannot be mimicked lightly (without creating another temporary element or a document fragment, for example), while the two others can.

Great, so I can keep using insertAdjacentHTML and not worry about its deprecation.

☆PhistucK