On the 16th December, a HTML5 extension specification for the <main> element was submitted to the W3C under something called an editors draft. The abstract is as follows:
This specification is an extension to the HTML5 specification [HTML5].
It defines an element to be used for the identification of the main
content area of a document. All normative content in the HTML5
specification, unless specifically overridden by this specification,
is intended to be the basis for this specification.
The main element formalises the common practice of identification of
the main content section of a document using the id values such as
'content' and 'main'. It also defines an HTML element that embodies
the semantics and function of the WAI-ARIA [ARIA] landmark role=main.
Example:
<!-- other content -->
<main>
<h1>Apples</h1>
<p>The apple is the pomaceous fruit of the apple tree.</p>
<article>
<h2>Red Delicious</h2>
<p>These bright red apples are the most common found in many
supermarkets.</p>
<p>... </p>
<p>... </p>
</article>
<article>
<h2>Granny Smith</h2>
<p>These juicy, green apples make a great filling for
apple pies.</p>
<p>... </p>
<p>... </p>
</article>
</main>
<!-- other content -->
It's got all the info in there and I feel I should start incorporating it into web pages. As far as I know now, the HTML5 spec is just progressive with new features been "bolted" on to the spec with no upgrade. I guess that means the browsers will start implementing it when they can - the question is, how long does this take and how do I know all browsers support it? Should I just build it like so for now and resort to a polyfill?
Support for <main> will be much like support for any other new container element introduced in HTML 5.
New enough browsers will support it.
Older browsers will let you style it so it is display: block and give you the visual effects of it
Older versions of IE won't support it at all without a JavaScript shim (which will work in exactly the same way as the ones for all the other new container elements).
The "when" depends on what level of browser support you need and how willing you are to depend on a JS shim.
For now, I would be careful about usng it.
For the future of the proposal, what really matters is implementation in browsers. In particular, because <main> is a proposed block level element, it will require a change to the HTML5 parser implementation as well as giving it the default ARIA role of main.
Without the default ARIA role, there is no point to the element, although using it now in preparation for that is a reasonable approach.
The parser change does require a modicum of care though. Remember that the </p> tag is optional. Now suppose you decide that before your "main" content you want a paragraph of preamble. You could write:
<!DOCTYPE html>
<body>
<p> This is my page preamble ...
<main>
My main content ...
<div>
A story ...
</div>
</main>
</body>
If and when browsers implement the <main> element, the <main> tag will automatically close the <p> element and in the DOM, the <p> element and the <main> element will be siblings of one another. The <div> element and its content will be a child of the <main> element. i.e. The DOM will be:
HTML
+--HEAD
+--BODY
+--P
| +--This is my page preamble ...
+--MAIN
+--My main content ...
+--DIV
+--A story
However, right now in browsers, the <main> becomes a child element of the <p> element, and while "My main content ..." is a child of the <main> element, the <div> element is not. i.e. the DOM has this structure:
HTML
+--HEAD
+--BODY
+--P
| +--This is my page preamble ...
| +--MAIN
| +--My main content ...
+--DIV
+--A story
Now, of course, this is easily avoided by explicitly using a </p> tag, on the preamble paragraph, but it is a trap for the unwary.
The HTML 5.1 main element is now implemented in Webkit. Validation support to follow shortly. Expect Firefox implementation soonish.
You can go ahead and use it, Chrome 26 and Firefox 21 already implemented it.
Just as with the introduction of many other new HTML5 elements, not all browsers recognise <main> or have preset styles for it. You’ll need to ensure it displays as a block level element in your CSS:
main {display:block;}
For the time being, you'll also need to use JavaScript to create the element for older versions of IE:
<script>document.createElement('main');</script>
Of course, if you use the html5shiv, <main> is now baked in directly.
Related
My goal is to use the correct H* tag (H1 to H6) in my html5 code.
I read here I shouldn't use <section> at all: "Why you should choose article over section : Browsers’ visual display of headings nested inside elements makes it look as if they are assigning a logical hierarchy to those headings. However, this is purely visual and is not communicated to assistive technologies"
but I feel that isn't true because of the answers to this popular question:
that says "sections in an article are like chapters in a book, articles in a section are like poems in a volume" and I want to use sections for their intended purpose.
The problem is this mdn page says "Important: There are no implementations of the proposed outline algorithm in web browsers nor assistive technology; it was never part of a final W3C specification. Therefore the outline algorithm should not be used to convey document structure to users. Authors are advised to use heading rank (h1-h6) to convey document structure."
The guy from the first link I posted does make a good point about halfway down that page where he says "browsers display different sizes of font depending on how deeply the is nested in <section>s”.
So am I correct in saying I have to correctly match H* tags to depth/nesting to achieve a good outline AND visual styling or is there a different way. eg this would be incorrect:
<body>
<h1> something </h1>
<section>
<h1> section heading for outline </h1>
<article>
<h1>my first news article</h1>
<p>stuff</p>
</article>
</section>
</body>
because screen readers can't properly process <section> for outlining.
and because browsers display different fonts according to level of nesting.
so then would this would be correct?
<body>
<h1> something </h1>
<section>
<h2> section heading for outline </h2>
<article>
<h3>my first news article</h3>
<p>stuff</p>
</article>
</section>
</body>
note: This is my first question I'm posting so please go easy on me if I've made a faux-pas, I'm new here :)
The document outline algorithm based on <h1> has been removed from the spec and actually never worked. In terms of heading levels, your last code example is the correct one.
Why the HTML Outlining Algorithm was removed from the spec – the truth will shock you!
There Is No Document Outline Algorithm
So you should not use it, and your quote holds true.
Authors are advised to use heading rank (h1-h6) to convey document structure.
Correctly using <section>
As to the question of using <section> vs <article>.
You shouldn’t avoid the latter due to styling issues. You already did your research and should stick to your outcome. You’d need to apply some styling yourself, though.
I’d also like to add the ARIA perspective on a page summary:
<article> has role article
An article is not a navigational landmark
and
<section> has role region, which is …
[…] sufficiently important that users will likely want to be able to navigate to the section easily and to have it listed in a summary of the page.
To do so, it is also noted
Authors MUST give each element with role region a brief label
So, let’s put it together
<body>
<h1> something </h1>
<section aria-labelledby="s1-heading">
<h2 id="s1-heading"> section heading for outline </h2>
<article>
<h3>my first news article</h3>
<p>stuff</p>
</article>
</section>
</body>
Let's consider a html book (to step away from the usual blog post example).
The code might look something like this:
<!DOCTYPE html>
<html>
<head>
<title>The title</title>
</head>
<body>
<h1>The title</h1>
<article class="the-book">
<h2>Chapter I</h2>
<section>
<!-- the contents -->
</section>
<h2>Chapter II</h2>
<section>
<!-- the contents -->
</section>
</article>
</body>
</html>
What would be the correct heading numbering within chapters? Is it correct to restart the numbering in the new scope and use <h1>, <h2> again? Or do we use the next unused level (<h3>)?
I am asking this in context of semantics and correct HTML5 code not of presentation.
The best way is to keep your nesting valid regardless of the expected scoping of <article> and <section>. In other words, for choosing your <h#> level, pretend <article> and <section> do not exist.
You may be thinking of the HTML5 Document Outline Algorithm, but the Document Outline Algorithm was never a recommendation in a final W3C spec. There was a warning explicitly against authors relying on it, though the outline language was retained for browsers to understand how to implement support (eventually).
It has been removed from the HTML5 specification (June 9), the HTML validator has been updated to recognize that no browser ever implemented it (June 16), and there is no action on any of the open bugs with the browsers to do anything about it (Chromium, Firefox, WebKit, IE / Edge).
You can get the latest take on heading structure in the HTML 5.2 draft spec, recent as of January 14, 2018 (it updates regularly).
If you want more context or history, I have a blog post that covers it with links to the spec sources. Just go to the bullet list at the bottom: http://adrianroselli.com/2016/08/there-is-no-document-outline-algorithm.html
For example, if I want to put h1 in a left column and content in a right column:
<div class="left-column">
<main>
<h1>Document Title</h1>
</main>
</div>
<div class="right-column">
<main>
<p>Text content<p>
</main>
</div>
Is it correct? Thanks!
The short answer is yes, you can. However, the W3C spec forbids it while the WHATWG spec allows it. As the author of the main element wrote the W3C version and is at odds with WHATWG's interpretation, I would defer there. There is also an open bug to have the WHATWG spec align with the W3C spec.
However, you SHOULD NOT as the best use of main involves supporting assistive technology (AT) (screen readers, for example). It also maps to the ARIA role of main, so it has a direct mapping expectation.
AT users have a quick way to navigate to the main element, which represents the main content of the page. If you use more than one, then those users may never see it as they do not expect there to be more than one block of main content (the WHATWG bug report bears this out as stated by AT users).
Also the HTML validator will throw an error, which may or may not be a concern.
In most cases, multiple article elements can be nested within a main to achieve the desired effect for styling hooks.
I don't have enough rep points to post more than 2 links, else I'd offer some more material.
I think not - There must not be more than one <main> element in a document. The <main> element must NOT be a descendant of an <article>, <aside>, <footer>, <header>, or <nav> element.
it can only be use once per page. see this link here
http://html5doctor.com/the-main-element/
For more info about why. Take a look at this one
http://lists.w3.org/Archives/Public/public-html/2013Jan/0230.html
Here is the Alignment
<div class="left-column">
<main>
<h1 align="left">Document Title</h1>
</main>
</div>
<div class="right-column">
<main>
<p align="right">Text content<p>
</main>
</div>
What are people's opinions on semantic HTML for confirmation, error and warnings messages?
Currently I have something simple like:
<div class="message message-warning">
<h3>Message Title</h3>
<p>Message text</p>
</div>
Whereby the message-warning class gets replaced by message-confirmation or message-error if the message is a different type.
Is there a more semantic way of marking this up?
May I suggest <figure>?
Excerpt from HTML5 Doctor (and they, from W3C):
The figure element represents a unit of content, optionally with a caption, that is self-contained, that is typically referenced as a single unit from the main flow of the document, and that can be moved away from the main flow of the document without affecting the document’s meaning.
Lets answer the questions first:
Is such a dialog a single unit? Yes
Is such a dialog self-contained? Yes
Can such a dialog be moved away from the document without affect the document meaning? Yes
Yes, it fits a <figure> perfectly.
And, the <figcaption> is especially good for title bars / headings.
So, I'd go with <figure> without even trying to look further:
<figure id="dialog-box" class="warning">
<figcaption>Message Title</figcaption>
<p>Message text</p>
</figure>
Use the <dialog> element, and call .show() instead of .showModal(), or give it the open attribute if rendering server-side.
As long as it’s not shown modally, it won’t block interactions with other page content.
Old answer (before <dialog> was a thing):
Alerts are one of the semantics that ARIA added to HTML, because there's no straightforward way of doing in "pure" HTML. Hence:
<aside role="alert">
<h2>Message Title<h2>
<p>Message Text</p>
</aside>
I personally like to use <aside> as the element to slap the role on — it's technically not part of the page content, as described by Jeff Lindblom's answer.
Having a "semantic" CSS selector for this is easy enough:
[role="alert"] {
font-size: 2em; /* or what have you */
}
The <figure> idea is interesting, but I don't think it fits here. What it's missing is the actual content to justify use of the tag. According to the spec, <figure> represents a "unit of content" - meaning an image, diagram, code block, etc. that may optionally have a caption for this content (<figcaption>). It would be a stretch to say that the message outside the <figcaption> represents an appropriate unit of content.
We should also be cautious of using <h#> tags in this instance, as the message is secondary content, and should probably not be part of the document outline.
One could argue, under the revised spec, that an <aside> would be appropriate. It's now considered "tangential content" when used outside an <article>.
<strong> would be appropriate for the "title" of the message, since it's a semantically more important part of the message, but not a document header. So the code might look so:
<aside class="warning-or-whatever">
<strong>Message Title</strong>
<p>Message Text</p>
</aside>
One could also argue, since there's nothing specifically created for such a feature, that a good old-fashioned, semantically meaningless <div> might be the best element. I guess it comes down to how "tangential" you feel your messages are.
Thanks,
Jeff
No. There is no element in HTML that denotes a confirmation, error, or warning message.
Technically, the samp element has been defined as “sample output from programs, scripts, etc.” in HTML 4.01 and in HTML 3.2, though originally in HTML 2.0 as “sequence of literal characters, typically rendered in a mono-spaced font” and being somewhat redefined in HTML5 as “(sample) output from a program or computing system”. So its meaning is rather vague, and it’s not used much, so there is no real point in using it. But it might be argued that it is acceptable to use samp markup for any message from a program. It is a text-level element, so you would need to use it separately inside h3 and inside (any) p, more or less breaking the structure.
It might also be said that the messages are quotations from an external source, so they could be wrapped inside blockquote.
The use of h3 vs. some other markup isn’t really a semantic question, but structural: is this a heading for some content at the 3rd level of nesting?
I think the strong element is an appropriate element for such messages.
You could use several strong elements to indicate the importance of the message:
<strong>Login successfully.</strong> <!-- confirmation -->
<strong><strong>Wrong login data.</strong></strong> <!-- warning/error -->
If it’s stand-alone message for which a heading is warranted, use a section element instead of a div. In case of serious errors that apply to the whole page, it should be the first element on the page.
Various variants are possible:
<section class="message message-error">
<h1><strong><strong>Error:</strong> Wrong login data.</strong></h1>
<p>The username and/or password is wrong. Try …</p>
</section>
<section class="message message-error">
<h1>Error</h1>
<p><strong><strong>Wrong login data.</strong></strong></p>
<p>The username and/or password is wrong. Try …</p>
</section>
<section class="message message-error">
<strong><strong>Wrong login data.</strong></strong>
</section>
<section class="message message-error">
<p><strong><strong>Wrong login data.</strong></strong> Try …</p>
</section>
Which one to use depends on the kind of message, if the exact error is know, if additional help text is provided, and if several message could come up at the same time.
Note that you probably don't want to use a heading for messages that apply to a single input element (e.g. when the user didn't fill out a required field or entered wrong content etc.), as these error messages should be in the corresponding label or directly next to the input element.
For accessibility, you should have a look at WAI-ARIA. Maybe aria-live="assertive" might be an appropriate way to mark error messages.
If you want to go semantic, you can use a semantic-web approach by making an ontology for messages and warnings and use RDFa to embed it in your HTML.
Take these two pieces of markup:
<div id="header">
<img src="/img/logo.png" alt="MyLogo" />
<ul id="misc-nav">
<li>..</li>
</ul>
<header>
<h1>Welcome to Bob's Website of Fantastical Conbobulations</h1>
<p>The smell of invention awaits you...</p>
</header>
</div>
and
<header>
<img src="/img/logo.png" alt="MyLogo" />
<ul id="misc-nav">
<li>..</li>
</ul>
<h1>Welcome to Bob's Website of Fantastical Conbobulations</h1>
<p>The smell of invention awaits you...</p>
</header>
My example may not be perfect, but I'd like to know if the purpose of the tag is for semantic definition of the content, or is it block level structural definition with CSS?
It is my understanding from the spec itself, that the first example is the correct interpretation, yet I see the second being touted as the right way.
Can you offer any clarity on it?
Both are fine. But what exactly do you mean by "structural" vs "semantic"?
It's your first method (semantically).
The < header> tag defines an
introduction to the document.
<header>
<h1>Welcome to my homepage</h1>
<p>My name is Donald Duck</p>
</header>
<p>The rest of my home page...</p>
http://www.w3schools.com/html5/tag_header.asp
Spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-header-element
The header tag purely semantic.
However, in fact all HTML tags are to provide a context to the content (= semantics).
Use CSS to style your content approperiately.
I would advocate the following combination of markup and CSS:
In your CSS:
header {
background: #fff url(/img/logo.png) top left no-repeat;
padding-left: 64px; /* or whatever required to display margin correctly */
}
/* if you REALLY want your navigation to appear as a bulleted list */
nav a {
display: list-item;
}
In your page markup:
<nav>
<a>...</a>
<a>...</a>
</nav>
<header>
<h1>Welcome to Bob's Website of Fantastical Conbobulations</h1>
<p>The smell of invention awaits you...</p>
</header>
This way you're using the semantic <header /> and <nav /> tags to mark up text content, and then using CSS to enhance the presentation with display formatting, logo images, etc.
I recall - although alas I can't find the sources now - that the proposed new elements in HTML5 (header, nav, footer, aside, article, etc.) were chosen based on analysis of Google's database of websites to identify the most commonly-used ID attributes assigned to DIV elements, figuring that those represented the most common scenarios where developers were using DIVs to wrap meaningful elements of their page structure.
HTML5 actually does away with block/inline distinction in favour of a more nuanced content model. The header element is flow content, which is like the default state for HTML5 elements. Semantically it should be considered as introductory information for its nearest section content or sectioning root ancestor.
I think both your examples are valid uses of the element, though I personally would probably markup your first one this way:
<header>
<img src="/img/logo.png" alt="MyLogo" />
<nav>
<ul>
<li>..</li>
</ul>
</nav>
<hgroup>
<h1>Welcome to Bob's Website of Fantastical Conbobulations</h1>
<h2>The smell of invention awaits you...</h2>
</hgroup>
</header>
I used to think that the first method is the proper way to use the element, as it is intended to provide relevant information for a given section it is included in, not being a section itself, besides we already have elements for structuring the content, but for what i've seen in some pages, the reason many people includes also a header element at root level is to provide that same information considering the whole page as a big section, so i've changed my mind to think both of the examples can be considered correct.
If you read the W3C HTML5 specification you will find that every html page should have only one H1 tag, so if you use h1 then h2 then h3 you might see some weird styling. That is because the browser expect one h1 on every html page when it parses it.
So you can instead use h1 h2 h3 tags and style them any way you want.
The point of using semantic html elements is because your website will be 'read' not only by web browsers but also by web crawlers, tools that read the page with voice, braile tools and many more applications and physical tools.
So when those applications read your website they don't read css, only html and might read some javascript. So when they see lang="en" they know to read the contents in the element in english etc. When they see "section" they know it's section element and when they see "aside" they know it is some aside element etc.
We can easy see the page and know what is what, but visually impaired and other people can't do that so for them this will be of great help. Think about that when you make your websites, think about all the people that will access it and how easy will be for them to do that.
That is the whole point of the new awesome html5 elements. You can make the same webpage just with one element - "div" for example, and with a whole range of new html5 semantic elements - article, section, header, footer, aside etc. The webpage will look the same in web browsers, but smart applications like search engine robots will crawl the page better and some applications that read web pages will parse the page more easily.
The point of web is to be open to all people and free, and I agree to that.
In the future, the web will evolve without doubt, new tools will be made that will parse web pages, and using new html5 semantic elements will make your webpages future proof, so these new tools will read our pages in smart way.
Hope this helped someone :)