Intent to Deprecate and Remove: webkitdropzone global attribute

107 kali dilihat
Langsung ke pesan pertama yang belum dibaca

Victor Costan

belum dibaca,
6 Feb 2017 04.19.2406/02/17
kepadablink-dev

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

belum dibaca,
7 Feb 2017 01.47.0507/02/17
kepadaVictor Costan, blink-dev
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

belum dibaca,
11 Feb 2017 06.14.2711/02/17
kepadaPhilip Jägenstedt, blink-dev
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!)

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

PhistucK

belum dibaca,
11 Feb 2017 08.39.4711/02/17
kepadaVictor Costan, Philip Jägenstedt, blink-dev
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

belum dibaca,
11 Feb 2017 09.40.2511/02/17
kepadablink-dev

ssccoottnn...@gmail.com

belum dibaca,
11 Feb 2017 09.40.2511/02/17
kepadablink-dev

ssccoottnn...@gmail.com

belum dibaca,
11 Feb 2017 09.40.2611/02/17
kepadablink-dev

Victor Costan

belum dibaca,
11 Feb 2017 16.02.2911/02/17
kepadaPhistucK, Philip Jägenstedt, blink-dev
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

belum dibaca,
13 Feb 2017 03.45.4213/02/17
kepadaVictor Costan, PhistucK, blink-dev
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

belum dibaca,
13 Feb 2017 21.41.5113/02/17
kepadaPhilip Jägenstedt, PhistucK, blink-dev
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

belum dibaca,
14 Feb 2017 08.07.4714/02/17
kepadaVictor Costan, PhistucK, blink-dev
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

belum dibaca,
17 Feb 2017 14.18.5717/02/17
kepadaPhilip Jägenstedt, PhistucK, blink-dev
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

belum dibaca,
17 Feb 2017 17.45.4517/02/17
kepadaVictor Costan, Philip Jägenstedt, PhistucK, blink-dev
Great, thank you!  It sounds like you could also submit a spec/test PR that's likely to be accepted.

PhistucK

belum dibaca,
17 Feb 2017 19.00.5417/02/17
kepadaVictor Costan, Philip Jägenstedt, blink-dev
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

belum dibaca,
17 Feb 2017 19.49.1717/02/17
kepadaRick Byers, Philip Jägenstedt, PhistucK, blink-dev
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

belum dibaca,
18 Feb 2017 07.47.2718/02/17
kepadaVictor Costan, PhistucK, Philip Jägenstedt, blink-dev
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

belum dibaca,
18 Feb 2017 11.06.3318/02/17
kepadaRick Byers, Victor Costan, PhistucK, Philip Jägenstedt, blink-dev
LGTM2

--

Dimitri Glazkov

belum dibaca,
18 Feb 2017 11.30.0618/02/17
kepadaChris Harrelson, Rick Byers, Victor Costan, PhistucK, Philip Jägenstedt, blink-dev
LGTM3

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

Philip Jägenstedt

belum dibaca,
21 Feb 2017 04.58.5921/02/17
kepadaVictor Costan, Rick Byers, PhistucK, blink-dev
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).
Balas ke semua
Balas ke penulis
Teruskan
0 pesan baru