No-Bullshit Guide to Detecting Everything in HTML5 | Hacker News Reader

No-Bullshit Guide to Detecting Everything in HTML5

diveintohtml5.org

140 pointsuggedal35 comments

Open articleView on HN

Here, check your browsers:

http://mylittlehacks.appspot.com/html5

Great stuff - thanks for sharing! You should post this as a top-level article.

Checking IE6 is not even funny :-(

Unfortunately, IE8 doesn't do much better.

Excuse my ignorance, what's the !! for?

converts a value that evaluates to false, to an actual false boolean.

Its two negation operators. The first returns false is the object exists and true if it doesn't and the second flips that around.

So you get true if the object exists and false otherwise.

Double negation is used for explicit boolean conversion, i.e.:

    !!0 -> false
    !!1 -> true
    !!"" -> false
    !!"s" -> true
    !!null -> false
    !!undefined -> false

It makes sure that it returns a boolean value as opposed to something truthy/falsy which could lead to oddness if you try and directly compare it with a boolean value.

According to the spec, media.canPlayType returns either "", "maybe" or "probably". An empty string "" is falsy in Javascript and a non-empty string is truthy, but if you try and compare them directly with booleans then you can get some odd behaviour:

  if ("yes"){ // true }
  if ("yes" == true){ // false }
  if ("yes" === true){ // false }

  if (""){ // false }
  if ("" == false){ // true }
  if ("" === false){ // false }

I personally prefer to make sure that any function which you're expecting the return value to be used as a boolean actually returns a boolean value. I know there are many people out there with a dislike of !! though.

Canonicalization, so that e.g. null and undefined turn into false and ordinary values (e.g. functions, arrays, numbers, objects) turn into true.

Try putting things like these into the address bar of your browser:

  javascript:alert(!!null)
  javascript:alert(!!undefined)
  javascript:alert(!!{})
  javascript:alert(!!Math.floor)

Ahh, thanks for that. Coercion to boolean.

It's to magnify the emotion expressed. In the olden days, before emoticons, people used a larger vocabulary to express themselves, but often times that failed to express the magnitude of their feelings. They used !! for that purpose. Of course, today we see the abuse of the !! quite rampant. I LOVE YOUR HTML5!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! is an example of this. Note that this is a post-fix operator.

Hah! I am guilty of over using exclamation marks in posts/texts. I eventually found myself re-reading messages and stripping them out! Unfortunately, nowadays, it's emoticons I overuse. :)

The others already answered this but I suppose writing return Boolean(x) instead of return !!x would be much clearer.

Useful. Sadly, I don't see detection for @font-face -- perhaps because it's not very simple?

http://paulirish.com/2009/font-face-feature-detection/

But if it's not supported, the browser will just try the next font in the CSS declaration. Is there something cooler you can do with detection?

Surprisingly, this query returns almost nothing:

http://www.google.com/search?q=site:diveintohtml5.org+font

Some browsers don't support OTF fonts (like Android?) I can't seem to find a way to detect that short of getting into subtleties of WebKit revisions, but even that doesn't seem to denote support.

Modernizr (linked at the bottom of my guide) can detect support for @font-face. It is decidedly non-trivial.

http://github.com/Modernizr/Modernizr

Thanks, and a note: under FFox3.5/Linux, I noticed a small delay before the title fonts (Agnes Nutter style ;-) loaded over something simpler. More interestingly, I cannot select the words "Appendix A" to copy elsewhere. I checked the source, and see they're in style ( h1:before{content:"Appendix A:"} ).

Curiously, under Konqueror 4.3 I can highlight those words, together with the rest of the title, but pasting (either X or ^c^v) also misses them ...

Ah, the oddities of CSS. The first issue is because I'm using custom fonts via @font-face. Firefox has made some... design decisions... that cause the effect you're seeing. I've actually just recently discovered a way to reduce the number of dynamic fonts I'm loading, but the underlying issue is still that Firefox wants to paint the page before the dynamic fonts are finished loading.

The second issue is CSS generated content. I honestly don't remember why I chose to put chapter numbers and appendix letters in CSS and the rest of the title in content. Purity? Really? That doesn't sound like me. ;-) It would probably be simpler to move it all into the h1.

Its because @font-face is CSS2 (http://www.w3.org/TR/1998/REC-CSS2-19980512/fonts.html#font-...) and has nothing to do with HTML5

Related -- http://html5test.com/

css3 transition support. You could probably make something smaller, but this does work.

function checkForTransitionSupport() { var cssTransitionsSupported = false; var div = document.createElement('div'); div.innerHTML = '<div style="-webkit-transition:color 1s linear;-o-transition:color 1s linear;-moz-transition:color 1s linear;"></div>'; cssTransitionsSupported = (div.firstChild.style.webkitTransition !== undefined) || (div.firstChild.style.OTransition !== undefined) || (div.firstChild.style.MozTransition !== undefined); delete div; return cssTransitionsSupported; }

I'm constantly confused by 'HTML5', because many of these examples look more like Javascript than a markup language. I've used HTML5 a bit here and there, but just as the next version of XHTML, using things like the <article> tag.

The examples are all JavaScript code to detect support for new html5 tags/features. If the client doesn't support one, for example <video>, you can fail gracefully and maybe offer an alternative piece of content eg Flash.

HTML5 is a set of enhancements to HTML and to the JavaScript DOM API. This page is actually a great summary of HTML5 features that developers are likely to care about. For instance:

- The <audio> and <video> elements

- The <canvas> element

- Form validation (without JavaScript!)

- New <input>s for data like dates, times, numbers, ranges, and colors, for which the UA can provide OS-native controls

- An API for cross-domain communication between windows

- An API for providing and accepting drag and drop within, between, into, and out of browser windows

- Web Workers for computation in the background

- Web Sockets for efficient communication with your server

- A persistent local database

...and much more!

This page focuses on detecting support for many HTML5 features in JavaScript, so that a developer could, say, swap in their own datepicker if the browser doesn't offer one.

Wow, it's so intuitive.

Yes, it screams for a wrapper library. Might take all of 10 minutes to design the API.

Modernizr (linked at the end of my guide) can detect some of these features, plus a few others:

http://github.com/Modernizr/Modernizr

My longer chapter on detecting HTML5 features ( http://diveintohtml5.org/detect.html ) explains the detection patterns, and shows how to detect things with or without Modernizr. I've been working with the Modernizr developers to expand their detections, and at the same time some of the code in this guide is taken directly from Modernizr.

So is there a handy table showing the results of all these tests in all* browsers?

*within reason obviously...

For something like that, it's best to read PPK's excellent Quirks Mode site - http://www.quirksmode.org/compatibility.html

This will be useful for writing those "Regressive Enhancements".

FUCAKING ADOBE HATERS!

This crowd has zero sense of humor. This post was meant to be seen in light of all the Flash gnashing and public war with adobe... Sigh. Thanks for the neg karma.

Reply on news.ycombinator.com