W3C home > Mailing lists > Public > public-html-comments@w3.org > June 2011

Re: HTML 5

From: Jukka K. Korpela <jukka.k.korpela@kolumbus.fi>
Date: Fri, 03 Jun 2011 09:32:29 +0300
Message-ID: <4DE87FFD.4020101@kolumbus.fi>
To: public-html-comments@w3.org
3.6.2011 6:08, Jens O. Meiert wrote:

> Not sure this point got much attention: the reason why it’s not
> advisable to use any presentational markup is that it’s harder to
> maintain

The arguments against presentational markup vary a lot, apparently due 
to varying estimates on what might be the best tactics. In this respect, 
they resemble religious attitudes and cultural prejudices.

In which sense is <b>foo</b> harder to maintain than <span 
class="bold">foo</span>?

What might the difference in maintenance difficulty be if in both cases 
the markup is actually automatically generated, using preprocessing or 
server-side technology, and is never modified directly?

> How presentational markup is easier to read is not clear to me: using
> more code typically does but one thing, making it harder to understand
> the code, and if you want to understand how a document will look like,
> the answer should be made by the style sheet.

Finding how a style sheet might modify rendering is surely more 
complicated, and often _much_ more complicated, than understanding the 
rendering effect of presentational markup.

While <span class="bold">foo</span> might seem obvious, you are just 
making a guess. If the author has been more structural and has actually 
written <span class="avainsana">foo</span>, you would understand the 
intended meaning (assuming you know the language from which the author 
picked up the semantic name for the class, of course) but would have 
little clue of the rendering.

Presentational markup is honored by current and future browsers, out of 
necessity of dealing with billions of existing pages. Therefore, authors 
can and will use it if they find it useful and easier to use than the 
alternatives (if they even know the alternatives). The way to propagate 
good authoring habits – which is what this is really about – is to give 
them better tools, packaged better, and to teach them.

Removing presentational markup from specifications does not really help 
anyone, except in the sense that it may bring the feeling of having done 
Something, or at least trying something. And HTML5 is’t even removing 
it, just throwing it into the dark side. HTML 4.01 is confusing, with 
its Transitional, Strict, and Frameset DTD and “deprecation”, which 
almost (but not completely) coincides with not being Strict. HTML5 
replaces that stuff with other concepts, which are not necessarily easier.

However, reopening the whole issue of presentational markup would 
probably just slow down the process and cause endless debates, if not 
worse. Authors have lived with HTML 4.01, perhaps ignoring parts thereof 
and learning from other sources that parts thereof are dead letters, and 
authors can live with HTML5.

But if specific issues related to specific “presentational markup” 
(itself a vague concept) are raised, it would be best if we all could 
put our beliefs, taste for style, and habits aside – and concentrate on 
specific pros and cons. For example, border="1" is now allowed in 
<table>, despite many people’s attitudes against any presentational 
markup. There were specific arguments that made that possible, and the 
quasi-semantic description that was adopted probably helped in the 
process. So anyone who wants to get some of e.g. “align, alink,...” into 
approved HTML5 should carefully consider what is really needed and find 
strong and specific arguments in favor of it.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/
Received on Friday, 3 June 2011 06:32:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 3 June 2011 06:32:53 GMT