I was seeing the W3C Document Object Model and excited that different programming languages have to implement their interfaces accordingly. Like other languages, JavaScript also maintains the DOM.
So I'm curious to know about the following questions:
Which versions of javascript implements dom level 1, 2,3 and so
forth.
Are they all implemented in javascript?
Are they implemented by javascript or implemented by ECMAScript and
followed by JavaScript?
And what are the IDL definitions described in W3C DOM: Are they
needed to understand for javascript developers or is that the symbol
of implementation by HTML?
The pedantic answer is "none".
There is no formal mapping of JS iteration to DOM-specification.
In general, JS-versioning has all but been abandoned (save major overhauls), though can be seen as signposts of when you might start to consider feature-checking.
This is because...
Not really, no.
That is to say, yes, the APIs which you will use to interface with the HTML DOM are all implemented in JavaScript...
However, no browser has a stable, feature-complete implementation of either
JS or HTML DOM[1-4].
Because both specs are so large, and ever-changing, different vendors have prioritized different features at different times, leading to patches of incompatibility.
To further this actual answer, the JS spec says nothing of DOM or BOM ("Browser ...") APIs.
This is the reason #1 must be a "No", as different DOM/BOM combinations on different JS implementations leads to the fundamental inability to say "All JS1.7-compliant browsers are DOM3 compliant."
The truth is that no browser is wholly compliant with either spec, and neither spec is the latest, anyway. As for technical-implementation (the code behind the API), there are no rules, so long as the behaviour is well-defined. Some browsers defer to C/C++ for core JS/DOM/BOM functionality, while older IE browsers had an ActiveX layer between the browser and JS DOM access (making touching elements for any reason arbitrarily expensive).
Here's the rub.
Most people would consider them to be different things.
Most people would think "JS is the thing that you use in the browser, to do your scripting.".
Really, ECMAScript and JavaScript are the same thing, and "JavaScript" is a Sun (now Oracle) trademark... how none of us are getting sued is a mystery.
JS/ECMAS knows nothing of DOM or BOM, and it's up to the vendors to include DOM-access in their browser (on a per-feature, rather than per-version basis). It should also be noted that while VendorA might implement a feature from the spec, and VendorB might omit it, VendorC might have an off-standard implementation of it, and also implement a similar but completely out-of-spec feature, as well.
Don't worry about the DOM implementation specifics.
As a JS-dev, you won't need to know or care what a Java implementation of an HTML node might look like.
Even with WebIDL, and moving away from the old-world Java-centric view, as far as day-to-day usage of JS as a language, the DOM-node interfaces are as dry as toast, unbuttered, face-down in a sand dune, unless it's really what you're into.
Even then, it's more for people who make the browsers, and not the people who make things which run in them.
These aren't all of the answers. And while I've tried to remain subjective, I'm sure there's a little objectivism in there, as they aren't wholly cut and dry. I've tried to be, at least, factual.
From an engineering perspective, being careful about how and when you use the DOM in client-side JS is important -- both for making code portable and for allowing each language in the client-side stack to have access to the HTML in question, without doing somersaults in JS, to accommodate, because you built your whole site using DOM construction in JS.
From a pragmatic standpoint, rather than trying to match features to versions, use sites like http://caniuse.com to match features to browser versions. It's much more productive.
And have fun.
Related
Where can I find a list of all the differences between V8 and ECMAScript? For example V8 supports const, which isn't part of the ECMAScript standard.
Edit: Direct answer: Track status of ES5 implementations in progress which indicates the V8 googlecode issues tagged es5
or https://github.com/joyent/node/wiki/ECMA-5-Mozilla-Features-Implemented-in-V8
V8 implements all of ES5 currently aside from a handful of edge cases, and only then in order to be compliant with the majority of how other current browsers handle the given situation.
Because it won't be living on its own nearly all of the differences you'll be dealing with will be in the host environment implementation wrapped around it. For most uses this is the various APIs web browsers provide. As a non-browser example, Node.js provides custom APIs for file system and network interaction. In terms of core language there's just not that much wiggle room. Minus the DOM, JavaScript is a pretty damn simple language to use (part of why it's so awesome) and has a really specific Specification document.
ES5 is an iteration up from ES3 and nearly 100% backwards compatible if not using 'use strict'. After nearly a decade of stagnation along with inability to gain a consensus among major JavaScript engine implementers ES5 was born and limited primarily to cut out and address the worst issues with the language. The extent of mainstream use ES5 is Array extras, Object extras (mainly Object.create), Function.bind, and strict mode (which is entirely about stripping features out), and a handful of natives helpers like built in JSON and base64.
Most of this 240 page specification is spent in laboriously defining every detail about behavior that has existed in JavaScript for almost 15 years, as well as the list of features which will be deprecated and eventually removed (with, various uses of eval, etc.).
Harmony (ES6) is the first real big change we're going to see. ES5 accomplished the goal of getting engine implementations on the same page and gutting most of the problematic parts of JS. Looking forward to ES6, it's time to address some fundamental language issues that require syntax changes to fix. ES6 is scheduled for finalization in late 2013 but large chunks are already implemented in JS engines in order to test them and see how they work in practical usage. The web is a living thing and implementing new standards isn't a matter of creating a new spec and then unleashing it on the world like it is most other industries. Ideas are floated and must past muster at both the implementer level (the guys who write V8, Spidermonkey, JSC, Chakra, etc.) and then the actual user level (user in this case being web developers writing code to run in those engines). Ivory tower dictation just results in lack of use.
Specifically in the case of const: this is currently not exactly defined entirely. It's a keyword with similar but not exactly the same functionality in V8 and Spidermonkey, and has a similar but not exactly the same meaning for ES6. You're probably safe to use it if you expect your target audience's engine to support it currently, but as implemented it wasn't technically part of any official spec. migrating let' andconst'
Beyond that there's "Host Objects" which are exposed by the given engine a JS script is running in. JavaScript existed first as an implementation and second as a specification, so until recently it wasn't obvious to non-experts to know where the diving line is. When it's running in a browser (as is usually the case) the Document Object Model is exposed as a host object for automatic usage. The functionality of the DOM is largely described using IDL and is under the purview of the W3C. The multitude of specification implementations encompass 6 top level sections, almost 50 separate working groups, and around 1000 separate specifications. These are interfaces exposed to JavaScript but completely ungoverned by the requirements of any JavaScript specification. The DOM encompasses a huge space of described functionality and continuously changing implementations thereof.
Are there general reasons not to deal with Document's and Element's prototype?
I like to create my own little framework, because my current project doesn't need the mass of features of the existing frameworks.
I don't need to support browsers which don't support Element/Document-constructor and also will not execute scripts that are not under my control.
So would you recommend to extend the prototype or should I go the usual way and create own objects from Element/Document?
Do you plan to extend default DOM elements? If so, please don't. Juriy Zaytsev (aka Kangax) clearly describes why not in What’s wrong with extending the DOM.
Yes, unfortunately. It would be lovely to be able to add functionality by fiddling the DOM prototypes, but in practice it's just not reliable given today's technology.
Document, Element and others etc may be ‘host objects’ implemented by the browser with no ability to fiddle with their prototypes. Host objects may potentially have many other weird behaviours that a native JavaScript object wouldn't. DOM Nodes are host objects in IE6-7 and many older, niche and mobile browsers.
Even if they are implemented as native-JavaScript objects, there is no standard (yet) that described where the constructor-function for them is to be found, for you to go fishing about in the .prototype. Document, Element and so on are just W3 DOM interface names, they say nothing about what the implementation objects are to be found.
It happens that modern browsers (IE8 native mode and recent versions of Firefox, Opera and WebKit) do make constructor-functions available so you can start adding methods to Document or HTMLElement. But even then, there are differences between what objects are exposed, as not every browser provides the DOM interfaces with implementations under the same names. (The subinterfaces/implementations of NodeList are particularly troublesome.)
You can see how DOM prototyping has worked in practice by looking at the Prototype.js framework. When it works, it's super smooth. But because you can't prototype everywhere, you end up with some extremely ugly stuff where the framework has to deal with places prototyping won't work by copying methods into every instance of a Node. And then you've got the situation where your code might forget it needs to force this ‘augmentation’ and so it might work or not work depending on whether some other function happened to augment the same node before. This leads to really horrible browser-specific, interaction-order-specific, race-condition-prone debugging pain.
If you can limit your prototyping work to a few well-supported interfaces, and give up on all but the latest browsers, you can probably get away with it.
what basic tips should we observe in design web pages(html/css/javascript) for having highest compatibility with most browsers(IE-firefox-opera-chrome-safari)?
thanks
Validate often and squash all validation errors by the time you make a public release. The purpose of validation, after all, is to parse the html as a standards-compliant browser would and then avoid the errors that a browser's parser would find.
Apply progressive-enhancement techniques. Often that means moving some of the complexity of dynamic pages to the back-end (e.g. php, django, what have you) so that you can have complex functionality that doesn't break in one of the thousands of different client environments in which a page's javascript will run. jQuery is excellent for narrowing the focus of your javascript development towards feature enhancement instead of open-ended features-in-javascript, and it'll help with cross-browser compatibility as well.
IE - Test in at least one live version of IE 7 or 8. Unfortunately, there really isn't any way around this, because even IE8 misbehaves like no other browser. If possible, limit your goal of support for IE6 to html/css (i.e. don't promise support for user-enhancement-features via javascript in ie6). If possible, drop support for IE 5.5 and below.
For Javascript, use libraries that are intended on being platform-independent (ie: JQuery, Prototype). Not everything will be, but it'll make your life much easier.
For CSS, I'd say follow standards, but IE tends to cause problems across the board.
Which means, you need to test, and test often. Selenium is awesome for automated functional testing, and it works with pretty much every browser. We use a Selenium RC server on a Windows machine to test IE and Firefox, which are then controlled from our standard Java JUnit tests.
Keep things simple.
The simpler your markup, CSS, and JavaScript, the easier it will be to track down incompatibilities. Try to limit yourself to CSS1 for as much as possible. Only use more modern CSS2/3 features when there is no easier way to accomplish your task.
Don't use tables, they just add extra complexity. Using semantic markup not only makes things maintainable, but also gets you the best cross browser support if done properly.
Keep in mind that floats are evil, but are also very powerful. Use them generously, but avoid trying to clear floats. Use overflow instead.
Use a JavaScript framework. Framework developers have smoothed out most of the cross-browser bugs for you. I recommend jQuery, but you can choose any framework your developers feel comfortable with. My advice is to:
Use a JavaScript framework that doesn't alter the prototypes of native objects (like Prototype JS does)
Doesn't introduce many global variables. Most frameworks follow this rule.
Aside from those 2 rules for JavaScript, try using closures to encapsulate code so you don't introduce your own global variables.
One strategy I use is to start my CSS with a set of rules that blank everything out. Each browser may have different values for element attributes so ensuring that everything is consistent from the get-go can be handy. Here is an example reset.css
http://meyerweb.com/eric/tools/css/reset/
Take a look at this great article: Browser Compatibility Tutorial
Remember: something won't just work for a specific browser (mayble a left dotted border won't show in Chrome). Do not be upset about that if you can! :) Cross-compatibility is an art that takes a lot of time.
I am going to play a devil's advocate for a moment. I have been always wondering why browser detection (as opposed to feature detection) is considered to be a flat out as a bad practise. If I test a certain version of certain browser and confirm that, that certain functionality behaves is in some predictable way then it seems OK to decide to do special case it. The reasoning is that it will be in future foolproof, because this partial browser version is not going to change. On the other hand, if I detect that a DOM element has a function X, it does not necessarily mean that:
This function works the same way in all browsers, and
More crucially, it will work the same way even in all future browsers.
I just peeked into the jQuery source and they do feature detection by inserting a carefully constructed snippet of HTML into DOM and then they check it for certain features. It’s a sensible and solid way, but i would say that it would be a bit too heavy if i just did something like this in my little piece of personal JavaScript (without jQuery). They also have the advantage of practically infinite QA resources. On the other hand, what you often see people doing is that they check for the existence of function X, and then based on this, they assume the function will behave certain way in all browsers which have this function.
I’m not saying anything in the sense that feature detection is not a good thing (if used correctly), but I wonder why browser detection is usually immediately dismissed even if it sounds logical. I wonder whether it is another trendy thing to say.
It seems to me browser detection has been widely frowned upon since this post by Resig a couple of years ago. Resig's comments however were specific to libraries/framework code, i.e. code that will be consumed by other [domain-specific] applications/sites.
I think feature detection is without question a good fit for libraries/frameworks. For domain-specific applications however I'm not so sure browser detection is that bad. It's suitable for working around known browser characteristics that are difficult to feature-detect, or for browsers that have bugs in their implementation of the feature itself. Times that browser detection is appropriate:
sites/applications that are not cross-browser and need to show a warning/dialog/DifferentPage tailoring to that client's browser. This is common in legacy applications.
Banks or private sites with strict policies on what browsers and versions are supported (to avoid known security exploits that may compromise user's data)
micro-optimizations: occasionally one browser is ridiculously faster than the others when performing some operation a certain way. It can be advantageous depending on your user base to branch on that particular browser/version.
Lack of png transparency in IE6
many display/rendering issues (read: IE css support) that are only witnessed in specific browser versions and you don't actually know what feature to test for.
That said, there are some major pitfalls (probably committed by most of us) to avoid when doing browser detection.
Here's a good article explaining how feature detection is superior in so many ways to browser sniffing.
The truth is that sniffing is extremely fragile. It's fragile in theory, as it relies on an arbitrary userAgent string and then practically maps that string to a certain behavior. It's also fragile in practice, as time has shown. Testing every major and minor version of dozens of browsers and trying to parse build numbers of some of those versions is not practical at all; Testing certain behavior for quirks, on the other hand, is much more robust. Feature tests, for example, often catch bugs and inconsistencies that browser vendors incidentally copy from each other.
From my own experience, fixing Prototype.js in IE8, I know that 90% of the problems could have been avoided if we didn't sniff in the first place.
While fixing Prototype.js I discovered that some of the features that need to be tested are actually very common among JS libraries, so I made a little collection of common feature tests for anyone willing to get rid of sniffing.
The ideal solution would be to have a combination of both feature and browser detection. The former falls down because of the points you mentioned and the latter because sometimes browsers publish false information to "make things work" just so.
Mozilla has a great Browser Detection Primer that might be helpful to you as well.
From wikipedia
"At various points in its history, use of the Web has been dominated by one browser to the extent that many websites are designed to work only with that particular browser, rather than according to standards from bodies such as the W3C and IETF. Such sites often include "browser sniffing" code, which alters the information sent out depending on the User-Agent string received. This can mean that less popular browsers are not sent complex content, even though they might be able to deal with it correctly, or in extreme cases refused all content. Thus various browsers "cloak" or "spoof" this string, in order to identify themselves as something else to such detection code; often, the browser's real identity is then included later in the string."
I was wondering why JavaScript has such a confusing API. It is not consistent across browsers, there is a different way to get the value from each type of form input, and it is unforgiving of mistakes. jQuery has changed my life because its API is so much easier. Why did the creators of JavaScript not set up the API like that in the first place?
The JavaScript API, itself, is consistent between browsers (and is defined by ECMA, though originally developed by Netscape). The difference between browsers is the document object model (DOM). The DOM was developed independently by the different browsers, originally IE and Netscape, but now IE, Mozilla and others. The W3C has joined to try to consolidate the differences and create a common standard. For backward compatibility, the old differences remain. And, yes, jQuery has gone a long way toward making the DOM easier.
Creators of Javascript did not setup the API, since Javascript is a language, not an API.
What you are refering to is the Document Object Model (DOM) which is the document manipulation API. It is a standard specified by the W3C and its behaviour should be consistent among browsers.
Unfortunately, some parts were badly specified, some other parts are badly implemented by browser vendors. Additionally, vendors extend this API with proprietary extensions that may never be added in the standard but that are very popular (like document.all in its time).
That's why today's API in browsers are so inconsistent.
I think most of it is the remnant of the browser war. Javascript had a very troublesome history, made of a total war between microsoft and netscape, with Sun involved as well. Javascript is actually a very nice language. It has some critical design mistakes, but you can work around them. As for the API, you can use a good wrapping library that hides all the complexity and uses the most appropriate API.
One important suggestion, if I may. Don't fight it, nor try to use it masked as something else. Embrace it even with its defects. Once you know them, you won't step on them anymore, or if something is fishy you will find the problem easily.
I'll bite. Check out Douglas Crockford's videos (http://javascript.crockford.com/), he does a good job explaining why some of JavaScript is in the situation that it's in. (http://yuiblog.com/blog/2007/01/24/video-crockford-tjpl/)
This doesn't directly answer your question, but:
A lot of people are bothered by the between-browser inconsistencies. While a few folks become really good at ironing out the differences in their own JavaScript code, most can't afford to spare the time. This is why there is such a profusion of frameworks available to do the dirty work for you. JQuery is the most popular of these, I think, and I'd recommend it to you as an alternative to swallowing a lot of Aspirin for your headaches.