W3C home > Mailing lists > Public > public-webplatform@w3.org > March 2015

Listing Discouraged Web Features

From: PhistucK <phistuck@gmail.com>
Date: Fri, 20 Mar 2015 23:21:49 +0200
Message-ID: <CABc02_+KzxXZpqEJ=FE3+OVzwynY=Ha-9uL3kCvmd9dPF64z2w@mail.gmail.com>
To: "public-webplatform@w3.org" <public-webplatform@w3.org>
Following a brief blink-dev discussion
I would like to create a page that lists all of the discouraged web
platform features, at -
docs.webplatform.org/wiki/Discouraged_Features (nonexistent at the moment)

It will include a list of web platform features (CSS property, CSS value,
CSS function, DOM member, JavaScript member, HTML element, HTML
attribute...) that are currently supported in one of the browsers and its
use is generally discouraged, because it is vendor prefixed, because it is
badly designed, because it is a liability to the platform, or because there
is a new, much superior API. This does not mean it is currently deprecated
or obsolete or not supported, it just means that browsers wish to get rid
of it at some point.

Hopefully, such a list could help expedite removing these from the
platform, or become the go-to place for web developers that want to make
sure their code will continue to work.

The list will include, at least, the ways to access the feature. I will
monitor the page and make sure every feature is linked to its article (if
it exists), has a small description, has a reason of discouragement and
hopefully an alternative implementation.
If this proves to be successful (features are actually added), I might add
a Semantic MediaWiki property to the listed features so it could be marked
in the article itself.

Is there any objection to creating such a page?


---------- Forwarded message ----------
From: PhistucK <phistuck@gmail.com>
Date: Fri, Mar 20, 2015 at 5:29 PM
Subject: Listing Discouraged Web Features (was [blink-dev] Intent to
Deprecate and Remove: Window.offscreenBuffering)
To: Philip Jägenstedt <philipj@opera.com>
Cc: Chris Harrelson <chrishtr@chromium.org>, "TAMURA, Kent" <
tkent@chromium.org>, Philip Rogers <pdr@chromium.org>, 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 -

(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?)


On Fri, Mar 20, 2015 at 9:22 AM, Philip Jägenstedt <philipj@opera.com>

> As suspected, enumeration was a big contributor, at the counter is now
> dropping:
> https://www.chromestatus.com/metrics/feature/timeline/popularity/356
> Based on counters that have been removed entirely in previous releases, it
> looks like it will take long time to settle:
> https://www.chromestatus.com/metrics/feature/timeline/popularity/207
> 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
Received on Friday, 20 March 2015 21:22:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:14:09 UTC