So in the past I'd use a basic page structure like this:
HTML Code:
<body><div id="header">This is the header</div><div id="nav">....</div><div id="main">The is the main content of the page.</div><div id="footer">...</div></body>
So in moving to HTML5 we all know how to handle the header, nav and footer parts, but what about the "main" part? Would you use
I'm not using the semantic tags yet -- they don't add much value in my opinion. In any case, this examples under the nav element over at the W3C site may answer your question:
I'm not using the semantic tags yet -- they don't add much value in my opinion. In any case, this examples under the nav element over at the W3C site may answer your question:
Yeah two good points. 1) I wouldn't switch TOO quick to HTML5 tags unless you're fully prepared for the browser incompatibility and 2) All of the HTML5 apps I have seen use <divs> widely since they are still supported in the specs
Yeah two good points. 1) I wouldn't switch TOO quick to HTML5 tags unless you're fully prepared for the browser incompatibility and 2) All of the HTML5 apps I have seen use <divs> widely since they are still supported in the specs
I noticed apple.com uses <nav>. So I wonder if Apple doesn't care about the browsers that don't support that element or do they somehow serve those browsers different HTML.
Using HTML5 tags is fine as long as you include this little script for non-complying (primarily IE ver. < 9) browsers: <script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
Just add this code into between the <head></head> tags:
The <div> vs. <section> argument is all over the Web, but the simple rule of thumb is:
If the content you are wrapping has a header title, then <section> can be used. For a simple content container, <div> should be used. Notice that I used the word "can" for the section, since you could just as well enclosed the whole thing in a container <div> and then used a <section> or <article> element with a header title inside the enclosing <div>. There are several ways of coding in HTML5, so don't get stuck on details too much.
Using HTML5 tags is fine as long as you include this little script for non-complying (primarily IE ver. < 9) browsers: <script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
I understand the shiv but was wondering what the attitude was about the small % or browsers that don't support it (old IE w/o JS). I looked at apple.com with an HTML5 disabled browser and the site is functional but the nav is devoid of styles, just plain text links on the left side of the page. So Apple's attitude is like "the site will look weird but will be functional without JavaScript".
Originally Posted by WebWarrior
The <div> vs. <section> argument is all over the Web, but the simple rule of thumb is:
If the content you are wrapping has a header title, then <section> can be used. For a simple content container, <div> should be used. Notice that I used the word "can" for the section, since you could just as well enclosed the whole thing in a container <div> and then used a <section> or <article> element with a header title inside the enclosing <div>. There are several ways of coding in HTML5, so don't get stuck on details too much.
Thanks for that. At this point I'm going with the traditional <div id="main"> convention, since there is just one of those per page and <section> implies it's possibly one of many.
I might get some heat for this from HTML pedants out there, but I seldom care for the small % of users that don't have JS. Honestly, this is 2012 and everyone wants to enjoy the Web 2.0 features, so it's unlikely that you'll run into too many of users w/out JS.
Why? I tend to give unique elements unique names, and use class as rarely as possible in the hope that I can avoid it.
Well, I'm not a purist in the matter -- and I couldn't produce the link to the article off-hand -- but, it's a matter of transfer size, efficiency, and consistency.
By re-using styles throughout a site, you decrease the size of your stylesheet, introduce consistency, and reduce site-rendering time (mainly b/c your stylesheet is transfered, interpreted, and cached more quickly). Facebook was actually one of the leading examples in the article (which I'm sorry I don't have a link to): by ditching ID's they were able to eliminate a lot of similar rules and shrink their stylesheet(s) by like 90%.
Not that you'll never have a reason to apply a style to one and only one element, but even in those cases, you could just as easily create a classname and add it to the list of classes on the nod. And then you can re-use the style! You're not writing a line of code that applies ONLY to element X.
Ideally, you'd create a set of "components" that fit together and pull from a set of standard styles to ensure you don't unnecessarily end up with tens of thousands of lines of CSS.
You might, for instance, have some coloration styles, positioning styles, spacing styles ... and then you build re-usable components using the appropriate classes and/or tag hierarchies. Much more efficient than writing a style that applies to node X and then another similar rule to also apply to nodes Y and Z.
Why? I tend to give unique elements unique names, and use class as rarely as possible in the hope that I can avoid it.
Matter of style really. I personally use class for all styling purposes and use ID only for DOM. One must keep in mind that ID has more "weight" than class when it comes to applying styles. This can prevent from some CSS classes applied on elements inside the container from working properly.
...
Ideally, you'd create a set of "components" that fit together and pull from a set of standard styles to ensure you don't unnecessarily end up with tens of thousands of lines of CSS.
You might, for instance, have some coloration styles, positioning styles, spacing styles ... and then you build re-usable components using the appropriate classes and/or tag hierarchies. Much more efficient than writing a style that applies to node X and then another similar rule to also apply to nodes Y and Z.
I like to use it. I recall using it in a case of a layout where a small sidebar appeared on the left on some pages, while a larger sidebar appeared on the right on others. A simpler example is to use it on buttons. Create a generic button style with common properties and then create specialized versions .button.cancel, .button.publish, etc...
Bookmarks