Hi guys, I’m starting to learn HTML5 in my sch now. But yea… my lecturer suck at explaining.
just wondering if div container still relevant? for exmaple code 1 vs code 2, which one is recommended way of coding it and why?
<nav id="navigation">
<ul>
<li>link1</li>
<li>link2</li>
</ul>
</nav>
VERUS THIS
<div id="navigation">
<nav>
<ul>
<li>link1</li>
<li>link2</li>
</ul>
</nav>
</div>
[font=verdana]In that particular case, I’m struggling to see a reason for including the <div>, unless you need it as an extra styling hook (given that we can’t yet rely on multiple backgrounds working). This is a perfect example of divitis – just putting <div>s in for the sake of it, when they don’t do anything and aren’t needed.
On the other hand, there are plenty of cases where a <div> will still be needed in HTML5, where there is no suitable alternative container to use.[/font]
As Stevie said, unless there is a really good reason for extra hooks, all you need is
<ul>
<li>link1</li>
<li>link2</li>
</ul>
Both the <div> and the <nav> are pointless—at least at this stage, where nav basically adds nothing of value. (Maybe one day it will provide useful semantics to some devices, but I don’t think it does yet.)
well, after some researching, nav seems pointless but actually it is useful. It somehow tell your browser which portion they are looking. Not sure what is the benefit though. And yes, div is actually no point to put.
Thanks guys!
I thought nav was good for screen-readers and such stuff. No? Let the blind know that the following list of links is for navigating the site?
But anyway, in the OP second example, there’s a redundancy to have the nav inside the div, because the nav functions as a div itself already. It’s just putting one div inside another div, when structurally, given the first example, all that’s necessary is one div. It’d be like drawing a square, and then drawing a second square with the exact same position and dimensions on top of the first one, and when someone looks at it and thinks it’s one square, you insist no no no, it’s two squares with the same dimensions and position. If it acts like one div, looks like one div, you don’t need a nav and a div. Choose one or the other.
But as a general question, I think divs are still relevant. Just not for nav, because nav is it’s own div now.
Maybe one day, but not yet. HTML5 isn’t finished yet, so it will be a while before user agents take it really seriously … so we have years to wait.
When I’m looking at an html doc, I prefer to see <nav> than <div id=“nav”> though, regardless of screen readers.
And how do you feel whan you see <[COLOR="#FF0000"]ul[/COLOR] id="nav">? That is, proper code. 
I feel fine about that as well, but I think for many people, their vision for their site is translated more readily into creating a new div/nav before putting a <ul> in there. I know I visually think in divs.
It’s worth knowing at least that it’s completely unnecessary. A <ul> is a block level element around your <li>s, so nothing else is needed. If you want extra semantics for assistive technologies, you can currently add role="navigation":
<ul role="navigation">
When I’m looking at an html doc, I prefer to see <nav> than <div id=“nav”> though, regardless of screen readers.
This usage of <nav> is fine. Ralph is saying that those tags don’t add any practical value to browsers or users yet.
If you prefer seeing things like <nav> <section> and <article> it’s fine to start using them.
I’ve found that the different tags do make them stick out in the HTML so it can help readability of the code, that’s the only real benefit of the tags though at this stage.
Not disagreeing with you, although I mostly look at code via browser inspectors, where the fewer nested elements, the easier it is to read and study code. Endless nesting of divs and other elements is a real pain.
Someone from one of the WG’s posted a screenshot (of view-source) of some site on twitter. It was divitis, except made of <section> tags. It was lawlz.
Sectionitis sounds like a more serious disease though. Prolly gives you cancer.
Doesn’t quite roll off the tongue like “divitis”, but prolly a word we will have to get used to. There seems to be a tendency to use more sections that there would have been divs, often, which is going to prove a nightmare for stylings. I found myself having to help a member the otter day with something like section section section section.class. 
(I wonder if this is what the Mayans meant by the end of the world.)
Unless you still need to support IE8…
Of course, there are JS libs that can make IE8 recognize those new markup elements, but that brings us back to “no practical value.”
Yeah just the other day I realised this doesn’t work (looking up syntax did not tell me anything, because they did not actually post real syntax, only an example of code… this was the one time where I would have rather seen syntax):
document.createElement(header,nav,aside,footer);
This’ll create “header” but not the others. No, each has to be listed separately.
document.createElement(header);document.createElement(nav);document.createElement(aside);document.createElement(footer);
Then you have to display: block them.
Then you have something. Something browsers still see as spans styled like blocks. The only software I know of who’s even started seeing any meaning in the new tags yet are some screen readers, and they’re still working on that (basically, a “nav” element will get an intrinsic role of “navigation” so the screen reader is reading the browser’s output to AT when the browser tells the AT about the element.
Steve Faulkner recently posted a screen shot of some info given to AT about an element (this is an example of a proposed new element, <main>):
For me, this is the only value these new tags give us. Well, that and also some more freedom with styling and Javascript.