SitePoint Sponsor

User Tag List

Page 1 of 3 123 LastLast
Results 1 to 25 of 64
  1. #1
    SitePoint Addict
    Join Date
    May 2008
    Location
    Missouri, USA
    Posts
    273
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    HTML5 Review - My first attempt

    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!

    Code HTML4Strict:
    <!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>
    Follow Me On Twitter: BryceRay

  2. #2
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    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:
    Code:
    <!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...

    Code:
    <!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. #3
    SitePoint Addict
    Join Date
    May 2008
    Location
    Missouri, USA
    Posts
    273
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.
    Follow Me On Twitter: BryceRay

  4. #4
    SitePoint Wizard bronze trophy Black Max's Avatar
    Join Date
    Apr 2007
    Posts
    4,029
    Mentioned
    12 Post(s)
    Tagged
    0 Thread(s)
    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. #5
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,168
    Mentioned
    454 Post(s)
    Tagged
    8 Thread(s)
    Nice comparison, Jason, and nice reply, bar338.

    Quote Originally Posted by bar338 View Post
    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:

    Quote Originally Posted by deathshadow60 View Post
    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.

  6. #6
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ralph.m View Post
    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.

  7. #7
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,168
    Mentioned
    454 Post(s)
    Tagged
    8 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    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.

  8. #8
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,276
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    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 : )

    <ul id="search-nav"> <!-- Did not use <nav>
    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.

    Quote Originally Posted by Crusty
    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).

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

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

    <ul class="pagination"> <!-- Not sure if I should use the <nav>
    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).

    Code:
            <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. #9
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,276
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Oh:
    Quote Originally Posted by Crusty
    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.

    (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. #10
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,168
    Mentioned
    454 Post(s)
    Tagged
    8 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    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:

    Code:
    <form role="search" ...>

  11. #11
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,276
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Not sure what I had added to my coffee there...
    Quote Originally Posted by me
    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.

  12. #12
    SitePoint Wizard rguy84's Avatar
    Join Date
    Sep 2005
    Location
    Durham, NC
    Posts
    1,659
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bar338 View Post
    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.
    Ryan B | My Blog | Twitter

  13. #13
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,276
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    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. #14
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    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.

    Quote Originally Posted by deathshadow60 View Post
    swap DFN for Mark,
    No. Why would you? dfn and mark are different elements with different semantics.

    Quote Originally Posted by deathshadow60 View Post
    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.

    Quote Originally Posted by deathshadow60 View Post
    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.)

    Quote Originally Posted by deathshadow60 View Post
    lip service doctype
    It's nice isn't it?

    Quote Originally Posted by deathshadow60 View Post
    and a character encoding meta older browsers don't even understand (so they fall back on the http headers),
    They do understand it.

    Quote Originally Posted by deathshadow60 View Post
    the need for that scripting shiv idiocy that breaks most of the time anyways...
    You don't have to use it.

    Quote Originally Posted by deathshadow60 View Post
    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.
    Simon Pieters

  15. #15
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Methinks you missed the entire point and meaning of my post.
    Quote Originally Posted by zcorpan View Post
    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.

    Quote Originally Posted by zcorpan View Post
    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.

    Quote Originally Posted by zcorpan View Post
    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.

    Quote Originally Posted by zcorpan View Post
    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.

    Quote Originally Posted by zcorpan View Post
    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)

    Quote Originally Posted by zcorpan View Post
    They do understand it.
    No, they don't. I'm assuming you didn't know what I was referrring to, becuase THIS:
    Code:
    <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.

    Quote Originally Posted by zcorpan View Post
    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.

    Quote Originally Posted by zcorpan View Post
    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...

    Hence the demo code in the spec:
    Code:
    <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. #16
    SitePoint Enthusiast
    Join Date
    Jul 2010
    Posts
    93
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    what's next? Maintaining a specification with CVS? No, that's NOT a suggestion, I'm being facetious.
    Oops

  17. #17
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    No, they don't. I'm assuming you didn't know what I was referrring to, becuase THIS:
    Code:
    <meta charset="utf-8">
    Is NOT understood by most browsers
    Yes it is. That's why it was added to the spec, because it worked already.

    Quote Originally Posted by deathshadow60 View Post
    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.

    Quote Originally Posted by deathshadow60 View Post
    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.

    Quote Originally Posted by deathshadow60 View Post
    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).

    Quote Originally Posted by deathshadow60 View Post
    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?

    Quote Originally Posted by deathshadow60 View Post
    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.

    Quote Originally Posted by deathshadow60 View Post
    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.
    Simon Pieters

  18. #18
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by clairs View Post
    Yeah, most W3C specs are in fact in CVS (W3C Public CVS Repository). WHATWG uses Subversion though (Subversion server for WHATWG).
    Simon Pieters

  19. #19
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,276
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    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. #20
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    When y'all gonna git with the times? : D
    Mercurial repositories index
    Simon Pieters

  21. #21
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by zcorpan View Post
    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.
    Why would it even work -- charset only applies to the tag it is declared on -- you can even use it to MIX character encodings inside a document (what it's for) -- putting it on a meta does absolutely NOTHING in browsers that don't know 5, and many that allegedly do!

    Now, if it was on a tag that wrapped some content... like say... HTML? Of course that wouldn't work either since in HTML 4 (and browsers designed for it) the ONLY TAG that has the charset attribute is ANCHOR... which is why on a standalone tag like META where prior to HTML 5 there is no charset attribute there is no way that should/would/could or even does work... So unless you're setting it in your HTTP header, you're not gonna have much success with it.

    Quote Originally Posted by zcorpan View Post
    What is evidenced?
    The entire preceeding two paragraphs to the statement and everything I just said above?

    You can have zero h1s and use section, header, article and footer. Or only one. Or half. Or all. It's up to you.
    AGAIN, you missed what I'm saying. I AGREE with what you just said -- that does not conflict or preclude what I'm saying. What I'm saying is that IF you use numbered headings and IF you use those tags, they all become h1's because the count gets reset every time you open one of those new tags.

    So where you would have in HTML 4
    Code:
    <h1>Topmost title of which all other headings are subsections</h1>
    
    <div id="content">
    
    	<div class="section">
    	
    		<h2>Start of section 1</h2>
    		<p>Some text describing the subsection</p>
    		
    		<div class="subSection">
    			<h3>Start of a subsection of section 1</h3>
    			<p>Some Text</p>
    		<!-- .subSection --></div>
    	
    		<div class="subSection">
    			<h3>Start of a subsection of section 1</h3>
    			<p>Some Text</p>
    		<!-- .subSection --></div>
    		
    	<!-- .section --></div>		
    	
    	<div class="section">
    	
    		<h2>Start of section 2</h2>
    		<p>Some text describing the subsection</p>
    		
    		<div class="subSection">
    			<h3>Start of a subsection of section 2</h3>
    			<p>Some Text</p>
    		<!-- .subSection --></div>
    	
    		<div class="subSection">
    			<h3>Start of a subsection of section 2</h3>
    			<p>Some Text</p>
    		<!-- .subSection --></div>
    		
    	<!-- .section --></div>		
    	
    <!-- #content --></div>
    With HTML 5 you end up with

    Code:
    <h1>Topmost title of which all other headings are subsections</h1>
    
    <div id="content">
    
    	<section>
    	
    		<h1>Start of section 1</h1>
    		<p>Some text describing the section</p>
    		
    		<article>
    			<h1>Start of a subsection of section 1</h1>
    			<p>Some Text</p>
    		</article>
    	
    		<article>
    			<h1>Start of a subsection of section 1</h1>
    			<p>Some Text</p>
    		</article>
    		
    	</section>
    	
    	<section>
    	
    		<h1>Start of section 2</h1>
    		<p>Some text describing the section</p>
    	
    		<article>
    			<h1>Start of a subsection of section 2</h1>
    			<p>Some Text</p>
    		</article>
    
    		<article>
    			<h1>Start of a subsection of section 2</h1>
    			<p>Some Text</p>
    		</article>
    	
    <!-- #content --></div>
    I'm not saying you have to use them {endless string of frustrated expletives omitted} you {even nastier long string of expletives and personal insults about your family and level of education} Joking -- <ducky>it's called a sense of humor, you should try one, it's nice!</ducky> -- I'm saying that if for semantic reasons you are using headings, the presence of heading, section, footer, and article reset them all into being H1's instead of maintaining the cascade that actually made numbered headings make SENSE... NOT that anyone actually bothered using them properly which is probably WHY HTML 5 took that route... at which point ditch the numbered heading tags alltogether as they no longer serve a purpose; Just use HEADER instead. Header vs. Heading -- redundant pointless BULL.

    Quote Originally Posted by zcorpan View Post
    One reason is that you can make it degrade correctly in UAs and ATs that don't know about section elements.
    You're missing the point, by the rules of HTML 5, using lower order headings like you are supposed to in HTML 4 is as broken/nonsensical as skipping heading numbers and having multiple h1's under the old specs! You cater to the older UA's by using lower order numbers, you're telling HTML 5 structure where to stick it -- you use the rules for HTML 5 structure, you're telling older UA's where to stick it... All because most people are too malfing stupid to understand the numbered heading tags in the first place! Something so simple a 2nd grader could probably grasp it -- but with people these days graduating high school with the equivalent of a fourth grade education circa 1980, I really shouldn't be shocked by this.

    I really don't think you've grasped what I'm saying, that or you are being deliberately obtuse on this... Are you joking and I missed the joke?

  22. #22
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    <header> is different to the <hx> tags, you can't just use one instead of the other...

    *grabs popcorn*

  23. #23
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    Why would it even work
    It works because people have historically used stuff like
    Code:
    <META HTTP-EQUIV=CONTENT-TYPE CONTENT=text/html; charset=windows-1251>
    ...and expect it to work in browsers, so they sucked it up long before HTML5.

    Quote Originally Posted by deathshadow60 View Post
    -- charset only applies to the tag it is declared on
    No, <meta charset=...> and <meta http-equiv="content-type" content="text/html; charset=..."> applies to the whole page.

    Quote Originally Posted by deathshadow60 View Post
    -- you can even use it to MIX character encodings inside a document (what it's for)
    No you can't.

    Quote Originally Posted by deathshadow60 View Post
    -- putting it on a meta does absolutely NOTHING in browsers that don't know 5, and many that allegedly do!
    It changes the character encoding of the document (unless there's a BOM or HTTP content-type charset), that's what it does.

    Quote Originally Posted by deathshadow60 View Post
    Now, if it was on a tag that wrapped some content...
    Please leave your sense of logic at the door, thanks!

    Quote Originally Posted by deathshadow60 View Post
    The entire preceeding two paragraphs to the statement and everything I just said above?
    OK. The statements were wrong so the evidence has to be bogus.

    Quote Originally Posted by deathshadow60 View Post
    AGAIN, you missed what I'm saying. I AGREE with what you just said --
    OK, then no need to discuss it further I guess.

    Quote Originally Posted by deathshadow60 View Post
    You're missing the point, by the rules of HTML 5, using lower order headings like you are supposed to in HTML 4 is as broken/nonsensical as skipping heading numbers and having multiple h1's under the old specs!
    I disagree. It's allowed by the spec and makes perfect sense if you care about legacy UAs/ATs.

    Quote Originally Posted by deathshadow60 View Post
    You cater to the older UA's by using lower order numbers, you're telling HTML 5 structure where to stick it --
    The HTML5 structure is identical (by design), so I'm sure it won't mind.

    Quote Originally Posted by deathshadow60 View Post
    I really don't think you've grasped what I'm saying, that or you are being deliberately obtuse on this... Are you joking and I missed the joke?
    I'm just trying to correct misconceptions.
    Simon Pieters

  24. #24
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by zcorpan View Post
    Yeah, most W3C specs are in fact in CVS (W3C Public CVS Repository). WHATWG uses Subversion though (Subversion server for WHATWG).
    Which again I don't think people got my joke -- That was a "oh wait, too late"; an indication of the idiotic levels the "specification" has reached. I was being flippant, indicating they had already done so. (hence the word facetious?) When a specification for something as simple as HTML is big enough to warrant SVN, it may just be time to pitch it in the trash and start over.

    Interesting history of HTML specs though, as formatted web pages:

    HTML 2 - 11k (flat)
    HTML 3.2 - 122k (+32k of images)
    HTML 4 - 53k (+3k images + 3k CSS)
    HTML 5 - 4,824K (+601k images +2k CSS)

    Oh yeah, some real "improvements" there. When a specification goes from the size of the Declaration of Independance to larger than the KJV with a ribbon bookmark, it MAY be time to consider it a wee bit overcooked.

    Admittedly, MUCH of that is all the NON-HTML stuff they've thrown under the HTML 5 banner -- but still, we're supposed to be taking web development queue's from a group that publishes the new standard as a single 5 meg website? Much less it was bad enough the endless legalese the earlier specs were written in -- Without the markup as flat plaintext it's still 2.3 megabytes; The equivalent of ten sitepoint books or four James A. Michener novels... NOBODY except total nutjobs are going to actually read that as a technical specification!!! Lands sake the technical manuals for a F-16 are smaller COMBINED... and trust me, a Viper (Falcon for you gropo's, "Fighting Falcon" for the civvie pukes) is and should be significantly more complex than something as moronically simple as HTML should be.

    Probably why every time someone says "uh-uh" or talks about HTML 5, I can point them at where the spec says "uhm, no..." or at the very least does the exact opposite in their examples.... I'm one of the few crazy {string of expletives again omitted} far enough out there to even ATTEMPT reading it end to end.

    Which I have.... and of course by the time I finished it a hefty part of the content I'd read had already changed. The problem with using anything that's still in DRAFT.

  25. #25
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by zcorpan View Post
    It works because people have historically used stuff like
    Code:
    <META HTTP-EQUIV=CONTENT-TYPE CONTENT=text/html; charset=windows-1251>
    ...and expect it to work in browsers, so they sucked it up long before HTML5.
    The global structure of an HTML document

    Is not, has not, nor ever has been part of the HTML 4 or 3.2 specification as a valid attribute on META. The only place that ever existed as a fully working element was Netscape 4, which by extension Gecko picked up... IE kind-of mimicked it, but doesn't set the value properly in the DOM completely shtupping scripts who will do things like read innerHTML as the wrong encoding.

    Does NOT work in Opera, Does NOT work in Webkit, Does NOT work properly in IE (though it tries)... Only place it works is in Gecko based browsers, which makes sense them being Netscape 4's sweetly retarded cousin and all.

    It's a perfect example of undoing everything HTML 4 STRICT was about... like say... using the actual HTTP commands to do ****. You know in theory ANY response header element should be able to be sent that way? Of course browser makers dragged their heels on actually doing it -- so much like Object they'll throw it in the trash for some other technique that they'll never agree on implementing the same way.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •