I'm currently building a WebApp with the following structure :
However, I'm not often developping for Web, and I would like to know what HTML tags I should use to enclose the different sections of the app.
Should I use <header> tags for the header bar, <nav> for the menu, <aside> for the notifications and <article> for the body, or something else? (I'd appreciate it too if you can give me some kind of skeleton for this)
I don't think anyone actually does it any standard way, but I really recommend looking into smacss -- scalable and modular architecture for css. https://smacss.com/book/type-layout It's a great philosophy on how to organize and name css/html.
Following smacss, you will divide your content based on header, footer, and article. whereas navigation is a child element of either header or article, so you can either choose to use the tag (if the navigation will remain constant throughout your entire web structure), or if it'll be flexible and changing, you should stick to labeling the navigation a class or id, and not use the tag itself (this is to ensure you can reuse as much css as possible... read the entire smacss article for more on reusing css and further reading on oocss -- object oriented css)
Yes, I believe you are on the right track.
Personally, I'd use
<header id="site-header">
<nav id="menu">
<section id="main">
<aside id="notifications">
While your use of article is not wrong for sectioning, I like to think of layout as the division of a page into sections. And then, within the main section, there may be many articles - possibly with their own headers, footers, sections etc.
I also like to use ids for each important part of the page - on top of making the content semantics even clearer, id also makes it much easier (and faster) to find and select them using JavaScript.
Just a minor note: I'd avoid calling the main content section "body" simply for the reason that it can be confused with the <body> tag.
Just use them like you have listed above. It's worth just referring to this handy guide to ensure your chosen tags work cross browser (See and for an example).
There is no wrong or right answer.
The use of the HTML5 tags such as header,nav,footer,aside,section can help you and other developers better understand your structure .Here is sample . you can go to the link to see how it is used !
<!DOCTYPE html>
<html>
<head>
<title>Title of the page</title>
</head>
<body>
<header>
<h1>Here is <span>HTML5</span> Page</h1>
</header>
<nav>
<header>
Navigation menu
</header>
<ul>
<li><span>Blog</span></li>
<li>About</li>
<li>Contact</li>
</ul>
</nav>
<section>
<header>
<h1>Blog posts for April 2012</h1>
</header>
<article>
<header>
<h1>Information about this example</h1>
This example is a modified version of http://netstream.ru/htmlsamples/html5-blog/index.html
</header>
<p>Try to move the mouse on different elements. The structure will be highlighted and you will be able to see the different inclusions of elements one in each other. If you move the cursor to this sentence, it will be highlighted in dark grey, showing the presence of an <article> element, surrounded by a <section> element (light grey), etc. So we have some articles in a single section element. The page title at the top is a <header> element, while the tag cloud on the right is a <aside> element. The main menu on top (with Blog, About, Contact) is a <nav> element.</p>
<figure>
<img src="http://www.fredcavazza.net/files/2009/09/html5_structure.png" alt="Example of HTML5 structuring tags" />
<figcaption>
Fig. 1 : an example of how new structuring elements could be used. This page put a <nav> on top, and does not have headers and footer for each article, like in this figure, but it could... By the way, this is a <figcaption> inside a <figure> element...
</figcaption>
</figure>
</article>
<article>
<header>
<h1>History</h1>
</header>
<p>Work on HTML 5 originally started in late 2003, as a proof of concept to show that it was possible to extend HTML 4's forms to provide many of the features that XForms 1.0 introduced, without requiring browsers to implement rendering engines that were incompatible with existing HTML Web pages. At this early stage, while the draft was already publicly available, and input was already being solicited from all sources, the specification was only under Opera Software's copyright.</p>
<p>In early 2004, some of the principles that underlie this effort, as well as an early draft proposal covering just forms-related features, were presented to the W3C jointly by Mozilla and Opera at a workshop discussing the future of Web Applications on the Web. The proposal was rejected on the grounds that the proposal conflicted with the previously chosen direction for the Web's evolution.</p>
<p>Shortly thereafter, Apple, Mozilla, and Opera jointly announced their intent to continue working on the effort. A public mailing list was created, and the drafts were moved to the WHATWG site. The copyright was subsequently amended to be jointly owned by all three vendors, and to allow reuse of the specifications.</p>
<p>In 2006, the W3C expressed interest in the specification, and created a working group chartered to work with the WHATWG on the development of the HTML 5 specifications. The working group opened in 2007. Apple, Mozilla, and Opera allowed the W3C to publish the specifications under the W3C copyright, while keeping versions with the less restrictive license on the WHATWG site.</p>
<p>Since then, both groups have been working together.</p>
</article>
<article>
<header>
<h1>HTML vs XHTML</h1>
</header>
<p>This specification defines an abstract language for describing documents and applications, and some APIs for interacting with in-memory representations of resources that use this language.</p>
<p>The in-memory representation is known as DOM5 HTML , or the DOM for short.</p>
<p>There are various concrete syntaxes that can be used to transmit resources that use this abstract language, two of which are defined in this specification.</p>
<p>The first such concrete syntax is HTML5 . This is the format recommended for most authors. It is compatible with most legacy Web browsers. If a document is transmitted with the MIME type text/html, then it will be processed as an HTML5 document by Web browsers.</p>
<p>The second concrete syntax uses XML, and is known as XHTML5 . When a document is transmitted with an XML MIME type, such as application/xhtml+xml, then it is processed by an XML processor by Web browsers, and treated as an XHTML5 document. Authors are reminded that the processing for XML and HTML differs; in particular, even minor syntax errors will prevent an XML document from being rendered fully, whereas they would be ignored in the HTML5 syntax.</p>
<p>The DOM5 HTML , HTML5 , and XHTML5 representations cannot all represent the same content. For example, namespaces cannot be represented using HTML5 , but they are supported in DOM5 HTML and XHTML5 . Similarly, documents that use the noscript feature can be represented using HTML5 , but cannot be represented with XHTML5 and DOM5 HTML . Comments that contain the string -> can be represented in DOM5 HTML but not in HTML5 and XHTML5 . And so forth.</p>
</article>
</section>
<aside>
<h1>Tag cloud</h1>
<ul class="tag-cloud">
<li>ajax</li>
<li>apple</li>
<li>css</li>
<li>firefox</li>
<li>google</li>
<li>html</li>
<li>internet explorer</li>
<li>iphone</li>
<li>css3</li>
<li>ipod</li>
<li>javascript</li>
<li>jquery</li>
<li>mac</li>
<li>opera</li>
<li>rss</li>
<li>html5</li>
<li>web</li>
<li>web 2.0</li>
<li>web-??????????</li>
<li>windows</li>
<li>yahoo</li>
<li>youtube</li>
</ul>
</aside>
<footer>
<p>© 2009 Some blog</p>
</footer>
</body>
</html>
Related
My question is probably based on a bad design. However, I can't change that and need to work with it. This is the visual draft I'm talking about, it's just a part of a full website:
As you can see there's a title of an article with a background image, then a breadcrumb toolbar and finally, the articles content. Now, usually, if there wouldn't be the breadcrumb toolbar you could simply wrap it into an <article>. But the breadcrumb divides the article in a "pre" article and a main article part. The only "clean" HTML5 way would be to wrap the article including the header with background image into an <article> and position the breadcrumb into the target visual position. However, I'm classifying this as "hack" and I'm searching a better way.
What would be the preferred markup for this scenario?
There won't be any perfect the solution for the current requirement.
As pointed out by comments to the previous answer, the nav is not related to the article.
Also, WCAG instructs that :
1.3.2 Meaningful Sequence: When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined. (Level A)
EDIT : If changing the order of the element can preserve a meaningful sequence (G57), when the elements does not match visually the DOM order (see C27) the visual focus indicator of the screen reader will not match the standard reading order which will result in bad UX for people with low vision using a screenreader.
So it's impossible to try a CSS visual hack to invert the order between the elements visually without breaking another rule.
You may think of a third technique :
set aria-hidden on the visible title,
use aria-labelledby on the article tag to point to the h1 outside the article element :
For instance:
<header>
<h1 aria-hidden="true" id="title">Your title</h1>
<nav><!-- nav here --></nav>
</header>
<article aria-labelledby="title">
// article here
</article>
Another way to do is to duplicate the title element, one visible, one for assistive technology
<header>
<div aria-hidden="true">Your title</div>
<nav><!-- nav here --></nav>
</header>
<article>
<h1 class="sr-only">Your title</h1>
// article here
</article>
It could be something like this -
<article>
<header>
//APPLY BACKGROUND IMAGE
<h1>YOUR TITLE</h1>
</header>
<nav>
//USE BREADCRUMBS HERE
</nav>
<section>
//USE THIS FOR CONTENT
</section>
</article>
I have been working with a lot of html structuring lately and I started to wonder what are the elements that are allowed as children of an <a> element?
Anything as long as there insn't any interactive content like buttons, forms, other link...
w3.org HTML5 specs :
The a element may be wrapped around entire paragraphs, lists, tables, and so forth, even entire sections, so long as there is no interactive content within (e.g. buttons or other links).
see link to source
And here is an example of what you can do (still form w3.org) :
<aside class="advertising">
<h1>Advertising</h1>
<a href="http://ad.example.com/?adid=1929&pubid=1422">
<section>
<h1>Mellblomatic 9000!</h1>
<p>Turn all your widgets into mellbloms!</p>
<p>Only $9.99 plus shipping and handling.</p>
</section>
</a>
<a href="http://ad.example.com/?adid=375&pubid=1422">
<section>
<h1>The Mellblom Browser</h1>
<p>Web browsing at the speed of light.</p>
<p>No other browser goes faster!</p>
</section>
</a>
</aside>
Changes in HTML5
Although previous versions of HTML restricted the a element to only containing phrasing content (essentially, what was in previous versions referred to as “inline” content), the a element is now transparent; that is, an instance of the a element is now allowed to also contain flow content (essentially, what was in previous versions referred to as “block” content)—if the parent element of that instance of the a element is an element that is allowed to contain flow content.
HTML language reference
I have a web page like the following one:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Title</title>
</head>
<body>
<header>
<span>Logo</span>
<nav>Navigation</nav>
</header>
<main>
<h1>Page heading</h1>
<div>
Page content
</div>
</main>
<footer>
Content information
</footer>
</body>
</html>
The page structure is similar to one example in the current HTML5 draft: http://www.w3.org/html/wg/drafts/html/master/grouping-content.html#the-main-element and I think it is semantically correct.
Now I would like to style this document using CSS. I would like to be the header at the top and footer at the bottom, which is, of course, easily doable. Inside the header I would like to put the logo to the right and the navigation in the center, which is also okay (e.g by using the flexible box layout model, which is in one or the other way supported by modern browsers, or by using floats).
My problems begin when I want to put the main's content heading (the h1 element) visually in the left of the header. I could do with position: absolute but such a layout is not very flexible and would break as soon as the header's or the heading's sizes change. The proposed CSS grid layout http://www.w3.org/TR/css3-grid-layout/ may be able to do exactly what I want but it is, as far as I know, only supported (somehow) in IE 10.
One simple and working solution would be to simply restructure my page:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Title</title>
</head>
<body>
<div>
<h1 id="heading">Page heading</h1>
<header>
<span>Logo</span>
<nav>Navigation</nav>
</header>
</div>
<main aria-labelledby="heading">
<div>
Page content
</div>
</main>
<footer>
Content information
</footer>
</body>
</html>
This solution, while easily layoutable, however, has its full semantics only expressed via aria-* attributes and seems to go against the spirit of the HTML5 semantics (especially the main element).
While my example page may be simple, you can easily imagine a more complicated one where the visual position of many more elements are not in the same order as the flow order of the HTML5 markup (and nested so that the flexible box layout order property won't suffice). How would you solve the problem? Rewrite the HTML5 markup with non-semantic elements (e.g. divs) so that it corresponds more to the visual layout and then exchange the non-semantic elements by semantic ones (e.g. footer or main) wherever possible with the new structure?
I am running into the same conundrum as you, and I appreciate the frustration. I will attempt a negative answer, because I feel both of these positive ones (which say you can achieve both your ends) are missing the point.
Firstly, the way I see it, your principle difficulty is that CSS cannot move an element to a new container. The two answers fall into two categories:
Some are ultra-specific hacks (subjectively speaking) involving floats, negative margins, and/or absolute positioning which can move an item presentationally out of its container. These can be effective, but only in very specific cases. As your needs grow, it becomes difficult to maintain and it requires putting a rather large thinking cap on to address each new need or edge case that you had missed earlier. The answer by #jennifit attempts to move you in this direction. It is, I believe, the normal route taken by those trying hard to follow the spirit of semantic HTML5, which is admirable. But it can be a quagmire that makes you begin to ask exactly who you're maintaining your semantic purity for? Is it for the search engines, the screen readers, or ease of maintenance? I'll get back to this after the next classification.
Some are pragmatic rationalizations that claim to be equivalent semantically but are, in truth, a different semantic meaning. These are really semantic hacking in my opinion. #volker-e 's answer is an instance of this. He's right, this is an alternative markup that could work -- but, it doesn't equal the same semantic meaning. The h2 belongs in main as an h1 -- it makes no sense to move it within the page's header. In fact, you're saying that your heading is unrelated to your main content. This, in some ways, is worse than using that div you wanted to use, because you're making a false semantic relationship by grouping the page-header and site-header into the same semantically-significant header. A semantically meaningless container, such as div, for both header and main, is actually less perverse in my opinion.
So, getting back to what I said about who you're maintaining semantic purity for, this is the real philosophical question at play. There is often an obvious, effective, and maintainable solution without rationalized mis-uses of existing semantic elements or css 'tricks'. In your case, of having an item which is semantically a child but presentionally not a child, the answer is the one you've already put forth as a question:
Rewrite the HTML5 markup with non-semantic elements (e.g. divs) so
that it corresponds more to the visual layout and then exchange the
non-semantic elements by[sic] semantic ones (e.g. footer or main) wherever
possible with the new structure.
This is the right thing to do whether you're semantic-purity was intended for
accessibility: in this case you can achieve that in a non-hierarchical way with ARIA roles.
search engines: search engines still understand the old way to do things, so you're not going to get into SEO trouble if you follow older approaches to semantics.
maintenance: this is the reason most people are lured in by -- but the problem is, what's the point of maintainable HTML but unmaintainable CSS, or the other way around? you have no choice but to see your maintenance as a combination of both CSS and HTML, and you have to find the middle ground where they are both deranged equally when you run into a difficult presentational problem.
The only other possible answer, if you feel that HTML semantics are all that matter, is to accept the limitations that hierarchical HTML semantics places on your layout. The problem is, there is no way in CSS to re-create the layout hierarchy. Until that happens, you'll have to accept that HTML is both a presentational and a semantic language, and, therefore, semantics will always be a matter of "better" and "worse". Truly beautiful or rich or perfect semantics will be unachievable in many, if not most, layouts.
My approach would be the following:
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Title</title>
</head>
<body>
<a class="aural" href="#content">Jump to content</a>
<header role="banner">
<h1 class="site-logo">Logo</h1>
<nav role="navigation" aria-labelledby="nav-heading">
<h6 id="nav-heading">Navigation</h6>
<ul>…</ul>
</nav>
<h2 id="heading">Page heading</h2>
</header>
<main id="content" role="main" aria-labelledby="heading">
Page content
</main>
<footer role="contentinfo">
Content information
</footer>
</body>
</html>
and then go for a CSS ruleset like:
header h1,
header h2,
header nav {
float: right;
}
Diff:
You have appropriate accessible headings for page's content
You save otherwise seemingly useless div in header & main
You've got a nice HTML5 structure outline, which helps SEO.
I've included (was not part of the question) the navigational landmark roles as of WAI-ARIA 1.0 draft specification
I've included a skip link, which is still recommended best practice
Minor change: I know, charset value case is insensitive, but as you also write DOCTYPE uppercase, UTF-8 is the more correct value, see http://en.wikipedia.org/wiki/UTF-8#Official_name_and_variants
The first structure may still work if there is position:relative in < main > and using position:absolute on h1 with a z-index and a -ve margin. That way, the heading will always float on top in the same position in relation to the main content. While it may not be the best solution, I think it will not break the layout (?)
I'm referring to a main menu and a smaller supermenu (don't know the proper term), as seen here:
For something like this, I was going to put two <nav> elements in the <header>. Is there any reason (SEO or otherwise) that this is a bad idea? If so, what would an alternative be?
(this is different from multiple <nav> tags, which referred to multiple on an entire page, not in a single block element)
Short answer: no there is not (probably)
Longer answer: the HTML5 spec itself is a bit fluffy on the subject:
http://dev.w3.org/html5/spec/Overview.html#the-nav-element
The thing is that they designate the <nav> element to 'major' navigation blocks, but leave it to the imagination (of both developers and parsers) what that means. As you can see they even provided an example where they exclude the "site-wide" from the navigation block.
<body itemscope itemtype="http://schema.org/Blog">
<header>
<h1>Wake up sheeple!</h1>
<p>News -
Blog -
Forums</p>
<p>Last Modified: <span itemprop="dateModified">2009-04-01</span></p>
<nav>
<h1>Navigation</h1>
<ul>
<li>Index of all articles</li>
<li>Things sheeple need to wake up for today</li>
<li>Sheeple we have managed to wake</li>
</ul>
</nav>
</header>
They seem to do that because they consider limiting the number of links in nav elements a plus for readability (think screen readers etc).
It is probably a bit too early to know what the search engines are going to do, but it seems safe to think that they will attach more importance to nav element links to detect the structure of you site and maybe more so if you have less of them...
My impression: Twitter and Facebook links seem certainly out, support and blog are debatable
I think it does not matter. NAV element just marks functional role of some content. So if you have two separate navigation blocks (regardless of where it's placed: in header or in other parts of page), you are free to use separate NAV elements for them. Some "penalties" from search engines in that case would be pointless.
Nav can be used multiple times on a page in HTML5.
CAN…yes
SHOULD…probably not.
I’ve always worked on the basis that the NAV tag is only for the primary page/site navigations.
If my main (header) navigation area is used for the [nav] then any other menus can be in divs with some role for ARIA.
Are any of these method good to use to keep the website compatible in all browser while using HTML 5 elements?
Just for example
method 1
<div class="section">
<section>
<h1>title</h1>
<p>text</p>
</section>
</div>
method 2
<section>
<div class="section">
<h1>title</h1>
<p>text</p>
</div>
</section>
In above method I will not write any CSS for HTML 5 tags so layout will not be disturbed.
Edit: my question is specially for Mobile websites because in desktop websites I know I can use HTML 5 Shiv and Modernizer but in mobile still my browser are still in use which don't have support or partial support of JavaScript. and Bandwidth is also an important issue in mobile internet so adding a JavaScript will decrease the performance.
I'm making website for mobile with content management system to update content in future and content will be updated by client using WYSIWYG Editor.
A better way would be to use the HTML5 tags as usual and include the HTML5 Shim by Remy Sharp.
Although semantically both the methods are same, I'd go with method-1 as it correctly separates content from container. (OOCSS principle)
<section>
<h1>title</h1>
<p>text</p>
</section>
This is the content. It represents a section of a document and is meaningful. You can now enclose this in a container (<div>) and style it as per your requirements.
Also, you'd realise that method-1 is more flexible when used in large websites
Personally, I use an HTML reset, use Modernizer to check for features, then shim in things:
if( Modernizr.fontface) {}, Modernizr.canvas, Modernizr.audio, etc.
This is good: http://bit.ly/b5HV1x
By HTML 5 reset, you can define the tags not understood by browsers:
footer { display:block; }
I don't think either of those methods are any good. <section /> should be used for any "section" of the markup that doesn't have a specific tag like <header /> or <article />. <div /> should be still used for layout purposes.