The WHATWG Blog

Please leave your sense of logic at the door, thanks!

Archive for the ‘Elements’ Category

Adding JavaScript modules to the web platform

Wednesday, April 13th, 2016

One thing we’ve been meaning to do more of is tell our blog readers more about new features we’ve been working on across WHATWG standards. We have quite a backlog of exciting things that have happened, and I’ve been nominated to start off by telling you the story of <script type="module">.

JavaScript modules have a long history. They were originally slated to be finalized in early 2015 (as part of the “ES2015” revision of the JavaScript specification), but as the deadline drew closer, it became clear that although the syntax was ready, the semantics of how modules load each other were still up in the air. This is a hard problem anyway, as it involves extensive integration between the JavaScript engine and its “host environment”—which could be either a web browser, or something else, like Node.js.

The compromise that was reached was to have the JavaScript specification specify the syntax of modules, but without any way to actually run them. The host environment, via a hook called HostResolveImportedModule, would be responsible for resolving module specifiers (the "x" in import x from "x") into module instances, by executing the modules and fetching their dependencies. And so a year went by with JavaScript modules not being truly implementable in web browsers, as while their syntax was specified, their semantics were not yet.

In the epic whatwg/html#433 pull request, we worked on specifying these missing semantics. This involved a lot of deep changes to the script execution pipeline, to better integrate with the modern JavaScript spec. The WHATWG community had to discuss subtle issues like how cross-origin module scripts were fetched, or how/whether the async, defer, and charset attributes applied. The end result can be seen in a number of places in the HTML Standard, most notably in the definition of the script element and the scripting processing model sections. At the request of the Edge team, we also added support for worker modules, which you can see in the section on creating workers. (This soon made it over to the service workers spec as well!) To wrap things up, we included some examples: a couple for <script type="module">, and one for module workers.

Of course, specifying a feature is not the end; it also needs to be implemented! Right now there is active implementation work happening in all four major rendering engines, which (for the open source engines) you can follow in these bugs:

And there's more work to do on the spec side, too! There's ongoing discussion of how to add more advanced dynamic module-loading APIs, from something simple like a promise-returning self.importModule, all the way up to the experimental ideas being prototyped in the whatwg/loader repository.

We hope you find the addition of JavaScript modules to the HTML Standard as exciting as we do. And we'll be back to tell you more about other recent important changes to the world of WHATWG standards soon!

Posted in Elements, Processing Model, WHATWG | No Comments »

The Future of the Web: My Vision (May 23, 2012)

Wednesday, May 23rd, 2012

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.

To achieve this, we use the following CSS Code.


header > h1 { font-size: 2.75em; }
section.topsection { font-size: 2em; }
section > section { font-size: 75%; }
section h1 { font-size: inherit; }
section * { font-size: 16px; }
section h1, section p { margin: 0; }

As you can see, the above code generates a much more aethetically pleasing, and far more understandable result than one without styling.

At this point, you are probably asking: How can this actually apply to real life?

Well, below this I will explain.


Use in Practical Design

As mentioned above, the true power of this method is revealed when used in practical application.

In the figure below, I will demonstrate said power by use of the first chapter of the book Alice's Adventures in Wonderland by Lewis Carroll.

404
Styling used in Practical Application
Click Here for Citation

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.

And now, to show the code that makes it work:

HTML:
<article>
<header>
<hgroup>
<h1>ALICE'S ADVENTURES IN WONDERLAND</h1>
<h2>By Lewis Carroll</h2>
<h3>THE MILLENNIUM FULCRUM EDITION 3.0</h3>
</hgroup>
</header>
<section class="topsection">
<h1>CHAPTER I. Down the Rabbit-Hole</h1>
<section class="subsection">
<p>...</p>
<p>...</p>
<p>...</p>
<p>...</p>
<p>...</p>
</section>
<div class="sep">* * * * * * * * * * * * * * * * * * * *</div>
<section class="subsection">
<p>...</p>
<p>...</p>
<p>...</p>
</section>
</section>
</article>
Note: Text removed to prevent overcluttering.


CSS:
hgroup * { margin: 0; }
hgroup h1 { font-size: 2em; }
hgroup h2 { font-size: 1.5em; }
hgroup h3 { font-size: 1em; }
section { margin-bottom: 2em; }
section h1 { margin: 0.5em 0; }
p { text-indent: 1em; margin: 1em 0; }
p:first-of-type { margin-top: 0; }
.sep { font-weight: bold; margin: 0 1em 2em; }
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.

Posted in Elements, Syntax, Tutorials | 7 Comments »

The Future of the Web: My Vision (May 1, 2012)

Tuesday, May 1st, 2012

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>

Figure 1
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>

Figure 2
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>

Figure 3
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.

Until then,

-Christopher Bright

Posted in Elements, Syntax, Tutorials | 8 Comments »

Implementation progress on the HTML5 <ruby> element

Friday, November 13th, 2009

If you don't know what the HTML5 ruby element is, you might want to take a minute to first read the section about the ruby element in the HTML5 specification and/or the Wikipedia article on ruby characters. To quote from the HTML5 description of the ruby element:

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).

きのうの豪雨で山の水源地は<ruby>氾濫<rp>(</rp>
<rt>はんらん</rt><rp>)</rp></ruby>し、濁流
<ruby>滔々<rp>(</rp><rt>とうとう</rt><rp>)</rp>
</ruby>と下流に 集り、猛勢一挙に橋を破壊し、どうどうと 
響きをあげる激流が、<ruby>木葉微塵<rp>(</rp>
<rt>こっぱみじん</rt><rp>)</rp></ruby>に<ruby>橋桁
<rp>(</rp><rt>はしげた</rt><rp>)</rp></ruby>
を跳ね飛ばしていた。

If you don't happen to have Japanese fonts installed, here's a screenshot of the source for reference:

ruby source markup

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.

So here's the rendered view of that same text:

見よ、前方の川を。きのうの豪雨で山の水源地は氾濫はんらんし、濁流滔々とうとうと下流に集り、猛勢一挙に橋を破壊し、どうどうと響きをあげる激流が、木葉微塵こっぱみじん橋桁はしげたを跳ね飛ばしていた。

And here is a screenshot of how it should look in a recent WebKit nightly or Chrome dev-channel release:

ruby rendered view

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.

Posted in Browsers, Elements | 3 Comments »

<section> is not just a “semantic <div>”

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 »