github at esdiscuss.org (2013-07-12T02:27:21.793Z)
On Tue, May 7, 2013 at 10:15 AM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote: > Mark said: "all major JS platforms support some harmless feature, > cross-browser web content will come to depend on that feature" > > if `__proto__` is harmless, and deprecated methods such `__defineGetter__` are > still there, I wonder what you consider harmfull to implement. > `__proto__` wasn't harmless, but its harm was survivable. That's why it took so long for the Cajadores and I to come around to the position that we don't need to remove it from SES. We would have been better off without it, but that's not a realistic choice. `__defineGetter__` and blink are harmless because they only do that which can be done by other means. `RegExp.leftContext` is harmful, especially when undeletable, because it creates a global communications channel. Because it is undeletable, initSES has to do bizarre things to remove it from SES.
On Tue, May 7, 2013 at 10:15 AM, Andrea Giammarchi < andrea.giammarchi at gmail.com> wrote: > Do you believe acting passively will keep bringing any good to the > language specification? > > A **precedent**, title of one of my posts about __proto__, is exactly what > you have here. > > "Since every browser has it, no matter how bad or good it is, let's us put > that there too and it will be standard" > > This seems legit to me, specially from IE that does not want to be left a > part anyhow. > > IE ruled out few standards in the DOM world (thankfully less in the ES > one). > > Same all "other" browsers implemented non standard innerHTML, IE adopted > some other non-spec'd thing. > > Same Chrome implemented an even falsy document.all, IE can decide that > {}.__defineGetter__ is not undefined anymore. > > Not only it's used, but the new "isNotIE()" feature detection of these > days is: > > if ({}.__defineGetter__) { > // not IE, not at all > } > > same if(document.all) was used for the inverted behavior in the past. > > Same WebKit decided that innerText was fine, IE can chose __anythingHere__ > is fine too and this is OK, we should not point/complain because this is > what every other engine/browser has always done. > > Is just a matter of context, either DOM or ES, those once alternative > browsers adopted IE non standards approach to avoid being left behind and > now it's vice-versa. > > I believe the elephant in the room is the adoption of experimental and non > standard features, documented properly in the MDN so that everyone can > learn with examples how to use them. > > Instead of writing a deprecated in the MDN page, I would rather expect > that every execution of a piece of code that uses these features logs in > the console a **warning** that a deprecated thing is being used. > > This is valid for every build step of any programming language, JS decided > that early adoption or usage of deprecated things is fine ... trapping the > future behind early and old mistakes or not fully defined behaviors (again, > __proto__ and all its partial implementations is a clear example) > > I would rathe expect that this logging is noticed by developers and that > not a single minute is wasted behind improving performance of that > technique, I would rather see ever-green browsers reacting fast instead of > supporting such deprecated, non-standard, thing, for years! > > Sadly, what I see is that instead of filtering, TC39 "ignores" these > things that come out of developers necessities and become standards, or > decide to standardize the mess "passively", as long as all browser agreed > that mess is needed. > > Mark said: "all major JS platforms support some harmless feature, > cross-browser web content will come to depend on that feature" > > if __proto__ is harmless, and deprecated methods such __defineGetter__ are > still there, I wonder what you consider harmfull to implement. > __proto__ wasn't harmless, but its harm was survivable. That's why it took so long for the Cajadores and I to come around to the position that we don't need to remove it from SES. We would have been better off without it, but that's not a realistic choice. __defineGetter__ and blink are harmless because they only do that which can be done by other means. RegExp.leftContext is harmful, especially when undeletable, because it creates a global communications channel. Because it is undeletable, initSES has to do bizarre things to remove it from SES. > > Object.prototype.toSource() ? something I've polyfilled for IE5 ages ago, > never made it and not because harmfull, simply because pointless due > inability to bring the scope around once re-evaluated. > > The potentially-laser-foot-gun __proto__ already landed, and there's > nothing else that powerful that could have made it so my question is: > shouldn't TC39 be a stopper for these kind of problems instead of blindly > embrace whatever comes through? > > I'd really like to understand what is the real TC39 role 'cause lately I > am having hard time understanding this every time IE embraces some early > mistake nobody cared 'till the day before if it was "all-but-IE" > > Best Regards > > > > > On Tue, May 7, 2013 at 9:20 AM, Dean Landolt <dean at deanlandolt.com> wrote: > >> Oh. Sorry for the noise. >> >> >> On Tue, May 7, 2013 at 12:18 PM, Brandon Benvie <bbenvie at mozilla.com>wrote: >> >>> On 5/7/2013 9:16 AM, Dean Landolt wrote: >>> >>> Are they not in the es6 draft yet? I was going by what you'd said a half >>> hour ago: >>> >>> These are already in the ES6 spec in fact, under Annex B (normative >>>> optional). >>> >>> >>> Regardless, this seems like the perfect place for all of the duners, >>> IMHO. >>> >>> >>> Oh apologies for not being clear. I meant the likes of >>> `String.prototype.blink` and friends are in Annex B. >>> >> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130507/d0bfc2e0/attachment.html>