[whatwg] Presentational elements in Web Applications 1.0

[James Graham]

Eugene T.S. Wong wrote:
> On Tue, 17 Jan 2006 11:00:18 -0800, James Graham <jg307 at cam.ac.uk> wrote:
> 
>> Accepting mpt's argument for a moment, what is the semantic equivalent 
>> of <center> or <big>?
> 
> <CENTER> would be the equivalent of <SECTION> or <DIV>.

<div> has no semantics; it is already an element of the type you suggest 
(except that the default presentation is different). <section> is 
fundamentally different in that it affects the document structure - 
insofar as a non-semantic companion element is needed <div> is 
sufficient. Beyond this, there is no need _whatsoever_ for additional 
elements with a default graphical presentation of display:block; and no 
semantics. They add nothing to the language and, in the case of <center> 
  don't even address probably the most common use of css positioning 
which is to float a block (especially an image) to the left or right of 
the screen. Or are you also in favor of <float-left> <float-right> and 
so on?

As a more general point, the notion of tying a element to a particular 
default presentation is weird because an author, a UA or a user can 
override that default. This is why it's preferable to have meaningless 
elements have the simplest possible style rules.

>> I suppose <big> is a bit like <h1> but surely we could just 
>> reintroduce <font> and be done with it?
> 
> Well, font would have been used within good semantic markup,

I assume you mean "would _not_ have been used...", otherwise I'm missing 
your point.

> 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.

Less markup? How? Because you could write <big> rather than <div> and a 
style deceleration? So you propose saving a few bytes (maybe) at the 
expense of encouraging authors to use markup that is device-specific 
(i.e. only applies to graphical browsers), making it more likely that 
they will create inaccessible sites "because the spec says you can use 
<big> to make text big" (when what they reallky want is e.g. <h1>).


> However, just for the record, standards compliant pages don't 
> automatically load faster.

OK, it's not automatic. But using CSS for positioning rather than tables 
(say) creates one, large, cacheable, style file and a selection of 
smaller pages of markup which generally loads faster, at least after the 
first page.

>> 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.
> 
> I agree with you on this.
> 
> However, I'd much rather that the non-experts misuse the non-semantic 
> markup, than the semantic markup.

And I would rather see non-expects encouraged to learn which semantic 
markup is useful (and, importantly, how users benefit) than create a 
bloated spec full of presentational elements for every occasion. I 
certainly disagree with Ian that /all/ non-semantic markup should be 
ditched (in particular, simple elements such as <div> and <span> will 
continue to be useful) but I see no reason to retain elements that are 
tied to specific graphical presentations, any more than I see the need 
to introduce elements for specific aural presentations. One can perhaps 
see that very simple text formatting markup will be useful in preventing 
abuse but, in my eyes, the argument does not extend to <center> or 
<big>. If you use <center> or <big> to markup headings, text that is 
often both large and centered, it prevents me from creating a useful 
navigational outline of your page. This is a real, not theoretical, 
problem. In this particular case it is, perhaps, worse, to not markup 
any headings at all than to mark up headings poorly since at least poor 
markup will usually give me some idea of what is going on.

> An entire society can't even speak 1 
> language consistently, let alone mark it up semantically.

Indeed, perfeaction isn't going to happen. But that doesn't mean wes 
shouldn't make it easy to get right.