HTML5 tags and CSS

[CChawps]

I was just wondering if it would be worth using the new <nav> tag for horizontal
navigation panes, instead of aligning it in the right way using CSS. Is it even possible?

Concerning two other tags, <header> and <footer>. If I were to create an 800px centered
layout for my website, would it then be possible to use these tags, instead of using <div>?

And! I can't seem too grasp what the <aside> tag actually does...?

Then again, is this all meaningless? Should I just go with <div> and CSS?

[jscheuer1]

It seems that some of the members here already have some experience with these new tags. I have very little. But as long as you use an HTML 5 DOCTYPE, they should work as advertised in most browsers.

I would also note that there is no "right way using css". If you go down that route you must make sure to use valid code, with at least a general understanding of what it's doing, and test in your target browsers. Same as when using the nav or any new HTML 5 tag.

[CChawps]

Well, of course I've read about what each tag actually does. <header> and <footer> defines the header and footer area. But instead I could just use a div with an id <div id="header"> to define the area. I just don't understand it :P then again I think that tags like <nav> are smart, and can make the progress of creating a website even more simple. I also think that HTML5 is a brilliant approach too decrease the use of third party applications like flash and java, when so many people nowadays use mobile devices too access the internet.

[traq]

I was just wondering if it would be worth using the new <nav> tag for horizontal
navigation panes, instead of aligning it in the right way using CSS. Is it even possible?

new html5 tags don't have any "magic" functionality. they don't replace or compete with css; they add on to html. The only difference in html markup right now would be, instead of using <div id="nav">, you'd use <nav>. your css rules would need to use nav{} instead of #nav{}.

As browsers update, they will likely include some default styling for them, much like they currently give default padding, margins, line-height, sometimes text-indent, etc. etc., to <p> or <div>.

Other than that, the can be thought of as "specialized" <div> elements. Most modern browsers will recognize them, but you will need to define "display: block" in your css. Internet Explorer is the exception: IE < 9 will ignore the unknown elements unless tricked into recognizing them via javascript. So, at this point, it's a little extra work to use them, and widespread benefits will come a little later.

however, the benefits of html5 have little to do with the new elements. they'll be great for DOM parsers, eventually, but that will only benefit the people who are aware enough of the DOM to care (so, javascript gurus, like you, John, will come to love it because it has the potential to make your DOM completely predictable across browsers).

[jscheuer1]

I already love HTML 5. It's so much simpler and cleaner if you want and use it that way. And it also has new possibilities for complexity and nuance, enabling it to deliver a richer web experience.

I hadn't realized that the new tags were unsupported in IE < 9. Looking at the IE developer tools, the earlier IE take them to be self-closing tags incapable of containing anything. So I guess unless you want to do some conditional comment gymnastics, they're out if you want to support those older IE browsers.

They do provide superior organization where supported.

[djr33]

I'd prefer a more abstracted form of HTML rather than a tutorial-esque "let me do that for you" approach given by <nav> and elements like that. HTML should be moving away from expected forms and toward flexibility-- abstraction. This is shown by <strong> instead of <b>. I used to hate that (and I still don't love typing the extra letters), but it makes sense because it allows more freedom and more compatibility.

This is the same complaint I have about Macs. I love apple, or at least I used to. The first versions of iMovie, for example, were great, at least for basic projects. But now they attempt to "help" (read "limit what you can do") by adding one-button-does-it-all and other such features.


Does this mean that moving forward HTML will become a standardized format so that all webpages have <nav>, <content>, <header>, <footer> and whatever else they are supposed to have? Isn't the utility of HTML based in its flexibility??

Now I do realize that <div> will still exist. But it seems that these other elements may be preferred out of laziness (sometimes laziness, anyway), and people still start asking questions like "I used <nav>, but it doesn't look like the nav menu I imagined... what's wrong?".

On the other hand, I'm excited about the actual improvements of HTML5 such as <audio> and other tags that have been lacking for a while. It will of course take a long time for the browsers to catch up, but having additional features will be very helpful.

[traq]

the biggest thing I worry about with the new elements is css styling - it's just thirty more sets of rules that we'll need to include in our base css to limit cross-browser styling oddities. but we'll always have that anyway... : )

beyond that, there is what most people don't see (and never will): it's the processing model. The biggest part of html5, by far, is how it defines how _everything_ should be handled. everyone gets the same dom. even if the markup is invalid, it should be wrong in exactly the same way in all browsers. <nav>, etc., is also an attempt to give browsers a better idea of the actual content of the document, rather than just generic blocks. Basically, using <nav> instead of <div> is just the same as using <p> instead of <div>.

BTW, <b>, like <i>, is still valid in html5, but it has a different meaning/application than <strong>.

@John - yeah, it just closes them as soon as it sees them, and the content is left to run free. It ends up looking a lot like if your css was simply turned off (since IE ignores the elements you were styling). You can use a javascript solution - basically, document.createElement('nav');, and then it works. There's also htc -based solutions (which are more complex), and xhtml solutions (which, although it "works", makes even less sense to me than ignoring the problem).