Which browsers, if any, support Object.observe? I'm surprised I'm unable to find any info on this.
(And are you aware about any estimated times of arrival for this feature?)
About Object.observe: "Object.observe allows for the direct observation of changes to ECMAScript objects. It allows an observer to receive a time-ordered sequence of change records which describe the set of changes which took place to the set of observed objects." — see ecmascript.org, the Solution section.)
Edit November 2015: Apparently Object.observe has been cancelled:
http://www.infoq.com/news/2015/11/object-observe-withdrawn
https://esdiscuss.org/topic/an-update-on-object-observe
"I plan to withdraw the Object.observe proposal from TC39"
https://esdiscuss.org/topic/save-object-observe-please-make-weakmap-weakset-observable
"Save Object.observe()! (please)"
You can use kangax's Browser Compatibility Table for Object.observe
It is part of ECMA Script 7 Specifications, it seems. Luckily, at the time of this writing, my current browser, Chrome 33, is the only one which supports it :)
If you like to enable it in Chrome 33,
Visit chrome://flags/
And enable Enable Experimental JavaScript
Polymer is a new and promising framework that intends to implement Web Components, for which Object.observe() is an integral part.
It provides polyfill implementation for "evergreen" browsers; the latest ones available.
Moreover, they track what browser have native support for this feature, so it speeds up their implementation.
This polyfill is available as a separate library on GitHub.
No browsers. If its not true today, it will be true someday, and then this can be the accepted answer.
Chrome 35+ supports Object.observe() Method.
More details here: html5rocks
Update: It's moved to chrome 36 beta.
It used to be present in both Chrome & Opera, but the feature has been removed from both browsers after the standards committee withdrew the proposal for this feature!
Chrome 36+, Opera 30+. My favorite way of answering these questions is http://caniuse.com. It's clear, consice, and has instant search.
Disclaimer: I'm the author of object-observer library.
basarat's answer is definitelly the right one - nowadays no browser supports it.
Most of the polyfills performing 'dirty-checks' - not the best way to achieve observance IMHO.
Better way is to pick up one of the several libraries providing the same functionality utilizing native Proxy capabilities, object-observer being just one of them.
Related
After having read another similar post that doesn't answer mine, I wonder what is an easy and fast way to know if my Chrome version 68 supports JavaScript ES9 ECMAScript 2018.
There will not be a major release of ES9 in any browser. In the past it has always been a feature by feature rollout. This behavior probably has parts of its reasons in the way a ECMAScript standard is developed. Before any feature is moved to the final stage in the standardization process it has to be implemented in at least two independent implementations, typically browsers. So each feature will probably land in the major browsers eventually, but probably even before the standard they belong to is finalized.
For more information see https://tc39.github.io/process-document/ (see notes at Stage 4, finished).
Is anyone aware of a definitive list of areas of missing support for ECMAScript/JavaScript in the major browsers (I'm talking IE7+, Firefox, Chrome, Safari and Opera).
Obviously we do feature detection in our code, but I'd like a list of features that we need to perform detection on ideally.
Some commonly referenced sources are
Great compatibility tables at QuirksMode. Some of them are being updated recently.
Kangax sums up ES5 support very well.
Microsoft released reports of IE standards support.
Can I Use also includes some information about support of a few Javascript APIs.
A popular source many folks use is: http://kangax.github.com/es5-compat-table/
For Mozilla: https://developer.mozilla.org/En/JavaScript/ECMAScript_5_support_in_Mozilla
For Webkit: http://labs.trolltech.com/blogs/2010/01/15/ecmascript-5-and-webkitjavascriptcore/
For IE: http://www.microsoft.com/download/en/details.aspx?id=14170
You might find Thomas Lahn's ECMAScript support matrix useful.
I doubt very much that there is a definitive list of all the bugs, non-conformities or inconsistencies of browsers, even if restricted to some (undefined) set of "major browsers". The usual strategy is to program for standards and use feature detection and documented alternatives to work around known inconsistencies. Then test as widely as reasonable to discover the unknowns.
While browsers frequently introduce new features, they rarely remove old ones without a very long period of deprecation. So well written code should continue to work in new browsers even if if contains feature tests to work around inconsistencies in browsers that are no longer in use.
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.
I want to determine the best javascript framework to use in order to maintain IE 6 compatibility.
Specifically I want to know which best supports IE6 - Dojo or JQuery.
I determine compatibility based on the amount of work you have to do to make the framework work with IE6 (framework may have features that need special coding to enable them to work with IE6, or there may be features that are incompatible altogether).
Are there any benchmarks, or compatibility matrices, for the various javascript frameworks that quantify the work you would have to do to maintain IE6 compatibility?
Both jQuery and DOJO claim they support IE6:
http://docs.jquery.com/Browser_Compatibility
http://o.dojotoolkit.org/support/faq/what-browsers-does-dojo-support
DOJO does seem to have quite a grandiose claim:
... 100% of the available
functionality works, that
accessibility is handled correctly,
and that all internationalization and
localization is supported. This is a
very high bar, ...
And jQuery claims they test regularly in IE6.
Personally, I would let other requirements dictate which framework you use. One of the fundamental jobs for a JavaScript library is to be cross browser compatible, so any decent library is going to be good at it.
"Better" in your question indicates subjectivity, so I'd probably change this to a community wiki.
The best thing to do in each case is to look at what the libraries say they support. I know that he following frameworks handle IE6 well:
Prototype
jQuery
I don't have up-to-date personal experience with Dojo or ExtJS, but they supported IE6 well a couple of years back when I looked into them — I'd be surprised if they don't still support it (for now). (ExtJS's "learn more" page says IE6 and up; the "supported" list on the Dojo front page is not, shocking, a link to a list.)
The Closure team originally said they supported IE6 (although they have no official list), but that may have changed with Google's recent decision to drop IE6 support from their web apps.
Amongst other things, the main priority of a javascript library is to solve the cross-browser issues. Having said that, I personally use jQuery and yes it overcomes the IE6 issues too other than other later versions of IE.
It's the year 2009. Internet Explorer 8 has finally been released, and Firefox is coming up to 3.5. Many of the large browsers are starting to integrate features from CSS3 and HTML 5, or have been doing that for quite a while now. Still, I find myself developing web pages exactly the same way I did back in 2005.
A lot of progress has been made since then, and I think the reason that I haven't started taking advantage of these new possibilities is that it's so hard to know which of the new features that work in all major browsers. Since I'm mostly a backend developer I just don't have the time to keep up these developments anymore. Still, I feel like I'm missing out on a lot of cool stuff that actually would make my life a lot easier.
How can I quickly determine if a feature of CSS3 or HTML5 is supported by all major modern browsers?
Can I Use is a website which tracks browser support for current and upcoming web standards. Check it out if you would like to know whether or not a given feature is widely supported.
Font embedding through CSS, using #font-face. Webkit/Safari has been supporting it since version 3.1, Microsoft since IE4, Mozilla since Firefox 3.5 (browser support overview).
Also, the varied implementations of the Selectors API, which provides a browser-native CSS selector engine for use in DOM scripting.
For other examples, When Can I Use... seems to be a very good reference.
I would say display:table and a range of CSS2.1 selectors are the big wins for designers. display:table solves some unsolvable or difficult layouts like 100% height and inside borders without breaking semantics and using actual tables.
Multiple classes (.c1.c2)
I use min/max-width/height a lot.
Also working :hover and !important are awesome.
I would have liked to add SVG support to that list but naturally Microsoft messed that up.
BTW, big warning to those getting excited about HTML5 features. There is no official date for the adoption of this spec. It's even been implied it could take another 10 years (though I doubt that). The point is anything you do with HTML5 now is subject to breakage when the official spec does arrive and in the meantime you can expect plenty of browser inconsistencies, bugs and API changes (not to mention browsers that don't support the features at all).
Browser support for local storage should enable a bunch of new ideas now that some content can be saved on a user's machine.
Reference docs:
Mozilla Firefox
Internet Explorer