W3C home > Mailing lists > Public > public-html@w3.org > September 2007

Re: [html] Semantics of "aside", "header", and "footer"

From: Robert Burns <rob@robburns.com>
Date: Fri, 7 Sep 2007 19:59:24 -0500
Message-Id: <0FA7AE35-DE7C-4B70-B6A5-B25F5984D09B@robburns.com>
Cc: HTML Working Group <public-html@w3.org>
To: James Graham <jg307@cam.ac.uk>, Jens Meiert <jens.meiert@erde3.com>

Hi Jens and James,

On Sep 7, 2007, at 6:33 AM, Jens Meiert wrote:
>
> Andrew Fedoniouk wrote:
>> footer { position: fixed; top:0; }
>>
>> Is it still footer or is it header now?
>
> That exactly “made me wonder”.
>
>
> Robert Burns wrote:
>> My view is that simply changing the names of the elements cannot —
>> alone — change them into non-presentational elements. More
>> importantly, I think we need to think about the semantic contents of
>> these parts of the page more systematically.
>
> Agreed, and I didn't intend to “change their names” anyway. It  
> looks like a desirable “semantics update”, too.

The problem I'm trying to underscore here is that the semantics an  
author might place in a footer are too varied and too diverse to be  
included in a single element named footer or anything. We need to  
think about separating these semantics into separate elements  
(perhaps like Atom has done).

On Sep 7, 2007, at 6:33 AM, Jens Meiert wrote:
> Maciej Stachowiak wrote:
>> I disagree that they are presentational. Headers, footers and asides
>> are identifiable parts of web documents and indeed non-web documents
>> just as much as paragraphs and sections are. Furthermore, it is hard
>> to see how they are any more presentational than <tfoot>, <thead>,
>> <h1> or <th>.
>
> Obviously, “thead” and “tfoot” play in the same league, but their  
> existence since HTML 4 is certainly a “bonus” […].

I think for an entire web page there might be some justification for  
adding a header and a footer as a presentational-oriented region of a  
page. The more severe problem is trying to ruse these names header  
and footer for something else. That will only lead to their misuse.  
The current draft uses the name 'header' to mean a heading and not a  
header. This is a problem. The same problem could be solved by simply  
have a 'heading' element (or 'h' element) that could b e arbitrarily  
nested to indicate sub-headings.

> Apart from the already mentioned issues, I begin anticipating  
> scenarios like “aside-itis” (the potential “div-ebola” successor)  
> and endless “header” and “footer” discussions (like “a logo placed  
> in the top-left corner must (not) be placed within `header´” wars).  
> Different element names  with adjusted semantics might reduce or  
> prevent that.

I agree. I think if we have an element called 'header' and an element  
called 'footer' they should be specifically used in the way the class  
header and footer are commonly used: as a container for contents at  
the top and bottom of the page respectively. In many ways these are  
all like 'aside' in that they are for information that is tangential  
to the contents of the page.

On Sep 7, 2007, at 6:54 AM, James Graham wrote:
>
> Jens Meiert wrote:
>> Andrew Fedoniouk wrote:
>>> footer { position: fixed; top:0; }
>>>
>>> Is it still footer or is it header now?
>> That exactly “made me wonder”.
>
> It's a footer. Functionally you might notice this for several reasons:
>
> * It wouldn't take part in the heading algorithm [1]

Again, this relates to the confusion over header and heading. A  
header should also not take part in the heading algorithm. A heading  
and its subheadings should take part in the heading algorithm. If a  
heading happens to be presented at the top of a apge in a region   
called a header that should not enter into whether it takes part in a  
heading algorithm.
>
> * It wouldn't be read by a screenreader which ignored footers in  
> some sort of page skimming mode

This is true for all of the aside/tangential material on a web page:  
including a header (that's not defined to be the same as a heading).

> * It could have a different default print stylesheet
>
> The second point is an example of extra functionality that can be  
> provided by having a <footer> element. There's also evidence that  
> authors would use this element, even if they do not use the UAs  
> which make use of <footer> to improve the user experience; "footer"  
> is the most commonly found classname in the Google survey by some  
> margin [2]. Any other name to represent the same concept is likely  
> to be more confusing than following this precedent.

'footer' and 'header' are both common class names. However, they are  
common class names that define the presentational top and bottom of a  
page. Redefining them to mean something else in HTML5 will only lead  
to confusion. We should instead provide semantic elements for the  
metadata about a document or its sub-articles and sub-sections and  
not try to repurpose 'header' and 'footer' to serve that duty. If we  
feel a strong need for 'header' and 'footer' as used in those class  
names, then we should simply define those and be open about their  
presentational nature.

> <header> also fills a hole in the language; it provides a way of  
> marking up heading + subheading content; the lack of this  
> functionality in HTML 4 is something that authors often try to work  
> around by abusing <h1>-<h6> e.g. by doing things like
>
> <h1>My blog</h1>
> <h3>With an amusing tagline</h3>
> <h2>My First Article</h2>

Again, this should be done through a heading element rather than  
confusing this with a header. The existing h1 – h6 heading elements  
or even a new 'heading' or 'h' element could be arbitrarily nested to  
indicate headings, sub-headings, and sub-sub-headings, etc.

On Sep 7, 2007, at 8:07 AM, James Graham wrote:
>
> Jens Meiert wrote:
>>>>> footer { position: fixed; top:0; }
>>>>> Is it still footer or is it header now?
>>> It's a footer. Functionally you might notice this for several  
>>> reasons:
>> Couldn't any other element bear this functionality, too, meaning  
>> an element
>> that has a different name, but the same or similar semantics?
>
> Of course it can be called anything. Assuming we want the name to  
> be functional, there are a few constrains that need to be optimized  
> including, significantly in this context, whether a chosen name  
> will encourage authors use an element as intended or not. I think  
> "footer" does well here by providing a reference point for the  
> expected content that authors are familiar with from other types of  
> publishing. This, to me, outweighs the concern that the name could  
> be misleading because it possible to make the element appear  
> somewhere other than below the content to which it applies or the  
> concern that they might put non-"footer" content in the element for  
> some reason.

The name 'footer' does well for the most part because its not trying  
to be other than  a  footer. To the extent that the HTML5 draft tries  
to prescribe what goes in a footer (in other words a region at the  
bottom of the page) the name is not appropriate. Similarly, the use  
of the name 'header' for instead a heading is inappropriate, because  
most authors will assume a 'header' is meant to define a region at  
the top of a page.

Semantically, I think all of these elements — header, footer and  
aside — are just asides. That is they are for defining parts of the  
document that are tangential to the document itself,, wherever a  
designer decides to lay them out. As the class names 'header' and  
'footer' are commonly used they are intended to define specifically  
those tangential parts of a document that are located at the top and  
the bottom of the page respectively. We should try not to stray too  
far from that usage.

Take care,
Rob

Take care,
Rob
Received on Saturday, 8 September 2007 00:59:42 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:49 UTC