Intent to Deprecate and Remove: webkitdropzone global attribute

[Victor Costan]

Primary eng (and PM) emails

pwn...@chromium.org

Summary

The dropzone global attribute [1, 2] was introduced by the HTML5 drag and drop specification as a declarative method for specifying an HTML element's willingness to be the target of a drag-and-drop operation, as well as the content types that can be dropped onto the element, and the operation (copy/move/link) that would result from dropping something onto the element. No browser has implemented the unprefixed version. Blink and WebKit implement a prefixed form of the attribute, webkitdropzone.

Given that the attribute failed to gain traction with other browsers, I would like to immediately remove it from our implementation, to reduce the risk of having Web content grow to depend on it.

[1] https://html.spec.whatwg.org/multipage/interaction.html#the-dropzone-attribute

[2] https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/dropzone

Motivation

This is a prefixed attribute that will never be standardized. The standardized version of the attribute is failing to gain traction from other browser implementers. Therefore, I would like to remove the attribute before Web content starts depending on it.

Compatibility And Interoperability Risk

No browser currently supports the un-prefixed version of the attribute [1].

Our implementation was incorrect until M57 [2, 3], so webkitdropzone could not be used to accept file drops on sites (it only worked for file: origins). We didn't receive any complaints, and I only learned about the bug while trying to fix an issue [4, 5] whose code happened to be related to the webkitdropzone implementation.

Given these issues, applications targeting the Web platform (i.e. Firefox, Edge, IE) cannot rely on dropzone / webkitdropzone support, and must declare the willingness to accept drag-and-drop operations via the imperative API offered by the dragenter and dragover event handlers [6].

Edge: No signals

Firefox: Not supported - bug comment suggests they're unhappy with the spec https://bugzilla.mozilla.org/show_bug.cgi?id=723008

Safari: Public support - rniwa opened a bug on Firefox's tracker asking for the attribute to be implemented https://bugzilla.mozilla.org/show_bug.cgi?id=723008

Web developers: No signals

[1] http://caniuse.com/#feat=dragndrop

[2] https://crrev.com/2575303002

[3] https://crrev.com/2585553002

[4] https://crbug.com/104681

[5] https://crrev.com/2575303002

[6] https://developer.mozilla.org/en-US/docs/Web/Events/dragenter

Alternative implementation suggestion for web developers

Applications targeting the Web platform should declare their willingness to accept drag-and-drop operations via the imperative API offered by the dragenter and dragover event handlers.

Usage information from UseCounter

https://www.chromestatus.com/metrics/feature/timeline/popularity/490

https://www.chromestatus.com/metrics/feature/popularity#PrefixedHTMLElementDropzone

The usage appears to be at 0.07% currently. However, based on the HTTPArchive data below, I'd guess that most of it is feature detection.

Looking at HTTPArchive yielded the following results:

https://community.sears.com/auraFW/javascript/C9w03EpEHI__XcCDlMV8MQ/aura_prod.js -- in list of attributes, doesn't appear to be used

https://community.kmart.com/auraFW/javascript/C9w03EpEHI__XcCDlMV8MQ/aura_prod.js -- exactly the same as above

https://globalchallenges.org/main.5bd764e65b815c6d94e3.bundle.js -- in list of attributes, doesn't appear to be used

http://html5test.com/scripts/8/engine.js -- seems like it'll cause us to lose a point in html5test.com

https://questions.learnosity.com/v2.97.0/dist/api.js -- check for prefixed versions of dropzone in all browsers

OWP launch tracking bug

https://crbug.com/688943

Entry on the feature dashboard

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

Requesting approval to remove too?

Yes

[Philip Jägenstedt]

Do you think we should also yank this unprefixed attribute from the HTML spec as well? If we start that process now, it'd be a chance for others to protest if they actually did want to implement and ship this but haven't gotten around to it yet.

The number of sites in httparchive is remarkably small, so this seems rather low risk. Almost certainly the counter is being hit by accident by enumeration, which is a common problem with attributes. In https://bigquery.cloud.google.com:443/savedquery/762219082167:20eb08762edc47178a5e7caba3170864 there are 500 hits of the use counter, if you're curious about how that might happen. I didn't look too closely, and one can safely assume this sites will not be breaking. 

Can you write an example code snippet for how to migrate from webkitdropzone to dragenter + dragover? Something that can be copy-pasted can really help when sites are suddenly broken.

[Victor Costan]

On Mon, Feb 6, 2017 at 10:46 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

Do you think we should also yank this unprefixed attribute from the HTML spec as well? If we start that process now, it'd be a chance for others to protest if they actually did want to implement and ship this but haven't gotten around to it yet.

Yes, I think the attribute should be yanked. Asides from the Mozilla objections, which I agree with, I also think that the declarative API is a bit out of place, given that handling a drop requires script anyway. I started the discussion at https://github.com/whatwg/html/issues/2331

But IMHO this is an orthogonal issue. I think that even if dropzone makes a comeback in popularity, its specification might change (given the Mozilla objections), so we should remove our prefixed attribute to reduce the risk of having Web developers start writing code against the current implementation.

 

The number of sites in httparchive is remarkably small, so this seems rather low risk. Almost certainly the counter is being hit by accident by enumeration, which is a common problem with attributes. In https://bigquery.cloud.google.com:443/savedquery/762219082167:20eb08762edc47178a5e7caba3170864 there are 500 hits of the use counter, if you're curious about how that might happen. I didn't look too closely, and one can safely assume this sites will not be breaking. 

Can you write an example code snippet for how to migrate from webkitdropzone to dragenter + dragover? Something that can be copy-pasted can really help when sites are suddenly broken.

I wrote a polyfill for webkitdropzone -- I think that's as copy-pasteable as it gets. The code is below (Google-only for now, sorry!)

https://docs.google.com/a/google.com/document/d/1nxV-gaIh26ChHLbJo6o9KrC3iKq1ECHbcFi25ncW_Gs/

Sorry I took so long to respond to this. The polyfill was a tad more challenging than expected!

    Victor

[PhistucK]

Unfortunately, as long as it is Google only, it is useless for the context of this intent...

☆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.

[ssccoottnn...@gmail.com]

//metactrl.com

[ssccoottnn...@gmail.com]

//metactrl.com

[ssccoottnn...@gmail.com]

//metactrl.com

[Victor Costan]

Sorry for being unclear! I'm going through the process to have it open-sourced. I'll update this thread as soon as that happens.

    Victor

[Philip Jägenstedt]

Thanks Victor. Having a drop-in polyfill available is great, it helped in the SVGPathSeg removal it seems.

I think we should do this removal, but can you ping the thread again when the polyfill is public and when there's been some time for others to react to the spec-side removal?

☆PhistucK

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

[Victor Costan]

Oh... I thought the right course of action is to remove the implementation before touching the spec. I'll focus on the spec until the polyfill gets released.

Thank you very much for the hints!

    Victor

☆PhistucK

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

[Philip Jägenstedt]

There isn't a correct order to do things as such, I would say that when we're removing something that's not a Blink-only feature, the most important question is whether it'll also be removed in the remaining engines, in this case WebKit. Poking at the spec is a way to figure this out. And skepticism isn't necessarily a blocker, it's just worth knowing if we decide to remove anyway.

If you ping https://github.com/whatwg/html/issues/2331 and there's no response in a week or so, then let's not block on that.

☆PhistucK

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

[Victor Costan]

My polyfill is now public: https://github.com/google/dropzone-polyfill

I think this makes it as easy as possible for impacted developers to cope with the removal while they migrate their code.

    Victor

☆PhistucK

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

[Rick Byers]

Great, thank you!  It sounds like you could also submit a spec/test PR that's likely to be accepted.

[PhistucK]

I suspect something is missing from the readme...

"The code needed to replace webkitdropzone can be as simple as:

Limitations"

Thank you for posting the polyfill!

Does it handle dynamic element insertion (looks like it does not, unless you want the library user to call handleDom after any insertion, which is counter intuitive, not fire-and-forget)?

You can probably use MutationObserver in order to support dynamic DOM changes.

☆PhistucK

[Victor Costan]

On Fri, Feb 17, 2017 at 2:45 PM, Rick Byers <rby...@chromium.org> wrote:

Great, thank you!  It sounds like you could also submit a spec/test PR that's likely to be accepted.

I will work on getting the attribute removed from the specification.

Can the spec work can happen in parallel with this deprecation / removal? Ideally, I would like to at least deprecate (but ideally remove) webkitdropzone sooner rather than later, to avoid having more Web content grow to depend on it.

Thank you,

    Victor

[Rick Byers]

Yeah given that this was almost completely broken prior to M57, and that we have evidence that the UseCounter is dominated by attribute test/enumeration, it seems safe to remove without a deprecation warning.

LGTM1 to remove directly in M58

[Chris Harrelson]

LGTM2

--

[Dimitri Glazkov]

LGTM3

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

[Philip Jägenstedt]

Yeah, to not implement something the spec says is very common, and we need not block removals and updating the spec. The important thing is just that if nobody implements this or plans to, it's removed from the spec within some reasonable time frame (months).