Intent to Remove: EventSource 'URL' attribute (uppercase alias)

[Joshua Bell]

Another one - in hindsight, I should have sent just one I2R...

Primary eng (and PM) emails

jsb...@chromium.org
phi...@opera.com

Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/d/msg/blink-dev/1m47rW4w7dc/MOf_2kgb2wIJw

Summary

Remove the previously deprecated `URL` attribute on the EventSource interface, which is an alias for the standard `url` attribute.

Motivation

Like on WebSocket, the uppercase variant was in the initial "Server Sent Events" 2009 drafts, but by 2011 and implementation in non-WebKit browsers the spec only has the lower case variant:
https://html.spec.whatwg.org/multipage/comms.html#the-eventsource-interface

Usage information from UseCounter

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

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

Usage is under 0.02%.

Entry on chromestatus.com

https://www.chromestatus.com/features/5311740673785856

Compatibility Risk

The uppercase attribute isn't supported in Opera 12.16 (Presto), Firefox Nightly and IE11, but per source inspection, the uppercase alias is still present in WebKit.

[Philip Jägenstedt]

LGTM! Usage is around 0.002%, which is of course under 0.02% :)

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

[Chris Harrelson]

LGTM

[Philip Rogers]

LGTM

[PhistucK]

Sorry for this delayed reply -

The use counter does not say a lot, since I do not see a use counter for EventSource itself (or am I missing it?). If most of the EventSource usage also uses EventSource.URL, I am not so sure this is such a great idea.

Furthermore, the usage seems to be increasing.

I have not heard of a lot of websites that use EventSource, but, breaking most of those who do use it is pretty terrible.

☆PhistucK

[Joe Medley]

Which milestone removed this?

Joe Medley | Technical Writer | jme...@google.com | 816-678-7195

[Philip Jägenstedt]

The removal landed on March 5, which means it will be gone in M43.

[PhistucK]

Now I see that the initial post linked to EventSource and not to the relevant deprecation entry. :(

And Philip won the race to answer your question - Chrome 43. :)

☆PhistucK

[Joe Medley]

Thanks for checking the ticketing link. Removal signals aren't always as clear as those for new features. Documentation is just as important.

[PhistucK]

Alex, it would be great (:)) if you could update the Chrome 43 beta post with this removal (I think WebSocket.URL was also removed at that time, so it should be included as well).

Thank you!

☆PhistucK

[Paul Kinlan]

Also, can we make sure ChromeStatus is up to date.  I know it is retorspective to some extent now, but I am trying to make sure every developer facing change has a more discoverable and developer friendly listing on chromestatus.  Thanks,

P

[PhistucK]

Unfortunately, the launch process itself excludes "minor or trivial changes" (which I think is very wrong, considering that Chrome does not have an official documentation venue), so chromestatus.com will 'never' be completely up to date.

:(

☆PhistucK

[Joe Medley]

+1

Joe Medley | Technical Writer | jme...@google.com | 816-678-7195

[Paul Kinlan]

I think this one area we are working on and exploring how we can improve this. I do believe that a deprecation, removal or an API change should be messaged proactively and be made as discoverable as possible.

[Alex Komoroske]

It mike make sense for us to revisit that requirement for Chrome Status entries, given how important they have become.

I'll have the blogpost updated.