Archive for the ‘Elements’ Category
Thursday, March 19th, 2009
HTML 5 introduces new elements like <section>, <article> and <footer> for structuring the content in your webpages. They can be employed in many situations where <div> is used today and should help you make more readable, maintainable, HTML source. But if you just go through your document and blindly replace all the <div>s with <section>s you are doing it wrong.
This is not just semantic nit-picking, there is a practical reason to use these elements correctly.
In HTML 5, there is an algorithm for constructing an outline view of documents. This can be used, for example by AT, to help a user navigate through a document. And <section> and friends are an important part of this algorithm. Each time you nest a <section>, you increase the outline depth by 1 (in case you are wondering what the advantages of this model are compared to the traditional <h1>-<h6> model, consider a web based feedreader that wants to integrate the document structure of the syndicated content with that of the surrounding site. In HTML 4 this means parsing all the content and renumbering all the headings. In HTML5 the headings end up at the right depth for free). So a document like the following:
<body>
<h1>This is the main header</h1>
<section>
<h1>This is a subheader</h1>
<section>
<h1>This is a subsubheader</h1>
</section>
</section>
<section>
<h1>This is a second subheader</h1>
</section>
</body>
has an outline like:
This is the main header
+--This is a subheader
+--This is a subsubheader
+--This is a second subheader
If you just blindly convert all the <div>s on your pages to <sections> it's pretty unlikely your page will have the outline you expected. And, apart from being a semantic faux-pas, this will confuse the hell out of people who rely on headings for navigation.
Hopefully, in time, we will get tools that make this kind of mistake obvious and CSS support for selecting headings based on depth. Until then remember <section> is not just a semantic <div>
Posted in Elements, Tutorials | 24 Comments »
Wednesday, March 18th, 2009
We have previously talked about how to get Internet Explorer to play ball when using the new HTML5 elements, but today I'm going to talk about Firefox 2.
Firefox 2 (or any other Gecko-based browser with a Gecko version pre 1.9b5) has a parsing bug where it will close an unknown element when it sees the start tag of a "block" element like p, h1, div, and so forth. So if you have:
<body>
<header>
<h1>Test</h1>
</header>
<article>
<p>...</p>
...
</article>
<nav>
<ul>...</ul>
</nav>
<footer>
<p>...</p>
</footer>
</body>
...then in Firefox 2 it will be parsed as if it were:
<body>
<header>
</header><h1>Test</h1>
<article>
</article><p>...</p>
...
<nav>
</nav><ul>...</ul>
<footer>
</footer><p>...</p>
</body>
So if you style the new elements with CSS it will probably look completely broken in Firefox 2.
If you care about Firefox 2 then there are some ways to fix this:
- Go back to using
div elements
- Use content type negotiation between
text/html and application/xhtml+xml
- Fix up the DOM with scripting
(1) is probably wise if your content structure changes between pages or over time. (2) also works but means that users will be exposed to the Yellow Screen of Death should a markup error slip through your system. Otherwise (3) can be worth to consider.
Fixing up Firefox 2's DOM is actually pretty simple if you have a consistent structure. Using the same markup as above it could look something like this:
<body>
<header>
<h1>Test</h1>
</header>
<article>
<p>...</p>
...
</article>
<nav>
<ul>...</ul>
</nav>
<footer>
<p>...</p>
</footer>
<!--[if !IE]>--><script>
// dom fixup for gecko pre 1.9b5
var n = document.getElementsByTagName('header')[0];
if (n.childNodes.length <= 1) { // the element was closed early
var tags = ['ARTICLE', 'NAV', 'FOOTER', 'SCRIPT'];
for (var i = 0; i < tags.length; ++i) {
while (n.nextSibling && n.nextSibling.nodeName != tags[i]) {
n.appendChild(n.nextSibling);
}
n = n.nextSibling;
}
}
</script><!--<![endif]-->
</body>
You might think that this script would work for IE, too, when not using the createElement hack, but apparently IE throws an exception when trying to append a child to an unknown element. So you still have to use the createElement hack for IE.
If you want to move the script to head and run it on load and you don't have anything after the footer then you would replace 'SCRIPT' in the tags array with undefined to make it work.
(If you want to do content type negotiation and want to just serve XHTML to Gecko-based browsers with this bug then you should look for the substrings "Gecko/" and "rv:1.x" where x is less than 9, or "rv:1.9pre" or "rv:1.9a" or "rv:1.9bx" where x is less than 5.)
Posted in Browsers, DOM, Elements | 17 Comments »
Saturday, January 17th, 2009
The previous post discussed how to enable styling of the new HTML5 elements in IE by using a simple script. However, if the user has scripting disabled, the layout would probably fall apart badly.
So that means if you care about IE users with scripting disabled, you can't use the new elements, right?
Not necessarily.
There are some tricks to work around the broken DOM and limited styling in IE:
- Know what the DOM looks like and target other elements than the new elements for styling.
- Use the universal selector (
*) to target the right element.
- Use
noscript.
What does this mean?
Target other elements for styling
Consider you have the following markup:
<body>
<article>
...
</article>
<nav>
<ul>
...
</ul>
</nav>
</body>
Instead of doing this:
* { margin:0; padding:0 }
body { background:silver }
article { border:solid; background:white; margin-left:10em }
nav { position:absolute; top:0; left:0; width:10em }
...do this:
* { margin:0; padding:0 }
html { background:silver }
body { border:solid; background:white; margin-left:10em }
ul { position:absolute; top:0; left:0; width:10em }
Now of course you're going to use other ul elements than the navigation, so how do we get more specific on which element to target? The obvious solution is to set a class or id on the ul element, but there's another solution which might be more convenient in some cases, which brings me to...
Using the universal selector
Depending on the situation, and whether you care about IE6 or not, you can use the universal selector to target the element you want.
Consider you have the following markup:
<body>
<article>
<header>
<h1>...</h1>
<p>...</p>
</header>
...
...and you want to style the p that is in header, you would do this in the normal case:
article header p { font-weight:bold }
But in IE, the article, header, h1 and p elements are all siblings, so the selector wouldn't match.
So then one would expect this to match, but it doesn't (IE doesn't allow selecting unknown elements using type selectors):
article + header + h1 + p { font-weight:bold }
However, this matches:
body > * + * + h1 + p { font-weight:bold }
Using noscript
The above techniques shouldn't mess up other browsers (or IE when scripting is enabled), however if you prefer (or if something would screw up) you can use a separate style sheet for IE when scripting is disabled by just using the following markup:
<head>
<!--[if IE]>
<noscript><link rel="stylesheet" href="ie-noscript.css"></noscript>
<![endif]-->
...
Conclusion
The above techniques might not be very scalable or might well impact maintanence, but the point of this article is to show that it is possible to use the new elements while still supporting IE with scripting disabled.
Posted in Browsers, DOM, Elements | 11 Comments »
Wednesday, January 7th, 2009
Internet Explorer poses a small challenge when it comes to making use of the new elements introduced in HTML5. Among others, these include elements like section, article, header and footer. The problem is that due to the way parsing works in IE, these elements are not recognised properly and result in an anomalous DOM representation.
To illustrate, consider this simple document fragment:
<body>
<section>
<p>This is an example</p>
</section>
</body>
Strangely, IE 6, 7 and 8 all fail to parse the section element properly and the resulting DOM looks like this.
BODY
SECTIONP
#text: This is an example
/SECTION
Notice how IE actually creates 2 empty elements. One named SECTION and the other named /SECTION. Yes, it really is parsing the end tag as a start tag for an unknown empty element.
There is a handy workaround available to address this problem, which was first revealed in a comment by Sjoerd Visscher.
The basic concept is that by using document.createElement(tagName) to create each of the unknown elements, the parser in IE then recognises those elements and parses them in a more reasonable and useful way. e.g. By using the following script:
document.createElement("section");
The resulting DOM for the fragment given above looks like this:
BODY
section
P
#text: This is an example
This same technique works for all unknown elements in IE 6, 7 and 8. Note that there is a known bug that prevented this from working in IE 8 beta 2, but this has since been resolved in the latest non-public technical preview.
For convenience, Remy Sharp has written and published a simple script that provides this enhancement for all new elements in the current draft of HTML5, which you can download and use.
This script is not needed for other browsers. Opera 9, Firefox 3 and Safari 3 all parse unknown elements in a more reasonable way by default. Note, however, that Firefox 2 does suffer from some related problems, for which there is unfortunately no known solution; but it is hoped that given the faster upgrade cycle for users of Firefox, relatively speaking compared with IE, Firefox 2 won't pose too much of a problem in the future.
Posted in Browsers, DOM, Elements, Events, Syntax | 25 Comments »
Friday, September 26th, 2008
I gave a talk at Google on Monday demonstrating the various features of HTML5 that are implemented in browsers today. The video is now on YouTube, so now you too can watch and laugh at my lame presentation skills!
The segments of this talk are as follows. Some of the demos are available online for you to play with and are linked to from the following list:
- Introduction
-
<video> (00:35)
-
postMessage() (05:40)
-
localStorage (15:20)
-
sessionStorage (21:00)
- Drag and Drop API (29:05)
-
onhashchange (37:30)
- Form Controls (40:50)
-
<canvas> (56:55)
- Validation (1:07:20)
- Questions and Answers (1:09:35)
If you're very interested in watching my typos, the high quality version of the video on the YouTube site is clear enough to see the text being typed. More details about the demos can be found on the corresponding demo page.
Posted in Browser API, Browsers, Conformance Checking, DOM, Elements, Events, Forms, Multimedia, Syntax, WHATWG | 7 Comments »