Re: Bug 7034

Maciej Stachowiak, Wed, 24 Mar 2010 03:33:31 -0700:

> I think I understand the value of avoiding quirks mode and almost 
> standards mode, enough to explain it. I'm not sure I understand fully 
> why presentational markup is to be avoided. Can you provide some 
> reasons or point to a good reference?
> 
> I ask because I'm planning to make a wiki page that collects 
> rationales for authoring conformance requirements.

*Whose* problems do authoring conformance profiles solve? Authors’? 
User agents’? Spec writers’? Users’? Problems with the language itself?

(1) 'Saving resources' seems to be the essence of authoring 
conformance, in the letter from Ian that Ann pointed to: [1] 

 readers’ resources (better accessibility), 
 author’s resources (lower the maintenance costs, more file reuse), 
 hardware’s resources (lower the file sizes) and 
 user agent’s resources (better caching). 

Saving resources seems like an excellent starting point for defining 
conformance. And saving resources looks to me to have been more 
instrumental in the defining e.g. HTML4 Strict, than the wish to be 
more 'semantic'/less 'presentational'.

 Problem: Saving resources is fine. But _authoring_ conformance 
requirements should not dictate _how_ the _author_ saves _his/her_ 
resources. Example: CSS does not care whether I write 

    *{font:1em/1 serif}                                OR
    *{font-family:serif;font-size:1em;line-height:1;} 

 So why (as an example) does HTML5 care whether I write <span 
style="text-decoration:line-through"> or <strike>? I really think that 
classifying some elements as shorthand variants of more general 
elements, could be a way to go. E.g. to say that <center> is just 
shorthand for a certain styling of <div>, and <strike> is a styled 
variant of <span>.

(2) From 'saving resources' and 'reuse', the way is short to 
'simplicity'. Which leads to 'pedagogical' and 'logical':  the essence 
of the language should be simple to learn. Which leads to separation of 
concerns: the code should be simple to use and simple and fast to 
analyse.  'Safe' saves resources as well. An authoring profile should 
cover all these things - it should define a useful essence of the 
language.
 
 Problem: Killing your babies. An authoring profile should not define 
*any* application of a more complex understanding of the language as an 
error. And should also not show undue love for certain gotcha features 
(while at the same time perhaps ban other gotcha features). Lack of 
consequence can make the authoring profile difficult to learn and 
problematic to adhere to.

 Problem: The non-draconian nature of HTML means that the authoring 
conformance requirements run the risk of becoming a presentation of how 
one wishes the language had looked like. And if we are eager enough in 
this, the conformance requirements becomes draconian, on behalf of the 
language.

 Problem: 'Simple to validate' should not affect what we consider 
valid. E.g. it may be simpler to guarantee that <span> doesn't express 
the wrong semantics ..., than it is to check whether <strike> expresses 
correct semantics ... But this should not lead to stamping <strike> as 
an error. (It could be relevant to *inform* that editorial deletions 
should use <del> instead of <strike>, however.)

(3) Separation of concerns vs simplicity: The list of elements to learn 
becomes shorter if we concatenate several presentational elements into 
a single element that authors can style accordingly. And it can 
simplify things to place presentational features inside CSS, instead of 
operating with structural and presentational semantics in the same 
layer. By removing/relocating features with presentational semantics to 
another layer, we allow authors to work with the HTML code in a way 
which appears to them - the authors - as more "semantic" - the "fuzz" 
has been moved out of HTML. 

 Problem: "less is more" isn't equal to "more semantic". Admittedly, 
*if* authors operate with a simpler profile of the language, the 
resulting code might express semantics which are more relevant across 
media. But there is no increase in semantics by going from <strike> to 
<span>. Tina Holmboe was in principle correct in hinting that <span> is 
a problematic element! [2] ;-) 

 Problem: Authoring conformance should not conflict with progressive 
enhancements. CSS overrules presentational attributes in HTML elements. 
Thus, when the presentation is important, then a presentational 
attribute or element in the HTML code could improve the fallback. 
Google claims to practise something like that.

[1] http://lists.w3.org/Archives/Public/public-html/2009Oct/0961

[2] http://lists.w3.org/Archives/Public/public-xhtml2/2007Aug/0020

-- 
leif halvard silli

Received on Thursday, 25 March 2010 05:49:40 UTC