HTML5 Review - My first attempt

HTML & CSS
1

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.

Thanks!


<!doctype html>
<html lang="en">
<head>
	<meta charset="utf-8">
	
	<title>HTML 5 Search Results</title>
	<meta name="description" content="HTML 5 Search Results">
	<meta name="author" content="Bryce Ray">
	
	<link rel="stylesheet" href="css/styles.css?v=1.0">
	
	<!--[if lt IE 9]>
		<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
	<![endif]-->
	
</head>
<body>

<!-- 
Embedded Within large website Template
-->

	<!-- Search Bar / Search Options -->
	<header>
	
		<!-- Switch between media search modes -->
		<ul id="search-nav"> <!-- Did not use <nav> because this navigation is secondary, it is not of "Primary Importance" -->
			<li>Content</li>
			<li>Images</li>
			<li>Media</li>
		</ul>
		
		<form id="search" method="post">
			<h1>Search Query</h1>
			<input type="search" id="search-text" name="search-text" autocomplete="off" list="search_list" autofocus required aria-required="true"> <!-- Turn off the default browser auto complete, auto focus to search on page load, text is required, use list below for custom auto complete -->
			<datalist id="search_list"> <!-- Custom Auto-Complete Functionality -->
				<option>Suggested Text1</option>
				<option>Suggested Text2</option>
				<option>Suggested Text3</option>
			</datalist>
			<a href="#">+ Advanced Search</a>
			<section class="advanced-search"> <!-- Initially Hidden -->
				<!-- Add advanced search form -->
			</section>
			<input type="submit" value="Search">
		</form>
	</header>
	
	<!-- Search Results -->
	<!-- Only one of the below sections will show at any given time.  Visibility would be toggled by #search-nav -->
	<!-- Should I use <h2> 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) -->
	<section id="search-content">
		<h1>Content Search Results</h1>
		<aside> <!-- Used for relevant Google-Like paid for advertisments -->
			<ol class="search-results search-ads"> <!-- Ordered list because content will be ordered by weighting -->
				<li>
					<header></header> <!-- Title of result -->
					<div class="preview"></div> <!-- Small sample of pages content -->
				</li>
			</ol>		
		</aside>
		<ol class="search-results"> <!-- Ordered list because content will be ordered by weighting -->
			<li>
				<header></header> <!-- Title of result -->
				<div class="preview">This is some page content with important <mark>keywords</mark></div> <!-- Small sample of pages content - use the <mark> to highlight a search term -->
			</li>
			<li>
				<header></header> <!-- Title of result -->
				<div class="preview">This is some page content with important <mark>keywords</mark></div> <!-- Small sample of pages content - use the <mark> to highlight a search term -->
			</li>
			<li>
				<header></header> <!-- Title of result -->
				<div class="preview">This is some page content with important <mark>keywords</mark></div> <!-- Small sample of pages content - use the <mark> to highlight a search term -->
			</li>
		</ol>
		<footer> <!-- Footer for the Search Results Section -->
			<ul class="pagination"> <!-- Not sure if I should use the <nav> element here -->
				<li><a href="#"></a></li>
				<li><a href="#"></a></li>
				<li><a href="#"></a></li>
			</ul>
		</footer>
	</section>
	
	<section id="search-images">
		<h1>Images Search Results</h1>
		<ol class="search-results"> <!-- Ordered list because content will be ordered by weighting -->
			<li>
				<div class="preview"></div> <!-- Small sample of pages content -->
			</li>
			<li>
				<div class="preview"></div> <!-- Small sample of pages content -->
			</li>
			<li>
				<div class="preview"></div> <!-- Small sample of pages content -->
			</li>
		</ol>
		<footer> <!-- Footer for the Search Results Section -->
			<ul class="pagination"> <!-- Not sure if I should use the <nav> element here -->
				<li><a href="#"></a></li>
				<li><a href="#"></a></li>
				<li><a href="#"></a></li>
			</ul>
		</footer>
	</section>
	
	<section id="search-media">
		<h1>Media Search Results</h1>
		<ol class="search-results"> <!-- Ordered list because content will be ordered by weighting -->
			<li>
				<div class="preview"></div> <!-- Small sample of pages content -->
			</li>
			<li>
				<div class="preview"></div> <!-- Small sample of pages content -->
			</li>
			<li>
				<div class="preview"></div> <!-- Small sample of pages content -->
			</li>
		</ol>
		<footer> <!-- Footer for the Search Results Section -->
			<ul class="pagination"> <!-- Not sure if I should use the <nav> element here -->
				<li><a href="#"></a></li>
				<li><a href="#"></a></li>
				<li><a href="#"></a></li>
			</ul>
		</footer>
	</section>
	<small>&copy; Some Random Search Engine</small>
<!--
End of Embedded Search Results
-->

	<script src="js/scripts.js"></script>
</body>
</html>
2

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.

Doing what you are using HTML 4.01 Strict, I’d end up with this:


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html	lang="en"><head>

<meta
	http-equiv="Content-Type"
	content="text/html; charset=utf-8"
>

<meta
	http-equiv="Content-Language"
	content="en"
>

<meta
	name="description"
	content="HTML 4 Strict Search Results"
>

<link
	type="text/css"
	rel="stylesheet"
	href="/theme/screen.css"
	media="screen,projection,tv"
>

<title>
	HTML 4.01 Search Results
</title>

</head><body>

<!-- 
	I'd have the outer div#pageWrapper in either HTML 4 or 5 for semi-fluid or other hooks
-->

<div id="pageWrapper">
	
	<h1>Site or page title of which ALL OTHER HEADINGS are subsections</h1>
 
	<ul id="topSearch">
		<li>Content</li>
		<li>Images</li>
		<li>Media</li>
	</ul>
				
	<form id="search" method="post">
		<fieldset>
			<legend><span>Search Query</span></legend>
			<!-- span inside legend is due to legend being unreliable on taking CSS styling -->
			<label for="topSearchText">Enter Search Term Here...</label>
			<input type="search" name="search-text" >
			<input type="submit" value="Search" class="submit">
			<a href="#">Advanced Search</a>
		</fieldset>
	</form>
	
	<div id="contents">
	
		<div id="textResults">
		
			<h2>Text Search Results for "<dfn>Stripped</dfn>"</h2>
			
			<h3>Title Of Result</h3>
			<p>
				Put content into a paragraph <dfn>stripped</dfn> probably tag stripped and truncated at 256 characters. (seems the current trend). Yes, I realize this is technically DFN abuse... but using the "defining instance" as what the search is for makes some sense. 
			</p>
			
			<h3>Title Of Result</h3>
			<p>
				I wouldn't even bother with making these a list as these are not "bullet point" items the moment you have more than one set of block level containers inside them. If you can put a heading tag on it, that's when you stop using lists IMHO. List <dfn>Stripped</dfn> we still have semantic meaning by just using heading tags properly!
			</p>
	
			<h3>Title Of Result</h3>
			<p>
				Which is how the code can be <dfn>stripped</dfn> down so much. 
			</p>
			
			<ul class="pagination">
				<li>1</li>
				<li><a href="#">2</a></li>
				<li><a href="#">3</a></li>
				<li><a href="#">Last</a></li>
			</ul>
			
		<!-- #textResults --></div>
	 
		<div id="imageResults">
			<h2>Images Search Results for "<dfn>Stripped</dfn>"</h2>
			<ol><!-- these items are small enough to be list items -->
				<li>
					<a href="#">
						<img src="http://www.sitepoint.com/forums/images/result1Thumb.png" alt="thumbnail description" >
						Brief text describing this
					</a>
				</li><li>
					<a href="#">
						<img src="http://www.sitepoint.com/forums/images/result2Thumb.png" alt="thumbnail description" >
						Brief text describing this
					</a>
				</li><li>
					<a href="#">
						<img src="http://www.sitepoint.com/forums/images/result3Thumb.png" alt="thumbnail description" >
						Brief text describing this
					</a>
				</li> 	
			</ol>
			
			<ul class="pagination">
				<li>1</li>
				<li><a href="#">2</a></li>
				<li><a href="#">3</a></li>
				<li><a href="#">Last</a></li>
			</ul>
			
		<!-- #imageResults --></div>
		
		<div id="mediaResults">
		
			<h2>Media Search Results for "<dfn>Stripped</dfn>"</h2>
			
			<ol><!-- these items are small enough to be list items -->
				<li id="imageResult1">
					<a href="#">
						<img src="http://www.sitepoint.com/forums/images/result1Thumb.png" alt="thumbnail description" >
						Brief text describing this
					</a>
				</li>
				<li id="imageResult2">
					<a href="#">
						<img src="http://www.sitepoint.com/forums/images/result2Thumb.png" alt="thumbnail description" >
						Brief text describing this
					</a>
				</li>
				<li id="imageResult3">
					<a href="#">
						<img src="http://www.sitepoint.com/forums/images/result3Thumb.png" alt="thumbnail description" >
						Brief text describing this
					</a>
				</li> 	
			</ol>
			
			<ul class="pagination">
				<li>1</li>
				<li><a href="#">2</a></li>
				<li><a href="#">3</a></li>
				<li><a href="#">Last</a></li>
			</ul>
			
		<!-- #mediaResults --></div>
		
	<!-- #content --></div>
	
	<div id="advertisingResults">
	
		<h2>Advertisements</h2>
		<!-- 
			adverts go here, I would NOT put them before actual content in source order as that just pisses off people on small screen, NOR would I put a ordered list around them. 
		-->
		
	<!-- #advertisingResults --></div>
	
	<div id="footer">
		&copy; Some Random Search Engine
	</div>
	
<!-- #pageWrapper --></div>	

<script type="text/javascript" src="js/scripts.js"></script>

</body></html>

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…


<!doctype html>
<html lang="en"><head>

<meta charset="utf-8">

<meta
	name="description"
	content="HTML 4 Strict Search Results"
>

<link
	type="text/css"
	rel="stylesheet"
	href="/theme/screen.css"
	media="screen,projection,tv"
>

<!--[if lt IE 9]>
	<script
		type="text/javascript"
		src="http://html5shiv.googlecode.com/svn/trunk/html5.js"
	></script>
<![endif]-->

<title>
	HTML 5 Search Results
</title>

</head><body>

<!-- 
	I'd have the outer div#pageWrapper in either HTML 4 or 5 for semi-fluid or other hooks
-->

<div id="pageWrapper">
	
	<header>
	
		<h1>Site or page title of which ALL OTHER HEADINGS are subsections</h1>
		
		<nav> 
			<ul id="topSearch">
				<li>Content</li>
				<li>Images</li>
				<li>Media</li>
			</ul>
		</nav>
				
		<form id="search" method="post">
			<fieldset>
				<legend><span>Search Query</span></legend>
				<!-- span inside legend is due to legend being unreliable on taking CSS styling -->
				<label for="topSearchText">Enter Search Term Here...</label>
	 			<input type="search" id="topSearchText" name="search-text" autocomplete="off" list="search_list" autofocus required aria-required="true">
	      <datalist id="search_list">
	          <option>Suggested Text1</option>
	          <option>Suggested Text2</option>
	          <option>Suggested Text3</option>
	      </datalist>			
				<input type="search" name="search-text" >
				<input type="submit" value="Search" class="submit">
				<a href="#">Advanced Search</a>
			</fieldset>
		</form>
		
	</header>
	
	<div id="contents">
	
		<section id="textResults">
		
			<header>
				<h1>Text Search Results for "<dfn>Stripped</dfn>"</h1>
			</header>
			
			<section>
				<header>
					<h1>Title Of Result</h1>
				</header>
				<p>
					Put content into a paragraph <dfn>stripped</dfn> probably tag stripped and truncated at 256 characters. (seems the current trend). Yes, I realize this is technically DFN abuse... but using the "defining instance" as what the search is for makes some sense. 
				</p>
			</section>
			
			<section>
				<header>
					<h1>Title Of Result</h1>
				</header>
				<p>
					I wouldn't even bother with making these a list as these are not "bullet point" items the moment you have more than one set of block level containers inside them. If you can put a heading tag on it, that's when you stop using lists IMHO. List <dfn>Stripped</dfn> we still have semantic meaning by just using heading tags properly!
				</p>
			</section>
			
			<section>
				<header>
					<h1>Title Of Result</h1>
				</header>
				<p>
					Which is how the code can be <dfn>stripped</dfn> down so much. 
				</p>
			</section>
			
			<footer>
				<nav>
					<ul class="pagination">
						<li>1</li>
						<li><a href="#">2</a></li>
						<li><a href="#">3</a></li>
						<li><a href="#">Last</a></li>
					</ul>
				</nav>
			</footer>
			
		<!-- #textResults --></section>
	 
		<section id="imageResults">
		
			<header>
				<h1>Images Search Results for "<dfn>Stripped</dfn>"</h1>
			</header>
			
			<ol><!-- these items are small enough to be list items -->
				<li>
					<a href="#">
						<img src="http://www.sitepoint.com/forums/images/result1Thumb.png" alt="thumbnail description" >
						Brief text describing this
					</a>
				</li><li>
					<a href="#">
						<img src="http://www.sitepoint.com/forums/images/result2Thumb.png" alt="thumbnail description" >
						Brief text describing this
					</a>
				</li><li>
					<a href="#">
						<img src="http://www.sitepoint.com/forums/images/result3Thumb.png" alt="thumbnail description" >
						Brief text describing this
					</a>
				</li> 	
			</ol>
		
			<footer>	
				<nav>
					<ul class="pagination">
						<li>1</li>
						<li><a href="#">2</a></li>
						<li><a href="#">3</a></li>
						<li><a href="#">Last</a></li>
					</ul>
				</nav>
			</footer>
			
		<!-- #imageResults --></section>
		
		<section id="mediaResults">
		
			<header>
				<h1>Media Search Results for "<dfn>Stripped</dfn>"</h1>
			</header>
			
			<ol><!-- these items are small enough to be list items -->
				<li id="imageResult1">
					<a href="#">
						<img src="http://www.sitepoint.com/forums/images/result1Thumb.png" alt="thumbnail description" >
						Brief text describing this
					</a>
				</li>
				<li id="imageResult2">
					<a href="#">
						<img src="http://www.sitepoint.com/forums/images/result2Thumb.png" alt="thumbnail description" >
						Brief text describing this
					</a>
				</li>
				<li id="imageResult3">
					<a href="#">
						<img src="http://www.sitepoint.com/forums/images/result3Thumb.png" alt="thumbnail description" >
						Brief text describing this
					</a>
				</li> 	
			</ol>
			
			<footer>
				<nav>
					<ul class="pagination">
						<li>1</li>
						<li><a href="#">2</a></li>
						<li><a href="#">3</a></li>
						<li><a href="#">Last</a></li>
					</ul>
				</nav>
			</footer>
			
		<!-- #mediaResults --></section>
		
	<!-- #content --></div>
	
	<section id="advertisingResults">
		<header>
			<h1>Advertisements</h1>
		</header>
		<!-- 
			adverts go here, I would NOT put them before actual content in source order as that just pisses off people on small screen, NOR would I put a ordered list around them. 
		-->
		
	<!-- #advertisingResults --></section>
	
	<footer id="pageFooter">
		<p>
			&copy; Some Random Search Engine
		</p>
	</footer>
	
<!-- #pageWrapper --></div>	

<script type="text/javascript" src="js/scripts.js"></script>

</body></html>

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.

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.

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.

5

Nice comparison, Jason, and nice reply, bar338. :slight_smile:

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

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.

6

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.

7

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.

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.

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

<input type=“search” id=“search-text” name=“search-text” autocomplete=“off” list=“search_list” autofocus required aria-required=“true”>

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 :slight_smile:
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).


        <ul id="search-nav">
            <li>Content</li>
            <li>Images</li>
            <li>Media</li>
        </ul>

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

9

Oh:

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.

(example within a generated slider)
role=“slider” aria-labelledby=“label_handle_valueA” aria-valuemin=“0” aria-valuemax=“71” aria-valuenow=“7” aria-valuetext=“Aug 03”

10

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

<form role="search" ...>
11

Not sure what I had added to my coffee there…

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.

12

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.

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.

14

No, you don’t have to.

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

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

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

It’s nice isn’t it? :slight_smile:

They do understand it.

You don’t have to use it.

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

15

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

(re: wrapping header around things)

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

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

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.

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

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)

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.

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.

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…

Hence the demo code in the spec:

<body>
 <h1>The Wiki Center Of Exampland</h1>
 <nav>
  <ul>
   <li><a href="/">Home</a></li>
   <li><a href="/events">Current Events</a></li>
   ...more...
  </ul>
 </nav>
 <article>
  <header>
   <h1>Demos in Exampland</h1>
   <p>Written by A. N. Other.</p>
  </header>
  <nav>
   <ul>
    <li><a href="#public">Public demonstrations</a></li>
    <li><a href="#destroy">Demolitions</a></li>
    ...more...
   </ul>
  </nav>
  <div>
   <section id="public">
    <h1>Public demonstrations</h1>
    <p>...more...</p>
   </section>
   <section id="destroy">
    <h1>Demolitions</h1>
    <p>...more...</p>
   </section>
   ...more...
  </div>
  <footer>
   <p><a href="?edit">Edit</a> | <a href="?delete">Delete</a> | <a href="?Rename">Rename</a></p>
  </footer>
 </article>
 <footer>
  <p><small>© copyright 1998 Exampland Emperor</small></p>
 </footer>
</body>

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.

16

Oops

17

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

You must be doing something wrong with your testing.

Agreed. Validator.nu doesn’t whine.

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

What is evidenced?

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

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

18

Yeah, most W3C specs are in fact in CVS (W3C Public CVS Repository). WHATWG uses Subversion though ([url=http://svn.whatwg.org/]Subversion server for WHATWG).

19

When y’all gonna git with the times? : D

For us regular, normal web developers, Let’s stick to using properly-leveled headers for now.

20

Mercurial repositories index :stuck_out_tongue: