I want to learn HTML5 and have been working to understand the new tags and rules. I'm developing the html structure for a search form and search results page (similar to the way google works). I've been working hard to understand the semantic meaning of all the decisions I make. Below is the result of what i've been working with. I've included an ample amount of comments to explain my thought process. I would really appreciate it if someone would be able to offer advise on how to improve this markup from a technical or semantic point-of-view.

Well, learning it to understand it is good -- if for no other reason than to understand why it's total bloated garbage. I learn things before I reject them -- it's why my comments often piss off fanboys; I learn where to stick the knife and twist before I badmouth things.

Let's review what you have:

Ignoring the HTML 5 shiv crap, uselessly vague head and meta tag that nothing actually uses -- many of the problems I'm seeing would be just as bad if you weren't using HTML 5. The presence of the HEADER element is simply an extra unnecessary wrapper in most layouts -- the same as the wasteful "<div id="header">" nonsense many people practice. You have a invalid/inaccessible/malformed form using a h1 to do LEGEND's job, no fieldset, some garbage empty section inside the form for christmas only knows what (probably scripting in which case the script should add the element to the DOM)... Of course with the use of section tags you can now use multiple H1's.... but the presence of the aside directly after the H1 when it doesn't appear to be the content for that heading (hence the aside tag), aside tag wrapping an OL that STILL ends up with a class on it (meaning I'd either move the class to the aside or not bother wasting the extra pointless wrapping tag around it), header tag for what should be a HEADING tag... results in a list when you have block level children meaning it probably should NOT be considered list items (ordered OR unordered)...

To me I just see bloated/pointless extra markup for nothing... about the only element you are using that even offers a code improvement to me would be the MARK tag... and honestly I'm not sure why we needed a new tag for that since DFN could fill that job rather nicely.

It is indeed an excellent example of why I think HTML 5 is a bunch of unnecessary fat bloated bull -- entirely typical of what I'm used to seeing from it and my own experiences in playing with it.

I mean, if that code isn't reason enough to kick it to the curb, I don't know what is...

Header, nav, footer -- Redundant and pointless bloat. If they wanted to give us that stuff, it would have been a hell of a lot more useful if it was just an attribute added to all tags... like recycle "scope" or make "rel" useful or something.

Oh, and just because they're "ordered by weighting" is no reason to throw them into an OL. Or even a UL. I draw the line at using lists the moment they have their own structure; that's what numbered heading tags and source order are for; and why the constant list abuse is little more than wasted markup.

But to be fair, you have to compare them apples to apples -- by coding it both ways to compare.

To make that HTML 5 as I understand using HTML 5... we have to throw in header tags around a bunch of semantic tags for no good reason, swap DFN for Mark, use the footer tag but still have to add block level containers inside footer since it's apparently not ENTIRELY block level (still not sure I understand that!) anything remotely resembling lists of links gets nav thrown around it. (nav being a nice descriptive name with every link on a page being navigation), lip service doctype and a character encoding meta older browsers don't even understand (so they fall back on the http headers), the need for that scripting shiv idiocy that breaks most of the time anyways... Oh, and of course since we're using sections EVERYTHING becomes a H1, because that makes it so much clearer what's going on...

Oh yeah, that's SUCH an improvement... No wait, not an improvement... what's the word I'm looking for? I can't even do it with one word... "Idiotic stupid asinine pointless useless bloat" works... Maybe an acronym for that? ISAPUB? I like that... ISAPUB.

I mean other than the autocomplete thing and mark... the rest of it is just stupid. When/if I use HTML 5, it will be for those and you will not find header, section, nav or any of the rest of that pointless non-semantic bloat in my code... though really that's why I'm using XHTML 1.0 Strict for now with NO plans to migrate. HTML 5 is "cute" ... but ultimately 90% of it is crap that just seems to exist to revert coding practices back to 1998 and/or amounts to throwing our hands up and saying "oh well, people are just going to vomit up code any old way to hell with the rules, so lets just pretend STRICT never existed and just slap some lip-service header on HTML 3.2" It LITERALLY seems to exist just for the people who want to slap extra wrappers around everything for no good reason -- the same people who missed the point of strict, don't understand semantics, proper heading orders, or any of the other good coding practices of the past decade.

Basically, Mr. Peabody wants his keys back.

bar338
—
2011-06-15T03:06:08Z —
#3

I appreciate the feedback, I can tell you put a lot of time into it.

Not to derail this topic, but here is my opinion on HTML5 (keeping in mind i'm only just beginning to understand it).

Today, HTML5 offers little advantage and increased bloat.

In the future, I can see HTMl5 offering increased flexibility. HTML5 is more about improving the semantics of the code from a machine-readable stand-point then a user or developers standpoint. I can think of some innovative things HTML5 will allow automated parsers to do. Whether the parser is a crawler, screen reader, or some other type of bot, HTML5 gives the parser more insight into the true meaning of the webpage components. However, I think HTML5 stops short of what it could offer in this consideration (in order to reduce the size of the spec).

The only reason I would use HTML5 today or in the near future is to support moving in this direction. But I would do so understanding there will be extra work required to make the website safe for users.

On the subject of Headers, I think XHTML has it wrong. I really like that headers are examined within scope now. It truly allows you to transplant code and maintain semantics.

I do agree with you on the fact that xhtml strict offered stronger coding style guidelines. I think that these guidelines should have been maintained better. Rather than the HTML5 spec trying to reduce tag size which in reality probably makes 0 improvement on 99% of websites out there.

Black_Max
—
2011-06-15T07:19:48Z —
#4

I am definitely down with using CSS3 techniques now, when I can do so without negatively impacting functionality in browsers that don't handle CSS3. HTML 5 ... though I'm very pleased with the new SitePoint book about the two, I'm gonna wait until the whole thing is stabilized before implementing it.

ralphm
—
2011-06-15T07:55:37Z —
#5

Nice comparison, Jason, and nice reply, bar338.

bar338 said:

In the future, I can see HTMl5 offering increased flexibility. HTML5 is more about improving the semantics of the code from a machine-readable stand-point then a user or developers standpoint. I can think of some innovative things HTML5 will allow automated parsers to do. Whether the parser is a crawler, screen reader, or some other type of bot, HTML5 gives the parser more insight into the true meaning of the webpage components.

That's certainly one way HTML5 could offer improvements over HTML4/XHTML. As Jason mentioned, though:

deathshadow60 said:

Header, nav, footer … If they wanted to give us that stuff, it would have been a hell of a lot more useful if it was just an attribute added to all tags... like recycle "scope" or make "rel" useful or something.

I've been exploring ARIA roles, and they seem better to me than the HTML5 elements. They cover a lot more bases than HTML5 will, and they can be used instead of classes for styling.

system
—
2011-06-15T08:03:05Z —
#6

ralph_m said:

I've been exploring ARIA roles, and they seem better to me than the HTML5 elements. They cover a lot more bases than HTML5 will, and they can be used instead of classes for styling.

I want to like Aria -- it does seem to make more sense than the new HTML 5 tags; BUT

there's something about it that just rubs me the wrong way -- I don't know if it's the words they chose for things, but it really feels more like the pet project of a UI designer who could give a flying **** about accessibility... I think it's all the stuff that says how things should behave, which frankly is one of those things that has no business in the markup. HTML should be for saying what things are, not how they look OR how they should behave. That defeats the point of HTML in the first place.

If you stripped out all the behavior and oddball UI stuff, it has some real potential. Honestly, Aria is more complex than the HTML it's being applied to -- that's NOT an improvement.

ralphm
—
2011-06-15T08:10:52Z —
#7

deathshadow60 said:

If you stripped out all the behavior and oddball UI stuff, it has some real potential. Honestly, Aria is more complex than the HTML it's being applied to -- that's NOT an improvement.

Most of it is over my head, but it's impressive how ARIA can make otherwise inaccessible widgets and the like fully keyboard accessible. Of course, that begs the question of whether or not that complex, 'widgety' stuff belongs on websites, but it's probably here to say.

Stomme_poes
—
2011-06-15T12:05:36Z —
#8

Both bar338 and Crusty left in the Advanced Search in the HTML.

Screw that. If I don't have Javascript on, you are PROMISING me that I get an advanced search. In fact, it's just an anchor that doesn't go anywhere. So I recommend you only make promises like that when you can keep them: create that anchor with Javascript, because then you know it will be able to fulfill its promise to users.*edit I was assuming the Advanced Search was a Javascript something... if it's a real link, ignore my rant above : )

&lt;ul id="search-nav"&gt; &lt;!-- Did not use &lt;nav&gt;

because this navigation is secondary, it is not of "Primary Importance" -->

The authors and the doctors seem to continually wish-wash about what a <nav> really means and when to use it.Reading Bruce and Remy's (now too old) HTML5 book, they were slapping navs on everything and anything that even remotely looked like some kind of navigation (except loose anchors in the body text)... even suggesting maybe a search form should have nav.

Luckily it seems the froth has faded and more sanity has prevailed, but I've been considering "nav" for all navigation lists, but only adding the ARIA landmark of "navigation" to the primary navigation lists.

Well, if I used <nav> and HTML5 which I don't primarily because these new semantics are not in the browsers today nor in the AT and the bugs are plenty and while future-proofing a site sounds nice, they also need to work today, and today mixing ARIA and HMTL5 (as opposed to ARIA and HTML4) does not work.

So I suppose for this example, saving <nav> elements for primary navigation might be the best thing.

Crusty said:

You have a invalid/inaccessible/malformed form using a h1 to do LEGEND's job, no fieldset,...

HTML5 lets you stuff inlines directly into a form... you know, kinda like it lets you stuff inlines directly into a blockquote and lets you wrap anchors around blocks. It's gettin' crazy, man!

As a side note, for anyone who has discovered the "search" ARIA role... do not put it on inputs, since this appears to override the input's role of... "input". And don't bother putting it on search forms either, since it might hide the form in some screen readers and isn't a navigable landmark anyway (plus the moment a form is announced, if you go to it you'll hear right away that it's search).

You gotta ask yourself what you did wrong if it's not obvious to the user that typing a search term is required. We don't have "You must type stuff into this form in order for it to work" above all our other forms, do we? "Required" is valuable when users aren't sure what is required and what isn't, because the form mixes required and optional fields. (though if there are multiple inputs and they all happen to be required, it's good to state "all fields are required" beforehand... but who has a form made entirely out of optional fields???)

I find myself raising hairs at the thought that if I am using assistive technology or a linear browser, that the page may force me to miss whatever comes before the search input... even on a page whose whole purpose might be search, like Google.The OP can't do anything about this, but I would rather that autofocus is something the user can set in their browsers rather than the author. The first time I come to your site I may want to read/explore everything like I normally do. After the second, third, whatever time I visit I may indeed want the benefit of just jumping directly to search (which I cannot do in Google since I have to tab through all the site-garbage first... but I use DuckDuckGo anyway). Would be nice if it was a setting I control rather than one the author controls.Okay autofocus rant over : )

&lt;!-- Should I use &lt;h2&gt;

in place of <header> for each of the linked results? --> <!-- Chose not to use <section>for preview because it will be so short (1-2 sentences) -->

I'd use heading tags instead of headers since the document outline of HTML5 ranks heading tags based on nesting... if you're not presenting <article> or <section> tags, then use an appropriately-leveled heading tag instead.

Also agree with Crusty about not using an ol for the results. The user tends to assume the first result is the most relevant according to the search engine, and the user often disagrees with the search engine by clicking on something that's NOT the first result Tho DuckDuckGo uses the zero-click boxes as a way of stating "I think this was your preferred result" which is separate from the results list.

And I do consider it a results list, so I would use a list. I'd be cool with them having bullets next to them, which would fit Tommy Olsson's "bullet test" to determine if they belong in a list.

Though just a linear row of headingtag-paragraph groups would also be fine.

<div class="preview"></div> <!-- Small sample of pages content -->

Ah, have you met the <details> element? I just saw a working implementation in Chrome. Browsers who don't support simply show everything, while <details> is meant as an HTML version of "show a little bit... show more if user requests".

&lt;ul class="pagination"&gt; &lt;!-- Not sure if I should use the &lt;nav&gt;

element here -->

I wouldn't if you are operating on the idea that <nav> is reserved for primary navigation. Having a single "next page" link before the pagination list allows anyone who got to the bottom easy access to the next page.

Though I guess the question is, what's Primary Navigation? Is it navigation of the site itself, or navigation of some main application on the site, without which there would be no site and no point? I dunno.Since my sites aren't applications, my <nav>s would be site navigation, and I usually have two of those (main navigation and small-print navigation).

I would consider a list of checkboxes instead. Suppose I want results that are both images (png/jpg/gif/svg) and media (videos etc)?

Stomme_poes
—
2011-06-15T12:40:11Z —
#9

Oh:

Crusty said:

HTML should be for saying what things are, not how they look OR how they should behave.

When someone needs a handle for a slider widget, what's the best HTML element to use? Most people use spans, but frankly, until they add a "slider-handle" tag to HTML, ARIA will have to describe what the thing IS by knowing what it DOES.

In increasing use of web applications, ARIA is going to be more and more important for naming the "true" purpose of HTML elements being used basically as placeholders for things that don't exist.

for anyone who has discovered the "search" ARIA role... do not put it on inputs,

I thought it was meant to be put on the form itself, as in a search form:

<form role="search" ...>

Stomme_poes
—
2011-06-15T14:40:09Z —
#11

Not sure what I had added to my coffee there...

me said:

since it might hide the form in some screen readers and isn't a navigable landmark anyway (plus the moment a form is announced, if you go to it you'll hear right away that it's search).

Bleh, no... the landmark might not work right cross-browser, but the reason I mention no putting the search role on forms was that if your label or legend was also search, people were confused by duplicate announcements (similar to NVDA in FF4 with <nav> and role="navigation"). I followed someone who did user testing with the roles on real users.

I'm just saying for now I'd leave it off, esp if your search form is one of the first things in source anyway.

I thought it was meant to be put on the form itself, as in a search form:

Yes. However we found out for example that JAWS would ignore the text input because someone, somewhere put the role of search on it : )

The role can also go on a container of the form, which could be better if there are other search mechanisms after the form too.

rguy84
—
2011-06-15T14:53:49Z —
#12

bar338 said:

In the future, I can see HTMl5 offering increased flexibility. HTML5 is more about improving the semantics of the code from a machine-readable stand-point then a user or developers standpoint. I can think of some innovative things HTML5 will allow automated parsers to do. Whether the parser is a crawler, screen reader, or some other type of bot, HTML5 gives the parser more insight into the true meaning of the webpage components. However, I think HTML5 stops short of what it could offer in this consideration (in order to reduce the size of the spec).

Meh, for screen readers - you can have a paragraph on it's own, or nested 5 levels deep.A screen reader sees it the exact same.

Stomme_poes
—
2011-06-15T15:09:04Z —
#13

Whether the parser is a crawler, screen reader, or some other type of bot, HTML5 gives the parser more insight into the true meaning of the webpage components.

Just change it to say"will, sometime in the indeterminate future"

It's a laudable goal, and many are working on it. Just keep in mind it's not here very soon.

The reason I don't use HTML5 today is because what I build today has to work today (and for UAs of yesterday), not just maybe eventually in the future. When enough UAs can handle (correctly), and get great benefit from HTML5, I'll use it.

The future is exciting. Like, right now I'm already looking forward to the wonderful sleep I'm going to do tonight. I love sleep. It's great.

zcorpan
—
2011-06-16T11:59:12Z —
#14

deathshadow60 said:

To make that HTML 5 as I understand using HTML 5... we have to throw in header tags around a bunch of semantic tags for no good reason,

No, you don't have to.

deathshadow60 said:

swap DFN for Mark,

No. Why would you? dfn and mark are different elements with different semantics.

deathshadow60 said:

use the footer tag but still have to add block level containers inside footer since it's apparently not ENTIRELY block level (still not sure I understand that!)

It's block level. No need to throw anything extra in footer.

deathshadow60 said:

anything remotely resembling lists of links gets nav thrown around it. (nav being a nice descriptive name with every link on a page being navigation),

No. You only use nav when you want AT users to be able to skip to or past your <nav> blocks. (Not that that is implemented in ATs yet.)

deathshadow60 said:

lip service doctype

It's nice isn't it?

deathshadow60 said:

and a character encoding meta older browsers don't even understand (so they fall back on the http headers),

They do understand it.

deathshadow60 said:

the need for that scripting shiv idiocy that breaks most of the time anyways...

You don't have to use it.

deathshadow60 said:

Oh, and of course since we're using sections EVERYTHING becomes a H1, because that makes it so much clearer what's going on...

You don't have to use h1 everywhere even when using section.

system
—
2011-06-16T13:31:19Z —
#15

Methinks you missed the entire point and meaning of my post.

zcorpan said:

No, you don't have to.

(re: wrapping header around things)

Then why have the extra element even exist in the spec in the first place.

zcorpan said:

No. Why would you? dfn and mark are different elements with different semantics.

(re: dfn vs. mark)This is what I mean by missing the point and meaning -- because I'm talking about writing it in the current RECOMMENDATION as a COMPARISON -- there is no "MARK" tag in HTML 4.01 STRICT. It's either going to end up having to be a DFN or a SPAN with a class if you aren't using HTML 5 yet. That's the POINT OF THAT SECTION you completely missed. There is no MARK in HTML 2, 3 or 4... So how COULD I choose MARK? Asking "why would you" doesn't even make SENSE there.

zcorpan said:

It's block level. No need to throw anything extra in footer.

Actually, it's block candidate -- the flow content requirement screwing up the DOM implementation; The scripting guys are (or were) last time arguing about that with the markup guys -- though I think a middle ground was reached where now it can be any flow content (so yer right for the time being, give it a week), you just can't use HEADER or FOOTER inside FOOTER... which is why you have heading abuse with that HGROUP nonsense using h2's to do SMALL's job.

Part of the problem with DRAFT, even stupid little tags are moving targets. Be real fun with no versioning to even keep track of changes to the "living document" idiocy... what's next? Maintaining a specification with CVS? No, that's NOT a suggestion, I'm being facetious.

zcorpan said:

No. You only use nav when you want AT users to be able to skip to or past your <nav> blocks. (Not that that is implemented in ATs yet.)

(re: throwing nav around things for no reason)Which puts another element on the DOM for nothing when we are starting to see things like google penalize us for excessive DOM elements... said excess elements slowing functions like getElementsByClassName to a crawl... all for what probably should have been an ATTRIBUTE instead... because at least then it could be a property of an existing tag that works just fine in legacy support, instead of some BS extra tag wrapping a bunch of code just to bloat it out.

zcorpan said:

It's nice isn't it?

Oh yes, the lack of versioning control and referencing to save a handful of bytes is just SO MUCH of an improvement... NOT. Mind you, I was never wild about the URL to the common dtd's being required, but trimming it down to the point where you don't even have versioning isn't the answer! (of course, it would be nice if browsers actually checked the DTD listed)

zcorpan said:

They do understand it.

No, they don't. I'm assuming you didn't know what I was referrring to, becuase THIS:

<meta charset="utf-8">

Is NOT understood by most browsers to mean the contents of the entire document, even the ones that allegedly support much of HTML 5. The only reason it MIGHT get picked up by older browsers is it being an unclosed tag... but since meta is a standalone that doesn't require a close in HTML 4... Yes, charset is a valid attribute, but is only applied to the contents of the tag it's on in older browsers!

Set your server to not send charset-encoding, use the HTML 5 meta -- hey, it's always iso-8859-1 in most every browser except firefox 3.6+ (doesn't even work in 3.5). Yeah, that works when you've saved as UTF-8, sure it does.

Which honestly is why I think that entire meta should be removed from having the validator ***** about it being missing -- if you're sending it with the right character encoding in the http header... Though admittedly for local testing where there is no HTTP, it does serve a purpose. (too bad the HTML 5 one doesn't work for that!)

As evidenced by using that one instead of the http-equiv version, and sending a local page for validation in Opera or even just viewing the page.

zcorpan said:

You don't have to use it.

Unless of course you actually care about your pages working in at least half the browsers currently in use -- which is where your "Oh it's only xx%" idiots will chime in with their "let's make the Internet not work for anyone that isn't me" crap.

zcorpan said:

You don't have to use h1 everywhere even when using section.

Again, I think you missed what I was saying -- I wasn't saying you "have to use h1's in sections" I'm saying "most headings become H1's if you use section, header, article, and footer" -- there's a difference.

IF you use heading tags by the new rules of HTML 5, the start of each section/article resets how you should be choosing them -- meaning there is little reason to even use lower order headings if you're bloating out the markup with section/article/header/footer...

Intstead of a h1 saying "root heading of which all other headings are subsections" followed by three h2, they all get turned into h1... defeating the point of even having numbered headings and basically boils down to catering to the people who never grasped or understood STRICT or semantic markup.

Of course I love the floating cdata in the UL in the demo, the paragraphs around non-paragraph elements, lack of list around an obvious list of choices...

Basically taking a dump on everything STRICT gave us.

clairs
—
2011-06-16T19:10:56Z —
#16

deathshadow60 said:

what's next? Maintaining a specification with CVS? No, that's NOT a suggestion, I'm being facetious.

No, they don't. I'm assuming you didn't know what I was referrring to, becuase THIS:

`

`

Is NOT understood by most browsers

Yes it is. That's why it was added to the spec, because it worked already.

deathshadow60 said:

Set your server to not send charset-encoding, use the HTML 5 meta -- hey, it's always iso-8859-1 in most every browser except firefox 3.6+ (doesn't even work in 3.5). Yeah, that works when you've saved as UTF-8, sure it does.

You must be doing something wrong with your testing.

deathshadow60 said:

Which honestly is why I think that entire meta should be removed from having the validator ***** about it being missing -- if you're sending it with the right character encoding in the http header...

Agreed. Validator.nu doesn't whine.

deathshadow60 said:

Though admittedly for local testing where there is no HTTP, it does serve a purpose. (too bad the HTML 5 one doesn't work for that!)

It should work for that (yes, even in old browsers).

deathshadow60 said:

As evidenced by using that one instead of the http-equiv version, and sending a local page for validation in Opera or even just viewing the page.

What is evidenced?

deathshadow60 said:

Again, I think you missed what I was saying -- I wasn't saying you "have to use h1's in sections" I'm saying "most headings become H1's if you use section, header, article, and footer" -- there's a difference.

You can have zero h1s and use section, header, article and footer. Or only one. Or half. Or all. It's up to you.

deathshadow60 said:

IF you use heading tags by the new rules of HTML 5, the start of each section/article resets how you should be choosing them -- meaning there is little reason to even use lower order headings if you're bloating out the markup with section/article/header/footer...

One reason is that you can make it degrade correctly in UAs and ATs that don't know about section elements.