[whatwg] <CENTER>, <MENU>, <DIR>, <NL>; Re: Presentational elements in Web Applications 1.0

[Ian Hickson]

On Fri, 13 Jan 2006, Eugene T.S. Wong wrote:
> 
> I'd like to recommend that the WHATWG bring back <CENTER> because it 
> provides an excellent way of saying "this is a centered <DIV>". <DIV> is 
> no more semantic that <I>, <B>, or <CENTER>, yet they have their uses.

Based on the arguments given in this thread (the bulk of which are quoted 
below) I have concluded that we should not include <center> in the HTML5 
language. However, it will be defined in the rendering section in due 
course, and will continue to work in browsers for the forseeable future.


> I'd like to recommend that the WHATWG bring back <MENU> & <DIR>, because 
> these elements have semantic meaning and don't significantly affect how 
> the list is presented. The lack of significant effects means that the 
> legacy browsers will still be able to make use of the elements. The good 
> thing about creating more semantic list elements, is that they create a 
> greater diversity, standardization and detail, without requiring 
> enhancements to UA technology. You could make any type of a list and it 
> would work. The default styling may not be what you want, but it would 
> work.

<menu> is reintroduced for context menus and toolbars.

<dir> at this point is basically redundant with <nav><ul>, so should 
probably continue to be omitted, so as to not give too many mixed messages 
(HTML4 deprecated it, so reintroducing it now without substantial 
improvements or strong reasons would just be confusing).


> I'd like to recommend that the WHATWG standardize <NL>. I suggest this 
> because <NL> is shorter than <NAV> and because <NL> is consistent with 
> XHTML. As I typed the previous sentence, I noticed that <NL> is much 
> easier to type with 1 hand, than <NAV>.

Assuming you mean XHTML2's <nl><li href>, you can achieve the same results 
in HTML5 using <nav><ul><li><a href>, in a way that is backwards 
compatible with legacy user agents.


On Sat, 14 Jan 2006, Lachlan Hunt wrote:
> 
> No, center is presentational, div is not.  Authors should not use 
> presentational markup, regardless of how much easier it seems.  In fact, 
> the easier method is to increase the amount of semantics, increase you 
> knowledge of and skills with selectors so you don't have to use a class 
> for everything, and style based on the elements semantics.
> 
> What's wrong with:
> 
> <h1>Resume</h1>              h1 { text-align: center; }

Indeed.

On Sat, 14 Jan 2006, Rob Mientjes wrote:
>
> And just for the record, DIV is structural markup, which is allowed and 
> even encouraged if you have a complex, er, structure.

I'm not sure I'd say it's encouraged, but yes.


On Tue, 17 Jan 2006, Eugene T.S. Wong wrote:
> 
> Here is an example that I'm working on now. I'm trying to make a 
> flyer/brochure to hand out to businesses after talking to them. I hope 
> that they will consider giving me merchandise to use as prizes for a 
> poker club that I'm trying to start. There is absolutely no intent for 
> me to post this on the web. I may do that in the future, but definitely 
> not in the foreseeable future. The content is changed, but hopefully 
> it'll make sense.

For non-Web publishing, I would strongly recommend investigating in a 
more appropriate technology such as Open Office Writer, Pages, or Word.


> I refuse to use <H1> as a title, based on my own principles that there 
> can be only 1 title, just as there can be only 1 document root. There 
> can be multiple headings, but not mulitiple titles for each document.

HTML5 explicitly allows multiple <h1> elements. You could also use <h2>.


On Tue, 17 Jan 2006, Simon Pieters wrote:
> 
> There is a <title> element type for this purpose. Use the following CSS:
> 
>   head { display:block; text-align:center; }
>   title { display:inline; }

...or this, indeed.


On Sun, 15 Jan 2006, Matthew Paul Thomas wrote:
> 
> <div> is presentational: it means "present this as a block". That is 
> what it will mean in HTML 5 documents as well, regardless of how it is 
> eventually defined in the specification, because author momentum will be 
> too great to usefully narrow its meaning. And that's okay: there is no 
> evidence that any deity kills a kitten when someone uses <div>.

There's an open issue on exactly what to do with <div>, but yeah.


> Authors should use presentational markup whenever there is no available 
> semantic markup for the relevant meaning, or when they are providing 
> authoring facilities for people who cannot be expected to think about 
> semantic markup (e.g. people using Webmail, or people posting comments 
> on the author's Weblog). If authors -- or specifications -- try too hard 
> to use a semantic element, or to force other people to use it, it will 
> be misused so much that UAs can no longer trust the element to have any 
> particular meaning, so it will become de facto presentational.

True... but it's not clear if elements like <font> and <center> are the 
best way of addressing this.


> <div>
>     This was defined in HTML 3.0 and 3.2 to mean about the same as
>     <section> means in Web Applications 1.0, but was soon repurposed by
>     Web authors for any block for which the author could not think of a
>     better element. It will continue to be used that way in HTML 5,
>     because even if replacement elements like <cartoonpanel>, <login>,
>     <nav>, <order>, <search>, <sidebar>, <signup>, and <sudokupuzzle>
>     were introduced in an attempt to narrow the use of <div>, authors
>     would hardly ever bother using such specialized elements, since
>     they'd get no benefit from doing so. (But <aside> and <menu> will
>     reduce the use of <div> by a small amount, because they have
>     distinct and useful default presentations.)

Indeed.


> <dl>, <dt>, <dd>
>     These elements were semantic until HTML 4.0, which belied their
>     supposed meaning both in an example in the spec, and in the markup
>     of the spec itself. They remain presentational in the current Web
>     Applications 1.0 draft, because use for both "terms and
>     definitions" and "name-value data" is still too broad to have a
>     coherent meaning. (For example, from the markup alone, a search
>     engine will not be able to tell whether "Ian Hickson, Google,
>     ian at hixie.ch" is the answer to "Who is the editor of Web
>     Applications 1.0?", or a definition of the word "editor" itself.)

The latter would need a <dfn> around the word "editor".


> <i>
>     This has always been presentational, and will continue to be so in
>     the majority of HTML 5 documents. Most authors will assume it has
>     the same purpose as it did in previous versions of HTML; and many
>     of the authors who actually read that part of the spec will giggle
>     at the "instance of a term" frippery and disregard it.

This has changed since you commented on it, I believe. Now it's still 
"presentational", but it is at least media-independent, being defined in 
a way that is still usable in speech contexts.


> <p>
>     This has been semantic until now, meaning a paragraph. But the
>     current Web Applications 1.0 draft pretends that the English word
>     "paragraph" means something much broader than it really does, so
>     broad that it will have no semantics at all. (For example, someone
>     instructed to write a ten-paragraph essay will get incorrect
>     results from a paragraph count if, as suggested by Web Apps 1.0,
>     they use <p> for the essay's byline.) As a result, <p> will come to
>     mean "present this as a block with extra vertical margins".

The byline would be in the <header>, which would presumably be excluded 
from the paragraph count.

(I strongly feel that there is a difference between <div> used for 
grouping thematically related blocks, and <p> used for separating 
thematically related inline content, e.g. parts of a form. I want to make 
inline-in-<div> non-conforming in the case where <p> could better be 
used, but without making it non-conforming when it is being used to make 
custom widgets. I don't really see what to do about this. Maybe only 
allow <div> to contain blocks or <span> elements (but not both)?)


> <section>
>     This is semantic in the Web Apps 1.0 draft, but whether it remains
>     so in the real world will depend on who is faster: UA vendors
>     distributing software that prominently takes advantage of the
>     structure <section> is supposed to provide, or eager tech Weblog
>     authors misguidedly replacing all the occurrences of <div> with
>     <section> in their templates in an attempt to be "more semantic".
>     My money, regretfully, is on the Weblog authors.

Indeed.


> <strong> or <b>
>     If <b> is retained, it will remain a presentational element for
>     making text bold ad hoc, regardless of how the spec defines it. If
>     <b> is dropped, <strong> will become a de facto presentational
>     element for making text bold ad hoc, regardless of how the spec
>     defines it. (To a small extent this has already happened, thanks to
>     those people who have given the impression that <b> is naughty.)

The spec tries to address this in a way similar to <i>.


> <style>
>     This has always been presentational; it exists for no other reason
>     than to specify presentation.

Indeed.


On Mon, 16 Jan 2006, Eugene T.S. Wong wrote:
> 
> Yes! That is what I was trying to say earlier. The best case examples 
> are inline strings which are typically italicized and bolded, but aren't 
> being emphasized. The problem with using <EM> and <STRONG> in those 
> situations is that these 2 elements have been stretched to include more 
> than just emphasis.

Indeed, HTML5 tries to fix this.


> That's why I think that every semantic element should have a 
> corresponding element that appears to be the same, but doesn't have the 
> same meaning. If we had something similar to <TABLE> and its children, 
> then people may have been willing to transition to those other elements 
> with less arguments, and thus, blind people would find more value in 
> pages with actual tables. Having similar elements to <TABLE> and its 
> children doesn't represent best practises, but it does represent better 
> practises. The same goes for <DL> and its children. If there had been an 
> alternative, then there would have less likely been any tampering with 
> the semantic elements.

Pages would just be using exclusively the presentational elements, and 
we'd be in no better shape than everyone using XSL:FO or <font>. Shouldn't 
we aim for better than that? (I'm not sure how to achieve better.)


On Tue, 17 Jan 2006, James Graham wrote:
> 
> Accepting mpt's argument for a moment, what is the semantic equivalent 
> of <center> or <big>? Even if we took the argument to your extreme and 
> shadowed every semantic element with a meaningless element with the same 
> default presentation in some reference graphical browser, there's no 
> place for <center>. I suppose <big> is a bit like <h1> but surely we 
> could just reintroduce <font> and be done with it? But you can't be 
> suggesting that sites which employ the <font> tag are superior to ones 
> that use CSS? I mean, they load slower, usually use <font> tags instead 
> of headings, which reduces the readability and accessibility of the page 
> and generally have a negative impact.

Indeed.


> Whilst it is not implausible that a few select presentational elements 
> may improve the overall correct use of meaningful elements on the web, 
> history suggests that providing a raft of graphical presentational 
> elements at the markup-language level encourages the use of poor-quality 
> markup.

Agreed.


On Tue, 17 Jan 2006, Eugene T.S. Wong wrote:
> 
> Well, font would have been used within good semantic markup, without 
> CSS, whereas what I am proposing is to use it with CSS. So, with the old 
> way, using <FONT> means extra markup, most likely with no extra 
> semantics. With my suggested way, there would be the same amount of 
> elements as well made documents, and less markup than what is practised 
> now by experts.

But we had <font>, and this didn't happen.


On Tue, 17 Jan 2006, Eugene T.S. Wong wrote:
> 
> If they wanted a <H1> to represent a title, then they should have said 
> so, and demonstrated it.

That's the intent; let me know if the HTML5 spec is still vague on this.


On Tue, 17 Jan 2006, Eugene T.S. Wong wrote:
>
> I guess I should have looked up the dictionary definition earlier on. I 
> just looked it up now, and 1 of the definitions for "title" is "a 
> general or descriptive heading for a section of a written work". I was 
> wrong. If we look up "heading", we can see the same idea. I must say 
> that I'm pretty surprised. I've never heard of anybody using "heading" & 
> "title" interchangeably, outside of HTML.

I don't know what the difference would be if they're not the same. :-)


On Tue, 17 Jan 2006, Eugene T.S. Wong wrote:
> 
> There is no vegetable list, but there is <DIR>, and I figure that as 
> long as it's there, we should leave it as an option. We don't have to 
> create a element for every single concept, but I don't think that we 
> should get rid of any, as long as they are there and are properly 
> defined.

Well, HTML4 removed it (deprecated it), not HTML5... speak to the HTML4 
working group. :-)

But as noted earlier, I don't really see that it's that useful.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'