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

Re: Listing Discouraged Web Features

From: PhistucK <phistuck@gmail.com>
Date: Sat, 21 Mar 2015 00:34:15 +0200
Message-ID: <CABc02_+Kj2CL7KpYMA2iDSkpO+HMz9PBKN0Hbyq=71o2n1neCA@mail.gmail.com>
To: Austin William Wright <aaa@bzfx.net>
Cc: "public-webplatform@w3.org" <public-webplatform@w3.org>
We are talking about vendor prefixed properties and completely nonstandard
and proprietary properties here.
Window.WebKitTransitionEvent, Window.styeMedia, Node.swapNode,
scrollbar-3dlight-color (CSS property), padding-box (this is a CSS value
for box-sizing, though this specific one is just an example of stuff that
can be in this list, I have not researched about whether it is nonstandard).
Some of these features may not even have a page (because we generally do
not document nonstandard properties, like all of the Internet Explorer
specific properties or WebKit specific properties we used to have).

Also, previously standard features that are not yet deprecated in the
official sense due to lack of any data data that shows it can be removed.
It will be some sort of indication that the browsers generally do want to
deprecate or remove it, even if not this year.


☆*PhistucK*

On Sat, Mar 21, 2015 at 12:00 AM, Austin William Wright <aaa@bzfx.net>
wrote:

> 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
>>>
>>
>
Received on Friday, 20 March 2015 22:35:24 UTC

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