Re: Listing Discouraged Web Features

Generally this is information included in the page itself. We already
uniformly document standardization status and vendor support; and indicate
in prose if there's a preferred alternative. In the case of standardization
status, we have "Deprecated" to mean the behavior is standardized, but use
formally discouraged.

If we do need a list, after all this, we have Semantic MediaWiki, so we can
make it a MediaWiki category.

Can you present a particular example of a discouraged feature and explain
why it'd be good to put on a separate list, if this is insufficient?

Austin Wright.

On Fri, Mar 20, 2015 at 2:21 PM, PhistucK <phistuck@gmail.com> wrote:

> Following a brief blink-dev discussion
> <https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/RNk93vpOaV8>,
> 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?
>
> ☆*PhistucK*
>
> ---------- 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 <
> blink-dev@chromium.org>
>
>
> 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 <philipj@opera.com>
> wrote:
>
>> 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
>>
>