Listing Discouraged Web Features (was [blink-dev] Intent to Deprecate and Remove: Window.offscreenBuffering)

166 views
Skip to first unread message

PhistucK

unread,
Mar 20, 2015, 11:30:21 AM3/20/15
to Philip Jägenstedt, Chris Harrelson, TAMURA, Kent, Philip Rogers, blink-dev
Reading this list of discouraged APIs (below, by Philip Jägenstedt), I did not know some of the properties, or I did know (or iterated through them when searching for solutions when I write code and might have chosen them), but I did not know some of them are slated for deprecation or removal, or even that they are nonstandard (I obviously never read the entire specification and I do not think many web developers have).

While web developers can read the mailing lists and specifications of the W3C, WHATWG, IETF and others, it does not scale well (they will simply not do that - and it is an enormous amount of stuff to read).

Since you (and everyone else that regularly participates in standards discussions) know way better than me (and other web developers) about intentions to eventually remove features, I suggest that we create a page (since it is not specific to Blink, docs.webplatform.org should host it) that lists discouraged features.
docs.webplatform.org/wiki/Discouraged_Web_Features (nonexistent at the moment, of course) or something similar.

This list should consist of all of the features currently implemented in browsers, that are discouraged and are of interest for deprecation, obsoletion or removal. Even if it happens only in a few years, you let web developers know that a feature is discouraged and should not be part of their code base if they know what is good for them. ;)

To make it easy, I do not think any description must be included. The name of the API is enough. For example, for styleMedia -
styleMedia
window.styleMedia

(It is just important to include, or at least hint to, all of the ways this API can be accessed, because, for example not every web developer knows that a member of Window can also be accessed as x and not only as window.X and vice versa)

I can monitor the page and try and add small descriptions, reasons for discouragement, alternative implementations (if any) and links to the full documentation of every new property (and mark that documentation as discouraged right on its page), so you can simply 'hit and run' (well, 'add the names and go'). This is a very simple process (if you have a docs.webplatform.org user).

Of course, if anyone that adds stuff to the page want to add more than just the name, they are welcome. I am not that possessive. ;)

What do you think?
(And if you think you will add names to such a list, can you make sure this spreads to more than just blink-dev?)

PhistucK

On Fri, Mar 20, 2015 at 9:22 AM, Philip Jägenstedt <phi...@opera.com> wrote:
As suspected, enumeration was a big contributor, at the counter is now dropping:

Based on counters that have been removed entirely in previous releases, it looks like it will take long time to settle:

I'll wait a bit longer before poking at offscreenBuffering, but since enumeration seems to contribute at least 0.1% on window attributes, I'd also like to make the following non-standard attributes on window not enumerable:

clientInformation
defaultStatus
defaultstatus
orientation
screenLeft
screenTop
styleMedia
webkitURL
WebKitAnimationEvent
WebKitMutationObserver
WebKitTransitionEvent

Does that seem OK? It's not entirely without risk, so if there are any of these that we think should stay long-term (and be standardized) we shouldn't mess with them.

Philip

On Wed, Dec 3, 2014 at 4:30 AM, Philip Jägenstedt <phi...@opera.com> wrote:
OK, let's try that, if nothing else it will give us an idea of how much "noise" enumeration contributes.

Philip

On Tue, Dec 2, 2014 at 8:13 PM, Chris Harrelson <chri...@chromium.org> wrote:
Since this attribute is not getting in the way, how about we first make it not enumerable, and see if usage drops? 0.18% is a lot.

On Tue, Dec 2, 2014 at 1:50 AM, Philip Jägenstedt <phi...@opera.com> wrote:
On Tue, Dec 2, 2014 at 10:46 AM, TAMURA, Kent <tk...@chromium.org> wrote:
>
> Basically LGTM.
>
> > That's around ~0.18%, far above what we would usually try removing.
>
> It's high. I recommend to remove this just after branch so that we can have enough time to find serious issues.

Good idea, I'll do the removal in mid-January assuming this thread
gets another LGTM.

Philip

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



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

Joshua Bell

unread,
Mar 20, 2015, 12:50:31 PM3/20/15
to PhistucK, Philip Jägenstedt, Chris Harrelson, TAMURA, Kent, Philip Rogers, blink-dev
Unless such a thing already exists and is just poorly promoted, attempting this SGTM. 

It strikes me that, taken to an extreme, this would be the antithesis of caniuse.com - showing features slowly being deprecated across browsers/versions as they are removed from the platform, with links to workarounds and replacements.

Chris Harrelson

unread,
Mar 20, 2015, 12:55:18 PM3/20/15
to Joshua Bell, PhistucK, Philip Jägenstedt, TAMURA, Kent, Philip Rogers, blink-dev
+1 to what Josh said. Also, caniuse.com sees like a good kind of place to put this information.

Joe Medley

unread,
Mar 20, 2015, 2:02:51 PM3/20/15
to Chris Harrelson, Joshua Bell, PhistucK, Philip Jägenstedt, TAMURA, Kent, Philip Rogers, blink-dev
Mozilla is in the process of creating a database that will eventually have an API (http://web-platform-compat.readthedocs.org/en/latest/draft/intro.html). I haven't examined it specifically for how deprecation is handled. 

Those of us in Dev Platform have been told to give more attention to MDN than web platform.

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

PhistucK

unread,
Mar 20, 2015, 5:08:02 PM3/20/15
to Joe Medley, Chris Harrelson, Joshua Bell, Philip Jägenstedt, TAMURA, Kent, Philip Rogers, blink-dev
The last line your wrote is pretty sad to me. The only place that is officially backed by several vendors (including Google) is docs.webplatform.org and you are being told to give more attention to MDN. But that is off topic, so I will just let it go... :(

I am not sure this quite fits that Mozilla database. I am talking about discouraged features, meaning, they can even be supported for the next five years, but there are plans, or desire to deprecate and remove them at some point, because they are vendor prefixed, because they badly designed, because they are a liability to the platform, or because there is a new, much superior API. I think it is a different goal, but I do not mind including it there as well (say, add a "discouraged" field to the features model).

The primary source of truth will still be docs.webplatform.org, since it is not vendor specific and since you can list all of the features along with all (or the most common, anyway) of the ways to access them.

I will ask around public-webplatform if this fits there.


PhistucK

Alex Russell

unread,
Mar 20, 2015, 10:28:50 PM3/20/15
to PhistucK, Chris Harrelson, Joe Medley, TAMURA, Kent, Philip Jägenstedt, blink-dev, Joshua Bell, Philip Rogers

MDN is a fine place for this. The W3C has made WPD particularly difficult to improve.

Better that we have up-to-date information for developers where they are likely to find it.

Regards

Philip Jägenstedt

unread,
Mar 21, 2015, 3:07:09 AM3/21/15
to PhistucK, Chris Harrelson, TAMURA, Kent, Philip Rogers, blink-dev
Understanding which non-prefixed APIs are not on the path to standardization and interop is indeed hard. As part of the IDL spec sync I've moved things for which I could not find a (modern) spec to sections marked with "Non-standard APIs", a case-insensitive search for "non-standard" in *.idl will find these and other pre-existing bits.

Unfortunately I've only gotten through 10% of the IDL files, but at least that includes most of DOM (Document, Node and friends) and the Window object. This would be a good start for anyone who wants to document (and discourage use of) these APIs, whether on WPD, MDN or caniuse.com.

For each non-standard API, it would be useful to research how widely implemented it is. It's very likely that some of them are de-facto standards with decent interop, where they should just be specified. I would not ask developers to stop using them, in particular if there's no good alternative.

Philip

PhistucK

unread,
Mar 21, 2015, 6:28:17 AM3/21/15
to Philip Jägenstedt, Chris Harrelson, TAMURA, Kent, Philip Rogers, blink-dev
Oh, so you basically want to know if the ones you mentioned are fine to discourage by gathering more data.
That means no one really knows... I think I retract my suggestion, then.


PhistucK

PhistucK

unread,
Mar 21, 2015, 6:30:06 AM3/21/15
to Alex Russell, Chris Harrelson, Joe Medley, TAMURA, Kent, Philip Jägenstedt, blink-dev, Joshua Bell, Philip Rogers
What do you mean by "The W3C has made WPD particularly difficult to improve"?

In terms of infrastructure, or in terms of editing and adding articles?

What were you trying to improve and got blocked?


PhistucK

Philip Jägenstedt

unread,
Mar 21, 2015, 6:55:08 AM3/21/15
to PhistucK, blink-dev, Philip Rogers, TAMURA, Kent, Chris Harrelson

Well, some APIs (like window.clientInformation, an alias of navigator) are useless and should be removed if possible, while some (like window.find()) possibly do something useful. It's a good rule of thumb to avoid all non-standard APIs, but to offer advice to developers on a specific API needs at least a few minutes of analysis.

If anyone wants to invest that time, I think it would be useful if when searching for, say, clientInformation, the first result is a page explaining that's it's useless and not supported in all browsers.

Philip

Michael[tm] Smith

unread,
May 2, 2015, 8:57:59 PM5/2/15
to PhistucK, Alex Russell, blink-dev
PhistucK <phis...@gmail.com>, 2015-03-21 12:29 +0200:
>
> What do you mean by "The W3C has made WPD particularly difficult to
> improve"?
>
> In terms of infrastructure, or in terms of editing and adding articles?
>
> What were you trying to improve and got blocked?

Dunno if Alex might have since responded offlist on this but regardless as
somebody who’s also been following the docs.webplatform.org efforts over
the last 3 years—but certainly not claiming to speak for the W3C staff no
for the rest of W3C organizationally—suffice it to say that despite the
best intentions of everybody involved, and a lot of blood, sweat, and tears
put into trying to make it happen, it seems pretty clear at this point that
docs.webplatform.org is not going to ever end being what some had hoped it
might turn out to be.

Instead the momentum for maintaining docs in this area—that is, a shared
space for collaborating on cross-browser reference and how-to docs about
the Web platform, for Web developers—instead remains pretty much where it
always has been, at MDN.

In the three years since the docs.webplatform.org was originally launched,
I think MDN has gotten significantly more inclusive and vendor-neutral and
certainly the spirit behind it is (to continue) to make it that.

Which is all just to say, IMHO MDN is a perfect home for this proposed
“Discouraged Web Features” documentation.

—Mike

P.S. As far as the wider webplatform.org effort, there is no plan to
abandon it; quite the opposite actually. There has already been work in
place to make webplatform.org into a resource for facilitating wider
collaboration on actual development and testing of new features for the
platform (rather than just Web-developer documentation for the platform)—
and so a resource that also complements MDN rather than competing with it.

One key effort in progress that feeds into where webplatform.org is likely
to be heading into the future is the “Web Platform Specs” effort that Robin
Berjon is heading up—

https://specs.webplatform.org/
https://github.com/webspecs

Another key piece of the plan is this:

https://discuss.webplatform.org/

That’s the former http://discourse.specifiction.org/ and runs Jeff Atwood’s
Discourse discussion software, and is in part an exploration of better ways
to facilitate and reward civil discussion about proposals for new features
for the Web platform (and to discourage uncivil discussion).

And along with those, I think some parts are of the “Modern Tooling” work
that Robin is also leading will end up finding a home at webplatform.org

http://w3c.github.io/modern-tooling/
https://github.com/w3c/modern-tooling/issues

—Mike

> On Sat, Mar 21, 2015 at 4:28 AM, Alex Russell <sligh...@google.com>
> wrote:
>
> > MDN is a fine place for this. The W3C has made WPD particularly difficult
> > to improve.
> >
> > Better that we have up-to-date information for developers where they are
> > likely to find it.
> >
> > Regards
> > On 20 Mar 2015 2:08 pm, "PhistucK" <phis...@gmail.com> wrote:
> >
> >> The last line your wrote is pretty sad to me. The only place that is
> >> officially backed by several vendors (including Google) is
> >> docs.webplatform.org and you are being told to give more attention to
> >> MDN. But that is off topic, so I will just let it go... :(
> >>
> >> I am not sure this quite fits that Mozilla database. I am talking about
> >> discouraged features, meaning, they can even be supported for the next five
> >> years, but there are plans, or desire to deprecate and remove them at some
> >> point, because they are vendor prefixed, because they badly designed,
> >> because they are a liability to the platform, or because there is a new,
> >> much superior API. I think it is a different goal, but I do not mind
> >> including it there as well (say, add a "discouraged" field to the
> >> features
> >> <http://web-platform-compat.readthedocs.org/en/latest/draft/resources.html#features>
> >> model).
> >>
> >> The primary source of truth will still be docs.webplatform.org, since it
> >> is not vendor specific and since you can list all of the features along
> >> with all (or the most common, anyway) of the ways to access them.
> >>
> >> I will ask around public-webplatform if this fits there.
> >>
> >>
> >> ☆*PhistucK*
> >>>>>> ☆*PhistucK*
--
Michael[tm] Smith https://people.w3.org/mike
signature.asc
Reply all
Reply to author
Forward
0 new messages