Back in 2011, Ben Schwarz took on the ambitious project of curating an edition of the HTML Standard specifically for web developers. It omitted details aimed specifically at browser vendors, and had several additional features to make the experience more pleasant to read.
Ben did an amazing job maintaining this for many years, but some time ago it fell behind the changes to the HTML Standard. Since the move to make HTML more community-driven, we've been hoping to find a way to synchronize the developer's edition with the mainstream specification. That day has finally arrived!
We've deployed an initial version of the new developer's edition at a new URL, https://html.spec.whatwg.org/dev/. It's rough around the edges, missing several of the features of the old version. And it needs some curation to omit implementer-specific sections; many have crept in during the downtime. We're tracking these and other issues in the issue tracker. But now, the developer's edition is integrated into our build process and editing workflow, and will forever remain synchronized with the HTML Standard itself.
Hereby we issue a call to the community to help us with the revitalized developer's edition. Two of the biggest areas of potential improvement are helping us properly mark up the source according to the guidelines for what goes in the developer's edition, and contributing to the design of the developer's edition in order to make it more beautiful and usable.
Finally, I want to thank Michael™ Smith for getting this process started, via a series of pull requests to our build tools which did most of the foundational work. And of course Ben Schwarz, without whom none of this would have happened in the first place.
Posted in Tutorials, What's Next | Comments Off on The Developer’s Edition of HTML makes a comeback
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>
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.
Thanks to Ben Schwarz the WHATWG now hosts an edition of the HTML standard specifically tailored for web developers: HTML5 for Web Developers. It is identical to the HTML standard, but information specific to implementors and not relevant to web developers has been removed. It also uses some CSS to make it look pretty. We hope you like it!
Welcome back to my semi-regular column, "The Road to HTML 5," where I'll try to explain some of the new elements, attributes, and other features in the upcoming HTML 5 specification.
Regular links (<a href>) simply point to another page. Link relations are a way to explain why you're pointing to another page. They finish the sentence "I'm pointing to this other page because..."
...it's a stylesheet containing CSS rules that your browser should apply to this document
...it's a feed that contains the same content as this page, but in a standard subscribable format
...it's a translation of this page into another language
...it's the same content as this page, but in PDF format
...it's the next chapter of an online book that this page is also a part of
Two categories of links can be created using the link element. Links to external resources are links to resources that are to be used to augment the current document, and hyperlink links are links to other documents. ...
The exact behavior for links to external resources depends on the exact relationship, as defined for the relevant link type.
Of the examples I just gave, only the first (rel=stylesheet) is a link to an external resource. The rest are hyperlinks to other documents. You may wish to follow those links, or you may not, but they're not required in order to view the current page.
Common link relations include <link rel=stylesheet> (for importing CSS rules) and <link rel=alternate type=application/atom+xml> (for Atom feed autodiscovery). HTML 4 defines several link relations; others have been defined by the microformats community. HTML 5 attempts to consolidate all the known link relations, clean up their definitions (if necessary), and then provide a central registry for future proposals.
How can I use link relations?
Most often, link relations are seen on <link> elements within the <head> of a page. Some link relations can also be used on <a> elements, but this is uncommon even when allowed. HTML 5 also allows some relations on <area> elements, but this is even less common. (HTML 4 did not allow a rel attribute on <area> elements.)
Link relations were added to the HTML 5 spec in November 2006. (Back then the spec was still called "Web Applications 1.0.") r319 kicked off a flurry of rel-related activity. The original additions were primarily based on research of existing web content in December 2005, using Google's cache of the web at the time. Since then, other relations have been added, and a few have been dropped.
rel=alternate
rel=alternate has always been a strange hybrid of use cases, even in HTML 4. In HTML 5, its definition has been clarified and extended to more accurately describe existing web content. For example, using rel=alternate in conjunction with the type attribute indicates the same content in another format. Using rel=alternate in conjunction with type=application/rss+xml or type=application/atom+xml indicates an RSS or Atom feed, respectively.
HTML 5 also puts to rest a long-standing confusion about how to link to translations of documents. HTML 4 says to use the lang attribute in conjunction with rel=alternate to specify the language of the linked document, but this is incorrect. The HTML 4 Errata lists four outright errors in the HTML 4 spec (along with several editorial nits); one of these outright errors is how to specify the language of a document linked with rel=alternate (The correct way, described in the HTML 4 Errata and now in HTML 5, is to use the hreflang attribute.) Unfortunately, these errata were never re-integrated into the HTML 4 spec, because no one in the W3C HTML Working Group was working on HTML anymore.
r485 defines how to use the media attribute in conjunction with rel=alternate
r1942 make the title attribute required for rel="alternate stylesheet".
rel=archives
New in HTML 5
rel=archives "indicates that the referenced document describes a collection of records, documents, or other materials of historical interest. A blog's index page could link to an index of the blog's past posts with rel="archives"."
rel=author is used to link to information about the author of the page. This can be a mailto: address, though it doesn't have to be. It could simply link to a contact form or "about the author" page.
The decision to drop the rev attribute seems especially controversial. The same question flares up again and again on the working group's mailing list: "what happened to the rev attribute?" But in the face of almost-universal misunderstanding (among people who try to use it) and apathy (among everyone else), no one has ever made a convincing case for keeping it that didn't boil down to "I wish the world were different." Hey, so do I, man. So do I.
rel=external "indicates that the link is leading to a document that is not part of the site that the current document forms a part of." I believe it was first popularized by WordPress, which uses it on links left by commenters. I could not find any discussion of it in the HTML working group mailing list archives. Both its existence and its definition appear to be entirely uncontroversial.
rel=feed "indicates that the referenced document is a syndication feed." Right away, you're thinking, "Hey, I thought you were supposed to use rel=alternate type=application/atom+xml to indicate that the referenced document is a syndication feed." In fact, that's what everyone does, and that's what all browsers support. Firefox 3 is the only browser that supports rel=feed. (It also supports rel=alternate type=application/atom+xml.) The rel=feed variant was proposed in the Atom working group in 2005 and somehow found its way into HTML 5. Just yesterday, I was discussing whether HTML 5 should drop rel=feed due to lack of browser implementation and complete and utter lack of author awareness.
HTML 4 defined rel=start, rel=prev, and rel=next to define relations between pages that are part of a series (like chapters of a book, or even posts on a blog). The only one that was ever used correctly was rel=next. People used rel=previous instead of rel=prev; they used rel=begin and rel=first instead of rel=start; they used rel=end instead of rel=last. Oh, and -- all by themselves -- they made up rel=up to point to a "parent" page.
HTML 5 includes rel=first, which was the most variation of the different ways to say "first page in a series." (rel=start is a non-conforming synonym, for backward compatibility.) Also rel=prev and rel=next, just like HTML 4 (but mentioning rel=previous for back-compat). It also adds rel=last (the last in a series, mirroring rel=first) and rel=up.
The best way to think of rel=up is to look at your breadcrumb navigation (or at least imagine it). Your home page is probably the first page in your breadcrumbs, and the current page is at the tail end. rel=up points to the next-to-the-last page in the breadcrumbs.
All major browsers support this usage to associate a small icon with the page (usually displayed in the browser's location bar next to the URL).
Also new in HTML 5: the sizes attribute can be used in conjunction with the icon relationship to indicate the size of the referenced icon. [sizes example]
rel=nofollow "indicates that the link is not endorsed by the original author or publisher of the page, or that the link to the referenced document was included primarily because of a commercial relationship between people affiliated with the two pages." It was invented by Google and standardized within the microformats community. The thinking was that if "nofollow" links did not pass on PageRank, spammers would give up trying to post spam comments on weblogs. That didn't happen, but rel=nofollow persists. Many popular blogging systems default to adding rel=nofollow to links added by commenters.
r1708 added the clause about commercial relationships.
rel=noreferrer
New in HTML 5
rel=noreferrer "indicates that the no referrer information is to be leaked when following the link." No browser currently supports this. [rel=noreferrer test case]
r1950 extends rel=noreferrer to also blow away the 'opener' when used with target=_blank
rel=pingback
New in HTML 5
rel=pingback specifies the address of a "pingback" server. As explained in the Pingback specification, "The pingback system is a way for a blog to be automatically notified when other Web sites link to it. ... It enables reverse linking -- a way of going back up a chain of links rather than merely drilling down."
Blogging systems, notably WordPress, implement the pingback mechanism to notify authors that you have linked to them when creating a new blog post.
rel=prefetch "indicates that preemptively fetching and caching the specified resource is likely to be beneficial, as it is highly likely that the user will require this resource." Search engines sometimes add <link rel=prefetch href="URL of top search result"> to the search results page if they feel that the top result is wildly more popular than any other. For example: using Firefox, search Google for CNN; view source; search for the keyword "prefetch".
Mozilla Firefox is the only current browser that supports rel=prefetch.
What improves Web applications? "A big plus point would be to prefetch the next page so it loads immediately the 'next' button is clicked."
rel=search "indicates that the referenced document provides an interface specifically for searching the document and its related resources." Specifically, if you want rel=search to do anything useful, it should point to an OpenSearch document that describes how a browser could construct a URL to search the current site for a given keyword.
OpenSearch (and rel=search links that point to OpenSearch description documents) is supported in Microsoft Internet Explorer since version 7 and Mozilla Firefox since version 2.
r484 adds a note about OpenSearch documents in particular
rel=sidebar
New in HTML 5
rel=sidebar "indicates that the referenced document, if retrieved, is intended to be shown in a secondary browsing context (if possible), instead of in the current browsing context." What does that mean? In Opera and Mozilla Firefox, it means "when I click this link, prompt the user to create a bookmark that, when selected from the Bookmarks menu, opens the linked document in a browser sidebar." (Opera actually calls it the "panel" instead of the "sidebar.")
Internet Explorer, Safari, and Chrome ignore rel=sidebar and just treat it as a regular link. [rel=sidebar test case]
r668 revamps the definition based on the concept of a "secondary browsing context."
rel=tag
New in HTML 5
rel=tag "indicates that the tag that the referenced document represents applies to the current document." Marking up "tags" (category keywords) with the rel attribute was invented by Technorati to help them categorize blog posts. Early blogs and tutorials thus referred to them as "Technorati tags." (You read that right: a commercial company convinced the entire world to add metadata that made the company's job easier. Nice work if you can get it!) The syntax was later standardized within the microformats community, where it was simply called "rel=tag".
Most blogging systems that allow associating categories, keywords, or tags with individual posts will mark them up with rel=tag links. Browsers do not do anything special with them, but they're really designed for search engines to use as a signal of what the page is about.
