Quick Question on Semantic HTML5 Structure (sections & articles)

**ralph.m** · Jul 28, 2012 08:34

Originally Posted by itmitică

it's the content that commands my use of section, and section that commands my use of heading.

Then you are using too many sections.

Code:

<section>
   <h3>Sweet</h3>
   <p>Red apples are sweeter than green ones.</p>
</section>

That's what I mean by sectionitis.

Hmmm... no. And you know it.

I know how it is now, but part of this discussion is about how things could be as this whole update to HTML is being considered. If the makers of HTML decide that something is explicit rather than implicit, that's how it will be. I don't see why they have to invent new elements to make it so.

**itmitică** · Jul 28, 2012 08:44

Originally Posted by ralph.m

Then you are using too many sections.

Code:

<section>
   <h3>Sweet</h3>
   <p>Red apples are sweeter than green ones.</p>
</section>

That's what I mean by sectionitis.

Obviously the examples in the specs have demonstrative purposes. Adding a whole lot of real content would fail to instruct: TL;DR.
And the same goes for the brevity of the content in the code for the OP's problem.

I first thought of implicit sectioning. But...

Originally Posted by itmitică

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

And, look at the HTML 4 specs. In this example, one would quickly draw the divitis conclusion... if wanted so.

http://www.w3.org/TR/html401/struct/global.html#h-7.5.5

Code:

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

Originally Posted by ralph.m

I know how it is now, but part of this discussion is about how things could be as this whole update to HTML is being considered. If the makers of HTML decide that something is explicit rather than implicit, that's how it will be. I don't see why they have to invent new elements to make it so.

Well, then I suppose you wanted HTML5 to look like this:

Code:

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

This would technically mean explicit.

**applehead** · Jul 28, 2012 15:47

Tbh Ralph, (and I mean no offence by this at all..) it seems you either a) can't or b) just don't want, to 'get it'. Whether it be for an inability to understand the reasoning, which is fair enough. Or through a determined refusal to accept. It seems like you are almost clutching at straws to have Heading tags do everything Section, Article & Aside do, PLUS what Headings are meant to do.

Whilst some of that may have been true for HTML 4, it is my opinion that developers should be happy tags and elements are now receiving more defined roles and purposes. The correct use of Headings & Divs seems almost rather vague now that we have (again in my opinion,) self-explanatory elements like section and article.

I don't believe there should be this deep a debate about what each tag is for per-say, as largely their name defines them and their correct use/role/purpose.

My initial question was just regarding how to split the services up to differentiate the levels and importance of service from the point of view of the business, not the coding language (referencing your point about them all being on individual pages or under one section together). Content is King.

I guess there will always be those who prefer HTML4 (as there were over XHTML1.x), but eventually their code will become out of date. All I'm trying to do is get my head around the best use of HTML 5 and put it into practice now, to help move the web forward and keep myself up to date. It is also much simpler, because of these more precisely defined roles for elements and tags, in HTML5, in my opinion - which is essentially why I've made the switch.

It's the future, and once you have your head around it, it's actually simpler to code & easier to understand.

Sitepoint's HTML5 & CSS3 for the real world book does a great job of explaining all this.

That's not to say I'm not loving the discussion though lol. Itmitica has a great way with words!

**ralph.m** · Jul 28, 2012 21:01

Originally Posted by itmitică

I suppose you wanted HTML5 to look like this ...

No, I think my ideal scenario would be something like ARIA roles on an HTML4-like structure. You could have a more fine-grained list of roles for very specific semantics. And they double as styling hooks, too. Win win.

Originally Posted by applehead

Tbh Ralph, (and I mean no offence by this at all..) it seems you either a) can't or b) just don't want, to 'get it'.

No offense taken at all. It is a very interesting discussion, and I'm not trying to be annoying. It's a bit of both, I guess: I haven't fully bothered to get my head around the new semantics, but partly because I don't agree with what I'm seeing. (I have read books on it, too.) Heading levels have worked for centuries as semanic organizers for content, and I don't see why that needs to change. It seems less practical to me to leave semantics up to containers rather than the content itself. Obviously I just have to accept that this is not the choice that's been made, but it's a pity.

**itmitică** · Jul 28, 2012 23:52

Originally Posted by ralph.m

No, I think my ideal scenario would be something like ARIA roles on an HTML4-like structure. You could have a more fine-grained list of roles for very specific semantics. And they double as styling hooks, too. Win win.

ARIA itself brings a whole lot more confusion to the table than HTML5 semantics could ever bring.

The roles overlap among them, or are being similar to a point where they differ just enough to be extremely confusing.

Also, you are prevented from using ARIA, where it conflicts with the strong native semantics. This because AT could then describe a contradictory state.

ARIA is for accessibility. What this says is this:
- when proper semantic is missing, use ARIA to explain the roles
- when proper semantic has arrived, abandon ARIA in that area

This makes ARIA not a replacement for semantics, but a temporary solution until full implementations of said semantics.
ARIA will never replace HTML 4, HTML5, HTML6, it will, and sadly, only theoretical, assist users through various intermediary stages of advancement to new standards.

Originally Posted by ralph.m

It seems less practical to me to leave semantics up to containers rather than the content itself. Obviously I just have to accept that this is not the choice that's been made, but it's a pity.

This is something I have to disagree with. Semantics is about containers for content. You can't have content without containers. I properly tag content... using a container.

Otherwise, I could just have a universal <tag></tag> container and fill the role attributes for each of them. Obviously having tags for semantics is better, and also, using proper tags is better than relying on optional attributes.

Content is king, yes, but its meaning is different from its purpose. Web designers don't decide semantics reading and interpreting what's written or pictured, they decide semantics judging the role of that content. ARIA, remember?

The web designer is not a food critique, the web designer is an aisle and shelf manager. He doesn't smell or feel the goods, he only manages the goods accordingly.

**ralph.m** · Jul 29, 2012 00:46

I wasn't saying that ARIA should be the solution, but something like ARIA be added to HTML to add semantics for digital devices that need it. (If the "paving the cowpats [sic]" idea had been genuine, then this development should have been taken into account more fully.)

At the end of the day, what the sighted user sees doesn't change, so headings will still provide the visual content structure and semantics. So why not let them provide the semantic structure for devices as well? And then, if devices such as screen readers need more information about the nature of the content, additional, role-like attributes would have been a perfect way to go—with a lot more specific options to choose from.

And instead of unnecessary <figures> and stuff like that, a simple <object> could have been used, with a combination of roles and/or for=""/id attributes (as used to associate label/input) could have been used to associate various objects, such as an image object with a caption. Much cleaner, neater and easier to understand, IMHO.

I can't help thinking that the developers of HTML5 just wanted to do something different to make a name for themselves—like educators who trash excellent, time-proven curricula not because they've come up with something better, but because they want to make their mark.

**itmitică** · Jul 29, 2012 01:36

Originally Posted by ralph.m

[...] headings will still provide the visual content structure and semantics. So why not let them provide the semantic structure for devices as well? And then, if devices such as screen readers need more information about the nature of the content, additional, role-like attributes would have been a perfect way to go—with a lot more specific options to choose from.

[...] a simple <object> could have been used, with a combination of roles and/or for=""/id attributes (as used to associate label/input) could have been used to associate various objects, such as an image object with a caption. Much cleaner, neater and easier to understand, IMHO.

Sometimes, like in the case of syndicated content (article), and not only, the use of normal headings to section a document, is just not logically possible. Otherwise, in HTML5, headings are still able to structure. But now web developers have more options, the web design is more flexible. More possible semantic constructs is a good thing.

Again, relying on optional attributes instead of mandatory (semantic) elements is not a full proof solution, it's a side solution.

Originally Posted by ralph.m

I can't help thinking that the developers of HTML5 just wanted to do something different to make a name for themselves

Web developers and web developing reached a threshold where they needed something better than HTML 4. If HTML5 is just a stepping stone or it's the real deal, it really doesn't matter. HTML semantics have and will have a new approach.

User Tag List

Thread: Quick Question on Semantic HTML5 Structure (sections & articles)

Thread Tools

Display

Tags for this Thread

Bookmarks

Bookmarks

Posting Permissions