I have read about some of the semantic elements on W3C, WHATWG, and MDN, but I still a little unclear on somethings. I also went to this article, on Sidebar and Aside are different!.
I have a few basic questions, or confirm that I am understanding what I have read:
Is the aside element not a sidebar?
In HTML5, can we use semantic and div tags?
When there are no semantic tags to use, is a div tag acceptable in HTML5 (this may be the same question as above)?
Can the semantic main element have other semantic tags embedded within, such as table, section, article and aside, but not limited to?
Keep in mind that semantic tags are just a way to keep the code more human readable and to standardize pages.
This is because before most users would define just divs and then a class describing its role like nav, footer, header, etc.
For your first question; no, an aside element does not represent a "sidebar" per se. It just represents content that is related to the main content, but it's not part of the main topic of the page. You could use it to wrap the contents of a sidebar (which is in itself a UI component), but you can use it for other things as well.
From the HTML5 specification:
The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography.
The element can be used for typographical effects like pull quotes or
sidebars, for advertising, for groups of nav elements, and for other
content that is considered separate from the main content of the page.
For your second question.
Yes, in HTML5 you can use divs or semantic tags whenever you like, but it is encouraged that you use semantics whenever possible; if there's no other tag you can use to define part of the document, then use a div without problems. You can use them interchangeably, at the end, most of them like main, section, footer, etc. are just divs with a different name to make it easier to read.
This has always caused great confusion. This is the original specification's author - Ian Hickson - on the subject in 2009 (his responses are in bold, to comments made by Tab Atkins Jr):
<aside> is similarly badly named. The name itself and the
description of it as "sidebar" content apparently leads almost
everyone astray into thinking it's for the ubiquitous website sidebar.
It is.
An informal survey showed that at least 3 people in that chat (me
included) immediately tried to misuse <aside> in precisely this way
when we first heard of it, and when I discussed the issue with another
friend mid-chat his response was roughly "what's confusing about them?
footer is for site footer and aside is for side panels".
That is a correct interpretation.
Related
According to the HTML5.1 spec, as outlined in the link below, every page should only have one h1 element. Naturally, I feel that the h1 element on the homepage should be a title describing the website itself. This raises the question, how do you correctly deal with h1 headers on subpages if the h1 element used on the homepage is used in header?
For instance, let's assume we are building a website for Adam's Sweet Shop, we create the layout and we create our header:
<header>
<h1>Adam's Sweet Shop</h1>
...[other header elements]
</header>
Now, that works fine for the homepage. But as we delve into the subpages, we are left with two options. We create a different h1 element describing that page and delegate the header h1 into a different tag. This would seemingly satisfy the requirements of the HTML5.1 spec, but it almost seems 'hacky', plus for templates this would require two different header files.
The second option is to create two h1 elements, one describing the website in the header, the other within the main element describing the page.
<header>
<h1>Adam's Sweet Shop</h1>
...[other header elements]
</header>
<main>
<h1>About Adam's Sweet Shop</h1>
...[other body elements]
</main>
This obviously goes against the HTML5.1 spec, but seems less hacky. I originally built a site using second approach, but received a warning message from the W3C validator.
Are either of these approaches correct, and if not, what is a better approach, for instance, an ARIA label describing the 'real' h1?
https://www.w3.org/TR/html51/sections.html#the-h1-h2-h3-h4-h5-and-h6-elements
If it works better in your site design to have an h1 in the header and another h1 in the main, then that’s what you should do. Neither the canonical HTML spec nor the W3C copy of it say you shouldn’t use more than one h1 element per document if that’s what meets your needs. And the W3C HTML checker won’t report any errors or warnings for the markup example in the question.
As far as any accessibility concerns, it’s true screen readers will report both those h1 headings as being at the same (top) level, but that also seems appropriate for this particular case—it isn’t an absolute problem to have a couple top-level headings. (Though in contrast it would be a problem for screen readers if you marked up every section in your entire document with an h1—and that’s why the HTML emits warnings for that case (which is very different from your case).
HTML 5.1 has no restriction about having only one h1
The only requisits are:
The first element of heading content in an element of sectioning content represents the heading for that section. Subsequent headings of equal or higher rank start new (implied) sections, headings of lower rank start implied subsections that are part of the previous one. In both cases, the element represents the heading of the implied section.
This means that :
you must start with a h1,
you have to respect the h1>h2>h3... hiererarchy,
an heading starts a new section,
but you can perfectly start a new section at the same level as your first one
So having one h1 in both main and header sections is fine, according to the HTML specs,
it's possible, but it's (often) bad design.
You should always consider that your h1 is expected to be the webpage title (while the <title> element may already contain your website title). It makes no sense of having two titles for the webpage, for various reasons including SEO and accessibility.
So it's technically possible, HTML can be used for formatting complex multi-documents, but if you can avoid it, keep it simple.
edit
After reading through some discussions, I would no longer recommend using multiple h1 tags if you care about assistive technologies or browser outlining until the implementations are standardized.
My original answer should be valid in the future and for SEO purposes, but there is no guarantee for that.
original answer
You can have multiple h1s on a single page with the right sectioning. In HTML5, document outlines are created differently from previous versions.
Before HTML5, the whole page was considered the "root document", and the h1 was used to describe this root. It was a simple one-to-one relationship between HTML files and documents in the outline. This is important for SEO as engines use these outlines to guess what your page is about, and confusing them is a bad idea.
HTML5 introduced sectioning content such as article, section, header, footer, etc. According to the specs,
Sectioning content is content that defines the scope of headings and footers.
Each sectioning content element potentially has a heading and an outline.
This means you can use a h1 tag for every new outline created this way, because
Certain elements are said to be sectioning roots, including blockquote and td elements. These elements can have their own outlines, but the sections and headings inside these elements do not contribute to the outlines of their ancestors.
so if you use a h1 in a "child" outline created for example by nesting it in an article, it won't interfere with the outline (and thus SEO) of your parent outline.
So for all intents and purposes,
<html>
<head>
</head>
<body>
<h1>
My awesome collection of articles
</h1>
[ ... some content ... ]
<article>
<h1>
My awesome article
</h1>
</article>
</body>
</html>
is a valid use of headers and sectioning in HTML5. Also, this article does a great job at visually explaining all of this using nearly your example.
This has been bugging me for a while now, since the introduction of HTML5:
In some of our designs the page header is actually the title of the article you're viewing, which leads to a missing header in the outline (since the h1 is within the article, not directly a child of the body).
What would be a good practice for countering this?
I'm not a big fan of simply dumping in a hidden h1 in the body, as it's not the best idea for page-ranking for example.
I know that ideally the design would take these kind of things into account, but sometimes (as a developer) it's not your choice to make.
Example mark-up: http://codepen.io/TheDutchCoder/pen/DuKok
From the HTML draft:
When the main content of the page (i.e. excluding footers, headers, navigation blocks, and sidebars) is all one single self-contained composition, the content should be marked up with a main element and the content may also be marked with an article, but it is technically redundant in this case (since it's self-evident that the page is a single composition, as it is a single document).
According to this, you should drop the article container and go only with main.
Update (8-Nov-2013)
Well, I understand that having untitled sections is unappealing, but for the time being (HTML master draft, November 2013) there is no escape: <body> elements are sectioning roots that always start a section and are displayed in the outline. An outline such as:
The main article title
└── Related articles
Latest News
Latest Blog Posts
is simply not possible with the current outline algorithm in an HTML5 compliant way (you would need to add siblings to the <body>).
Since you were considering a suggestion to the W3C, here is an idea: perhaps the outline of a document should default to <title>.
A lot of marketing and content-heavy sites showcase the page's primary content using large text and/or images, sometimes with a slider, containing a call to action for signing up for a service, or downloading an app, etc.. I'm not sure what this design element is called, I got the term hero unit from twitter bootstrap:
http://twitter.github.com/bootstrap/components.html#typography
I think most of you know what I'm trying to describe... If it's not clear I can add screenshots or links to this question.
I looked at a few different sites, and some put this hero unit inside a ASIDE element, others use SECTION, ARTICLE and even HEADER. Using twitter bootstrap as an example again:
<header class="jumbotron masthead">
<div class="inner">
<h1>Bootstrap, from Twitter</h1>
<p>Simple and flexible HTML, CSS, and Javascript for popular user interface components and interactions.</p>
<p class="download-info">
Is HEADER the most appropriate tag for this type of content? Or should I use ASIDE, ARTICLE or SECTION?
From HTML5 doctor, where they discuss how to mark up the main content:
An assistive technlogy like a screenreader can find the main content because it is the first thing inside a page that isn't a header, nav or footer.
So I would just wrap your "hero unit" in a section. Each related group of content on a page should be grouped in its own section, with the first section being the start of the main content.
I would however second #net.uk.sweet's suggestion to frequently use a HTML5 outliner. Also, check out the HTML outlining article on the Mozilla Developers Network, it was really helpful for me.
I'd suggest looking at the w3 specification for each of the tags you're considering using and reading the description and usage examples. Of course you only need to look at the debate spawned by a seemingly simple question such as when to use an article tag to realise that this stuff is pretty subjective. However, reading the spec will leave you in a better position to formulate your own opinion:
http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-header-element
http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-aside-element
http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-article-element
http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-section-element
I do think that your header tag should be contained in a further sectioning element so that it's not hierarchically equal to other page headers within the element that contains it. What that sectioning element should be will depend on the content of your "hero unit" and how that content relates to the rest of the page.
Finally, check your work frequently in an HTML5 document outliner to get a feel for the structure of your new section and the page which contains it.
I am writing an online tutorial with sort of side notes or as they call it "admonitions" similar to those in Django tutorial:
https://docs.djangoproject.com/en/dev/intro/tutorial01/ (I mean the the boxes with green a frame and a note icon).
Which HTML tag I should use to enclose such notes to add a semantic meaning of a note that may be useful to read at a given point of a tutorial, but is not part of the main tutorial flow?
Noteworthy, the tag must allow for enclosing block elements.
I believe the accepted answer is not quite correct. According to the HTML5 working draft, the <aside> element can be used to mark up side notes in certain, but not all cases:
<aside> is appropriate if the side note "could be considered separate from the content", for example background material on Switzerland in a much longer news story, or a pull quote in a longer article. (examples from W3C document)
<aside> is not appropriate if the side note is "a parenthetical". The W3C gives no examples of what it means. A narrow interpretation would be anything that is put in parentheses, between commas or between dashes.
If you want to interpret the W3C spec strictly, not all of the sidenotes in the Django tutorial can be marked up with <aside>. For example, the note titled "Doesn't match what you see?" could not really be considered separate from the content, since it does not make sense without the content next to it. Arguably, "Where should this code live?" is also not an <aside>, as it mentions "this code", which ties it to the content.
In my opinion, the W3C definition is unnecessarily confusing and restrictive. The dictionary definition of aside is "a temporary departure from a main theme or topic", and the spec should just stick to that, rather than introducing subtle distinctions. Of course, there is no reason why you can't use <aside> for all sidenotes, if it makes your code simpler. Think of it as civil disobedience. :)
Relevant quote:
The aside element represents a section of a page that consists of
content that is tangentially related to the content around the aside
element, and which could be considered separate from that content.
Such sections are often represented as sidebars in printed typography.
The element can be used for typographical effects like pull quotes or
sidebars, for advertising, for groups of nav elements, and for other
content that is considered separate from the main content of the page.
Note: It's not appropriate to use the aside element just for parentheticals, since those are part of the main flow of the document.
In HTML5 (supported by all modern browsers), the tag is aside.
From http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-aside-element:
The aside element represents a section of a page that consists of
content that is tangentially related to the content around the aside
element, and which could be considered separate from that content.
Such sections are often represented as sidebars in printed typography.
The element can be used for typographical effects like pull quotes or
sidebars, for advertising, for groups of nav elements, and for other
content that is considered separate from the main content of the page.
It's not appropriate to use the aside element just for parentheticals,
since those are part of the main flow of the document.
This is a block-level element and enclose anything a block-level element usually can (i.e. almost anything). It is essentially a "semantic div".
I'm learning about HTML5, and honestly I can't say I'm really impressed. Semantics are nice and all, but I think that they introduced new elements with a very thin line between them, and a even thinner line between them and the old divs.
Everything is very clear if you do a generic purpose site, like a blogging engine, news publishing portal, and similar, but web apps... I'm having a lot of dilemmas about new html elements.
Here is my situation. I'm developing an ordering system. On the sellers interface I have 3 columns (inline), which represent the status of the order. When the status is changed element is moved from one column into another (background ajax, and js manipulation).
In Html4 I would use 3 divs and put a heading with a title on top of each one. Elements inside the columns would also be divs.
But what about HTML5? I have been looking at the section element, but I'm not really sure how to use it. Here are the options:
Put everything inside one section - I don't think that is the way to go
Put a section around each of the column divs, and heading inside the section
Replace the divs with sections
Put sections inside column divs
So, which way to go?
EDIT: first of all thanks everyone for your quick replies. In the end I'll probably go with Ian Devlins suggestion, and put each column as section. Anyway, just to point out my dissatisfaction with html5, multiple permitted options aren't always a good thing. I'm afraid what will the html5 web look like in a few years, when we can't fully agree on a simple question like this.
EDIT2: one more thing. I'll ask it here so I don't have to open another question. In addition to these 3 columns I have another div which contains order details, when any of the orders are selected. Should it be an article since its self-contained content, or to use an aside tag?
div is a perfectly valid HTML5 tag. If the new tags don't make any sense in your project, don't feel forced to use them.
To quote the w3.org spec:
The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading.
And another quote from the w3.org people:
The section element is not a generic container element. When an element is needed for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead. A general rule is that the section element is appropriate only if the element's contents would be listed explicitly in the document's outline.
Given the definition for section by w3 we can conclude that your example would be a good use of section because:
The elements have a header
It is a thematic grouping of content
It is a part of the document outline.
EDIT:
To expand upon your comment below, the new HTML5 elements are NOT supposed to replace the old HTML4 elements. For example, going through a page and replacing all the div elements with section elements would be flat out wrong. The section element was, in my opinion, intended to make it easier for machines to parse certain pages (think: feedburners) by giving a more semantic structure to a page. After all, what's easier to parse, a page with 30 div elements, or a page with 10 div 5 header 5 section 5 article and 5 footer elements?
In this particular case I would have an overall div around them, and then each column as a section as each one has a different meaning, each of which I assume has a heading indicating its status.
e.g.
<div>
<section id="col1">
<header><h1>Column 1</h1></header>
content....
</section>
<section id="col2">
<header><h1>Column 2</h1></header>
content....
</section>
<section id="col3">
<header><h1>Column 3</h1></header>
content....
</section>
</div>