ElkArte Community Modern, Free, Powerful
Community building forum software

Quote from: Xarcell – June 28, 2013, 10:08:32 amInteresting thoughts here. I would like to share my own...

Article tag should definitely be used. The W3C Spec says this:

QuoteThe article element represents a component of a page that consists of a self-contained composition in a document, page, application, or site and that is intended to be independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content.

"Syndication", "reuseable" and "form post" being the keys words here.

QuoteI agree that "catbg" and "titlebg" should not even be used anymore. It would be more appropriate to use the body class in conjunction with the header element. Example:

.action_messageindex h2, .action_home h2, .action_search h2 {
  background: green;
}

QuoteAs far as the windowbg and windowbg2, I think they should be renamed to "content_bg" and "post_bg", not "postbg" and "postbg2", because not all areas which use the class is a post. I personally hate using numbers in classes unless it's semantically necessary such as a board number or topic number. Note, that you could also use "content_stn", "content_alt", and "post_stn" "post_alt" for more added flexibility(stn = standard).

QuoteThe problem is, if you read the actual HTML5 specification, the elements in HTML5 are defined in a way that has little to do with how we have traditionally used them.

On the one hand, Hickson has introduced a whole new concept of structuring a web page in HTML5 with sectioning elements. On the other, Hickson is comparing his HTML5 sectioning elements to classes used in the wild with no understanding of what those classes were actually used for.

QuoteHTML5 wants to be backwards compatible, so the WHATWG decided not to introduce an h element (despite introducing a bunch of new sectioning elements), and instead wants to repurpose the h1 element to be the generic h element. Use h1 everywhere, and let the HTML5 outlining algorithm determine its true level… or so the theory goes.

This is a terrible idea for several reasons, the two main ones being accessibility and styling.

Accessibility

Using h1 everywhere is very bad for accessibility. Blind users rely heavily on the heading structure of a site. It’s important for all of us to be reminded of just how crucial heading structure is for accessibility purposes. For instance, a December 2008 survey of over 1000 screen reader users conducted by WebAIM found that 76% of blind and vision-impaired users ‘always or often’ navigated by headings when they were available. And a May 2012 survey found that 82.1% heading levels were ‘very useful’ or ‘somewhat useful’ when navigating a web page. (This is good, practical research, so take note.)

<snip>

Styling

But it gets worse. Lets say we want to run with a pure HTML5 outline, and we use h1s everywhere. Remember, in the HTML5 spec the h1 is just a generic h element; its real level is determined by how deeply its nested in sectioning elements.

So how do we style it? Well, we could add class names to all our h1 elements so we can pick them out, but that is contrary to the stated HTML5 goal of simplifying authoring; and we may as well stick to h1-h6 (all of which are treated as generic h elements in a HTML5 outline).

Here’s the generic style for an h3 element:

Code: [Select]

article aside nav h1, article aside section h1, 
 article nav aside h1, article nav section h1, 
 article section aside h1, article section nav h1, article section section h1, 
 aside article nav h1, aside article section h1, 
 aside nav article h1, aside nav section h1, 
 aside section article h1, aside section nav h1, aside section section h1, 
 nav article aside h1, nav article section h1, 
 nav aside article h1, nav aside section h1, 
 nav section article h1, nav section aside h1, nav section section h1, 
 section article aside h1, section article nav h1, section article section h1, 
 section aside article h1, section aside nav h1, section aside section h1, 
 section nav article h1, section nav aside h1, section nav section h1, 
 section section article h1, section section aside h1, section section nav h1, section section section h1 { 
    font-size: 1.00em; 
 }

Yet that’s what HTML’s structural elements give us. What a mess.

QuoteIt’s reasonable to suggest that perhaps user agents in the future, such as browsers and screen readers, will do more with HTML5′s structural elements, and that will make them more palatable to us as authors.

Opera’s Bruce Lawson suggested just that on the WHATWG mailing list in 2009:

    "After all, I know of no user agents that can use time, section, footer, datagrid etc but we mostly expect there to be soon.“

And here’s what Hickson, the HTML5 editor, said in reply:

   " I don’t. Most of the new elements are just meant to make styling easier, so that we don’t have to use classes.“

All that, and the editor doesn’t see user agents ever even using these elements. They are there, he says, to save us from using classes. Put another way, the creator of these elements seems unsure why they’re even in the spec, save ‘making styling easier’.

QuoteConclusions

Let’s wrap up with some conclusions.

    Headings matter: first, we should really care about the heading structure of our pages to help out blind and vision-impaired users trying to get around with screen readers. The venerable h1-h6 elements may be limited, but they’re relied on heavily by screen reader users.

    HTML5 structure is a mess: we should probably ignore HTML structural elements altogether. They’ve been a bit of a disaster — we have essentially forked the spec, created plenty of broken outlines, and wasted too much time already trying to get our heads around a fundamentally broken system. Long live divs.

    Consider ARIA landmarks: adding ARIA landmarks to your site is another simple, effective way of helping screen reader users.

    Consider schema.org and the future of semantics: schema.org has the backing of the major search engines, and while it’s certainly a mixed bag at the moment, it seems to be future for structured data on the web.

There are lots of good parts in the HTML5 specification, from new forms features to the History API and Canvas implementation. In fact, without the WHATWG, who have been the driving force behind HTML5, we’d still be stuck with HTML4/XHTML 1.0 while we waited for the W3C to get their act together. Nevertheless, just because HTML5 and all the related technology around it is new and exciting, it doesn’t mean we have to accept everything we’re given.

Sometimes it’s worth seeing how the HTML sausage is made, so we know what we’re eating. And in the case of HTML’s structural semantics, I’d rather pass.

QuoteLet me give you an example.

The spec says <header> and <footer> elements
define areas within a section, but do not define sections themselves, and so won’t
show up in a document outline.

This is something most people get wrong,
including those teaching HTML5 through books and blogs, whose examples
often show <header> being on par with <section>

 The spec also says
<header> and <footer> can be used multiple times per page (once per section,
for example), but you would never pick that up from most HTML5 resources out
there.

These may seem like pedantic, wonkish points. But they illustrate something
very serious—the community is trying to implement HTML5 markup in a way
that doesn’t have much relation to the actual HTML5 spec. It’s a weird inbetween
state of markup limbo that has inadvertently appeared because that’s
what everyone assumed these elements should be used for.

Quote from: emanuele – July 01, 2013, 01:18:10 pm

 emanuele is tempted to push the "like" button...

NO! Better write it. :+1: (/me thinks we need a :+1: smiley )