Categories
Web development

When can I use…

Preview of the 'When can I use' page

A few weeks ago I was trying to find out which browser supported exactly which experimental feature, be it CSS3, HTML5, or something else. I found a couple of useful pages, but nothing quite as detailed as what I was looking for. Since I enjoy graphs, charts, and showing the world how much IE6 really sucks, I went ahead and made what I was looking for.

Thus was born the “When can I use…” page, which shows tables of a variety of current and upcoming web technologies. For all major browsers (Internet Explorer, Firefox, Safari, Opera and Chrome), versions for four different eras (past, present, near and far future).

The page can be customized to show only certain browsers/features/eras, so you have the option to ignore lesser used browsers or for that matter the most used one (it’s a lot of fun to pretend Internet Explorer doesn’t exist). I’ve also included a summary at the bottom of the page, which shows what percentage of the displayed features are supported.

Most features were tested myself, to ensure that the information is accurate. Please let me know if you notice any mistakes. Keep in mind that a “supported” feature may not actually work 100%, as well as the fact that some of the specifications are not set in stone yet, so what may be supported today may not actually work in the future. However, it is likely that in most cases the browser will update its support as the spec changes.

The feature list includes anything I personally feel is of significant use to web designers, but still lacks support in at least one browser version. I am open to adding more features, but only if it’s of significant importance and not just a detailed subset of another feature.

I intend to update the page as new browsers are released, or at the very least once a year. Due to its popularity, the page is updated as soon as new information becomes available.

192 replies on “When can I use…”

Nice work, perfect for web developers, and I’ll certainly look at it in the future 🙂

Have you considered adding Geolocation support, which I think only Firefox 3.5+ supports currently?

Thank you for this wonderful tool ! 🙂
Is there a way to have more details about the JS solutions ?
I suggest a few more JS solutions for the Canvas Text support : ExCanvas has now the text drawing API : http://explorercanvas.blogspot.com/ and I suggest you a lib that completes the canvas text API for the browsers that don’t have it : http://code.google.com/p/canvas-text/
I don’t know if this solution is acceptable, but I just wanted to let you informed.

@Alexis Deveria
MessageEvent.origin is the ONLY way to ensure that you can trust a message. Without it, the feature should be classified as broken. There is no way in Opera 9.6 to know what origin a message truly came from without making a wild guess using MessageEvent.domain.

@Elijah

Hmm…I see what you’re saying, but the basic functionality still largely works, right? As mentioned in the FAQ, there may not be 100% support. If you still feel this lack of support is particularly significant for its usage, let me know. I’ll also be happy to add a resource link about that feature if you can suggest a page that describes any browser shortcomings for XDM.

Also, I’ll see what I can do to allow better code display in comments, thanks!

@Henri

I’ve changed the wording, since you’re right about the format(“truetype”) part. Thanks! However, Opera does appear to support OTF fonts without that declaration. This is mentioned in the changelog and can be tested by removing ‘format(“opentype”)’ on this demo page.

By Post Author

It seems that the note about Opera on the @font-face feature is wrong. Opera doesn’t support .otf fonts, but .ttf is downloaded even if format(“truetype”) is specified.

Under XDM, you have Opera 9.6 as fully supporting it, though it does not. Opera 9.6 does not support MessageEvent.origin and instead has MessageEvent.domain, which isn’t a valid HTML5 origin.

It can be partially fixed (though it just assumes the protocol is http:) with this:
if (typeof window.opera != "undefined") { // Opera 9.x MessageEvent.origin fix (only for http:, not https:)
if (parseInt(window.opera.version()) == 9)
Event.prototype.__defineGetter__("origin", function(){
return "http://" + this.domain;
});
}

PS. You should add support for <codeblock> or >pre< tags in comments. I have no way to express my code in an easy-to-read manner otherwise.

@Dan

Thanks! Those certainly seem worth adding.

@Lars

Firstly, thanks!

Secondly, thanks for the feedback.

Actually, “Far past” was only added when IE8 was released, and I didn’t want to remove IE6 (since we generally still need to support it). It’s not really accurately named, I have to admit. And looking at the latest Hitslink stats, Safari 3.0 is used less than Netscape 6, so it just doesn’t compare to the IE6 share. Same for Firefox 1.5.

The idea is that if you don’t care about how something works in a certain browser, you can simply uncheck it and the conclusion will change appropriately. I guess “When can I use” technically means “When can I use a given feature in a fully supported interoperable way”, but that gets a bit long. 🙂 The point you make about progressive enhancement is a good one, however. Maybe I can find a way to specify features that “don’t break” things.

And yes, I’d thought about adding JS/ES features to the list, seems only appropriate. Just haven’t taken the time to investigate them or do any browser testing on them. If you happen to any good resources that would help with this, that would be great. Thanks again!

By Post Author

a. Very useful table with lots of information. Thank you!

b. Suggested improvements.

Lumping together Safari 3.1 as both past and “far past” is misleading. Safari 3.1 was launched only slightly ahead of Firefox 3. Are you really sure that Safari 3.0 is dead?

The heading “When can I use…” is also misleading with the conclusions, since they do not factor in progressive enhancement. I can use e.g. rounded corners today. I just have to accept the fact that MSIE and Opera users don’t see them, but nothing breaks.

Have you considered adding JavaScript 1.6+/EcmaScript version 5 (aka 3.1) features as well?

Regarding SVG support, i know of 2 javascript workarounds to get it working in IE (by feeding it VML instead): dojox.gfx and Raphael. AFAIK they’re both limited on the common denominator in functionality, though.

I don’t know if that qualifies as a workaround for you. Just to let you know.

I have since rewritten the code where I ran into this so I don’t really have a test case for you, but here’s all the relevant details I can think of:

It might just be textareas. I had a form script that was creating and appending textareas with DOM methods. If the CSS rule applied to them had three or more background images defined, all of the background images would render (and in the correct stacking order and everything) but lose their positioning. I don’t know if it matters, but it was a single .PNG sprite being used for all of the background images. Also, a “resize: both;” declaration was in the rule.

On another note, I think “inline-block” might be missing form this list.

Comments are closed.