HTML5 - semantic markup

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

Threaded View
Feel like this post is akin to a fool whacking a hornets' nest with a
short stick...

Ok, so I'm looking at loads of stuff about semantic markup in html5,
and quite a lot of it makes sense: I already assign meaningful id &
class names to divs, such as header, content, sidebar (aside), footer
and so on, so the idea of turning those into markup that makes sense
to search engines etc. sounds fine.

Implementing it, though, at my level of ignorance, seems a quick way
for me to break a serviceable website.

As I struggle to get a handle on this new deal, there are a few qs I
haven't been able to resolve, and I'm hoping there's a fairly
straight-forward explanation that won't take up too much of anyone's
time...   :-/

For example, as I understand it, instead of writing <div
id="header"></div> I can write <header></header>, and assign css
parameters to that in my css file as (e.g.):

If I want to use a different header background image on different
pages, is it ok to write:
<header style="background:url(img.gif) top left no-repeat;">

Lastly, for now, can anyone tell me what the brower support is like
for this stuff?

I currently code for compatibility with IE8 as my lowest common
denominator.  I include code which more recent browsers can implement
but which won't break IE8, and which if not implemented will not
remove any significant content.

My brief experimenting with the above semantic html5 suggests that IE8
can handle it to some extent, but I don't think my methods are
reliable enough to act upon. Any observations gladly received!

Thank you.

Re: HTML5 - semantic markup

On 29.1.2013 12:18, wrote:

Quoted text here. Click to load it

I, for one, would not bother. Not even for brand-new projects.
Exaggerating a little: semantics is for authors. As Mr. Korpela puts it:

 title="The pragmatic guide to HTML: Principles or The HTML Anarchist’s
 cite=" ">
Use tags that suit your needs, instead of trying to find “semantically
correct” tags.

Quoted text here. Click to load it

To be fair, he continues:

"Use new tags, such as those defined in HTML5 drafts, if they have been
im­ple­mented sufficiently widely and well, they serve a useful purpose,
and due pre­cau­tion is taken to deal with non-supporting browsers."

But, as I really can't see much benefit, that is too many ifs for me.

Quoted text here. Click to load it

Well, no. Your selector matches the id "header", not the header element
(I'm not going to call them tags, not very soon at least).

Quoted text here. Click to load it

It would be much better to avoid inline styles. Sites are easier to
maintain if you separate markup and styles, even if a style is unique to
the site.

Quoted text here. Click to load it

Sort of:

Best wishes, Osmo

Re: HTML5 - semantic markup

Osmo Saarikumpu wrote:

Quoted text here. Click to load it

An important – if not *the* – paradigm of the Web is that *everyone* is an
author.  That is why this is comp.infosystems.www.*authoring*.html.

However, that IDs and class names have meaning serves a different purpose:
You can actually understand such markup, and code that uses it or is based
on it, at a glance.

Quoted text here. Click to load it

That is not the only instance where Mr. Korpela is dead wrong.  You should
better start thinking on your own instead of parroting his nonsense.
Quoted text here. Click to load it

There, he is contradicting himself already.  There is no logical reason why
one should only use semantic markup with HTML5.  HTML5 *improves* HTML's
ability for semantic markup; it does not introduce it.

Quoted text here. Click to load it

Short-sighted reasoning.  One immediate benefit is a better structured
document, because that makes it easier to maintain and format.  And in HTML4
times, replacing a layout table with proper elements (say, a “ul” and a
“div” element), reduced the footprint of a document considerably, allowing
it to be loaded and rendered faster.  It still does.

Quoted text here. Click to load it

A common misconception.  Separating code from each other has never per se
made maintenance of the whole easier as now you have to maintain two pieces
instead of one; that is particularly true with a Web site.  It is *usually*
useful that stylesheets common to several documents be defined in external
sources; that does not preclude the possibility of instances where it is

But: Context matters, and not enough context has been provided here.

Quoted text here. Click to load it

What kind of fallacy is that?

    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

Site Timeline