As we continue to transition whole-hog into HTML5 with new Web development, there are a few things you might need to know before deciding how to handle certain situations. I have discovered two somewhat major gotchas over the last few months that really made me reconsider my usage of the new technology.
While articles, asides, headers, footers, etc. are a fantastic way to introduce semantics into your page designs, there are a few elements and attributes that might not do quite what you’d expect.
Details & Summary
To begin with, let’s take a look at the <details> and <summary> elements. From my understanding of the new spec, the <details> element is supposed to include information about the page or article (such as author information, copyright, etc.). The <summary> element is supposed to be the really important information from that <details> umbrella.
What you might not know, however, is that some browsers (namely Chrome) handle the <details> and <summary> elements differently than other browsers currently do. I’m honestly not sure which browser implementation is correct, but they are pretty drastically different.
When a <details> element is used, Chrome automatically collapses its contents, adds an arrow next to it and adds an onclick handler to it so that the full content of the <details> element are shown only when clicked. If you include a <summary> tag inside the <details> element, that <summary> information will be the only text initially shown.
Any styles applied to the <details> element are essentially ignored by Chrome.
Another gotcha to watch out for is the way modern browsers handle forms. At this point, I believe Chrome, Safari, Firefox and Opera have all implemented ways to handle “required” elements in forms. In each of those browsers, if any form element has the “required” attribute, the browser will refuse to allow the user to submit the form until each of those elements has a value.
There are two issues I’ve experienced with these implementations.
First of all, each browser uses a completely different style of warning messages. There is no way (at least, as of yet) to style those warning messages. Last time I checked, the messages in Opera and Firefox were fairly attractive, but the messages in Chrome were incredibly ugly (sometimes the bubble in which the warning message appears doesn’t even stretch to the width of the message).
Another issue is that the implementation of these attributes is still being tested. There are minor (sometimes inconsistent) bugs in each of the browsers. A few months ago, when I was using the required attribute on a form, I found that some of the browsers had a lot of trouble recognizing when a radio button or select element had a value. No matter what value was chosen for those elements, the browser continued to stop the submission of the form, indicating that they were required.
The bottom line is, HTML5 brings with it some great possibilities; but it is still a very volatile technology. If you are going to use HTML5 for your projects, it might be a good idea to check on them fairly regularly to make sure that they still look the way you initially designed them. Of course, that said, even if you use XHTML1 or HTML4 with CSS2; the constant evolution of browsers might warrant a regular check on your pages anyway.