Intent to Deprecate: HTMLHeadElement.profile

[Philip Jägenstedt]

Primary eng (and PM) emails

phi...@opera.com

Summary

Remove the profile IDL attribute from HTMLHeadElement (which reflects the profile content attribute)

Motivation

This property was removed from HTML in 2010: 
http://html5.org/r/5063 

See also the "What to do with HTMLHeadElement.profile?" thread:

https://groups.google.com/a/chromium.org/d/msg/blink-dev/rOoVOq-XIpY/3PWPYibqALEJ

Compatibility Risk

The profile content attribute doesn't actually do anything, but that doesn't mean nothing could break by removing the reflected IDL attribute.

According to Boris Zbarsky, Firefox has been shipping without it for a bit over 3 years.

It was removed from Presto in July 2011. (Internal bug was CORE-39871)

The success of these removals makes it rather likely that removal is indeed safe.

WebKit and IE11 still support it.

Alternative implementation suggestion for web developers

The profile attribute doesn't do anything, so preferably stop using it or move to e.g. data-profile instead for site-specific information.

Alternatively, use getAttribute('profile') and setAttribute('profile') for a minimal fix.

Usage information from UseCounter

The usage is fluctuating between 0.05% and 0.075%, which is higher than most removals I'm aware of: 
http://www.chromestatus.com/metrics/feature/timeline/popularity/207 

Entry on chromestatus.com and/or MDN

None

Requesting approval to remove too?

No, let it be deprecated for at least one release cycle first.

[Anne van Kesteren]

On Fri, May 23, 2014 at 9:29 AM, Philip Jägenstedt <phi...@opera.com> wrote:
> According to Boris Zbarsky, Firefox has been shipping without it for a bit
> over 3 years.

See https://bugzilla.mozilla.org/show_bug.cgi?id=664544 for details. No hiccups.

> It was removed from Presto in July 2011. (Internal bug was CORE-39871)

:-)


--
http://annevankesteren.nl/

[Eric Seidel]

LGTM to deprecate. No sense in removing it any time soon though. It
has basically 0 cost to us.

[Ojan Vafai]

LGTM. I'd just remove it. That Firefox doesn't ship this and that the property doesn't do anything points to removing this not breaking content. Of course it's still possible, but I don't think we need to tread so lightly in this case since the fix for the site is just to remove a noop line of code.

[PhistucK]

You are taking it way too lightly, in my opinion.

While I would be happy (really, really happy) if the platform were leaner, reasoning with "just to remove a noop line of code" does not consider the actual state of the world.

People that use business web application (CRMs, ERPs) must pay a lot of money (and put a lot of effort into it) in order to move to a new version. The vendor fixes it in a new version, or in a patch for a newer version than the one the business uses and just like that, the application ceases working just because you removed this one-liner and all of the employees are now forced to use a different browser.

Business have started (or maybe a long ago already) moving to Chrome. With popularity, comes responsibility.
But not only businesses. Any other web application that may depend on it (and used once in a while, which skews the statistics as well) will just stop working without any signs in advance.

Now, I am not trying to convince you not to remove anything, of course, but a deprecation period is in order for any removal, trivial or not. Especially when usage statistics do not cover all of the user base, or sometimes much of a relevant user base (enterprises).

(Note, of course, that I do not care at all about this specific property. I never knew it even existed)

☆PhistucK

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

[Ojan Vafai]

In general, we should be very careful of how and when we remove features. But there's a judgement call in each case. Long-standing features with broad cross-browser support require much more care.

In this case, that Firefox is shipping without this gives me some confidence that we can remove this without breaking content. It's true that it's possible that there's some Blink-specific codepath that would break if this property started returning undefined instead of it's current value, but that seems extremely unlikely to me.

[PhistucK]

One release with it being deprecated does not seem like such a bad idea to me, anyway.

☆PhistucK