Quick Question on Semantic HTML5 Structure (sections & articles)

HTML & CSS
21

Precisely the issue at hand. I completely agree. HTML5 allows us to group or separate content explicitally with appropriate new tags: section & article (header, nav, aside & footer of course included also.) It’s really not that hard.

And with those new elements, the purpose of Headings is now further defined, focused to a narrower, more suitable, semantic and a more precise role. Rather than trying to use them to section split, group AND Title content. A heading is just that, a Heading. A “heading” is simply a Title for a piece of text copy or content. It does not denote a section of content, it merely Titles it.

HTML 5 offers us a clearer way to code semantically and tag group and section our content. The very fact you can use the word “section” so frequently just talking about laying out and splitting up content is testament to its (IMO, perfect) naming and purposful existence in HTML 5. It does what it says, and in itself describes it’s own use. To Section.

Furthermore, with the addition of these new elements, the H1-H6 tags now by impact, are also better described and have become more meaningful and suitable to their real roles; to Title.

22

the purpose of Headings is now further defined, focused to a narrower, more suitable, semantic and a more precise role. Rather than trying to use them to section split, group AND Title content. A heading is just that, a Heading.

Well, I still think a heading is a natural section split. Why use multiple elements to do what one can do?

The very fact you can use the word “section” so frequently just talking about laying out and splitting up content is testament to its (IMO, perfect) naming and purposful existence in HTML 5. It does what it says, and in itself describes it’s own use. To Section.

How is that different from “division” (<div>)? We already had a suitable word. :slight_smile:

the H1-H6 tags now by impact, are also better described and have become more meaningful and suitable to their real roles; to Title.

But the whole point of 1–6 is now lost. Those numbers have become largely meaningless. There might as well just be a single <h> element.

23

heading = implicit section
HTML 4 div / HTML5 section = explicit section
Two different things. You may not want to insert a heading just to start a new section, especially when the heading is not needed. Though, the div doesn’t have this power. It can only mark a group, it can’t guarantee the group to always be a thematic grouping.

In HTML 4, a DIV element, as a generic language/style container it is, it could associate a heading with the document section that follows it, allowing you to to define a style for the section (color the background, set the font, etc.) with style sheets.

In HTML5, 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.

Which is to say that the section element is not a generic container element, is not a div. When an element is needed only for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead.

Which makes div… not a section. :wink:

I’d say the 1-6 point is gained on every section instead.

24

[QUOTE=itmitică;5159005]heading = implicit section
HTML 4 div / HTML5 section = explicit section[/quote]

Explicit/implicit is just a matter of interpretation. That interpretation can be changed, just like anything else. It could just as easily be declared that using a heading represents an explicit sectioning.

You may not want to insert a heading just to start a new section, especially when the heading is not needed.

Then use <hr>.

A section, in this context, is a thematic grouping of content, typically with a heading.

Again I say, then, why not let the heading create the semantics?

I’d say the 1-6 point is gained on every section instead.

But in your examples above you seem to use a section element every time you use a new heading. Looks like we need a new term to go with HTML5: “sectionitis”.

25

Hmmm… no. And you know it. :slight_smile:

In HTML 4, hr is put under graphics.

In HTML5, hr is describes as paragraph-level thematic break, to signal a transition to another topic in the same section.

They say, “there is no need for an hr element between the sections themselves, since the section elements and the h1 elements imply thematic changes themselves”.

Because you could have another semantic element after a heading in a section, that would prematurely end the section.

No, it’s the other way around, I use headings for every section of my content. :slight_smile:

It’s not the headings that commands my use of section, it’s the content that commands my use of section, and section that commands my use of heading. That’s the right order. You’re describing nonsense.

26

Then you are using too many sections.

<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.

27

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…

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

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


<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>

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


<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.

28

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! :slight_smile:

29

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.

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.

30

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.

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? :slight_smile:

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.

31

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.

32

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.

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.