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.
Related
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.
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 would be interested to know a little about the history of the process of implementing touch events into the javascript language, such as when, but, better yet, the process by which the javascript developers decided on the rules for the touch api (is it an api?).
Also, do all touch devices adhere to a standard set of rules ... they would have to, right? otherwise how could javascript's touch api be cross-device dependable.
EDIT: wouldn't implementing a touch api into javascript constitute a new version of javascript?
wouldn't implementing a touch api into javascript constitute a new version of javascript?
Its important to recognize that the word Javascript can refer to many different things. There's the official ECMAScript spec, and then there are various implementations by different browsers and server-side environments. These implementations all implement different parts of the ECMAScript spec. Generally they each include some subset of the spec, along with some proprietary features as well. There were implementations of touch APIs (going back to safari on the original iPhone at least) well before it was part of the official spec.
This seems to be the spec that defines these events http://www.w3.org/TR/touch-events/, where it says:
Implementations that use ECMAScript to implement the APIs defined in
this specification must implement them in a manner consistent with the
ECMAScript Bindings defined in the Web IDL specification [WEBIDL] as
this specification uses that specification and terminology.
JavaScript is ECMAScript, or if you will, the ECMAScript implementation from Mozilla.
__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