Slashdot Mirror

Go to caniuse.com and find a feature that would prove useful to a particular web application. For example, look up camera and microphone access or 3D graphics. As long as a widely used browser (such as IE one version back or Safari for iOS) shows a red box for this feature, you have to build the application separately for each platform in order to avoid loss of business when users get an error message that a particular browser feature is absent.

Go to caniuse.com and find a feature that would prove useful to a particular web application. For example, look up camera and microphone access or 3D graphics. As long as a widely used browser (such as IE one version back or Safari for iOS) shows a red box for this feature, you have to build the application separately for each platform in order to avoid loss of business when users get an error message that a particular browser feature is absent.

What APNG needs isn't more tools, it's a convincing use case where it trumps WebP. And more than everything, it needs browser support: APNG 17.45%, WebP 40.17% plus Safari in the "near future". Neither is enough (unless you want to triple-encode everything), which is why /gif will be /gif for some more years.

What APNG needs isn't more tools, it's a convincing use case where it trumps WebP. And more than everything, it needs browser support: APNG 17.45%, WebP 40.17% plus Safari in the "near future". Neither is enough (unless you want to triple-encode everything), which is why /gif will be /gif for some more years.

Animated PNG support is terrible... see:

http://caniuse.com/apng

No IE, no Chrome, Opera dropped it when they went to Webkit, no iPhone, no Android...
looks like it's pretty much only available on 20%ish of desktop browsers and pretty much nothing mobile. You aren't going to get anyone to use it in a public-facing web application yet. Remember the days of "this site looks best in (Internet Explorer/Netscape/whatever)"... let's not do that again.

Maybe if the HTML 5 standard said that conforming user agents have to do this it would put a little more umph behind it. Of course, the standard seems to follow browser development in many cases now, not the other way around.

Close, but no cigar.

Browser support for box-sizing seems pretty good if you don't mind prefixing (and breaking on IE < 8).

If you set box-sizing: border-box on an element, it'll use the IE quirks mode box model for that element.

WebGL in particular is not supported by Chrome or the old Android Browser (except for one specific phone).

Three things: First, one Android phone is greater than zero iPhones. Second, Android lets you install Firefox, which does support WebGL according to this chart. Third, WebGL is in Chrome for Android beta, which means it's coming soon to Chrome for Android.

It's JavaScript. You can tunnel to the online game's server through a WebSocket in any JavaScript environment that supports WebSockets, which currently includes everything but IE <= 9, Android Browser, and Opera Mini (the version that does all the rendering server-side). And if your game is turn-based, you can still do your updates through XMLHttpRequest.

Quite a mess.

Not quite.

You can support almost all browsers out there with only two codecs: H.264 + your choice of ogg/theora or webm/vp8. And the H.264 will of course still work with Flash. This URL http://caniuse.com/#feat=webm is very handy if you want to see for yourself.

At least that's the situation for static streaming / VOD. Live broadcast is where the mess is with Apple's HLS, Microsoft's HSS, Adobe's RTMP, MPEG's DASH along with IETF-standard RTSP (15 years old but still somewhat alive) and various less-known protocols. AFAICT, none of the recent protocols (that support adaptive bandwidth and work over HTTP) support open audio/video codecs. If Google/Mozilla/etc want patent-free codecs to get traction, they should work on a version of DASH that works with theora/VP8.

My 0.02€ as a former employee of a large video-streaming-oriented CDN.

Not according to HTML5test.com, they aren't.

Checking caniuse.com and filtering to current browser versions shows FF18 tied with IE10 on HTML/CSS for W3C Recommendations and Proposed Recs. at 100%, with FF18 1% ahead on the Candidate Recommendations and 1% behind for Working Drafts. For the other/unofficial categories, FF18 leads IE10 by a wide margin.

Since those last two categories don't really count for much since they're subject to potentially massive changes, the best you could say is IE 10 is -almost- as compliant as the latest stable Firefox release (which is still saying something, considering how long Microsoft has been the Alabama of web standards integration...)

There are HTML5 APIs that Safari for iOS has taken a long time to implement, such as the ability to upload photos taken with the camera app (<input type="file"> was completely unsupported until iOS 6) or the ability to access the device's camera with the user's permission (getUserMedia, still unsupported).

There are HTML5 APIs that Safari for iOS has taken a long time to implement, such as the ability to upload photos taken with the camera app (<input type="file"> was completely unsupported until iOS 6) or the ability to access the device's camera with the user's permission (getUserMedia, still unsupported).

From my iPhone when I click on the issued a response link, all I get is a page saying a dedicated app is coming soon. I view that as another failure on Mega's side.

Mega uses JavaScript local file access APIs to read and encrypt user-selected files before uploading them. Historically, Safari for iOS has been severely lacking in JavaScript local file access APIs. So if Apple doesn't give web application developers the proper tools to read and encrypt user-selected files, how should that be regarded as a "failure on Mega's side" rather than Apple's?

That caniuse site is really useful. My horse for a mod point! (you can't have my kingdom, I already traded it for the horse)

I was under the impression that the "request desktop site" command only changed the user agent. Even a "request desktop site" command won't make a browser implement a JavaScript object that it doesn't implement, and a lot of older browsers don't implement APIs to read local files chosen by the user.

From my iPhone when I click on the issued a response link, all I get is a page saying a dedicated app is coming soon. I view that as another failure on Mega's side.

Mega uses JavaScript local file access APIs to read and encrypt user-selected files before uploading them. Historically, Safari for iOS has been severely lacking in JavaScript local file access APIs. So if Apple doesn't give web application developers the proper tools to read and encrypt user-selected files, how should that be regarded as a "failure on Mega's side" rather than Apple's?

Javascript can access and process file data directly with the HTML5 File API which is supported by recent versions of most major browsers.

I am posting with from:
Google Chrome 25.0.1364.5 (Official Build 174090) dev
OS Linux
WebKit 537.22 (@138211)
JavaScript V8 3.15.11.2
With silent update the meaning of these announcements is that it is time to check Can I Use? to see if any more css3 elements are now in widespread use so you can use them in web development.

[Safari for iOS] limits the capabilities of web applications. [...] Does Safari for iOS do WebGL and getUserMedia yet?

All browsers limit the capabilities of web applications. Generally for security and stability purposes.

Firefox and Opera support at least some WebGL on Android according to this chart, but Safari on iOS 6 does not.

If the owner of the website decides to support Android 2.2 browsers, great. If not, download Opera for free.

The trouble is that especially for a hobby site that might only be paying $120 per year or less for hosting, it's a bit more expensive per year to offer an HTTPS connection to users of Android Browser on Android 2, Internet Explorer on Windows XP, and Safari on Windows XP. Though shared hosts such as WebFaction have started to support SNI, most shared hosts that I've seen charge about $60 to $70 per year more for the dedicated IPv4 address needed to support HTTPS on the browsers included with Windows XP and Android 2. The best way I can think of is to make the login page available through both HTTP and HTTPS, redirect to HTTPS on the login page if the user agent appears to support SNI (Chrome, Firefox, Opera, recent Safari on Mac/iOS, IE on Vista/7/8), and present "Switch to Firefox or Opera, or continue insecurely" on the login page if the user was not redirected.

Not only browser, Android 2.2 owners can (and many do) override default applications

I'm aware that they can. I'd just like to see statistics that they do. StatCounter implies that 63% of Android users still require a dedicated IPv4 address for each SSL certificate:

• Android Browser on Android 2 (no SNI): 2.76%
• Chrome or Android Browser on Android 3/4 (with SNI): 1.37%
• Opera Mobile: 0.16%
• Firefox for Android: 0.07%

In addition, I'm under the impression that a lot of Android 2 devices tend to have ARMv6 CPUs, which Firefox doesn't yet support.

The sandbox adds security restrictions plus "tokens" for explicitly allowing the things that you, the site developer, want. The main purpose of the restrictions is to prevent content within an iframe from accessing content in or related to the parent page. For example, lots of ads are loaded in iframes, the sandbox attribute can prevent JavaScript in the ad from executing. The site Can I Use is a decent place to look for which browsers and browser versions support particular parts of HTML5, CSS3, etc. The iframe sandbox has had support from Google and Apple but Microsoft only added it in IE10 and no version of Opera on any platform has it.

What I mean was... how is an ordinary developer meant to find out what the current state of play is?

Start with http://caniuse.com/

Actually, I think this site is pretty clear about when you can start to use a certain property:

http://caniuse.com/#search=border-radius

It lists in what browsers it is supported, if you need to use a prefix and what market share these browsers have in total.

All [Macs support display rotation] Including the laptops and iMacs. Although obviously the primary displays on those are not portrait displays.

Thank you for clarifying.

Of course the fact that you changed the topic from the tablets and smartphones that my post was about means you can't argue against that point.

Tablets I'll grant, but as for smartphones, I don't know whether the text is big enough to read when the page first loads. I don't own a smartphone myself because I haven't found anything to justify an extra several hundreds of dollars per year, and I haven't seen anyone post a smartphone screenshot yet. And even so, the usage share table puts Safari for iPhone and iPad at 5.45 percent, which is only about 25% larger than those Mac owners who haven't switched from the pack-in Safari.

So you'd rather downgrade your security or pay for additional IP addersses to support XP users who can't bother to download firefox?

Yes. Operators of hobby sites would rather downgrade their security, and operators of commercial sites would rather pay for additional IP addresses because customers who run Windows XP and can't bother to download Firefox or Chrome (or lack permission to install it) might spread the word to other people that the site is broken for them.

Roughly 11 percent are using Internet Explorer 8* (source: caniuse.com), which is the latest version of IE for Windows XP, and about 1 percent are using IE versions. This far exceeds the usage share of Safari for Mac OS X and Safari for iOS combined. So if you were to block IE 6 through 8, you'd be telling one out of every eight viewers to patronize your competitor.

* I'll admit that using IE < 9 as a proxy for IE on XP is imperfect. But I imagine that the usage share of IE 7 on Windows Vista, IE 8 on Windows Vista, and IE 8 on Windows 7 is minimal compared to IE on XP.

Media Capture API not yet implemented

Using HTML5's GetUserMedia()

Which is undefined everywhere but Opera.

I stand corrected. Unlike reading files, FileWriter is supported only by 3 browsers now (2 of which are Chrome), so legitimate use for data: isn't yet going anywhere.

I stand corrected. Unlike reading files, FileWriter is supported only by 3 browsers now (2 of which are Chrome), so legitimate use for data: isn't yet going anywhere.

I stand corrected. Unlike reading files, FileWriter is supported only by 3 browsers now (2 of which are Chrome), so legitimate use for data: isn't yet going anywhere.

I just checked on caniuse.com today. SVG+SMIL doesn't work on any version of Internet Explorer (even IE 9) or on existing Android phones (which run Android 2.3), and the page states that it's "not working in HTML files" in Safari on Mac or iOS. And even today, what product should people use to edit SVG+SMIL toons?

Dunno about IE7, not even IE8 can do anything remotely fun or pretty. Oh, you meant a website that looks like ass, or uses graphics for every single thing? Yeah, that's possible with IE, sure. But otherwise, you couldn't be more wrong, there are worlds of difference between IE7 and (modern versions of) Firefox and Chrome. Don't believe me? http://caniuse.com/

^ no inline blocks, no :before and :after, no opacity (yeah, there's a speshul IE version of it, great) -- nope, unless you use a lots of graphics, there isn't shit you can do with that thing. Just accept that.

And don't even get me started on Javascript... there is just no way.

Also, this is about the admin interface! For my own first attempt at a CMS I did it the same way: IE visitors get something that looks okay-ish, visitors with a real browsers get to see the real website. Users with IE can use POST and be happy, users with real browsers get Javascript bling. But profile owners and admins have to use a modern browser, or fuck off. That approach saved me thousands of seconds of work, and many hundred bytes, so why shouldn't that scale for bigger projects? ^^

The aligning problems you cite are exactly the sorts of new features that are subject to the prefix problem -- see the flexbox spec (at http://www.w3.org/TR/css3-flexbox/)... and then see the 2009 flexbox spec (at http://www.w3.org/TR/2009/WD-css3-flexbox-20090723). Most browsers (minus the IEs) support the old version. A few Chrome versions -- NOT -webkit-*, just Chrome -- support the new syntax (see http://caniuse.com/flexbox).

So, to sum up: we have this new standard you desire, but the problem addressed by the FA is directly to blame for the lack of adoption.

"You totally didn't even understand the comment you made about the difference between feel good PR statements, and actual cold hard action did you? That's quite strange as it's not that difficult a concept to grasp. Still here's a link demonstrating EMI being the first to dabble in DRM free music:

http://www.theregister.co.uk/2007/02/26/emi_drm_talks_breakup/"

And they were the first to dabble "after" Apple's "Thoughts on Music" in January 2007. The article was published in "February 2007". So how is it evidence that EMI led the initiative by showing an article that came after Apple made the offer?

"Another fallacy. You're making the implication that selling a relatively small fraction of their library DRM free at a higher cost point is in some way comparable to offering all major label's music DRM free at a standard low price point"

So how could Apple offer all major labels music DRM free without the label's permission? Why would *Apple* choose to offer one labels music DRM free but not the others if they had the (legal) ability to?

""So there are a lot of places that sell books DRM Free books from the major publishers where?"

Well what sort of books are you gunning for exactly? Perhaps this list can get you started?

http://wiki.mobileread.com/wiki/E-book_stores#Dealers_and_Publishers_without_DRM

Or this one?

http://blog.the-ebook-reader.com/2011/02/07/where-to-get-drm-free-ebooks-for-kindle-sony-nook-and-other-ereaders/

Or is this another of your arbitrary definition tricks with your use of the term "mainstream" where you'll claim the likes of Pearson aren't "mainstream" enough?"

There are six major publishing houses. Again, you seem to think that Apple can arbitrarily allow media to be sold without DRM without the publishers permissions. It's no secret that there are six major publishers -- the ones being sued by the DOJ.

"Bwahahaha, lol yeah, that was a good one. It's like you actually believe your own bullshit. Yep, Apple was really welcoming to Flash, it didn't change it's terms to prevent use of interpreters and so forth in apps at all. Nope, none of that ever actually happened. So how are the fairies today? Going for dinner with Santa Claus tonight?"

So why did Adobe abandon Flash on non-Apple mobile platforms when it was fully embraced by Google?

"Yes, try using all of the new HTML5 form elements and let me know how you get on. I'm sure use of ogg/theora and ogg/vorbis will work great for you on Safari, "

Right because there is just so much ogg content out there. I'm sure that's on the top of most people's wish list....

"Yes, try using all of the new HTML5 form elements and let me know how you get on. I'm sure use of ogg/theora and ogg/vorbis will work great for you on Safari,"

So ogg is part of the HTML5 spec?

  and the autocomplete attribute work wonders. How about the file API,

"and meter and progress elements? I'm sure you could create a great looking site for Safari with them too!"

http://caniuse.com/progressmeter

And you also can't use them with the Android browser....

"I'm guessing you've not actually ever had any involvement with an HTML5 project have you"

Yes plenty.

Here's a full list of web features that 3.6 doesn't support and FF 12 does. If you use a website that employes any of those technologies, you'll lose some of the experience you were supposed to get.

And web developers won't care. I think this is an important note. Old IE users (6/7/8) make up a large enough chunk of the web that legacy support for them is considered a higher priority for most, but FF 3.6 users are very much a minority, so you can't expect any support going forward.

Troll? Strawman? I don't know. Either way, completely wrong.

IE9 is a completely good browser.

Users said the same thing about IE6, so you're obviously not a web developer.

It's on par with Chrome, but in fact it offers even more features and security than Firefox does currently, like sandboxing. It's also standards compliant and supports HTML5.

  IE9 is nowhere near Chrome or Firefox. You should be modded down for misinformation.

In terms of features, here's a quick comparison.
IE9 vs Firefox 9
http://caniuse.com/#compare=y&b1=ie+9&b2=firefox+9

IE9 vs Chrome 16
http://caniuse.com/#compare=y&b1=ie+9&b2=chrome+16

IE9's performance is also way behind - It barely wins on Sunspider and then loses badly on Kraken and V8 being up to 400% slower. Their 64bit build is even worse and the author didn't bother posting the results because they're so bad.

http://www.zdnet.com/blog/hardware/the-big-browser-benchmark-chrome-1615-vs-opera-11-vs-ie9-vs-firefox-98-vs-safari-5/17367

There's nothing to hate about IE9.

Sure there are. Besides not being as fast and not supporting standards as well as the others, it also only runs on Windows Vista and Windows 7. You're out of luck if you're running Windows XP, Linux or OS X. IE9 also has a new but buggy rendering engine. Here's one that I ran into a few days ago. http://www.ncf.ca/ncf/support/ie9_issue/index.html. Here's another http://stackoverflow.com/questions/6392826/mobile-table-crashes-ie9. There are more of these types of bugs in IE than all the other browsers combined. I still hate IE.

Troll? Strawman? I don't know. Either way, completely wrong.

IE9 is a completely good browser.

Users said the same thing about IE6, so you're obviously not a web developer.

It's on par with Chrome, but in fact it offers even more features and security than Firefox does currently, like sandboxing. It's also standards compliant and supports HTML5.

  IE9 is nowhere near Chrome or Firefox. You should be modded down for misinformation.

In terms of features, here's a quick comparison.
IE9 vs Firefox 9
http://caniuse.com/#compare=y&b1=ie+9&b2=firefox+9

IE9 vs Chrome 16
http://caniuse.com/#compare=y&b1=ie+9&b2=chrome+16

IE9's performance is also way behind - It barely wins on Sunspider and then loses badly on Kraken and V8 being up to 400% slower. Their 64bit build is even worse and the author didn't bother posting the results because they're so bad.

http://www.zdnet.com/blog/hardware/the-big-browser-benchmark-chrome-1615-vs-opera-11-vs-ie9-vs-firefox-98-vs-safari-5/17367

There's nothing to hate about IE9.

Sure there are. Besides not being as fast and not supporting standards as well as the others, it also only runs on Windows Vista and Windows 7. You're out of luck if you're running Windows XP, Linux or OS X. IE9 also has a new but buggy rendering engine. Here's one that I ran into a few days ago. http://www.ncf.ca/ncf/support/ie9_issue/index.html. Here's another http://stackoverflow.com/questions/6392826/mobile-table-crashes-ie9. There are more of these types of bugs in IE than all the other browsers combined. I still hate IE.

I posted a comment almost identical to yours this year praising IE9, but today IE9 is not a good browser.
It's an old and crusty browser, because you know web stuff moves THAT fast.

As usual IE is tightly bound to windows, and yet again particular versions of windows. IE9 supports some HTML5 stuff sure. It also supports canvas, but canvas is useless without requestAnimationFrame. Session history management, asyncronous external Javascript, native Regex form validation

http://caniuse.com/ for the complete list of how embarrassingly old IE9 is.
So sorry, but your comment is around 9 months out of date.

Inline SVG isn't the same thing as SVG images, which did precede HTML5. In Inline SVG the SVG tags are embedded within the HTML as if they were HTML tags. That's newer, since the creation of HTML5 spec. At the time Firefox 4 implemented it last year, then-current versions of Google Chrome, MSIE, Opera and Safari rendered the same tags as nonsense, a hopeless jumble. FF4 also implemented SMIL animation of Inline SVG first.

http://www.caniuse.com/#feat=svg-html5
http://www.caniuse.com/#feat=svg-smil

I know this because I had to reimplement some Java AWT charts and graphs in Canvas and Inline SVG for Section 508 compliance (accessibility). I now allow the user to choose Java AWT, Canvas or Inline SVG, according to what their browser supports. It's surprisingly easy to implement all 3, at least for the simplistic text, lines and rectangles one typically uses for charts and graphs.

Inline SVG isn't the same thing as SVG images, which did precede HTML5. In Inline SVG the SVG tags are embedded within the HTML as if they were HTML tags. That's newer, since the creation of HTML5 spec. At the time Firefox 4 implemented it last year, then-current versions of Google Chrome, MSIE, Opera and Safari rendered the same tags as nonsense, a hopeless jumble. FF4 also implemented SMIL animation of Inline SVG first.

http://www.caniuse.com/#feat=svg-html5
http://www.caniuse.com/#feat=svg-smil

I know this because I had to reimplement some Java AWT charts and graphs in Canvas and Inline SVG for Section 508 compliance (accessibility). I now allow the user to choose Java AWT, Canvas or Inline SVG, according to what their browser supports. It's surprisingly easy to implement all 3, at least for the simplistic text, lines and rectangles one typically uses for charts and graphs.

I don't think it is that bad as you mentioned.

Firefox developers did implement different things that Chrome (for example) didn't have.

Have a look at this site:

http://caniuse.com/

Firefox 5.0 84%
Chrome 13 (from last week ?): 90%

Also have a look at the differences:
http://caniuse.com/#compare=y&b1=firefox+5&b2=chrome+13

Firefox 6 is planned for 3Q of 2011 and the beta's currently support 86%

I don't think it is that bad as you mentioned.

Firefox developers did implement different things that Chrome (for example) didn't have.

Have a look at this site:

http://caniuse.com/

Firefox 5.0 84%
Chrome 13 (from last week ?): 90%

Also have a look at the differences:
http://caniuse.com/#compare=y&b1=firefox+5&b2=chrome+13

Firefox 6 is planned for 3Q of 2011 and the beta's currently support 86%

Well, on that site it is really easy to compare browsers, as you may know Chrome will remove a few video codecs:

http://caniuse.com/#compare=y&b1=chrome+13&b2=chrome+14
http://blog.chromium.org/2011/01/html-video-codec-support-in-chrome.html
http://blog.chromium.org/2011/01/more-about-chrome-html-video-codec.html

So that is why it is dropping.

It is all based on things that can be checked/tested. The farther future numbers are very unclear.

1) There's more to Chrome than Webkit + V8 + rolling version numbers. There's WebGL, there's voice input, there's websockets, inline SVG, animated CSS3 and tons of other stuff. None of this is essential, I agree, but if an app uses one of these features, it automatically gets locked out of all the other browsers that do not support them. Check out http://caniuse.com/ - it has a pretty handy tool for browser feature comparison.
2) Despite supporting MP3/AAC, Google willfully dropped H.264 support. I think it's a matter of convenience as much as a matter of open standards: the lion's share of music today is stored in MP3, and I believe it would turn off potential users from HTML5 media capabilities if there were almost no media files on the Net you could use them with.
3) Flash: maybe on Windows it ships with Flash; the Linux version doesn't. Also, I'm inclined to believe that it's mostly for the sake of security: a huge share of people already has Flash installed (usually preinstalled on their computers) anyway, so it's not like Chrome is helping to spread Flash. Rather, its support of rich HTML5 capabilities slowly renders Flash irrelevant.

http://caniuse.com/

It depends, if you look at the numbers:

"Calculation of support for currently selected criteria" (Recommendation, Proposed Rec., Candidate Rec., Working Draft, Other):

Current:
IE9: 58%
Firefox 5: 84%
Safari 5.1: 82%
Chrome 12: 89%
Opera 11.5: 76%

Near Future:
IE9: 58%
Firefox 6: 87%
Safari 5.1: 82%
Chrome 13: 89%
Opera 12.0: 79%

Farther future:
IE 10: 71%
Firefox 7: 87%
Safari 6: 82%
Chrome 14: 88%
Opera 12.1: 79%

You don't have to remember: http://caniuse.com/

A good reference is http://caniuse.com/

The stream API, formerly called the <device> element, has zero browser support. Adobe Flash Player, on the other hand, runs on almost every desktop PC. It also runs on any Android device with an OS version that was current around the time they started putting front-facing cameras on phones.

Let's try that again because that was horrible. Here are the proper links, I hope: http://caniuse.com/#compare=y&b1=ie|9&b2=firefox|4 http://caniuse.com/#compare=y&b1=ie|9&b2=firefox|3.6 Although I think the site doesn't want to help either. whatever.

Let's try that again because that was horrible. Here are the proper links, I hope: http://caniuse.com/#compare=y&b1=ie|9&b2=firefox|4 http://caniuse.com/#compare=y&b1=ie|9&b2=firefox|3.6 Although I think the site doesn't want to help either. whatever.

IE might have improved a lot performance wise, it is still way behind implementing many parts of many of the specs the other browsers already supported in their previous versions like Firefox 3.6.

Here an example list:
http://caniuse.com/#compare=y&b1=ie|9&b2=firefox|4
http://caniuse.com/#compare=y&b1=ie|9&b2=firefox|3.6