intent to remove DOMNodeInsertedIntoDocument, DOMNodeRemoved, DOMNodeRemovedFromDocument mutation events

[Ojan Vafai]

DOMNodeInsertedIntoDocument, DOMNodeRemoved, DOMNodeRemovedFromDocument are used on 0.03%, 0.01%, 0.01% of documents respectively. They present an undue implementation burden, have been removed from the DOM4 spec and have general support from browser vendors to get rid of them. Also, MutationObservers have shipped for a while now and provide all the needed functionality from these events.

Unfortunately, this still leaves in DOMSubtreeModified, DOMNodeInserted and DOMCharacterDataModified, which are used on  0.47%, 1.02% and 0.23% of documents. Hopefully the usage numbers will drop over time and we can remove support for these as well.

[Dimitri Glazkov]

LGTM. The number is still pretty high, but this is the Right Thing To Do.

:DG<

[Eric Seidel]

How do I evaluate "0.03%" as being "ok to remove" or not.

It seems we should have some sort of scale on:
http://www.chromium.org/blink#new-features

So that we can all better understand if these are good or bad numbers?

Would someone be able to add that to the wiki based on past data?
(Like "we removed a 0.5% and it was a disaster, but we removed a 0.05%
and it was fine".)

On Thu, Sep 5, 2013 at 12:43 PM, Ojan Vafai <oj...@chromium.org> wrote:

[Emil A Eklund]

Are the benefits from removing just some of the mutation events worth
the risk? While I agree that the end goal should be to remove all I
question whether removing just some of them is worthwhile.

[Adam Klein]

What risk do you have in mind? WebKit/Blink already lack support form
DOMAttributeModified, and have a slightly broken version of
DOMSubtreeModified (it doesn't fire on attribute modifications, only
on addition or removal).

[Emil A Eklund]

DOMNodeInsertedIntoDocument is used by 0.03% of all websites, that is
a pretty large number.

[PhistucK]

I am not sure about this at all - does the implementation of the Break on...>Subtree modifications/Attributes modifications/Node removal context menu feature of the Elements panel of the Developer Tools depend on these events?

And if so, might it add to the usage count?

☆PhistucK

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

[Adam Klein]

On Thu, Sep 5, 2013 at 3:32 PM, PhistucK <phis...@gmail.com> wrote:
> I am not sure about this at all - does the implementation of the Break
> on...>Subtree modifications/Attributes modifications/Node removal context
> menu feature of the Elements panel of the Developer Tools depend on these
> events?
> And if so, might it add to the usage count?

The inspector has its own instrumentation hooks in the DOM mutation
code (e.g., InspectorInstrumentation::willRemoveDOMNode), so it
doesn't depend on these mutation events.

[Adam Barth]

Here are some data points:

1) Blob.webkitSlice was used on 0.0053% of page views, and we successfully removed it.  Unfortunately, that statistic included use by the web inspector, which I remove commensurate with the API.  The methodology was also a bit different because this measurement predates UseCounter.

2) WebKitBlobBuilder was used on 0.006% of page views, and we successfully removed it.  We caused one compatibility issue with the Google+ photo uploader, but we were able to resolve that issue through evangelism.

We've also removed a number of other features with low usage, but I don't know the data off-hand.  My guess is that 0.03% would be highest usage feature that we've removed.  At 0.01%, DOMNodeRemoved and DOMNodeRemovedFromDocument are around the scale at which we've removed features without much compatibility impact.

None of the above really answers your question of where our threshold should be.  We may need to try things and fall flat on our faces to find out.

Adam

[Alex Russell]

On Thu, Sep 5, 2013 at 6:52 PM, Adam Barth <aba...@chromium.org> wrote:

Here are some data points:

1) Blob.webkitSlice was used on 0.0053% of page views, and we successfully removed it.  Unfortunately, that statistic included use by the web inspector, which I remove commensurate with the API.  The methodology was also a bit different because this measurement predates UseCounter.

2) WebKitBlobBuilder was used on 0.006% of page views, and we successfully removed it.  We caused one compatibility issue with the Google+ photo uploader, but we were able to resolve that issue through evangelism.

We've also removed a number of other features with low usage, but I don't know the data off-hand.  My guess is that 0.03% would be highest usage feature that we've removed.  At 0.01%, DOMNodeRemoved and DOMNodeRemovedFromDocument are around the scale at which we've removed features without much compatibility impact.

None of the above really answers your question of where our threshold should be.  We may need to try things and fall flat on our faces to find out.

+1 to that. And I suggest we should make Mutation Events the canary in that particular coal mine. They're slow, dangerous, and have many interfaces which we can judge the impact of removal on independently of each other.

On Thu, Sep 5, 2013 at 1:03 PM, Eric Seidel <ese...@chromium.org> wrote:

How do I evaluate "0.03%" as being "ok to remove" or not.

It seems we should have some sort of scale on:
http://www.chromium.org/blink#new-features

So that we can all better understand if these are good or bad numbers?

Would someone be able to add that to the wiki based on past data?
(Like "we removed a 0.5% and it was a disaster, but we removed a 0.05%
and it was fine".)

On Thu, Sep 5, 2013 at 12:43 PM, Ojan Vafai <oj...@chromium.org> wrote:

> DOMNodeInsertedIntoDocument, DOMNodeRemoved, DOMNodeRemovedFromDocument are
> used on 0.03%, 0.01%, 0.01% of documents respectively. They present an undue
> implementation burden, have been removed from the DOM4 spec and have general
> support from browser vendors to get rid of them. Also, MutationObservers
> have shipped for a while now and provide all the needed functionality from
> these events.
>
> Unfortunately, this still leaves in DOMSubtreeModified, DOMNodeInserted and
> DOMCharacterDataModified, which are used on  0.47%, 1.02% and 0.23% of
> documents. Hopefully the usage numbers will drop over time and we can remove
> support for these as well.
>

[PhistucK]

I expect extensions to use them a lot, because they monitor changes (not everyone updates to MutationObserver). Can you scan the web store for usage? perhaps this accounts for most of it.

☆PhistucK

[Dominic Mazzoni]

On Thu, Sep 5, 2013 at 1:24 PM, Emil A Eklund <e...@chromium.org> wrote:

+1 to this comment. I'm all in favor of deleting these APIs, but deleting half of them is arbitrary and confusing. I also question whether it actually improves the complexity of Blink to keep, e.g., DOMNodeInserted but not DOMNodeRemoved.

What could we do to better evangelize the deprecation of APIs we really want to get rid of but still have somewhat high usage? Could we create huge warnings in Inspector that are impossible to ignore? Could we use Google Webmaster Tools to communicate directly with sites using APIs we plan to deprecate?

[TAMURA, Kent]

Have we shown deprecation warnings for them?

On Fri, Sep 6, 2013 at 4:43 AM, Ojan Vafai <oj...@chromium.org> wrote:

DOMNodeInsertedIntoDocument, DOMNodeRemoved, DOMNodeRemovedFromDocument are used on 0.03%, 0.01%, 0.01% of documents respectively. They present an undue implementation burden, have been removed from the DOM4 spec and have general support from browser vendors to get rid of them. Also, MutationObservers have shipped for a while now and provide all the needed functionality from these events.

Unfortunately, this still leaves in DOMSubtreeModified, DOMNodeInserted and DOMCharacterDataModified, which are used on  0.47%, 1.02% and 0.23% of documents. Hopefully the usage numbers will drop over time and we can remove support for these as well.

--
TAMURA Kent
Software Engineer, Google

[Rafael Weinstein]

I looked at various points at usage by Chrome Extensions when we shipped Mutation Observers and in the months following. Myself and a few devrel folks spent quite a bit of effort trying to move popular extensions off of mutation events (including simply sending them patches to their code).

Unfortunately, my experience is that the few who were amenable to changing their code while it is still working have long since done it. (I suspect that deprecation warnings will do little to motivate developers).

Given that we have a replacement which has shown to be superior both in semantics and performance and have been shipping both now for over a year, I think we're well within good faith efforts at this point to start removing support for Mutation Events.

[Eric Seidel]

It sounds like we'd be the first browser to remove these, is that correct?

If that's true, I think it doesn't hurt to be conservative here, and
plan to ship a deprecation message in M31, and actually do the remove
in M32?

We should also of course add a row on the feature dashboard. I'm told
there isn't official UI support for deprecations their, but we have
precedent:
http://www.chromestatus.com/features/5067649092419584

Otherwise I'm in favor of removing these.

[Max Heinritz]

On Mon, Sep 9, 2013 at 2:25 PM, Eric Seidel <ese...@chromium.org> wrote:

It sounds like we'd be the first browser to remove these, is that correct?

If that's true, I think it doesn't hurt to be conservative here, and
plan to ship a deprecation message in M31, and actually do the remove
in M32?

We should also of course add a row on the feature dashboard.  

+1  

 

I'm told
there isn't official UI support for deprecations their, but we have
precedent:
http://www.chromestatus.com/features/5067649092419584

FWIW, I believe the chromestatus.com UI supports deprecated features as first-class citizens:

 

Let me know if you have any trouble.

[Ian Hickson]

On Thu, 5 Sep 2013, Adam Barth wrote:
>
> We've also removed a number of other features with low usage, but I
> don't know the data off-hand. My guess is that 0.03% would be highest
> usage feature that we've removed. At 0.01%, DOMNodeRemoved and
> DOMNodeRemovedFromDocument are around the scale at which we've removed
> features without much compatibility impact.

That seems about right. For what it's worth, going in the other direction:
the HTML parser's "<image> is a synonym for <img>" hack was added to the
spec when it was added to WebKit because Apple (dhyatt, I think) found it
was necessary for compatibility at a time where data showed that about
0.02% of the Web used <image> on their page somewhere.

That's a different metric (percentage of Web vs percentage of page views),
but is in about the same ball-park.

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

[Alex Russell]

Do you know when that was? Incentived to implement everything (no matter how far legacy or speculative) are inverse to usage.

[Ian Hickson]

On Wed, 11 Sep 2013, Alex Russell wrote:
>
> Do you know when that was?

2005 timeframe, plus or minus a few years.

> Incentived to implement everything (no matter
> how far legacy or speculative) are inverse to usage.

Not sure what you mean here.

[rosa maria palacios juncosa]