__proto__ is deprecated. Why do big browsers like Google Chrome still use it? Are there any plans to dump it?
One of the hardest thing to do in a language / framework is actually remove a deprecated feature. There is still loads of code in the world which depends on this feature. Removing it will break websites. Chrome has apparently looked at the cost of maintenance vs. the pain /cost of removal and chosen maintenance.
__proto__ is not only deprecated, it was actually never part of the standard. Removing the feature from Chrome would mean that some pages would no longer work in Chrome, and there is no reason to break these pages.
The feature has been added to JavaScript (ECAMScript 5) as the 'getPrototypeOf' function, and new JavaScript programs should use that instead.
A proto pseudo property has been included in §B.3.1 of the draft ECMAScript ed. 6 specification (note that the specification codifies what is already in implementations and what webites may currently rely on).
https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Object/proto
Related
I want to check JavaScript Version in my web browser.
Is navigator Object return proper JavaScript version?
navigator.appVersion; /*Is it correct?*/
navigator.appCodeName;
navigator.appName;
Is there any way to detect exact JavaScript Version from Browser console or anything else?
Browsers don't give any real version, because they don't exactly support any one version. They support some (or most) features of some versions.
Any support declared for "JavaScript 1.x" is just a legacy hack for compatibility with Netscape.
Similarly, these navigator fields are useless on purpose. In the past they have been misused to block browsers so much, that the spec now recommends all browsers to lie and say they are Netscape 4.0.
On the web, in general, you should never check version of anything to decide whether it supports the features you need, because it's too easy to make an invalid assumption and break your code in some browser, including future ones you can't test now (e.g. a feature may not be related to the version you assume, or browsers may lie about versions they support in order to work around sites blocking them).
You should use feature detection instead.
You can detect presence of individual JavaScript features by running them and seeing if they work. If the new feature requires a new syntax, you can try running that syntax inside eval. See how it's done on: https://kangax.github.io/compat-table/es6/ (there's a (c) icon with detection code next to features when you expand the list).
I just read on MDN about window.navigator.userAgent:
Deprecated
This feature has been removed from the Web standards.
Though some browsers may still support it, it is in the process of
being dropped. Do not use it in old or new projects. Pages or Web apps
using it may break at any time.
I am not finding any other significant reference on the web confirming this statement. User agent information are widely used by many companies for various reasons (analytics, bug fixes in specific browser ...). While I understand that one should use feature detection over ua sniffing it just seems incredible that this information would go away.
Is it really going away or is it just a Mozilla thing?
If so, is there a replacement for it?
The deprecation notice seems to be gone now. It was removed yesterday, over a year after this question was first asked, with the following comment:
rm deprecation marker. This is not removed from the living spec and no deprecation either. Most use cases are discouraged for quality reasons, but that's something else.
The WHATWG Living standard hasn't deprecated this property, so that confirms that the property isn't going away. Sure, it's a crapshoot and easily spoofed, but "not recommended for use" is not the same as "deprecated". As you note, too many authors and organizations depend on this property for it to be simply specced out of existence and removed from implementations.
Perhaps confusion over the meaning of the word "deprecated" is what resulted in the deprecation notice in the first place. The article itself is still incorrectly tagged "Deprecated", by the way.
Note that Mozilla is not responsible for contributions to the MDN docs. The community is. And as with any other community-curated, unofficial knowledge base (including this very site), don't treat its information as gospel, always cross-reference, etc (as you have done here).
Use feature detection. If you need to use feature X, test to see if X is available.
I don't mean the infamous HTML element <blink>, but the JavaScript function String.prototype.blink.
The MDN page in my link - but also a few other sources found by Google - indicate that this is a deprecated feature (W3Schools goes even further and lists it as nonstandard, incorrectly noting that it's not supported by any current browser, but anyway...)
alert("Hello World!".blink());
After a look into the ES6 specification (current RC is 34), I couldn't find any evidence for those claims: apparently, nothing in the spec suggests that the blink method is deprecated, obsolete or nonstandard.
Same thing for the other string methods big, bold, fixed, fontcolor, fontsize, italics, strike, sub, sup: while the respective HTML elements are deprecated, the JavaScript methods don't look like they are.
Of course, my sources may be inaccurate, but the MDN reference is usually quite reliable, so I'm suspecting that I'm overlooking something here.
Can someone else confirm or debunk the fact that the blink method is deprecated? Sources appreciated.
As neither the ES5 nor the ES6 spec uses the word "deprecated" anywhere, that leads me to believe that none of the methods are deprecated. Whether they should be is an entirely different matter...
They may produce tags that have been deprecated by the working group in charge of HTML or the DOM API, but the ECMAScript spec does not seem to recognize (or at least use) the concept of deprecated methods or classes.
Javascript in general doesn't have a concept of deprecation, even within the language, as discussed in this question. Some language features largely considered ambiguous or poor practice, such as the with statement, are not marked as "deprecated" in any official reference I can find. Methods like unescape are marked as deprecated in their MDN docs, but not the spec.
Yes
I think the description at the top of Annex B, where all these methods are defined, is pretty clear (emphasis mine):
The ECMAScript language syntax and semantics defined in this annex are required when the ECMAScript host is a web browser. The content of this annex is normative but optional if the ECMAScript host is not a web browser.
NOTE: This annex describes various legacy features and other characteristics of web browser based ECMAScript implementations. All of the language features and behaviours specified in this annex have one or more undesirable characteristics and in the absence of legacy usage would be removed from this specification. However, the usage of these features by large numbers of existing web pages means that web browsers must continue to support them. The specifications in this annex defined the requirements for interoperable implementations of these legacy features.
These features are not considered part of the core ECMAScript language. Programmers should not use or assume the existence of these features and behaviours when writing new ECMAScript code. ECMAScript implementations are discouraged from implementing these features unless the implementation is part of a web browser or is required to run the same legacy ECMAScript code that web browsers encounter.
Note that most of the string methods are not mentioned in ES5. As so often when it comes to web, browser vendors did their own thing and added custom extensions. In this case it got to a point where the TC39 committee decided that is important to at least mention them in the spec.
JavaScript and HTML (on the client side at least) are linked together. The blink method does the following (as per MDN):
The blink() method creates a HTML element that causes a string to blink.
Since the <blink> tag is deprecated, or at least classified as a non-conforming feature ...
The element is a non-standard element.
HTML5 classifies it as a non-conforming feature.
Source: http://www.w3.org/wiki/HTML/Elements/blink
... and the blink method generates such a deprecated tag, I think it's inferred that the JavaScript method is deprecated as well.
However, I can't find any official source saying as much, so I understand this is a less than perfect answer.
-EDIT-
As #ssube noted in a comment: A) the ES6 standard isn't even finalized yet, B) the drafts of it (which can be found here: http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts) don't even have the word "deprecated" in them. So it seems like in some sense it is true that the blink method isn't deprecated, because nothing is deprecated.
However, it seems any responsible documentation site (eg. MDN) is going to list it as deprecated because of it generating a deprecated tag, and that's the true origin of its "deprecated" status.
What i found:
Deprecated
This feature has been removed from the Web standards. Though some browsers may still support it, it is in the process of being dropped. Do not use it in old or new projects. Pages or Web apps using it may break at any time.
source: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/blink
I hope this can help you.
This is kind of a two-part question.
Why does IE require so much special treatment when handling Javascript? And are there any tricks, resources, and/or systems you have picked up for making your js IE-compatible, besides Firebug lite?
Using standardised libraries like J-query so you don't have to jump through all the hoops yourself works on the javascript side!
Also Yahoo User Interface (YUI) is good for making websites look extremely similar over different browsers. Their Grids library works really well.
Could you please elaborate little what you're referring to?
JavaScript in it's core is have mainly been the same the last 10 years. If you're worried about older IE versions (IE6-7) you can remain calm. IE6 was released with JavaScript 1.5 support so all JS code should run fine. Mozilla has a very good JS ref document at their MDC site. At the bottom of each page there's usually a list of what version of each browser that supports that specific function.
However the difference between browser usually lies in the DOM implementation or event handling. Where properties may have different names, at the top of my head these properties mainly are related to element/scroll positions.
To find the correct property to use, check in the developer tool (Firebug in IE, Developer Tools in Webkit or Developer Toolbar in IE) for that browser to find what you are looking for. If you're unsure set at JavaScript breakpoint in your code using the debugger;keyword or send something to the console using console.log(). In IE Developer Toolbar is available from IE8+ (I think).
Most of these problems are already resolved in the major JavaScript frameworks like jQuery, MonoTools and so on.
The two main "special treatment" things that come to mind are:
Events. Including assignment of event handlers, the way the event object is made available to the handler function, and some of the properties of the event object. See this page for more info: http://www.quirksmode.org/js/introevents.html
Ajax. Use of XMLHttpRequest versus ActiveXObject("Microsoft.XMLHTTP").
Most everything else should be fine.
You can write yourself some (relatively) simple helper functions to get around these issues, or use a library like jQuery that normalises the differences for you. If you do write it yourself, be sure to test for feature support rather than try to test for which browser - see this (long) article for an explanation: http://jibbering.com/faq/notes/detect-browser/ (I'm sure there are shorter explanations around but I can't be bothered finding one.)
If you using jquery in your page then you can check for ie with this code
if ($.browser.msie && $.browser.version == '6.0') {
//do IE specific code
}
This code will only run when the user browser will be IE 6.0 or you leave this condition
I was doing the browser recognition tutorial on w3schools,and I found that when using firefox and google chrome I received Netscape 5 as my result. I was just curious as to why this is. Anyone care to explain it to me?
I think this article about the Browser Object Model essentially answers your question. Basically, the navigator object is useless, and no one bothers to update it. Firefox has its roots in Netscape, and these properties have simply never been updated. (Note: I'd be interested in why they've never been updated, but I haven't found it yet).
That tutorial you're following at w3c is out of date. It's using an extremely old method of browser detection that quite simply doesn't work any more. A better version is here, but even this method isn't recommended any longer. All of these properties can be spoofed, and are quite simply unreliable.
The general method to identifying browsers these days is a technique called object detection, which essentially pokes at your browser's capabilities, and identifies it based on what it can do or what specific objects might exist.
It's of interest to note that modern libraries such as MooTools and JQuery make browser identification very trivial and clean by doing all this object and feature detection for you. MooTools has a Browser object, and JQuery has jQuery.browser, now deprecated in favour of jQuery.support.
Those were the days ;) Old style.
use navigator.userAgent instead
http://www.javascriptkit.com/javatutors/navigator.shtml
This trending topic might also be of use:
When IE8 is not IE8 what is $.browser.version?
To echo some of the other comments. Browser sniffing using the user agent is unreliable. Object detection and feature detection are the way to go