Intent to Implement and Ship: Event.deepPath
91 views
Skip to first unread message
Hayato Ito
May 20, 2015, 4:23:54 AM5/20/15
to blink-dev
Primary eng (and PM) emails
Spec
Summary
Event.path was renamed to Event.deepPath.
This is the resolution at Web Components f2f meeting [1].
Because Blink has already shipped Event.path, this will be just renaming basically.
I will send "Intent to Deprecate: Event.path" in another thread after the Event.deepPath is shipped.
Compatibility Risk:
As of now, it is not supported in any of the major browsers.
Ongoing technical constraints
No.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
OWP launch tracking bug?
None.
Link to entry on the feature dashboard
Requesting approval to ship?
Yes.
Philip Jägenstedt
May 20, 2015, 5:32:11 AM5/20/15
to Hayato Ito, blink-dev
Usage of Event.path is very high, over 3%, so it seems like quite a challenge to get rid of it. Is it not an option to keep the name and change the spec instead? Event.path isn't used for anything else, after all: https://dom.spec.whatwg.org/#interface-event
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Domenic Denicola
May 20, 2015, 12:03:55 PM5/20/15
to Philip Jägenstedt, Hayato Ito, ann...@annevk.nl, blink-dev
From: blin...@chromium.org [mailto:blin...@chromium.org] On Behalf Of Philip Jägenstedt
> Usage of Event.path is very high, over 3%, so it seems like quite a challenge to get rid of it. Is it not an option to keep the name and change the spec instead? Event.path isn't used for anything else, after all: https://dom.spec.whatwg.org/#interface-event
[+Anne, please correct me if I misrepresent you on the following]
At the F2F Anne expressed that he would like `event.path` to exist as the event’s normal path, censored so as not to include things in shadow trees. That is, this concept already exists in the DOM, and he would like to expose it under the appropriate name, `path`. The fact that the “deep path” concept is squatting on the `path` name is unfortunate, from this point of view.
At the F2F we ended up saying that there’s no need to expose the “path” concept as well as the “deep path” concept for now; we can expose “deep path” only, and later maybe introduce “path”. Thus our conclusion was to switch to exposing “deep path” as `deepPath` to leave room for a future `path`.
However, I wonder if in light of these usage numbers it would be good to introduce "deep path" and "path" at the same time? It would change the question from "how many sites would break if we totally removed `path`?" to "how many sites would break if `path` started censoring things in shadow trees?"
I guess we could only answer this if we had a better idea what that 3% `path` usage was doing...
> Usage of Event.path is very high, over 3%, so it seems like quite a challenge to get rid of it. Is it not an option to keep the name and change the spec instead? Event.path isn't used for anything else, after all: https://dom.spec.whatwg.org/#interface-event
At the F2F Anne expressed that he would like `event.path` to exist as the event’s normal path, censored so as not to include things in shadow trees. That is, this concept already exists in the DOM, and he would like to expose it under the appropriate name, `path`. The fact that the “deep path” concept is squatting on the `path` name is unfortunate, from this point of view.
At the F2F we ended up saying that there’s no need to expose the “path” concept as well as the “deep path” concept for now; we can expose “deep path” only, and later maybe introduce “path”. Thus our conclusion was to switch to exposing “deep path” as `deepPath` to leave room for a future `path`.
However, I wonder if in light of these usage numbers it would be good to introduce "deep path" and "path" at the same time? It would change the question from "how many sites would break if we totally removed `path`?" to "how many sites would break if `path` started censoring things in shadow trees?"
I guess we could only answer this if we had a better idea what that 3% `path` usage was doing...
Hayato Ito
May 20, 2015, 10:11:27 PM5/20/15
to Domenic Denicola, Philip Jägenstedt, ann...@annevk.nl, blink-dev
Yeah, 3% is surprising number to me. I have no idea about from where this number comes, as of now.
As for event.path, I thought that we should deprecate it after event.deepPath is shipped so that we can encourage developers to switch from event.path to event.deepPath.
I think we have several options for event.path:
1. We should have the new name for event's (local) path. e.g. event.localPath. In this case, we don't have to be hurry to deprecate event.path in Blink.
2. We should *reuse* the name of event.path, with the new behavior.
In this case, we should deprecate and remove event.path in Blink asap. Then, after a while, we will *revive* event.path with the new behavior.
In any case, I thought it's okay to implement and ship event.deepPath in Blink.
After shipping event.deepPath, we might have more usage data for both so that we can do the best judge about how we should treat the event.path in Blink (and in the spec).
Philip Jägenstedt
May 21, 2015, 5:01:12 AM5/21/15
to Hayato Ito, Domenic Denicola, ann...@annevk.nl, blink-dev
Since deprecation messages don't reliably drive down usage and since the usage of Event.path is so high, I think it would be best to change from the current state to the final state in a single step. Otherwise, a likely outcome is that we end up with Event.path and Event.deepPath as aliases forever, or worse that the specs only mention Event.deepPath but that de-facto you must support Event.path as well.
Shipping Event.deepPath first ought not to reveal anything interesting: initially the usage will be zero, and the usage of Event.path will remain the same.
If we have Event.deepPath, would an Event.path excluding nodes in shadow trees enable any new use cases?
Philip
smaug
May 21, 2015, 10:23:09 AM5/21/15
to Hayato Ito, Domenic Denicola, Philip Jägenstedt, ann...@annevk.nl, blink-dev
On 05/21/2015 05:11 AM, Hayato Ito wrote:
> Yeah, 3% is surprising number to me. I have no idea about from where this number comes, as of now.
>
> As for event.path, I thought that we should deprecate it after event.deepPath is shipped so that we can encourage developers to switch from event.path
> to event.deepPath.
>
> I think we have several options for event.path:
>
> 1. We should have the new name for event's (local) path. e.g. event.localPath. In this case, we don't have to be hurry to deprecate event.path in Blink.
>
> 2. We should *reuse* the name of event.path, with the new behavior.
This was the plan. .path would contain nodes only within the same DOM subtree, not inner shadow DOM.
> Yeah, 3% is surprising number to me. I have no idea about from where this number comes, as of now.
>
> As for event.path, I thought that we should deprecate it after event.deepPath is shipped so that we can encourage developers to switch from event.path
> to event.deepPath.
>
> I think we have several options for event.path:
>
> 1. We should have the new name for event's (local) path. e.g. event.localPath. In this case, we don't have to be hurry to deprecate event.path in Blink.
>
> 2. We should *reuse* the name of event.path, with the new behavior.
.deepPath would have also the shadow DOM nodes.
.path will be defined in DOM spec.
-Olli
> In this case, we should deprecate and remove event.path in Blink asap. Then, after a while, we will *revive* event.path with the new behavior.
>
> In any case, I thought it's okay to implement and ship event.deepPath in Blink.
>
> After shipping event.deepPath, we might have more usage data for both so that we can do the best judge about how we should treat the event.path in
> Blink (and in the spec).
>
>
> From: blin...@chromium.org <mailto:blin...@chromium.org> [mailto:blin...@chromium.org <mailto:blin...@chromium.org>] On Behalf Of Philip
> Jägenstedt
>
> > Usage of Event.path is very high, over 3%, so it seems like quite a challenge to get rid of it. Is it not an option to keep the name and change
> the spec instead? Event.path isn't used for anything else, after all: https://dom.spec.whatwg.org/#interface-event
>
> [+Anne, please correct me if I misrepresent you on the following]
>
> At the F2F Anne expressed that he would like `event.path` to exist as the event’s normal path, censored so as not to include things in shadow
> trees. That is, this concept already exists in the DOM, and he would like to expose it under the appropriate name, `path`. The fact that the “deep
> path” concept is squatting on the `path` name is unfortunate, from this point of view.
>
> At the F2F we ended up saying that there’s no need to expose the “path” concept as well as the “deep path” concept for now; we can expose “deep
> path” only, and later maybe introduce “path”. Thus our conclusion was to switch to exposing “deep path” as `deepPath` to leave room for a future
> `path`.
>
> However, I wonder if in light of these usage numbers it would be good to introduce "deep path" and "path" at the same time? It would change the
> question from "how many sites would break if we totally removed `path`?" to "how many sites would break if `path` started censoring things in
> shadow trees?"
>
> I guess we could only answer this if we had a better idea what that 3% `path` usage was doing...
>
> From: blin...@chromium.org <mailto:blin...@chromium.org> [mailto:blin...@chromium.org <mailto:blin...@chromium.org>] On Behalf Of Philip
> Jägenstedt
>
> > Usage of Event.path is very high, over 3%, so it seems like quite a challenge to get rid of it. Is it not an option to keep the name and change
> the spec instead? Event.path isn't used for anything else, after all: https://dom.spec.whatwg.org/#interface-event
>
> [+Anne, please correct me if I misrepresent you on the following]
>
> At the F2F Anne expressed that he would like `event.path` to exist as the event’s normal path, censored so as not to include things in shadow
> trees. That is, this concept already exists in the DOM, and he would like to expose it under the appropriate name, `path`. The fact that the “deep
> path” concept is squatting on the `path` name is unfortunate, from this point of view.
>
> At the F2F we ended up saying that there’s no need to expose the “path” concept as well as the “deep path” concept for now; we can expose “deep
> path” only, and later maybe introduce “path”. Thus our conclusion was to switch to exposing “deep path” as `deepPath` to leave room for a future
> `path`.
>
> However, I wonder if in light of these usage numbers it would be good to introduce "deep path" and "path" at the same time? It would change the
> question from "how many sites would break if we totally removed `path`?" to "how many sites would break if `path` started censoring things in
> shadow trees?"
>
> I guess we could only answer this if we had a better idea what that 3% `path` usage was doing...
>
> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
Hayato Ito
May 21, 2015, 11:14:34 PM5/21/15
to smaug, Domenic Denicola, Philip Jägenstedt, ann...@annevk.nl, blink-dev
Let me clarify the intention of this "Intent to Implement and Ship" Event.deepPath.
The intention is: I only request an approval to implement and ship Event.deepPath.
I'm not requesting an approval to deprecate an Event.path here. I should have clarified that in the first post. That's not my request here.
In any cases, I thought that implement and ship Event.deepPath in Blink is no worse than the current situation in Blink.
Hayato Ito
May 21, 2015, 11:46:22 PM5/21/15
to smaug, Domenic Denicola, Philip Jägenstedt, ann...@annevk.nl, blink-dev
As for the usage of Event.path, I've filed a bug to get a metric for that: https://code.google.com/p/chromium/issues/detail?id=491008
Philip Jägenstedt
May 22, 2015, 2:35:26 AM5/22/15
to Hayato Ito, smaug, Domenic Denicola, ann...@annevk.nl, blink-dev
That is the intention as I understood it, but I don't think it's a good idea to deal with Event.path and Event.deepPath in two separate steps, because of the high risk that we'll then be stuck with both. I'm also not sure why Event.path would be needed if Event.deepPath exists, except as a convenience.
There's plenty of precedent for shipping an alias and removing the old name later, especially when the old name is prefixed. It sometimes works out, but it's a gamble. Let's see what the other API owners have to say, but what I'd like to see is what the intended final state is, and an analysis of the risk of going directly from the current state to the final state.
Hayato Ito
May 22, 2015, 2:57:04 AM5/22/15
to Philip Jägenstedt, smaug, Domenic Denicola, ann...@annevk.nl, blink-dev
I understand. That makes sense.
I thought that if we remove event.path and add event.deepPath at the exact same time together, web developers don't have a period to migrate.
However, it might be *easy* for web developers to handle this situation by doing a feature check, such as:
if (event.deepPath) {
// use event.deepPath
} else {
// use event.path
}
I'm fine to remove event.path and add event.deepPath together. However, in this case, we should be more careful, I think.
Hayato Ito
May 22, 2015, 3:15:34 AM5/22/15
to Philip Jägenstedt, smaug, Domenic Denicola, ann...@annevk.nl, blink-dev
So let me change the request. Let me re-use this thread and request an approval of removing event.path in addition to shipping event.deepPath at the same time altogether.
Summary
Rename Event.path to Event.deepPath.
This is the resolution at Web Components f2f meeting [1].
We are removing Event.path and adding Event.deepPath at the same time together.
Compatibility Risk:
Medium-Low.
event.path: 3.1815%: https://www.chromestatus.com/metrics/feature/timeline/popularity/345
To estimate the risk, we might need to wait for a metric of RAPPOR.
Elliott Sprehn
May 22, 2015, 4:35:47 AM5/22/15
to Hayato Ito, Philip Jägenstedt, smaug, Domenic Denicola, ann...@annevk.nl, blink-dev
3% is crazy high, we definitely need to wait on that.
Philip Jägenstedt
May 22, 2015, 8:01:17 AM5/22/15
to Elliott Sprehn, Hayato Ito, smaug, Domenic Denicola, ann...@annevk.nl, blink-dev
Yeah, understanding why the usage is so high is a necessary first step regardless of whether Event.path is removed or changed to exclude shadow trees. Since the usage is so high, a quick way to find some examples would be to add a deprecation message in a local build and just visit the top 100 sites in the world and look at the developer console for the message.
Hayato Ito
May 24, 2015, 10:02:15 PM5/24/15
to Philip Jägenstedt, Elliott Sprehn, smaug, Domenic Denicola, ann...@annevk.nl, blink-dev
Okay. I'll withdraw this "intent to implement and ship" until we have a more clear data about the usage of Event.path, given that removing Event.path together at the same time is one of our options. We need a fine-grained metric for that.
Reply all
Reply to author
Forward
0 new messages