I apologize for the longer than expected wait for this article, but now, we may continue.
The article below will pick up where Part 1 left off.
Article 1: Websites and Sectioning Part 2: Styling
<warning>Warning: This article discusses the topic of <semantics>semantics</semantics></warning>
As we began with previously, we now have the basics down as to how to properly divide information into sections. This time, we will be looking into the second aspect of sectioning: Styling.
When a search engine or screen reader scans a website, it does so by evaluating the markup of the page. Humans however, view by way of sight. If we were to use absolutely no form of styling, it would be difficult, if not impossible, to logically divide an article into sections.
When we read through a webpage, several common features are used to guide us in logically separating it out:
Bolded text defining headings.
Heading text larger than the content below it.
Logical heading levels which decrease in size as it gets deeper.
Ocasionally indenting subsections and subheadings within their parents.
Web browsers of today will often do much of this work for you, but this is not always enough. Below, I will show you at most basic, the heading layout I choose to use when building a website.
<article>
<header><h1>Main Heading</h1></header>
<section class="topsection">
<h1>Top Heading</h1>
<p>Section Content</p>
<section class="subsection">
<h1>Heading</h1>
<p>Section Content</p>
<section class="subsection">
<h1>Heading</h1>
<p>Section Content</p>
<section class="subsection">
<h1>Heading</h1>
<p>Section Content</p>
<section class="subsection">
<h1>Heading</h1>
<p>Section Content</p>
<section class="subsection">
<h1>Heading</h1>
<p>Section Content</p>
</section>
</section>
</section>
</section>
</section>
</section>
</article>
Output of Example 1
Now obviously, this is more compact than any site would naturally be, and wouldn't use such simplified text. However, this perfectly demonstrates the decreasing levels of the font size of the heading. With each level, it gradually scales downward, starting from nearly 3 times larger than the content at highest, to the same size as the content at lowest.
In the above sample, you can easily see the logically broken down structure of the chapter. You have the main article with its heading, the major logical division (the chapter), and two minor logical divisions (the sections). Although the subsections lack heading text, you can still tell that they are seperated. Even if you were to remove the row of stars, the spacing alone would be able to divide them.
Note: To show the full extent of the sample, this example uses a multi-tier heading for the article. This will be explained further in Part 3.
And here we have it. Together, the markup and the styling provides a neat, clean look which greatly improves readability. As well, it is written in semantic code which allows computers to properly understand its meaning.
In conclusion of this section, we have now learned the importance of sectioning, as well as how to properly style sections. These two concepts, when applied properly, could help create a much richer and more consistantly appealing world wide web in the coming future.
Next time, we will be discussing more advanced ascpets of this layout principle, such as multi-tiered headings and asides.
Until then, I hope that you have learned something new from this subject.
-Christopher Bright
Notes
Starting from now, if this article does not thoroughly desribe something for you, please leave a comment detailing your problem. I will do my best to update it.
I will soon be working out a method to rate the usefulness of this article, for future reference.
Any comments made will be taken into consideration for the future. I intend to make this beneficial for everyone, so all comments are accepted.
Examples will now be made within iframes, due to the possible large size of the content.
References
Alice's Adventures in Wonderland Written by Lewis Carroll Converted to ebook by David Widger of Project Gutenberg. www.gutenberg.org/files/11/11-h/11-h.htm#2HCH0001 All rights go to their respective owners.
Updates
I have made a fix to the specific coding of the CSS, condensing it as much as possible, I believe.
Although further feedback will be needed to make a final decision, this may be the final entry of this series at this time.
Like probably many others who read this blog, I am a web design enthusiast, web standards advocate, and web designer by trade. I have been working with HTML since the early 2000s, and have enjoyed it ever since.
Over the years, the web has evolved around me. I have watched it grow and adapt. And now, as a newly started professional web designer, I wish to contribute.
From this week forward, I will be writing and sharing both opinions and tutorials on my opinions of the web, where it’s gone, and most importantly, where it’s going.
Article 1: Websites and Sectioning Part 1: The Basics
<warning>Warning: This article discusses the topic of <semantics>semantics</semantics></warning>
As a researcher by hobby, I often find myself reading through various encyclopedic websites. Whether it be a wiki, or a single purpose website devoted specifically to that aim, I spend countless hours of my time using them.
With the new work on HTML to semantically markup a website, I am rather excited to see what the future may hold for such informational websites. The concepts written in the specifications and drafts are very intriguing, and will hopefully someday improve the semantic importance of the web. Combine this with the ability for future screen readers, search engines, etc. to extract such data, the possibilities are near endless.
However, as I have read around, I have noticed that not all things are as clear as they should be. Although it has been several years since the formerly labeled HTML5 specification has come into the light, I can still see these arguments floating about.
In this specific case, I am referring to the use of the semantic elements such as <article>, <section>, and so-forth, as well as their relationship to the <h1>-<h6> elements.
Because it seems that many are in disagreement about the matter, I felt I should share my opinions as to what they mean, and how they could be used.
Below, you will see the method I have devised for sectioning out content.
(Note: All information is of my personal opinion, and may not reflect the views of other web designers, the WHATWG, or the W3C.)
Firstly, let us imagine the idea of a web page, likely encyclopedic in content. This page has a single focus, a single section, and a single paragraph.
At the very basic, it would be marked up as follows:
<article>
<section>
<p>Hello, World!</p>
</section>
</article>
Output of Example 1
As we can see, this bare minimum design utilizes three elements: <article>, <section>, and <p>. These elements, as can be semantically understood, represent the start of the article, the internal section, and the paragraph within the section.
Fairly simple, right?
Well, let’s take this a step further. What if you were to want to add a title to the article?
This is how it would be done.
<article>
<header><h1>Hello, World!</h1></header>
<section>
<p>Hello, World!</p>
</section>
</article>
Output of Example 2
Now, we see the addition of two new elements: <header> and <h1>. The <header> element designates this region of the document as the header of the article. The <h1> element designates this line of text as the title, or heading of the article.
Still, this seems simple, doesn’t it?
For our next step, let’s say that we wish to increase the scope of this article, from Hello, World! to Hello, World! and Foobar.
<article>
<header><h1>Hello, World! and Foobar</h1></header>
<section>
<h1>Hello, World!</h1>
<p>Hello, World!</p>
</section>
<section>
<h1>Foobar</h1>
<p>Foo</p>
<p>Bar</p>
</section>
</article>
Output of Example 3
Now we have an article which is both titled, and has two titled sections, each containing a heading within an <h1> element. We also have the article itself, headed within both an <h1> and <header> element.
This concept, though simplistic, is easy to read by humans, and holds semantic value to machines and scripts.
In conclusion, this is the way that I view the new method of sectioning content in HTML. Using this method, we come up with a quick, easy method to divide a document, and even a website, into logical sections which can be easily read by both humans and machines.
Next time, we will be discussing part two of this topic: Styling.
The ruby element allows one or more spans of phrasing content to be marked with ruby annotations. Ruby annotations are short runs of text presented alongside base text, primarily used in East Asian typography as a guide for pronunciation or to include other annotations. In Japanese, this form of typography is also known as furigana.
I give a specific example further down, but for now I want to first say that the really great news about the ruby element is that last week, Google Chrome developer Roland Steiner checked in a change (r50495, and see also related bug 28420) that adds ruby support to the trunk of the WebKit source repository, thus making the ruby feature available in WebKit nightlies and Chrome dev-channel releases.
A simple example
The following is a simple example of what you can do with the ruby element; make sure to view it in a recent WebKit nightly or Chrome dev-channel release. Note that the text is an excerpt from the source of a ruby-annotated online copy of the short story Run, Melos, Run by the writer Osamu Dazai, which I came across by way of Piro's info page for his XHTML Ruby add-on for Firefox (and which I mention a bit more about further below).
If you don't happen to have Japanese fonts installed, here's a screenshot of the source for reference:
Notice that the actual annotative ruby text (which I've highlighted in yellow in the source just for the sake of emphasis) is marked up using the rt element as a child of the ruby element, and the text being annotated is the node that's a previous sibling to that rt content as a child of the ruby element. The final new element in the mix is the rp element, which is simply a way to mark up the annotative ruby text with parenthesis, for graceful fallback in browsers that don't support ruby.
And here is a screenshot of how it should look in a recent WebKit nightly or Chrome dev-channel release:
Notice that the annotative ruby text is displayed above the ruby base it annotates. If you instead view this page in a browser that doesn't support the ruby feature, you'll see that the ruby text is just shown inline, in parenthesis following the ruby base it annotates. So the feature falls back gracefully in older browsers.
Support in other browsers
Current versions of Microsoft Internet Explorer also have native support for ruby, and you can also get ruby support in Firefox by installing Piro's XHTML Ruby add-on (and for more details, see his XHTML ruby add-on info page) — so we are well on the way to seeing the HTML5 ruby feature supported across a range of browsers. If you're not accustomed to reading printed books and magazines and such in Japanese, that might not sound like such a big deal. But for authors and developers and content providers in Japan who want to finally be able to use on the Web this very common feature of Japanese page layout from the print world, getting ruby support into another major browser engine is a huge win, and something to be very excited about.
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>
We have previouslytalked 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:
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.)
