Quick Question on Semantic HTML5 Structure (sections & articles)

HTML & CSS
1

So im laying out a services page for a website (general service information), and there are a few primary services, and a larger number of secondary services (with the majority of those, less important than the minority).

My question is, Which way is best to structure the HTML code that contains this information?

This is what I have so far:

[INDENT]header
[/INDENT]

[INDENT=2]logo
nav[/INDENT]

[INDENT]
div #main
[/INDENT]

[INDENT=2]section
[/INDENT]

[INDENT=3]h1 - service one title
p[/INDENT]

[INDENT=2]
section
[/INDENT]

[INDENT=3]h1 - service two title
p[/INDENT]

[INDENT=2]
section
[/INDENT]

[INDENT=3]h1 - service three title
p[/INDENT]

[INDENT=2][SIZE=1]

section .secondaryservices

[/SIZE][/INDENT]

article

[INDENT=4]h2 - secondary service one title (ie: service four)
p[/INDENT]

[INDENT=3]
article
[/INDENT]

[INDENT=4][SIZE=1]h2 - secondary service two title (ie: service five)
p

[/SIZE][/INDENT]

[INDENT=3][/INDENT]

[INDENT=2][SIZE=1]section .tertiaryservices

[/SIZE][/INDENT]

[INDENT=3] article
[/INDENT]

[INDENT=4]h3 - tertiary service one title (ie: service six)
p
[/INDENT]

[INDENT=3]article
[/INDENT]

[INDENT=4]h3 - tertiary service two title (ie: service seven)
p
[/INDENT]

[INDENT=2]
[/INDENT]

[INDENT=2][INDENT]article
[/INDENT]

[INDENT=2]h3 - tertiary service three title (ie: service eight)
p[/INDENT]
[/INDENT]

[INDENT]
[INDENT=2]article
[/INDENT]

[INDENT=3]h3 - tertiary service four title (ie: service nine)
p
[/INDENT]
footer
[/INDENT]

Now, is this correct?

Or should each of the Primary Services (ie the top three sections), have a single article inside them too? …to hold the service information? Matching the layout/structure of the secondary and tertiary services

Is an article always needed, or is it oay to sometimes place content inside just a section? If so, when? As per above?

I know this is probably a small matter, and may not matter to most, but im really quite into making sure things are done as correctly as possible, and still adjusting to HTML5 from HTML4/XHTML so would appreciate any advice.

Thanks guys!

2

Why use html5 elements?

For one thing, it won’t work properly in all browsers and html5 is still in draft mode and will be for quite a few years yet.

Imo, a definition list is what you need to semantically markup your information.

3

I’m not sure its a case of a dl, but certainly the use of all those sections and articles seems of dubious worth. This seems like a straight out job for titles and paragraphs to me. This page would be perfect with an H1 at the top, h2s for sub titles and h3s for further sub titles.

As for the HTML5, There doesn’t seem to be a reason for those first three sections. What makes them sections? Presumably the whole point of HTML5 would be that #main is a section itself. Those articles also really don’t seem like articles. The idea of articles was that the content could be extracted and stand on its own … meaning that it ideally would be headed by an H1.

HTML5 is going to provide fun times ahead … as the roles of the new elements are pretty vague. As tunnil says, there is no advantage in trying to use HTML5 at this stage … if ever.

4

I would use a <dl> for each group of services (primary, secondary, tertiary)

The <dt> would contain the service title and the <dd> the service description. You can then style the <dt>s and <dd>s to suit their function.

Above each <dl> you could have a <hx> header

5

No, there are no such rules, always use articles inside sections.
On the other hand, you don’t start from here: place content. You thematically group content into sections.

<hr>

Going into semantics.

  1. div#main is, in fact, section#main.

  2. I’d just use the semantic sectioning the headings (h1-h6) naturally provide. Something inherited from HTML4.

header
h1

section#main
h2 - service one title
p

h2 - service two title
p

h2 - service three title
p

h3 - secondary service one title (ie: service four)
p

h3 - secondary service two title (ie: service five)
p

h4 - tertiary service one title (ie: service six)
p

h4 - tertiary service two title (ie: service seven)
p

h4 - tertiary service three title (ie: service eight)
p

h4 - tertiary service four title (ie: service nine)
p

footer

There is another way, making each set of services a section, but that’s up to the content, really.

<hr>

Not to me. It’s pretty simple until everybody still learning starts reading between the lines and looks to overcomplicate half understood notions. This and various venting from developers still resisting adoption, for various personal reasons.

For me, there are clear advantages today: no more ul and div for everything. Since HTML5 semantics is already supported extremely well by current browsers, HTML5 it’s not a fade promise anymore, it’s a future demand for web developers. It’s up to web developer itself to properly learn and apply.

6

I think HTML5 is supposed to provide us some new options for how we use headings. It used to be (and for the moment, still is) the case that we could only denote sections and sub-sections by the heading levels (h1, h2, h3, etc.). But in HTML5, we can mark sections and sub-sections explicitly, which means our heading levels can reset within each section.

Copy-pasted from the HTML5 draft:

 <h1>Apples</h1>
 <p>Apples are fruit.</p>
 <section>
  <h1>Taste</h1>
  <p>They taste lovely.</p>
  <section>
   <h1>Sweet</h1>
   <p>Red apples are sweeter than green ones.</p>
  </section>
 </section>
 <section>
  <h1>Color</h1>
  <p>Apples come in various colors.</p>
 </section>

Though, I’ll also echo tunnil’s first post: This is only useful if browsers, crawlers, and screen readers recognize this markup and structure.

7

I disagree. Your post, Jeff, is but 1/3 of the story. HTML5 provides us with semantic sections. These semantic sections can now make use of headings in more than one way. But headings are but a side effect.

On the “Headings and sections” section:
http://developers.whatwg.org/sections.html#headings-and-sections

[…] headings of equal or higher rank start new (implied) sections, headings of lower rank start implied subsections that are part of the previous one. In both cases, the element represents the heading of the implied section.

Which makes my example perfectly valid.

Regarding new trends, there are a few things they encourage (not constrain) authors to do:

Sections may contain headings of any rank, but authors are strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section’s nesting level.

Authors are also encouraged to explicitly wrap sections in elements of sectioning content, instead of relying on the implicit sections generated by having multiple headings in one element of sectioning content.

which means to say, start headings from h1 in a new section and explicitly group the content. Which makes sense, but only when the content is asking for it and only when the outline of the documents benefits from it.

The following three examples describe these increasing degrees of grouping the content with semantic section elements and the issues one may encounter:

For example, the following is correct:


<body>
 <h4>Apples</h4>
 <p>Apples are fruit.</p>
 <section>
  <h2>Taste</h2>
  <p>They taste lovely.</p>
  <h6>Sweet</h6>
  <p>Red apples are sweeter than green ones.</p>
  <h1>Color</h1>
  <p>Apples come in various colors.</p>
 </section>
</body>

However, the same document would be more clearly expressed as:


<body>
 <h1>Apples</h1>
 <p>Apples are fruit.</p>
 <section>
  <h2>Taste</h2>
  <p>They taste lovely.</p>
  <section>
   <h3>Sweet</h3>
   <p>Red apples are sweeter than green ones.</p>
  </section>
 </section>
 <section>
  <h2>Color</h2>
  <p>Apples come in various colors.</p>
 </section>
</body>

Both of the documents above are semantically identical and would produce the same outline in compliant user agents.

This third example is also semantically identical, and might be easier to maintain (e.g. if sections are often moved around in editing):


<body>
 <h1>Apples</h1>
 <p>Apples are fruit.</p>
 <section>
  <h1>Taste</h1>
  <p>They taste lovely.</p>
  <section>
   <h1>Sweet</h1>
   <p>Red apples are sweeter than green ones.</p>
  </section>
 </section>
 <section>
  <h1>Color</h1>
  <p>Apples come in various colors.</p>
 </section>
</body>

This final example would need explicit style rules to be rendered well in legacy browsers. Legacy browsers without CSS support would render all the headings as top-level headings.

It’s extremely important to notice in the first example how they play with implicit sectioning (the ending h1) and the explicit sectioning (the section element).

It’s clear that with HTML5, authors do have more options and this thing probably scares most of them, accustom to divs after divs after divs. And the most powerful thing is that there are several right answers, a thing often overlooked by “legacy” developers used to having but one right semantic answer. Hence the venting, half truths (third truths :slight_smile: ) and never ending misunderstandings.

8

@tunnil - this is not a list of definitions. It is a ‘services’ page, describing the services provided, and talking about each service in some depth. We are not defining the services, we are discussing how they can help the reader, how you can benefit from them, and why you should use company X over company Y to be provided with them. So imho, a Definition List is not appropriate here.

The entire site has been coded in HTML5, hence its use. I’d rather not go off-topic into that one though lol.

How come Ralph?

But all of the services are individual services, not necessarily connected to one another, and can be used or purchased/employed on their own merits. So one is not needed by any other. They are all of ‘equal’ importance other than the way the business who provides said services wishes and chooses to promote or supply them. IE: a construction company may well do Windows and Doors, but you can bet that House Extensions and New Build Properties are of higher priority to them.

In that example, I would suggest the two ‘primary services’ (house extensions and new builds) would go into one Section (perhaps each inside an article? perhaps not), and the 'secondary services) inside another Section. No? I would like to hear any reasoning’s against this methodology.

See above.

Again, as per above, the content in each section CAN stand on its own (and perhaps should each have H1 tags).

IMHO, HTML5 is the future. People are using it now, and if you get used to using it now you can focus on learning other things whilst those who stic with HTML4/XHTML1.x trail behind to catch up. …not that I want to take this thread off topic at all.

Thanks for your input itmitica, I appreciate it; but wouldnt using the H1-H6 tags in that way create a sense that the content it all part of the same topic or item, closely related, but breaking down into further and further detail? I don’t feel that ‘fits’ the semantic behind the content. Each service is individual, and can be supplied on its own, and indeed companies out there exist solely to provide only one service of any within my primary, secondary and tertiary sections. Surely H1-H6 dont make clear the that the content under each heading is different and to a large extent, unrelated to one another?

I also would have to agree with your second point there, using sections as described. I feel this is a good ‘fit’ for the content, but would welcome your thoughts on this more… if you may?

Again not wanting to get into this, but yes. I agree 100%.

Is this not exactly what I have attempted to apply and do in my original code snippet posted in the opening post of this thread?

I used Sections to break up the differing categories of service (primary, secondary, tertiary), and inside each of those used H1-H6 tags to appropriately identify not only the title/name of each service, but also the importance of that service in relation to the company’s main goal. IE: H1 tagged services are primary, H2 tagged services as secondary, and so on. That is exactly what has been done in your code snippet above, but without the use of Articles. No?

Again, thanks to everyone who has commented and replied so far. I would love to hear more thoughts on this and of my comments above. I feel the thread is possibly near a solution/end? Does anyone have any other ideas or further comments to interject?

9

You use article not because “Each service is individual”, but when you want that content, describing the service, be easily syndicated, and when that content is an alien there.

Think of article elements like passengers in a train: the only thing connecting them is the wagon, the container. But they will all go different ways.

In your case, each service description describes various individuals from the same family. They all go to the same destination: home.

Also, it’s not about getting so precise with what content says, but about with what content is.

In this case, your services descriptions are the same thing: a tender. The transition from one service offer to another doesn’t mean another topic, it means a different of the same.

h1-h6 do offer an implicit level of sectioning for that. Using the section element, like you did, and like it is done in the second example from the specs, makes for a more explicit distinction in your content. If you feel it’s necessary, by all means, use the section elements.

The problem with your example is that you break consistency of heading rules inside sections. You could pick up the heading level from the parent section (h1 to h2), but here you’re trying to rely a false meaning (a service is more important) which is not the heading’s job.

In fact, each of the three services section are the same level:

section#main

section#primary_services
h1 - primary services title

section
h2 - service one title
p

section
h2 - service two title
p

section#secondary_services
h1 - secondary services title

section
h2 - secondary service one title
p

section
h2 - secondary service two title
p

section#tertiary_services
h1 - tertiary services title

section
h2 - tertiary service one title
p

section
h2 - tertiary service two title
p

I believe this is the right way, and the one I provided before was wrong. Sorry.
It’s wrong because there’s no real subordination between a primary service and a secondary service. It’s about business precedence here, and that’s not conveyable by markup.

10

All seems to make good sense itmitică. Thanks for taking the time to read and reply.

I think i’ll go with sections for the 3 main categories of service, and amend headings as per your example above (doing away with Articles).

Thank you again! :smiley:

11

Sure, but if you are going to put them all on the same page, then they all fall under Services, the main title—h1. In that reard, each is a subset of Services, so deserves an h2 heading. Any subests of each service deserves an h3 and so on. Otherwise, if they are all so individual, each should have its own page.

This document structure has served us well for centuries. I don’t see the point of shaking all these headings up as if in a blender and spitting them out in any old order. I don’t agree that it provides better semantics. No one has convinced me that there’s anything better than the traditional heading-based semantics.

These discussions (that I’ve seen so far) don’t seem to discuss styling. Styling all those headings with all those nesting levels is surely going to be a hell of a job.

12

@applehead
You’re welcome. :slight_smile:

From what I gather, for the OP, secondary are not subsets of primary and tertiary are subsets of secondary. These are services on their on, but the business focus is on the first set of services, then on the second and then on the third.

Lower level headings are not suppose to express the importance of the services, and, as such, they all fall under the same level, only that some occur sooner while others occur later.

Except that it’s not spitting them out randomly. That’s why it provides better semantics… but in browsers that served us well for centuries, that may be a problem. :slight_smile:

You should respect the fact that others acknowledge it as better semantics. Personal choices don’t just nullify the very existence of HTML5 semantics.

It’s not that complicate either. But if the simplicity of HTML4 is the one preventing you to adopt HTML5 semantics, then this is not the right reason.

13

The normal heading structures can account for any such combinations, IMHO.

You should respect the fact that others acknowledge it as better semantics.

I can respect their efforts without agreeing with them. I don’t see how a dog’s breakfast of headings and sections improves semantics. Semantics, by their very definition, are meant to make things meaningful and clear, which the new setup doesn’t seem to do at all. People have come up with new-age models for all sorts of things—such as education, in the process throwing out centuries of tradition and knowledge. These new models of education have failed miserably—at least where I live.

if the simplicity of HTML4 is the one preventing you to adopt HTML5 semantics, then this is not the right reason.

It’s the logic and true semantics of the older model that make me prefer it.

14

OK.

Let’s start from the top: HTML4.
http://www.w3.org/TR/html401/struct/global.html#h-7.5.5

The following example shows how to use the DIV element to associate a heading with the document section that follows it. Doing so allows you to define a style for the section (color the background, set the font, etc.) with style sheets.


<[B]DIV class="section"[/B] id="forest-elephants" >
[B]<H1>Forest elephants</H1>[/B]
<P>In this section, we discuss the lesser known forest elephants.
...this section continues...
<[B]DIV class="subsection"[/B] id="forest-habitat" >
[B]<H2>Habitat</H2>[/B]
<P>Forest elephants do not live in trees but among them.
...this subsection continues...
</DIV>
</DIV>

And let’s compare it with HTML5:
http://developers.whatwg.org/sections.html#headings-and-sections

However, the same document would be more clearly expressed as:


<body>
 <h1>Apples</h1>
 <p>Apples are fruit.</p>
 [B]<section>[/B]
  [B]<h2>Taste</h2>[/B]
  <p>They taste lovely.</p>
  [B]<section>[/B]
   [B]<h3>Sweet</h3>[/B]
   <p>Red apples are sweeter than green ones.</p>
  </section>
 </section>
 <section>
  <h2>Color</h2>
  <p>Apples come in various colors.</p>
 </section>
</body>

For me, it’s the logic and true semantics of the new model. :slight_smile:

Which is the old model… improved. HTML5 does make things more clear.

You’ll notice, that even in HTML4, even though headings imply sectioning to follow and to end, they resort to div to explicitly section the document.

div was also used as style hooks. To make a semantic difference, HTML5 brought the section element forward, which is to be used only for semantic sectioning purposes.

That’s better model, if you ask me.

The reason is that you could add any number of classes to a div: section, subsection, nav, header, footer. But an attribute is a value that could be overlooked or be missing, while an explicit correct element is sure to convey exactly the right meaning.

15

But you are comparing apples and … elephants. :lol:

I don’t see how the sections in the second example make a difference, except adding extra markup. If you stripped out those sections, the heading structure would still convey the same semantics.

Shrug, o well … I’m not trying to pretend to be knowledgeable on this stuff, and haven’t delved into HTML5 as much as you, but I’m still dubious about the need for new semantics. I’ve seen examples of where sematic value is indeed added, but only in fairly minor ways that don’t seem to justify all the fuss. I can see that value in small items like figcaption etc, which is fine—I’ll happily use them when widely supported. But as for the overall page structure, I remain unconvinced.

16

Not the way I see it, not the way HTML4 and HTML5 specs are written, and certainly not the way things are.
Again, implicit and explicit sectioning is the subject. You seem to think that implicit sectioning is the only way…

[QUOTE=itmitică;5158847]
You’ll notice, that even in HTML4, even though headings imply sectioning to follow and to end, they resort to div to explicitly section the document.

div was also used as style hooks. To make a semantic difference, HTML5 brought the section element forward, which is to be used only for semantic sectioning purposes.

That’s better model, if you ask me.

The reason is that you could add any number of classes to a div: section, subsection, nav, header, footer. But an attribute is a value that could be overlooked or be missing, while an explicit correct element is sure to convey exactly the right meaning.[/QUOTE]

17

The reason is that you could add any number of classes to a div: section, subsection, nav, header, footer. But an attribute is a value that could be overlooked or be missing, while an explicit correct element is sure to convey exactly the right meaning.

I would have preferred further development of ARIA roles, to be honest.

18

If the two overlap, I say that markup is a better choice. It makes it easier on both the developer and the browser vendor.

19

Roles allow for a whole lot more semantics, and these would perfectly double up as hooks for styling, rather than having to add classes to <section>s instead. Imagine how many semantic roles could be made available—then you’d have real semantics. As it stands, all the possibilities of meaning are rolled into a few new tags like <section>, <aside> and <article> … which don’t mean much more than <div> to me. <nav> is pretty vague, too, as every link is really for navigation. And even <footer> is pretty vague.

20

Looking at the online controversy surrounding HTML5, it seems web developers can’t handle simple semantics like header, section, footer. :slight_smile:

A whole lot more semantics I think it would blow the internet off the orbit!!! :rofl:

Seriously though, one thing that seems to contribute to the indecision and confusion is web developers trying to get ahead the content and start planning the structure before hand.

Once you decide upon the content, things get clearer and easier. But there is not a single HTML5 semantics universal answer for every content out there, as it may change along with your content changes.