W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2008

[whatwg] Thoughts on HTML 5

From: Smylers <Smylers@stripey.com>
Date: Fri, 29 Feb 2008 08:02:24 +0000
Message-ID: <20080229080224.GB30169@stripey.com>
html at nczonline.net writes:

> I had posted this on my personal blog:
> http://nczonline.net/blog/2008/2/28/thoughts_on_html_5. Ian requested
> I join the mailing list to continue the discussion, so here it is:

Hi there Nicholas.  Welcome to the list, and thanks for your comments.
I'll try to explain the purpose of elements that you are questioning.
Where I've snipped a point you made that's generally because I
agree with you and have nothing further to add.

> * the irrelevant attribute ... I can't imagine ever using it.

That's OK -- it isn't necessary for every author to use every element!
It's purpose is for use on interactive pages, where some things only
appear (or disappear), using JavaScript, after the user has done
something.

> Lachlan had commented that "irrelevant" could be changed dynamically
> to indicate parts of an application that may be relevant only during
> particular points in time.

For example think of an error message which appears if the user tries to
submit invalid input: when the page initially loads the error message
isn't relevant (no error has yet occurred), but it's in the document so
that it's there if needed.  At that point the script that's detected the
error condition can set irrelevant to false on the error message.

> I don't see how this is any different from hiding content that isn't
> necessary.

It _isn't_ different from that; it's exactly that!  It's providing a
mechanism for doing precisely that -- in HTML 4 there isn't a way of
marking up an element as being hidden.

>   The spec says, "When specified on an element, it indicates that the
>   element is not yet, or is no longer, relevant. User agents should
>   not render elements that have the irrelevant  attribute specified."
>   If it's not relevant, why is it in the page in the first place?

So that it can become relevant in response to events.

> * I'm not sure what the <section/> element offers over the <div/>
>   element. I thought the purpose of the <div/> was to indicate a
>   section of the page. If there's not a clear distinction between
>   these elements, I don't see the need for a second one.

<div> is semantically neutral; it just means that there's a division
(the author needed a block element) but doesn't give a reason for it --
similarly to how <span> merely denotes a run of text without giving a
reason.

In HTML 4 it's rare to need to resort to <span>, because there are many
other elements for denoting a span of text for a particular purpose
(<em>, <cite>, <dfn>, etc).

Along similar lines HTML 5 provides a block elements for specific
purposes, so that different sorts of blocks can be marked up
differently.  <section> is one of those.

A <section> is not merely any block division that the author needed to
make on the page (probably to hang some styles off), but is specifically
a section (or subsection) of a document.

For example consider a webpage with this design:

* a header with the site's name and logo and so on
* a left column with navigation links
* the main page content (what the reader has come here to read) in the
  middle; this is quite long, and has subheadings at various points
* a right column ('sidebar') with related information

In HTML 4 that would likely be marked up with lots of <div>s (or a
table).  HTML 5 has meaningful elements for each of those -- <header>,
<nav>, <article>, and <aside>.

Further, <article> can be split into <section>s.  Possibly the sidebar
would have sections too.  Note that because of how HTML 5 infers
sections from headings it isn't necessary to include <section> tags to
get a section; just using <h1>, <h2>, <h3>, etc at the appropriate level
will achieve the same effect.  But sometimes explicitly marking sections
is easier.

For an example of a document which clearly has lots of sections and
subsections see the HTML 5 spec itself!

> * I'm a bit unsure of the <article/> element. As with <section/>, it
>   seems only vaguely different from <div/>

Many HTML 5 pages will have just one <article> (whereas in the HTML 4
equivalent it would be necessary for that block to be just one of
several <div>s on the page).  That will enable user-agents to know the
'main purpose' of a page.  In particular text-based and speaking
browsers can offer to jump straight to it (something which authors have
to code by hand on each page in HTML 4).

> * The <aside/> element really pushes the boundaries of marking up
>   literary devices. ... Short asides are typically indicated by
>   parentheses and I don't see any reason not to keep doing that
>   (seriously).

Indeed, parens would still be the best thing to do there.  If no mark-up
is needed then don't bother with any.  But think of sidebars: books
often have 'boxes' out of the main flow of text describing a separate
point.  These sorts of asides obviously need some mark-up, and <aside>
would be appropriate to use there.

> * The <dfn/> is another that stresses the understanding of grammatical
>   structure for web developers. The intent is to designate the defining
>   instance of a term, abberviation, or acronym. Does that make sense to
>   you?

So far as I can tell it's defined in the way that I've always been using
it in HTML 4 anyway.

Documents which introduce a new term often italicize or embolden that
term; the surrounding sentence (or whatever) defines it.  Obviously in
order for this to happen this defining instance of the term needs to be
marked up in some way; <dfn> is the element to use for that.

> * Speaking of confusing, I've read the section about the <meter/>
>   element five times now and still have no idea what it's used for.

See this list of web pages has a little bar showing PageRank to the left
of each one:

  http://directory.google.com/Top/Regional/Europe/United_Kingdom/News_and_Media/Newspapers/

That PageRank indicator could be a <meter> -- it's indicating a
proportion of a whole.

I hope that helps.  Cheers.

Smylers
Received on Friday, 29 February 2008 00:02:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:39 UTC