Help with HTML Structure/DOM

So basically I have a page with the following structure (using “HTML5” elements). What I need is clarification on if this is acceptable usage of elements. If not guidance in the right direction.
Thanks much.

		<meta charset="utf-8">
		<link href="lbcstyle.css" rel="stylesheet" type="text/css">
		<link href='' rel='stylesheet' type='text/css'>
		<link href='' rel='stylesheet' type='text/css'>
		<?php include "kd_obj/lbcfunc.php";?>
                        <!--[if lte IE 8]>
			<script type="text/javascript">
			// HTML 5 entities for IE.
	<section class=layout>
		<header><h1 id=pgtitle>Lorem Ipsum Dollar</h1><p id=pgsubtitle>Lorem Ipsum Dollar</p></header>
		<nav> <?php lbc_nav(); ?> </nav>
		<aside class=bible>
			<p class=scripture>
			<?php lbc_scripture(); ?>
			<h1>Lorem ipsum dolor</h1>
			Lorem ipsum dolor sit amet, consectetur adipiscing elit.
			<h1>Lorem ipsum dolor</h1>
			Lorem ipsum dolor sit amet, consectetur adipiscing elit.
			<h1>Lorem ipsum dolor</h1>
			Lorem ipsum dolor sit amet, consectetur adipiscing elit.
			<p>This website makes extensive use of new web based technologies and coding.
			<br>We recomend that you make sure you are running the 
			<a href=#>latest version</a> of your current web browser. </p>
			<p id=copyright> &copy; 2011 Lorem ipsum dolor || [email][/email] </p>

It would be more helpful if you could post the actual generated source code (ie, what shows up when you go to the page and click “View source”) rather than the raw code with all the PHP stuff in there … because we can’t tell what the end result will look like until you do that.

A few suggestions:

[list][]your <article> text should be in <p>aragraph tags.
]I don’t see any need for the wrapping <section> element, unless it is required as a CSS hook.
[]No need for any classes within the <header> element.
]I still find it helpful to use the appropriate <h*> element rather than tagging everything as <h1> and letting the DOM sort out the hierarchy, it helps you to think about what the actual heading levels are.
[*]Rather than using <hr>, you’re generally better off using CSS borders.[/list]

I still find it helpful to use the appropriate <h*> element rather than tagging everything as <h1> and letting the DOM sort out the hierarchy, it helps you to think about what the actual heading levels are.

While I’d usually agree, with HTML5, in a browser that properly understands it, those h1’s are ok, because the browser builds a document structure based on those articles and their nesting levels, rather than blindly using the level of that header. A non-HTML5 browser will not, since it will treat the page like HTLM4. But, you can check your document structure at


Well, no, I take that back: BECAUSE no browsers properly implement the document structuring HTML5 prescribes (unless you use Javascript to fake it, see here
[noparse][/noparse]) using multiple h1’s TODAY will be trouble for some (many) screen reader users and other users of UAs and technology that uses headers for navigation or figuring out document structure (googlebots possibly as well). So okay, I still agree with StevieD : )

But if you’re asking a theoretical question of, is this ok? I agree with StevieD that the loose text in the <article>s belong in p’s, but for the rest, it seems ok.

However, since you have Lorem Ipsum in your <article>s, we can’t tell if how you’ve structured your markup is actually correct. It’s theoretically correct, but if there are various types of relationships between those <article>s and the <aside>, your nesting structure may be incorrect.

I guess with the way HTML5 means to change document structure/outlining compared to HTML4, the Lorem Ipsum text will really not be of any help in setting up HTML documents (not that it’s any good for HTML4 really).

Read more about the trouble/complexity of HTML5 structure at
The second h3 heading “Making simple concepts complex” describes the issue with headings and mixed nesting.

The advantage of using header-levels that start anew per article? Ideally, in the utopian future of HTML5-goodness, you’d be able to syndicate your articles, have them plugged into some other page, and the heading structure wouldn’t have to change.

So you presented a page with multiple, separate, standalone articles (like a Wordpress home page). Each one labels its own main header with an H1. If you move that article over to its own page, it’s still and H1. If you move that article over onto some other site where its already got its own set of headers, it’s still an H1 (header of your article content).

I don’t know if that will really work all that swimmingly once people start actually doing that… I can see finding the true document structure of each page the article is found on getting harder for users who rely on that. But we’ll see.

You probably mean the new <hgroup> in HTML5 that makes a doc outline understandable even with multiple h1 in it.

Thanks for that. So pretty much just several small tweaks.

The section element is indeed required for a css hook.

I have no problems with using <h1> for the first article, then <h2>, <h3>, <h4>. Generally Most pages will only contain one article.

For clarification, to style the paragraph in the header I would use the following?:

header p{attrib:value;}

Thanks for the intelligible feedback. Should be easy for me to polish the structure before I start adding content.

hgroup is slowly losing the war, man. It may be out of the spec.

hgroup was meant for when people think a tagline is supposed to be a header, so they do something like this
<h1>Moldy Duck-bread</h1>
<h2>That’s some mighty fine bread!</h2>

For some reason, wrapping an hgroup around those was seen as a good idea.

But the document outline I’m talking about is more general: how a supposedly-fully-HTML5-browser would render an outline of the document, based on the nesting of sections and articles and stuff.

Hey poes,

Not clear about the “real” outline, but…

I’m looking at both latest specs and see none of which you mention: out of the specs:

HTML Standard

This sounds good to me:

The hgroup element represents the heading of a section. The element is used to group a set of h1–h6 elements when the heading has multiple levels, such as subheadings, alternative titles, or taglines.

For the purposes of document summaries, outlines, and the like, the text of hgroup elements is defined to be the text of the highest ranked h1–h6 element descendant of the hgroup element, if there are any such elements, and the first such element if there are multiple elements with that rank. If there are no such elements, then the text of the hgroup element is the empty string.

and it defines the purpose for hgroup far beyond just grouping a tagline with a heading.

Not clear about the “real” outline, but…

Were my links unclear? (yes they’re unclickable but that’s me fighting the SEOman)

Maybe they were, so here are some more:

MDC explaining specifically the outline algorithm:

I first heard of this “new outline” thing in Bruce and Remy’s HTML5 book, where they claimed this was something new (not in HTML4) so it’s fairly new to me as well. They also stated in that book that no browser currently supports this. So, may be a moot point for now.

Also [noparse][/noparse], so I’m keeping an eye on that one.

I was looking only at post #6. No links there. :slight_smile:

Once again, looking at the specs, there is no sign of weaker support for hgroup. W3C talk the talk in wiki, but they don’t walk the walk in specs. As for WHATWG, even more, they seem to thing the spec, which also contains hgroup, is a done deal.

One unintended pun I guess:

hgroup should be removed from the spec until issues around it have been resolved

Since HTML5 and/or Fred are issues by them self, applying the same rules, we should remove their specs/drafts completely. :lol:

It probably cannot be removed because it would contradict their own idea of a living model. Thus if any browsers have adopted it in some form they’ll have to undo things, which is kind of backwards.

Hey Robert,

Yes, WHATWG seem to have embraced hgroup already.

W3C are not showing any signs of weaker support for hgroup either.

No “clear in context warning” in their latest spec: HTML5

A vocabulary and associated APIs for HTML and XHTML
W3C Working Draft 05 April 2011

Since HTML5 and/or Fred are issues by them self, applying the same rules, we should remove their specs/drafts completely.


I’m mostly following some of the guys involved in HTML5… in particular Bruce Lawson has changed his mind [about hgroup] and is now one of those kinda pushing to get it removed. The WHATWG guys are kinda of two minds: on the one hand, they want to add more semantic tags to HTML to make up for the lack they see in the HTML4 tags… on the other hand, they want to remove stuff they believe is redundant, broken, badly implemented, or just never used. Since browsers are going to support those things regardless, I’m not entirely sure why, but I guess it’s admirable. But so if a new tag gets questioned, they look to see if it’s really needed and debate whether it will stay in the spec.

There’s some kind of deadline around 2014 for something, I’m not sure what: a stable “base” spec maybe.

Ten or more years after the final deadline usually; so if you guess 2014 that’s 2024 at the earliest.

Okay the hgroup stuff, my fault, is off-topic.

Guess that useless twitter is good for something, huh.

That link would be

(no point in telling where you’re going with that swishy cunning redirect)[/ot]