There are many polyfills out there to convert the contents of a Canvas to a Blob. Before deciding to go with one of those, wanted to know the support of native method canvas.toBlob() on various browsers. How stable is the method in different browsers?? Couldn't find it on http://caniuse.com
Note: I am not looking for server side solutions or client-side polyfill based solutions. Interested in knowing about the stability of toBlob() API.
Updated Feb 02, 2017: canvas.toBlob is supported in Chrome since 50 as well as in Opera (Blink).
At the moment of this writing the support for toBlob() is poor (major browsers only):
Firefox has support (as currently the only one)
Chrome has intended support but there is currently an unsolved issue with it.
Internet Explorer 10-11 support it using prefix, msToBlob() but returns only PNG
Safari has an issue with status "resolved/won't fix"
Opera (Blink) has no support (method not present on canvas element)
Opera (old) has no support (method not present on canvas element)
None support toBlobHD() at this time (as with most of the HD suffixed methods).
Related
All:
I wonder if there is any plugin or something work as a virtual container can turn IE into Chrome environment? Just like running applet across browsers?
If no way to do this, can any one suggest some light weight solution to build an VM image?
Thanks
The Chrome team used to support a utility called Chrome Frame, but this was during a time when nearly all major IE versions had poor support for HTML5 and "CSS3".
The utility is no longer supported:
[In 2009] many people were using browsers that lagged behind the leading edge...
Today, most people are using modern browsers that support the majority
of the latest web technologies. Better yet, the usage of legacy
browsers is declining significantly and newer browsers stay up to date
automatically, which means the leading edge has become mainstream.
Given these factors we’ve decided to retire Chrome Frame, and will cease support and updates for the product in January 2014.
I'm not sure what you mean by the second part of your question though, regarding the building of a virtual machine. Virtual machines of Internet Explorer are available for free though http://modern.ie.
When i run HTML5 compatibility test in Android native browser then it see the IndexedDB support marked as "Prefixed", while in Chrome and other it is marked as "Yes".
I understand Chrome latest version has full support for IndexedDB but what does IndexedDB support as "Prefixed" means?
According to Mozilla page:
https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB
"Because the specification is still evolving, current implementations of IndexedDB hide under browser prefixes. Browser vendors may have different implementations of the standard IndexedDB API until the specification has solidified. But once consensus is reached on the standard, the vendors implement it without the prefix tags. Actually some implementations have removed the prefix: Internet Explorer 10, Firefox 16, Chrome 24. When they use a prefix, Gecko-based browsers use the moz prefix, while WebKit-based browsers use the webkit prefix."
As per Josh's comment:
Use something like the following statement to ensure compatibility:
window.indexedDB = window.indexedDB || window.webkitIndexedDB;
The characters 'webkit' are the prefix. You might need to use them in Android, but you no longer need to use them in Chrome (a few years ago you did)
Please could somebody list the browsers and versions for which the Content-Type: Multipart/X-Mixed-Replace is supported for creating an application based on comet principles. I have read conflicting accounts of its support in Chrome and Internet Explorer - although some reports mention its inclusion in IE 10.
A follow-up question is, how stable is this technology to build real-time applications? I ask because Wikipedia currently lists this Content-Type as experimental.
Thanks in advance!
The page you link to also answers your question. It is supported in FireFox, Chrome and Safari, but not in IE or in Safari on the iPhone. The page doesn't say anything about IE 10, but since it isn't officially released yet, that makes sense.
According to MSDN, though, IE 10 does seem to support Comet streaming.
Apart from IE, it has been around for years (since 1995 actually) and should be very stable. The reason why it is marked experimental, is that it isn't declared an official standard yet.
Apparently Google Analytics already uses this technology and I think they wouldn't if it wasn't stable.
Like the title says I'm just wondering the current support for canvas.toDataUrl? I have it working in Firefox 4 but haven't really tried it in any other browers. When I look it up on Google most of the results are pretty scattered as some are from a year ago. It says its only supported with webkit nightly builds. (which I assume now are the actual releases)
I'd also like to know the support for mobile devices as well.
I personally prefer using caniuse.com for finding out the current browser support. Caniuse covers various major releases of each browser, as well as some mobile browsers. However, I always recommend that with anything mission critical, you test in all browsers just to be on the safe side.
If you take a look again at caniuse.com you will see that the support tables are all color-coded and they tell you whether a browser fully-supports, partially-supports, does not support, or does not support (but a polyfill exists). The canvas.toDataUrl, property would fall under the category of "basic support", which shows that the canvas api (or rather the current working draft for it) is fully supported in all major browsers, and there is a polyfill available for IE.
So while it doesn't go into great detail about the specific properties browsers support, it stands to reason if a browser "fully-supports" the basic canvas API, you can safely assume that includes toDataUrl. Once again, if you dont want to leave things to chance, or if you for some reason do not trust caniuse.com, your best bet is to build a test-suite and personally test your app against all browsers.
Actually it's currently broken in the webkit nightly build, a minor security bug I found a couple days ago:
http://code.google.com/p/chromium/issues/detail?id=91016
But in general in the stable release of Chrome it works just fine. In IE9 it works just fine too.
If you had to choose a browser (just one) to be the primarily supported browser for a company jumping into HTML5 (CSS3).. Which one would be your safest bet on the middle-long term?
Chrome, FireFox, Safari, IE?
I'm looking for an objective recommendation based on standards driven/compliant, developer tools, fast & correct feature implementations, memory footprint, etc.
UserBase/MarketShare would not be an issue because it would be on a closed environment in which we control the clients (which are basically big machines with a Web interface).
Thanks!
I would say a webkit based browser. That would be the best balance of speed/stability and HTML5/CSS3 features.
However I believe that Opera has the most implemented features.
Opera has always been in the lead, but they've also always had weird bugs. Right now, Chrome is in an interesting position: Google just bought an internet video protocol company (On2), and so they have the power to end the H.264 vs. Ogg Theora battle by releasing this great new codec they've bought as open source.
HTML5 itself isn't anything new: it's just new elements that display differently. Think of it like this: if HTML5 was the first to introduce the <blink> tag, developers would be a little iffy about it because you can just use CSS to set text-decoration:blink or use some Javascript to make the blinking happen.
With HTML5, things aren't that different. Most of the new elements are just extensions of <div>. For the ones that aren't (<video>, <audio>, <canvas>, etc.), there are either already strong implementations (pretty much across the board) or the implementations as complete as the HTML5 spec is.
Will there be a best browser for HTML5? Probably not. It's all just a matter of how the browsers position themselves (like I mentioned with Chrome above).
If you control the environment I would say pick one based on that has features your app can exploit to make your job easier. Otherwise, lower-common-denominator is a widely used approach for a small team.
I would say Gecko (firefox and friends) or webkit (safari, chrome and friends). I wouldn't go with IE nor Opera. Here is a HTML5/CSS3 comparison table that pretty much supports my views.
Safari’s pushing CSS animations and transitions, if they’re a big draw for you.
If you want to make a HTML5 app/site that focuses on one browser, then you might as well use HTML 4 and JavaScript. For the next many many years most HTML5 sites will have to function in non-HTML5 mode.
See HTML5 features as glacing on the cake, to add benefits to the browsers that can take advantage of it.
All the modern versions of browser support HTML 5. But recently launched internet explorer 9 specifically designed by keeping in mind future web technology needs and incorporated latest features that give rich and interactive web experience. Latest browser Internet explorer 9 has more support for Cascading Style Sheet than previous versions of Microsoft browser. It supports CSS3 and more emerging SVG2 markup standards. IE 9 includes new java script engine that designed to take advantage of multi core processor and give maximum performance.