HTML5 - Laying with the "new" semantic tags... confusing?

Get Started
21

Great minds think alike. I too have embraced HTML5 because of this.

@Dablue;
From what I see from HTML5 those extra tags are just extra tags. Whether you use <article> or <div class=“article”> makes little difference. I personally would use <article> because it’s easier to read, however, saying this a tag is just a container and I don’t think container tags change anything. I attended the HTML5 Experts sessions and they mentioned those tags.

Not sure if I am doing things right, but I use <section> tags for the various sections of a page <nav> for the navigation. A little bit naughty but you can actually create your own tags, I did this once <mytag> and used css to style it. It did work rather nice. :stuck_out_tongue:

22

[QUOTE=itmitică;5143204]<article>, as an element in HTML, has a special meaning now, different from the article English word.[/QUOTE]

Not necessarily. The word ‘article’ in English means a lot more than simple a piece of writing—even though that’s the most common kind of ‘article’ these days.

23

Ok, lots to go at here and thanks to everyone’s for their input so far…

I’m not reading <article> as article, although I do think semantically its function is better suited to being called an <item> for the reasons I’ve already set out, and let’s not forget, HTML5 is all about improving semantics :slight_smile:

[QUOTE=itmitică;5143204]The article element represents a self-contained composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication.[/QUOTE]

I’ve highlighted what I consider to be the most important from the spec, afterall <section>s and <div>s are also self contained. What separates the <article> is the purpose of potentially being available for distribution… That’s not to say it ever will be.

[QUOTE=itmitică;5143204]When article elements are nested, the inner article elements represent articles that are in principle related to the contents of the outer article. For instance, a blog entry on a site that accepts user-submitted comments could represent the comments as article elements nested within the article element for the blog entry.[/QUOTE]

Yes, I’ve read that nested <article> comments should also be treated as <article>s too, but it goes against the spec’s description of being “independently distributable”. Why would you distribute a individual blog comment? You would syndicate the blog post with or without their related comments. Taken out of context, if it’s a legitimate comment relating to the blog post, it won’t make sense. I would argue comments would be better suited to the <section> tag.

Everything said here lends itself to my argument…

[QUOTE=itmitică;5143204]That’s the good thing about HTML5, you can use whatever you decide it’s best.[/QUOTE]

This is my main argument, it’s too open to one’s own interpretation. if “you’re” the one deciding the appropriate tag, what’s the point in trying to codify a rulebook for how the tags should be used in the first place? You might as well stick to using <div>s for the complexity and confusion it adds.

Then why bother with these new container tags?

Rest assured, you won’t be alone.

That doesn’t really lend itself to unifying a standard for mark up, does it?

24

You could create your own tags in XHTML 1.0 and obviously in XML so nothing new really. However the problem being with doing so front-end regarding a ‘typical generic webpage’ that usually ends up (text/html). The browser obviously wouldn’t natively understand (or Search Engine) so it was mainly a lost cause using extensibility for such a page. Hence another reason why h5 is broken in modern legacy browsers that could obviously support XML.

The “experts” which in fact were just guest talkers (one an employee for a browser vendor) made several slipups but I am not going to highlight them all… Overall they did at least say without JavaScript that there was a basically negligible benefit and in fact advised against using it.

At best they said you may want to experiment with certain parts (though were vague) as the browser vendors seem to be dictating and shifting. Though of course they even highlighted how that there was conflict - infighting - on which elements were going to be dropped with one party already doing the opposite to the other, i.e. fragmentation of the language’s main proponents and developing teams/parties in other-words they are going to blow themselves in bits with politics.

25

@Dablue

In post #20 I’ve tried to address the “issues” you see with comments as <article>s, no need to reiterate.

The one thing I’d add, is that HTML5 is not open to interpretation, it’s open to preference: keep using HTML4 semantics, which are poor, or switch over to new HTML5 improved semantics.

This is not to say: “HTML5 is a mixed up kid who doesn’t know what is what”, it is to say “HTML5 is a gentleman, it let’s you choose your way around”. So, you either go with HTML4 under the HTML5 umbrella or use HTML5, but it’s either one or the other, not a mixup.

A final word about HTML5: you can seriously consider about using it. If browser vendors are supporting it, it means they are serious about it. But, in the end, it’s your choice. The same happened with HTML4, transitioning from HTML3.2. There was a serious resistance at first. In the end, everybody ended up using it.

26

[QUOTE=itmitică;5143402]you either go with HTML4 under the HTML5 umbrella or use HTML5, but it’s either one or the other, not a mixup.[/quote]

That doesn’t seem consistent with the idea of a “living standard” (or whatever it’s called). You can use newer elements as you please or as they are introduced/supported.

In the end, everybody ended up using it.

Ha ha, not quite everyone yet, going by some of the code you see around here. :slight_smile:

27

[QUOTE=itmitică;5143204]no need to reiterate.[/QUOTE]

I’m not addressing the same point because because if I argue it more I will be right. I’m trying to hone in on nuances because it is a very fine line on what correctly dictates one container type over another. I simply want to instil best practices early on, and I hope others will follow suit as and when they make the transition. This is why I’m spending probably more time than I would like to clearly discuss and understand these nuances. HTML4 by comparision was easy.

[QUOTE=itmitică;5143204]HTML5 is not open to interpretation[/QUOTE]

You might say that, but at the risk of repetition, there are numerous examples by people who’ve already embraced HTML5 of different interpretations of the tags.

For years websites were designed incorrectly - <table>s vs <div>s. It took years to re-educate designers. I still see people to this day desinging with tables. That was a fundamental and more obvious issue to highlight - “you’re marking up your html incorrectly”. The same principle could be argued here in HTML5, but it’s not so simple to see the errors of your ways. <table>s and <div>s are one thing, <article>s, <section>s and <div>s are another. Re-educating correct principles on the latter will be more difficult than explaining the differences between a table of data and division of a page.

[QUOTE=itmitică;5143204]This is not to say: “HTML5 is a mixed up kid who doesn’t know what is what”, it is to say “HTML5 is a gentleman, it let’s you choose your way around”.[/QUOTE]

I understand what you are saying, but HTML4 (obviously) lets you choose your way around with more freedom and it does its job. Part of HTML5’s remit is to strengthen layout procedure and eliminate ambiguities - why else would you introduce a load of new layout tags?

Agreed.

I will start using it, I think it’s in our best interest. I don’t see it disappearing in favour of an “improvement” in XHTML. It will be around in the future in this format or another, my hopes are that it gets refined and the ambiguities get removed.

28 

<div class="header">
    [...]
    <nav>
        [...]
    </nav>
    [...]
</div>

This is what I’m talking about.

<hr>

And was used wrong because of its ambiguity. For example, <div> started out as a meaningless tag and ended up as a universal semantic carrier. It’s easy, yes, but it’s also wrong.

HTML5 new tags are a step towards specificity. A specificity that was already wished for. It seems a little ingrate of web devs to get their wish granted and to complain it’s not easier.

29

[QUOTE=itmitică;5143727]And was used wrong because of its ambiguity. For example, <div> started out as a meaningless tag and ended up as a universal semantic carrier.[/QUOTE]

I never thought HTML4 was ambiguous, but I guess you would argue the same for HTML5 :slight_smile: <div> was never a meaningless tag to me. <div> were divisions of a page.

The purpose of the new semantic tags in HTML5 could have probably been handled by microformats.

[QUOTE=itmitică;5143727]It’s easy, yes, but it’s also wrong.[/QUOTE]

I wouldn’t say wrong, maybe less defining, less specific?

[QUOTE=itmitică;5143727]HTML5 new tags are a step towards specificity.[/QUOTE]

I 100% agree. It just needs everyone to agree on how they should be used.

[QUOTE=itmitică;5143727]It seems a little ingrate of web devs to get their wish granted and to complain it’s not easier.[/QUOTE]

I’m not ungrateful. I think you think I’m condemning HTML5 - that it’s a waste of time. I’m not. I like the idea of progression, but still think HTML4 could have been extended. I’m not saying HTML5 is a waste of time, I will start using it asap when I feel comfortable enough with layout best practices. I’d just not rather reinvent the wheel to see it needs doing again.

For me personally, I think for the amount of time / people who have been involved with HTML5 there would be less ambiguity. The more examples I can quickly grasp, the better for me :slight_smile:

30

It is ambiguous, since you cannot reach a certain level of clarity in your structure but by the use of attributes. Which is also what’s wrong with microformats and “undeclared” attributes.

HTML is about tagging the content. If you want to classify the content, like microformats do, you should pick another format altogether.

31

These discussions nearly always turn to arguing semantics.

I feel getting super enthusiastic about semantic markup had it’s place when everyone was using spacer gifs, font tags and tables.
Now that people understand how to use the basic elements headings, paragraphs, lists, links, tables I feel we don’t need to worry.

Certain elements like <nav> and <time> I feel are good additions but there is clearing something wrong with the distinction of div, section and article, and even header & footer because so many people are getting hung up on it.

32

HTML5 attempts to improve the accuracy of semantics. ATTEMPTS being the operative word there. I think people (web professionals included) fail to see that the “holy grail” of web is simply unattainable and mutually exclusive… ‘Send all of the information w/o sending any of the info… also include meta’. The best one can ever hope for, realistically, is to achieve a good balance.

Similarly with semantics. HTML cant have a tag for everything (it would be XML then), so you cant expect HTML5 to have a specific tag for comments, blog post, etc. One has to approximate. This is not so hard; I like to think semantics as being a relative scale unique to each INDIVIDUAL HTML document . ( this is what you read as ‘open to interpretation’ but ‘open to interpretation’ is not ‘free for all’)

33

There is a clear contradiction in what you’re saying, but I argue that it’s probably the low technical value in some discussions that are confusing so many people.

HTML5 does a great job if you take the time to learn it first hand and not rely on what others have vented. If you don’t agree, you are free to politely disagree, but you definitely should shy away from remarks like that about people and web professionals. Extremely inappropriate for you to suggest that you can see one thing the whole of web professionals fails to.

34

HTML5 has not been finalized so the final standard could potentially diverge from how current browsers implement/interpret HTML5. You will need to decide if you want to risk going with HTML5 as it currently stands, risking pages not looking properly or breaking as browsers change their interpretation/implimenttation of HTML5 as the spec evolves or you could wait until the HTML5 spec is finalised and then after allowing a few weeks too account for many of the main browsers to finalise how they implement/interpret HMTL5 and then decide if your going to migrate over to HTML5 or stick with HTML4 or XHTML.

I personally won’t touch HTML5 for the time being until at least when it becomes a finalized spec. Once that happens I’ll probably have another look and examine HTML5 and decide if I want to migrate over to HTML5.

35

The W3C calendar for HTML5 looks like this:

  1. Last Call Working Draft was in 2011 Q2, which is past.
  2. Candidate Recommendation is 2012 Q2 which is present.
  3. Propose Recommendation and Recommendation are in Q1 and Q2 2014, which is near future.

This tells me that HTML5 specs are pretty stable now, and what could have been a valid concern about HTML5’s perishable nature, like in 2010, it isn’t anymore.

It also looks like a pretty good time to start to seriously consider HTML5, if you haven’t by now, or if you don’t retire by 2014:

http://www.w3.org/TR/html5-diff/

HTML4 became a W3C Recommendation in 1997. While it continues to serve as a rough guide to many of the core features of HTML, it does not provide enough information to build implementations that interoperate with each other and, more importantly, with a critical mass of deployed content. The same goes for XHTML1, which defines an XML serialization for HTML4, and DOM Level 2 HTML, which defines JavaScript APIs for both HTML and XHTML. HTML5 will replace these documents.

It’s worth nothing that W3C was rightfully criticized for their roundabout like, endless loop like process:

http://www.w3.org/TR/html5-diff/

1.3 Development Model

The HTML5 specification will not be considered finished before there are at least two complete implementations of the specification. A test suite will be used to measure completeness of the implementations. This approach differs from previous versions of HTML, where the final specification would typically be approved by a committee before being actually implemented. The goal of this change is to ensure that the specification is implementable, and usable by authors once it is finished.

and that they have a much much bigger scope that stands in the way of a better timing with the current desired pace, but for HTML5 strictly I now have WHATWG, which is something I look up to: http://developers.whatwg.org/.

The thing is, HTML5 is ready now. Or at least good parts of it are, that are certain to remain the same. Like <section>. Since all modern browsers have already implemented <section> the same way, “risk of not looking good or breaking” by 2014 is a bit of a goofy reason, if you ask me.

My personal opinion, is that too much energy is spent in threads like this one, in favor of how HTML5 shouldn’t be done at all, when what should really be appropriate for a technical forum is to clarify how it should be done instead. HTML5 has long gone from buzzword to reality for me not to take “won’t touch HTML5” more than just trolling attempts.

36

[QUOTE=itmitică;5144032]Since all modern browsers have already implemented <section> the same way …[/QUOTE]

If they’ve implemented it, why do we still have to style it with display: block? Doesn’t sound like it’s implemented to me … unless this situation has changed.

37

… unless you regard IE8 as being a modern browser.

Our different interpretation of modern is probably the same one that makes us see HTML5 in different lights.

But, for the sake of the argument, let me ask you this: how often do you find yourself applying display: inline to a block element or display: block or display: inline-block to a inline one? :wink:

And, please, let me stop you here, before another flame war starts again.

You don’t need to tell me that I’m disregarding a part of users who are still using legacy browsers.

Because I have an equaly valid argument: you are the one disregarding a big part of the users that are using modern browsers.

38

[QUOTE=itmitică;5144005]There is a clear contradiction in what you’re saying, but I argue that it’s probably the low technical value in some discussions that are confusing so many people.[/QUOTE]
Like I said, these discussion attract people who like to argue semantics :slight_smile:
I recognized that some of the tags are confusing but I don’t worry about them.

39

Confusion games with semantics in discussion and markup semantics are fun. :slight_smile:
Maybe a little less fun would thin off the confusion.

As for HTML5, I really can’t see what you’d expect from a tag discussion thread if not semantics… Most confusion roots in the fact that those willing to learn are filled up with the notion that HTML5 it’s not clear or it’s not viable. That’s why my recommendation, once more, is to K.I.S.S. and specs, and to take those various venting as they are: learning (and accepting) struggles.

40

HTML5 does a great job if you take the time to learn it first hand and not rely on what others have vented. If you don’t agree, you are free to politely disagree, but you definitely should shy away from remarks like that about people and web professionals. Extremely inappropriate for you to suggest that you can see one thing the whole of web professionals fails to.

The remark was not meant to get under anyone’s skin. I just meant that in many cases “we just wanted to do ‘this’” but it wasn’t what the language was intended for, as such we blame it rather than our expectations. This in o way was meant as a dig on anyone. Sorry if it sounded that way.

Restating what I said before HTML5 is wonderful, but it doesnt change the fact that semantics in any version of HTML is NOT an exact science and that one hinders one’s own progress in the understanding of markup if one expects it to be so.