Some features of the document.querySelector are not supported. I am worried that future changes made to the standard will bring change that might break code. I'm asking, as I discovered, KeyboardEvent.keyCode is likely to be removed and recommend to be replaced by KeyboardEvent.code this is an understandable change given depending on the keyboard the behavior changes but it doesn't change the fact that removing it breaks legacy sites and appilcations.
What is the fate regarding querySelector and the living standard; it confuses me.
I'm getting my question from second hand research from mozilla's documentation on the matter. Know I might understand better the intent if I was better in tune with W3C's precedent but I have trouble finding and reading W3C's intentions. https://dom.spec.watwag.org describes it and only mentions an intention to not add namespaces. I'm slightly confused on the matter and was hoping someone would know more then I.
I'm getting my question from second hand research from mozilla's documentation on the matter. Know I might understand better the intent if I was better in tune with W3C's precedent but I have trouble finding and reading W3C's intentions.
The obsolete selectors-api2 spec says that the Selectors API definitions have been merged into the DOM spec. Being the W3C, this is referring to their own DOM spec; the living DOM spec is dom.spec.whatwg.org (unlike the WHATWG, the W3C generally doesn't call their specs living specs because every TR is versioned and each version goes through its own standardization process). For some reason that MDN article doesn't contain a link to either DOM spec despite now correctly labeling the W3C Selectors API specs obsolete.
So no, querySelector() isn't going away, hasn't been deprecated. Nothing to worry about.
... describes it and only mentions an intention to not add namespaces.
That's just referring to the Selectors API not providing support for namespaced type and attribute selectors since those require a #namespace CSS at-rule, which cannot appear in or around a selector, to work.
Related
document.domconfig is obsolete and removed. Any heads up on what it was replaced with? Or how can I get the DOMConfiguration which is also obsolete?
Based on the javascript tag and lack of comments to the contrary, I'm assuming this question is about web browsers.
document.domConfig (and the related interface DOMConfiguration) was introduced in W3C DOM Level 3 Core in 2004.
The standard was not created only with web browsers in mind, as a matter of fact none of the implementations required to become a W3C Recommendation were part of a web browser.
So when the web browser renaissance began, a version of the DOM spec specifically for web browsers was created, now known as DOM Living Standard. Since there were no implementations of DOMConfiguration (indicating lack of interest from implementers and presumably web developers, particularly because many of the features are not relevant to the HTML DOM), the feature was simply pruned from the specification.
It was not replaced by anything in particular; there was nothing to replace.
If you asked "I could do X with domConfig, how do I do it in a web browser" you might get a better answer, but for a generic question about an interface with a dozen rather obscure options I guess this is what the answer should be.
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.
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
I'm trying to find any JavaScript frameworks whose sole aim is to standardize the DOM and JavaScript across all browsers.
What I'm not looking for is frameworks which create their own API to solve these common problems. I want something that will allow me to call for example myElement.dispatchEvent("click") in Internet Explorer. Not something that creates its own observer pattern with its own API.
At the moment the closest thing I can find is www.flowjs.com, this looks good and covers a lot but is missing document.createEvent and a few other features and supplies no contact information from the author.
Regards,
Chris
Dean Edwards' Base2 might be what you're looking for. You might find Diego Perini's NWEvents interesting as well...
Although it has its own API, Prototype tries to do that (at least partially). If you use Firebug, you can notice a lot of methods added to the DOM, in order to make the DOM equally in all browsers.
I know it's not exactly what you were looking for, but it's a half-way solution.
Also, in some browsers, it might not be possible to override some elements of the DOM. Try doing window.alert = function(i) {}; and it will raise errors in some browsers.
There is Ample SDK framework that contains DOM-Events / DOM-Core, and many other standards implementations. Although, it is less known yet, I would strongly recommend taking look into that.
Also, please note, myElement.dispatchEvent("click") is not something standard.
A comprehensive summary of JS libraries that standardize JS and DOM across browsers:
base2
Creator: Dean Edwards - http://dean.edwards.name/
Project page: http://base2.googlecode.com/
flowjs
Creator: Richard Herrera - http://http://doctyper.com/
Home page: http://flowjs.com/
Project page: http://flowjs.googlecode.com/
JDC
Creator: Tavs Dokkedahl?? - http://www.jslab.dk/
Project page: http://www.jslab.dk/projects.php
SLAB
Creator: Sean Hogan (that's me) - http://meekostuff.net/
Project page: http://meekostuff.net/projects/SLAB
WARNING: these libraries may be larger than you are expecting.
There's actually quite a lot of code required for IE6 / IE7.