Re: Semantic HTML5

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Osmo Saarikumpu wrote:

Quoted text here. Click to load it

Thanks for the warning, although it would have been better if you brought  
along sound arguments instead.

Quoted text here. Click to load it

Apparently you mistake a stance of being convinced about something for good  
reasons and not being convinceable by fallacious or otherwise poor counter-
arguments for following some sort of irrational cult.  That way lies madness  
the same as in the opposite direction.  Free your mind.

Quoted text here. Click to load it

That introduction was written in 2009 and last updated in 2011.  It is 2013  
and the summary is out of date, if it ever was exact.

You do _not_ have to detect HTML5.  Just use it where appropriate *and* be  
conscious of the fact that there are still some user agents which do not  
support it as such.

A problem here is that many features that actually have nothing to do with  
the markup language and the API associated with it, are subsumed under the  
same name because it sounds cool.  Geolocation is _not_ part of the HTML5  
API, for example.


Quoted text here. Click to load it

No.  You are confusing ?generic? with ?meaningless?; as it happens that
is a  
matter of semantics, the study of the meaning of words.  IOW, you are  
showing a poor understanding of semantics, which does not bode well for you  
to be in a position to tell what semantic (markup) is.  Sorry.

Quoted text here. Click to load it

No; for a start, by contrast to ?div?, ?section? is _not_ intended to be
used as a block element.
Quoted text here. Click to load it

While headings of different levels imply the beginning of a section, it is  
harder for parsers to recognize that, and ?div? elements to work around that
are not always an adequate replacement.  Which is where the ?section?  
element comes in.

A ?section? element has a required start-tag and end-tag.  What is *between*
those tags is the content of the section.  So it is very clearly delimited,  
and so it can be processed in a structured way without a full-blown HTML  
parser.  Given the complexity of proper HTML parsing as broken down in the  
HTML5 Specification, this is a Good Thing.
Quoted text here. Click to load it

More, as ?div? elements have come to be used they did not bear any  
semantics.  In HTML5 they are *supposed to* not bear any additional  
semantics because if you want that there are better element types:


Did you *intend* a ?div? element to be a section of text or was it just to  
work around the shortcomings of some layout engines (like MSHTML who ?  
according to CSS 2.1 ? miscalculates the offset width of an element when it  
has padding and width defined, so you better use margins on a parent element  

Quoted text here. Click to load it

A horizontal rule amidst running text not only is asthetically displeasing  
(which is a matter of opinion, but typographers would agree), but also  
rather hard to style uniformly (about which there cannot be debate).  It is  
also not indicative of the end of a section; it may be used for that, but  
historically and practically it has not (it has been more often used to  
delimit headers and footers).  For example, you will not find any horizontal  
rule in a quality scientific work except in tables and to delimit the page  
header and footer from the main content.  Because if it would be used for  
that, it would beg the question *which* section would be ended thus.  (Would  
we not need different horizontal rules for structurally differently nested  
sections?  That way lies madness.)

Quoted text here. Click to load it

And now all users of HTML5-capable user agents can navigate from elements  
that are not necessarily links or form controls if they have the there-
formerly proprietary ?tabindex? attribute specified.  Again, a Good Thing  
because sometimes you need to use such element types in a Web application.

Quoted text here. Click to load it

Can you not tell?  The more general one for navigation is the major one.  In  
a Web site, that would be the navigation that takes you to other, different  
parts of a Web site.  You could compare that (and people have implemented it  
so) with a table of contents as opposed to a footnote or a ?turn the page?  

On the other hand, there is no requirement that there be only one ?nav?  
element in a document.

Quoted text here. Click to load it

That is WHATWG HTML, the ?Living Standard?; not HTML5.  There are several  
people that hold that a technical specification that is forever changing,  
without snapshots to be identified and referred to, is not a technical  
specification at all, and certainly cannot qualify as being a Web standard.  
I am one of them; therefore, I am pleased that the W3C Process for HTML5 is  
continuing without a single, necessarily biased editor.
Quoted text here. Click to load it

It is only you.

Quoted text here. Click to load it

Yes, they are not.  Consider the user.

Quoted text here. Click to load it

< (fallacy)>
Quoted text here. Click to load it

The length of the element type name notwithstanding, whenever has additional  
semantics made something shorter?

Besides, that is probably  
< .  Certainly it is a  
fallacy, but I do not know for sure which one.
Quoted text here. Click to load it

Your logic is flawed.
Quoted text here. Click to load it

That is right, because apparently you do not understand (the value of)  
semantics in the first place.

Bottom line: The train has left the station, and you are barking up the  
wrong tree.  Not only are elements and attributes of HTML5 supported by  
browsers (particularly the mobile versions), but also HTML5 (finally) is a  
(non-WHATWG-driven) W3C *CR* now.

So you better learn how to use it properly; that is, carefully to your and  
your user's (potential) advantage.  As it has been before with HTML 4.01,  
but this time with fewer limitations.

var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

Site Timeline