HTML5 Reset

  • Started
  • Last post
  • 17 Responses
  • ukit0

    This was what I was imagining

    <html>
    <head></head>
    <body>
    <header></header>
    <nav></nav>
    <section>Stuff</section>
    <section>Stuff</section>
    <footer></footer>
    </body>
    </html>

  • pastpastdue0

    I think that's right. On my new portfolio site, <section> is the tag that contains different areas of the site. I was trying to figure out a system that would work across as many sites as possible. I realize there is semantic redundancy but I needed a container element. Basically:

    <section id="header">
    <h1>logo replacement</h1>
    <nav></nav>
    </section>
    <section id="content">
    <article></article>
    </section>
    <section id="footer">
    <footer></footer>
    </section>

    • I suppose this could all be done by a single div, in retrospect.pastpastdue
  • acescence0

    ^ the header section should be replaced with <header>. I think section encapsulating footer is redundant. they're really all the same though, header, footer, and article are just more specific sections

  • acescence0

    if you need to encapsulate something for the purpose of styling, then divs should be used.

    • Right, exactly what they say in the link belowukit
  • ukit0

    After reading the spec I walked away with the idea that <section> should not just be a universal container like <div>, but that they want you to use it for actual content.

    http://dev.w3.org/html5/spec/Ove…

    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.

    Examples of sections would be chapters, the various tabbed pages in a tabbed dialog box, or the numbered sections of a thesis. A Web site's home page could be split into sections for an introduction, news items, and contact information.

    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.

  • pastpastdue0

    I don't know why I didn't use <header>. It's been a few months since I've touched it and it was really my first foray into HTML5, and my personal site was the best place to start to figure out semantics.

    I used http://diveintohtml5.org/semanti… as a resource, clearly I misunderstood. It definitely isn't specific as to use for the section tag, so I used it liberally.

    Glad someone could clear it up. I will hopefully get around to reading the specs sooner rather than later.

  • pastpastdue0

    So, I guess to answer your question ukit (and hopefully you will agree,) this would be the proper usage, no?

    <html>
    <head></head>
    <body>
    <header></header>
    <nav></nav>
    <article>
    <h1>Article title</h1>
    <p>Synopsis or some shit</p>
    <section>
    <h2>Section Title</h2>
    <p>Content</p>
    </section>
    <section>
    <h2>Section Title</h2>
    <p>Content</p>
    </section>
    </article>
    <footer></footer>
    </body>
    </html>

  • ukit0

    Yes, I think so! At least, it makes the most sense to me.

    Let's face it, it's not like they make it easy to understand, is it? It's about as clear as the box object model...

    • Not to mention, for example. newspapers have a section and articles within a section, which is where my logic came from.pastpastdue
    • Well, no one said you couldn't put articles inside a section and have it also contain them right?;)ukit
    • This is fun, I can just sense the massive clusterfuck that is about to ensue as people argue over the proper use of these elements;)ukit
    • these new elements;)ukit
  • pastpastdue0

    @ukit

    I dunno. It's just interesting. It's all semantics – what better tags could be used? Sections, to me, just seem more correct as an area of a site, not an area within an article. It seemed like a content region within a site. But what better tag could have been used? They both make sense and the documentation clearly defines it as used correctly in my post above.

    It's also confusing to define things within both a <head> and a <header>, if you ask me. They're revamping semantics anyway, why not have the <head> be something more semantically correct? <include> would have been a better way to tackle that, I think. I have a lot of qualms with the structure of HTML as it is, but really can't offer a better solution.

    Personally, I don't think HTML5 is semantically sound enough. In terms of accessibility, it's to the point where anyone should be able to approach html with relative ease. I think it *needs* to be, given technology now. But when you have people who (I assume) are using it every day debating semantics, clearly there needs to be a few more rounds of revisions. And that sucks.

  • ukit0

    You know what I don't think it's as bad as I was making it out to be. You can quibble with the naming, and I'm not crazy about it, but the structure is hard to argue with.

    The trouble is that right now the people who write tutorials and come up with best practices for this stuff haven't really had a chance to delve into it, because the browser implementations are just now arriving. Imagine if you had to learn even the original HTML4 just from the spec and one or two articles;) I think once the people who are good at articulating this stuff have the write ups and tutorials ready it won't seem so hard to "get."

    • I mean, look at that Dive Into HTML5 site. He does a great job with most of it, but the descriptions of the elements are pretty much copy and pasted from the spec, and don't really make it easy to understand in plain English.ukit
    • pretty much copy and pasted from the spec, and don't really make it easy to understand in terms of practical usage.ukit
  • ukit0

    Another thing to keep in mind, none of this is required to write HTML5. You're welcome to keep on writing HTML the same way you always did and simply adopting the HTML5 doctype, although I imagine adding the <header> and <nav> stuff in would be pretty easy.

    Eventually I imagine using <article> and <section> correctly will become important for SEO, and you can imagine some pretty cool applications in terms of data mashup or restyling once you have information marked up on such a granular level.

  • Stugoo0

    I read this on the way into work and haven't really looked at the links in detail, but if you want to argue about semantics I recommend having a read of a book apart.
    It does a really great job on how to look at semantic ordering of code.
    The great thing about html5 (possibly bad too) is that its really loose in its semantics but its about how you order the code is how you indent on what it really means. As oppose to xhtml its a very literal _this is what you must do_

  • ukit0

    It's ironic that considering it's the "HTML5 reset" they didn't include any HTML5 elements in the reset part, wonder why?

  • pastpastdue0

    Also, why is the screen shot the Meyer reset?

  • lukus_W0

    I don't understand.

  • ukit0

    Well, it makes sense in theory. Update the CSS reset for HTML5. And they do give you an outline of an HTML5 doc, which is nice, and includes for IE, which is nice. I would probably bundle more stuff in my "HTML5 reset" though. What about some sort of JS progressive enhancement like the Modernizr script? Also, they have stylesheets for print, but what about mobile?

    • I think it's nicer to find out what works, rather than get a packaged work-flow from someone else.lukus_W
    • Also agree about Modenizr .. that seems essential for HTML5.lukus_W
    • Well, let's face it, they owned the domain and wanted some hits;)ukit
    • It is a nice looking siteukit
  • ukit0

    Something I am also wondering about is the use of the <section> element. Is it really supposed to wrap around an entire document like that??

    The way the spec explains it, <section> is supposed to be the content equivalent of a single Table of Contents item (bullet point) like you see at the top of a Wikipedia page.