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.
Related
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.
__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
as I am getting more and more into Android PhoneGap app development, I can see more and more nuances and little details between built-in Android browsers throughout the versions. I searched for some official or fan document, which would deal with these browser version differences. But I can't find anything useful.
It's a lot frustrating, because you have to test everything on all versions of Android emulator and if app grows big, it's A LOT of work to test all the features in all versions.
Everyone is excited about HTML5, I was too, but only to the point when I moved to doing the real thing. I realized that there is so many problems when dealing with different versions of Android behaving sometimes a lot differently.
If anyone has some good resource to share, I would be very happy. Thanks
EDIT: Added example of different behaviour betweeen Android browser versions ( but there is many of them):
This works in Android browser in 1.6, 2.2, 2.3 and 2.3.3. But it failes (application crashes or stops JS execution) in Android 2.1:
Object.keys(var).length
You asked a pretty general question. The general purpose answer is that any sort of cross browser development (even cross versions of the same browser) requires that you develop a familiarity with what features are safe across the targeted browsers, which features are not safe across the targeted browsers and which ones must be used only with careful testing or feature detection with fallback.
While one wouldn't exactly expect the type of difference you saw with the one example you referenced, it is clear that that is a fairly new feature in ECMAScript and it's not consistently implemented across normal browsers so I would put it in the category where it is not safe to assume that it works on all versions of Android, even if you've seen it some versions of Android. That means to me that you should only use it if you've explicitly tested that it's reliable in all the browser versions you are targeting or devise a feature test and only use it when you know it's present and reliable or develop a safer work-around.
As I think has been mentioned previously, this thread has a bunch of proposed work-arounds for the specific issue you mentioned.
I am not aware of any detailed written material that would document in advance for you the details of the differences between different Android browser versions. Since it's open source, there are probably developer checkin notes and some level of release notes, but that will probably be like looking for a needle in a haystack and may not even contain what you want. It is rare for any developers to produce such detailed information. We don't generally get that level of detail from any of the existing desktop browsers or iOS browsers and, even if you were on the development team itself, you probably would only see part of this info. I don't think you're going to find official documentation that covers what you want.
You're going to have to learn to treat is as more of an unknown and learn what areas are "safe", what areas require extensive testing before using and what areas are just too risky. Even when doing that, you'll find Android bugs in some version that trip you up. That's just the nature of building on someone else's platform. At least the Android set of browsers are a much simpler target than trying to target all desktop browsers from IE6 to IE9, Firefox 3 to 5, Safari 3 to 5, Opera 9 to 11, Chrome 9 to 12, all Android, all iOS and use HTML5 when available which is what I'm working on.
Once you've been through this wringer a couple times, you will realize that if the newer language/library feature carries any risk, you shouldn't use it at all unless it's absolutely central to what you're trying to accomplish and then you will have to test the hell out of it. If it's something like getting the length of the associative array which is just a programmer's convenience, then it's probably simpler to stick with a work-around that is guaranteed to be safe and just not spend your time dealing with any browser-support risk.
The only official documentation I am aware of is part of the Android developer documentation. If I were a betting man, I would bet that it only covers a subset of what you are seeking.
The general idea behind cross browser Javascript is inline feature testing (at least how I've come to accept it.) I don't know exactly what "features" you are specifically looking for but it's generally wise to test for the existence of a feature set then use it and have a fallback if that doesn't exist. (Even if the fallback is, "This site requires a browser that supports 'foo'")
Since you didn't give any examples, I'll pick on Ajax. It's always best to check for the existence of window.XMLHttpRequest, then act upon it. Of course, this is not performant if you are doing it for every instance of need so you could write a check procedure or a wrapper to accept your list of necessity let your wrapper cache/call the appropriate methods to perform that task.
Without examples of "features" that you are talking about being different from browser to browser though, it's hard to give any concrete advice on direction.
Let me start by saying I really appreciate the work done at QuirksMode.org but in recent experience the content seems a bit dated.
Some pages haven't been updated from anywhere between 6months and a year.
Compatibility tables still only show chrome at version 5.0 (W3C DOM Compatibility) or 1.0 (Event compatibility tables)
In cases where content seems a bit dated I generally refer to Sitepoint's References, but their HTML and Javascript Reference pages are also a bit our of date.
What compatibility reference guides do you all use?
update
I'm aware of sites like CanIUse, which are invaluable reference new feature support like new JS API libraries and CSS3 support. However I'm more interested in things like supported attributes (bad example I admit) and browser events. The more vanilla stuff.
And please, noone mention w3schools (see w3fools why you should never use this site)
http://caniuse.com is quite good and (provided you use the correct keywords) has good search functionality as well.
In addition to the above you might be interested in the ES5 compatibility tables that Kangax maintains at http://kangax.github.com/es5-compat-table/
update
In the meantime there is also the ES6 compat table. Quite red for now (9/2014) admittedly, but getting more and more useful.
I trust Quirksmode, have you any idea how many tests PPK runs? It's not that it's outdated (yet!) it's that CSS support (and Browser uptake) has reached a new level, trust me you will appreciate the experience if you have to support an older browser.
Not every FF or Opera user updates quickly anymore which is what could be relied on for a while! - so yes you're right to question the findings. personally I look for recent sites too but I don't "trust" them nearly as much as the older and even then I tend to test for myself.
There's no replacement for experience IMO often these guys can "guess" at what may be the problem based on their past experience even if the so called "bug" or unexpected display is new to them in that context.
I have a "bug" report detailed on PPK's site - yea it and me are old - but only last week I got asked about something (seemingly unrelated) which turned out to be the same thing and have the same solution, it's IE7 related so will be with us for a while yet. (I see caniuse thinks that's old eeek!) - I am completely in awe of these guys who have kept up these sites for so long, if you can reverse engineer the bugs you get to understand the browsers.. that will never fail you as long as the browsers are on the go - their render engines don't usually change all that much between versions!
but then again this is a new era of Browser wars so who knows what will happen :)
Have a look at this big javascript compatibility table
http://compatibility.shwups-cms.ch/de/home/
Its very big, but checks at the moment only for existenz of javascript properties.
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