rethinking our removal policy

432 views
Skip to first unread message

Ojan Vafai

unread,
Apr 21, 2014, 8:51:42 PM4/21/14
to blink-dev
Recent API removals have caused some unhappiness among web developers. Particularly, the attribute node related removals. I think it's time we refine our removal policy.

What I've learned is:
-We should weigh the benefits of removing an API more against the cost it has. %pageviews by itself is not the only metric we care about.
-The cost of removing an API is not accurately reflected by the UseCounter for older, widely implemented APIs. It's more likely that there's a longer-tail of legacy content that we're breaking.

I think this means a few concrete changes:
1. The intent to remove emails should include when we first shipped the API and what other browsers implement the API.
2. We shouldn't remove APIs that have small value on the path towards a removal that has significant value. Getting rid of attribute nodes *is* valuable and would benefit the platform. Getting rid of half the attribute node methods is not. So we should evaluate the usage of all the APIs we need to remove together in order to get there. Also, if we remove them, we should remove them all in the same release. Breaking people once is better than breaking them repeatedly in small ways.
3. We should be more hesitant to remove older, widely implemented APIs.
4. For cases where we're particularly concerned about the compatibility hit as in (3), we should do the removal behind a flag so that we can easily reenable the API on stable as we don't know the compat hit until the release has been on stable for a couple weeks.
5. I've seen a lot of numbers thrown around about percentages below which we think a feature is safe to remove. I've seen .03% and .06% many times. Both these numbers are too high by an order of magnitude at least. I don't know that having a fixed number here makes sense. It's a tradeoff between usage and cost.

Do these seem reasonable? Are there other refinements we should make to the removal process?

Incidentally, the attribute node removals have already been reverted: https://codereview.chromium.org/243333003/.

Emil A Eklund

unread,
Apr 21, 2014, 9:02:54 PM4/21/14
to Ojan Vafai, blink-dev
On Mon, Apr 21, 2014 at 5:51 PM, Ojan Vafai <oj...@chromium.org> wrote:
> Do these seem reasonable? Are there other refinements we should make to the
> removal process?

Fully agree, we need to be more conservative when removing features,
especially ones that have been around for years and are supported in
other browsers.

Elliott Sprehn

unread,
Apr 21, 2014, 9:08:39 PM4/21/14
to eae, Ojan Vafai, blink-dev
I agree as well. This policy sounds much better.

Jonas Sicking

unread,
Apr 23, 2014, 11:53:21 PM4/23/14
to e...@chromium.org, Ojan Vafai, blink-dev
Another thing that might help is more coordination between Mozilla and
Google on what to remove, and possibly even when.

I get the impression that as much as it annoys developers when an API
is removed, it annoys them even more if this is seen as a unilateral
move by one browser vendor. I've seen such feedback on this list, and
we have gotten similar feedback from developers when we've moved to
remove things from Gecko.

So for big items like showModalDialog and attribute-nodes, it might
help to coordinate on exactly what should be removed, and then make a
public announcement signed by both parties.

Another thing that can help is if we coordinate with spec authors and
get those features marked as deprecated in spec drafts and then point
to those spec drafts in the announcement.

I don't have any particular ideas for where we'd post such
announcements, so very open to ideas. I think mozilla both would be
happy to host them on mozilla branded locations like
hacks.mozilla.org, or have them hosted on google branded locations. Or
both.

For what it's worth, I think there's lots of overlap in what we want
to see removed. Things that come to my mind are attribute nodes
(possibly there's not agreement on ownerElement), showModalDialog,
namespaced attributes, sync XHR, XSLT and mutation events, but I'm
sure the list is much longer.

/ Jonas

brua...@gmail.com

unread,
Apr 25, 2014, 5:46:25 AM4/25/14
to blin...@chromium.org, e...@chromium.org, Ojan Vafai
Le jeudi 24 avril 2014 05:53:21 UTC+2, Jonas Sicking a écrit :
On Mon, Apr 21, 2014 at 6:02 PM, Emil A Eklund <e...@chromium.org> wrote:
> On Mon, Apr 21, 2014 at 5:51 PM, Ojan Vafai <oj...@chromium.org> wrote:
>> Do these seem reasonable? Are there other refinements we should make to the
>> removal process?
>
> Fully agree, we need to be more conservative when removing features,
> especially ones that have been around for years and are supported in
> other browsers.

Another thing that might help is more coordination between Mozilla and
Google on what to remove, and possibly even when.

I get the impression that as much as it annoys developers when an API
is removed, it annoys them even more if this is seen as a unilateral
move by one browser vendor. I've seen such feedback on this list, and
we have gotten similar feedback from developers when we've moved to
remove things from Gecko.
Yes, please coordinate! <3
 
So for big items like showModalDialog and attribute-nodes, it might
help to coordinate on exactly what should be removed, and then make a
public announcement signed by both parties.
+1

David, a web developer

Max Heinritz

unread,
Apr 25, 2014, 1:51:29 PM4/25/14
to brua...@gmail.com, blink-dev, Emil A Eklund, Ojan Vafai
I've added some of these learnings to the Blink wiki page:


When/if Adam's proposal is integrated into the wiki, we can refactor to have a cleaner separation between policy and process.

Max
Reply all
Reply to author
Forward
0 new messages