Remove 14.1, 14.2, 14.3, 14.4 about javascript HOT 18 CLOSED

Unless browsers show that those functions can be removed, removing them from the specification is irresponsible.

from javascript.

On Wed, 14 Nov 2012, Rick Waldron wrote:

Inclusion of these items in a normative standard is irresponsible and
future hostile.

If it has to be implemented by browsers, it must be specced.

If it doesn't, then browsers should remove support to prove it. :-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

from javascript.

Unless browsers show that those functions can be removed, removing them from the specification is irresponsible.

@Ms2ger: I disagree. We should give browsers time to attempt to eliminate their support before creating a spec that gives programmers a green light to use them. It's working at cross-purposes to elimination of the feature.

If it has to be implemented by browsers, it must be specced.

@Hixie: A fine proposition, but its antecedent is not satisfied: IE does not currently support these features and does not plan to support them, unlike __proto__, which is being specified in ES6.

Dave

from javascript.

There is a difference between implementation requirements and "giv[ing] programmers a green light to use them".

from javascript.

There is a difference between implementation requirements and "giv[ing] programmers a green light to use them".

This statement is contrary to reality, most commonly exemplified by the unbridled use of vendor prefixed APIs.

from javascript.

Looking through Opera’s bug tracker, web compat was one of the primary motivations for adding __defineGetter/Setter__, __lookupGetter/Setter. The following sites were reported as broken (back in 2006 anyways):

• www.live.com
• mail.yahoo.com
• www.start.com
• www.fusionuser.com
• www.activewidgets.com

Quoting @hallvors (if he doesn’t mind) from 2006:

Start.com, live.com (which AFAIK will replace much of today's MSN), Hotmail - seems Microsoft has great ambitions for the "Atlas" framework that relies on getters and setters. Like it or not but most important MS websites will be dead in Opera soon unless we implement getters/setters or get them to change their "compatibility layer" philosophy."

from javascript.

@miketaylr Understood. Honestly I don't care that much about whether this stuff goes in the spec or not, what I really want to know is, do we think it's possible to lead the web away from them so that we can eliminate them. (If not, so be it.) What do you think? Note that in 2006 ES5 was years away, so there was no Object.defineProperty/Object.getOwnPropertyDescriptor alternative at the time.

Dave

from javascript.

I'd be happy if the web moved away from it--it's super ugly. :)

I honestly don't have a sense how widespread it is, though. Searching in Github and Google Code shows that's it's not impossible to find today in libs (hard to know for sure how webby the results are, a quick glance shows some Node.JS modules in the results). It might be more useful to instrument a browser and try to gather stats a la Chromium's FeatureObserver.

Who knows, maybe the story is a lot better than it was in 2006... .

from javascript.

@Ms2ger, @Hixie: ISTM it would be helpful to add a notion of deprecation to features in this spec. Regardless of whether you believe programmers shouldn't interpret the spec as a green light, they very well might. You can't write a public document and say "this is only for implementors, no one else should read it." :)

Deprecation can always be removed if it turns out browsers aren't able to remove the feature. But as long as you know there's a good faith intention to try to remove the feature, it seems responsible and helpful to inform readers of the spec that they should steer clear of using the feature, and to tell them what the better alternative is.

Dave

from javascript.

On Wed, 14 Nov 2012, Dave Herman wrote:

@Ms2ger, @Hixie: ISTM it would be helpful to add a notion of deprecation
to features in this spec. Regardless of whether you believe programmers
shouldn't interpret the spec as a green light, they very well might.
You can't write a public document and say "this is only for
implementors, no one else should read it." :)

Doesn't work. In practice, authors don't read the spec. Either it's part of the platform, and browsers will support it and people will use it and we should just deal with it, or it's not needed to be in the platform and we should just remove it from all implementations and be done with it.

By the way, life gets much easier when you realise authors are going do things that you disagree with and our job is to define what the platform is, not try to remove things that aren't ideal. For example, I can't get rid of <font> or <div> from HTML, however much I'd like to.

from javascript.

Doesn't work.

Hang on there. Deprecation doesn't work for fully ubiquitous or fully standardized features, but browsers do remove features. It does in fact happen — just not always, and certainly not for entrenched features. But __defineGetter__ et al are not entrenched at the same level as e.g. __proto__. As evidenced, again, by the fact that Microsoft has said they're not feeling pressure to implement them the way they are __proto__, or by the fact that Mozilla is telling you right here in this thread that we intend to attempt to remove them.

In practice, authors don't read the spec.

You say that with such ease. And yet I talk to developers who read specs all the time. And often they're the type of developers who spread word about best practices, training other developers to do what they do.

This "spec" purports to define a portable set of functionality that works on the web. And yet the functionality it describes doesn't work in IE. It would cost you very little to add a warning saying: "This functionality is not portable across all major browsers, and some browsers that currently implement it are discussing removing it." And your argument is just "no devs will read this web page." That's a pretty thin defense.

By the way, life gets much easier when you realise authors are going do things that you disagree with and our job is to define what the platform is, not try to remove things that aren't ideal.

Please don't patronize. Of course the web is full of features I don't like. How do you think I feel about standardizing mutable __proto__ in ES6?

But my job, as a representative of an organization building a mainstream browser, does include eliminating problematic features, at least when they are either especially egregious (e.g., the late __parent__, RIP) or haven't yet reached a level of entrenchment that precludes their elimination. The hard part is trying to tell whether that's possible. But the process -- in practice! -- involves evangelism, developer console warnings, and then removal after some amount of lead time. We've done this before in Firefox, e.g. with sharp-literals and E4X. We'd now like to do this for __defineGetter__ and friends. It may not work, if we find it's breaking too many sites. But you're not helping, and possibly hurting, this effort by providing a web page that looks official and claims (falsely!) that the feature is fully web-portable.

Dave

from javascript.

I have no objection to adding a paragraph to the top of the spec saying that script authors must not depend on the extensions defined in this specification.

I strongly object to removing text describing features that are implemented in multiple modern js engines and for which no evidence exists that they can be removed without affecting compat. This can be revisited once an engine shipping in a mass-market browser successfully manages to remove a feature, not on the basis that they might at some future time attempt to remove it.

from javascript.

I agree with @Hixie if he rephrases as "authors don't necessarily notice whether something is deprecated by reading specs" - but I don't think anyone is really disagreeing that the real question is whether real-world usage makes it impossible to remove a feature.

Given that as of November 2012 Hotmail still loads this file:
https://gfx7.hotmail.com/mail/16.4.9569.1101/cmpt0.js
..we'd have to do quite some evangelising to be able to actually remove this.

from javascript.

On Wed, 14 Nov 2012, Dave Herman wrote:

Hang on there. Deprecation doesn't work for fully ubiquitous or fully
standardized features, but browsers do remove features.

Sure. And if browsers remove the feature, then we should drop it from the
specification too. That's not deprecation, that's obsoletion.

In practice, authors don't read the spec.

You say that with such ease. And yet I talk to developers who read specs
all the time.

The vast majority of authors don't read specs. There are always
exceptions, and the people who read the specs are naturally going to be
mostly surrounded by other people who read the spec.

By the way, life gets much easier when you realise authors are going
do things that you disagree with and our job is to define what the
platform is, not try to remove things that aren't ideal.

Please don't patronize.

I didn't mean it to be patronising. I used to think that we should write
specs to describe the ideal world. I since realised that's a fool's
errand.

But my job, as a representative of an organization building a mainstream
browser, does include eliminating problematic features, at least when
they are either especially egregious (e.g., the late __parent__, RIP)
or haven't yet reached a level of entrenchment that precludes their
elimination.

Sure. If the feature is removed from browsers, I don't think anyone here
would be arguing to keep it in the spec.

We'd now like to do this for __defineGetter__ and friends.

Please do.

But you're not helping, and possibly hurting, this effort by providing a
web page that looks official and claims (falsely!) that the feature is
fully web-portable.

It doesn't claim the feature is fully web-portable. It claims that
browsers are implementing the feature. Change the facts by removing the
feature, and the spec will change to match.

Ian Hickson U+1047E )..,--....,'``. fL
http://ln.hixie.ch/ U+263A /, .. \ \ ;._ ,. Things that are impossible just take longer. ..-(,..'--(,..'`-.;.'

from javascript.

That's not deprecation, that's obsoletion.

I don't care what it's called; I'm just saying it would be reasonable for this document to note that a particular feature is not as widely implemented as others, and that there is ongoing effort to remove it. This is useful information, and it wouldn't hurt the spec in any way to include it.

It doesn't claim the feature is fully web-portable. It claims that browsers are implementing the feature.

Actually, exactly what it's claiming is ambiguous. The spec just says:

This specification aims to document the differences between the ECMAScript specification and the compatibility and interoperability requirements for ECMAScript implementations in web browsers.

This could be interpreted to mean:

1. there exists at least one major browser that implements these features
2. there exist several major browsers that implement these features
3. all major browsers implement these features
4. enough web content depends on these features such that a browser that conforms with reality must implement these features
5. some web content depends on these features, and a browser that wishes to make that content work should implement the features as described in the spec

You say the spec claims 1. But it doesn't state that, and it's not a particularly useful point. Claim 2 isn't quite the point, either. Claim 3 is patently false, since IE doesn't implement these features. Same with claim 4. I think we probably all agree that claim 5 is most likely the case with this particular set of features.

But that doesn't preclude my simple request for a note stating that a feature is not as widely implemented as others, and that it may lose support over time. The note can easily be removed if the feature becomes more widespread.

I understand and support the idea that these specs are here primarily to serve browser implementers based on the empirical reality of the web as it is, not an ideal. When I say "please don't patronize" it's because you don't need to convince me that web specs are about documenting reality. I agree! All I'm asking is that the spec be clearer about its claims about reality.

Dave

from javascript.

It goes without saying that ancient non-ES features should be avoided whenever possible, especially when an ES-standardized alternative is available.

This document is only an attempt at speccing the non-ES features with the goal to improve interoperability.

What we should be evangelizing for is an entirely different issue.

That said, I wouldn’t mind adding a note saying authors shouldn’t rely on these extensions. Done in a8d9a06.

from javascript.

I’ve been wanting to add notes to each section saying which browsers / ES engines support this feature (similar to how it’s done in the HTML spec.

Example screenshot, taken from http://www.whatwg.org/specs/web-apps/current-work/multipage/named-character-references.html:

I’ve filed #5 for that.

from javascript.

@mathiasbynens Thanks! This sounds great.

Dave

from javascript.