Re: HTML 4.01 Strict table attributes and downplayed errors

On Tue, 31 Mar 2009, Henri Sivonen wrote:
>
> I considered implementing downplayed errors now that interest in HTML5 
> is growing on the author side and a better proposal to replace the 
> concept of downplayed errors has not emerged. Also, I considered 
> migrating my own site to HTML5 (at least those articles that I update 
> for other reasons), and I use the align attribute on table cells.
> 
> I was surprised to learn that only the abbr attribute was a downplayed 
> error for td and th. I had expected all HTML 4.01 Strict attributes 
> (except axis) that are not fully conforming per HTML5 to be downplayed.
> 
> Why aren't HTML 4.01 Strict attributes on table, td and th (except axis) 
> downplayed?
> 
> Is there a pragmatic reason why align on td and th isn't fully 
> conforming?

On Tue, 31 Mar 2009, Lachlan Hunt wrote:
> 
> Because it is presentational and CSS handles alignment just fine.  Is 
> there a reason align should be considered conforming?  Are you 
> suggesting that valign should be fully conforming too, or just a 
> downplayed error?

On Tue, 31 Mar 2009, Henri Sivonen wrote:
> 
> CSS properties handle alignment fine. Selectors don't handle it fine 
> usually without an author-set attribute to select on. It seems very 
> silly to use class=right (or class=number to pretend semantics) when 
> align=right works interoperably.

I don't see why we'd allow align="" but not allow all the other properties 
like colour, fonts, backgrounds, and so on. If the selectors problem is a 
problem, it's a problem for all properties. In fact, why doesn't the 
style="" attribute solve the problem for you?

There is a lot of credibility to be gained from being consistent in not 
having any presentational markup at all. It's a lot harder to argue the 
media-independent line when the language still has legacy presentational 
markup. It's worth noting the history, which is that in HTML4 these 
attributes were only kept in Strict (as opposed to only Transitional) 
because CSS2 and the display:table features weren't yet supported.


> Table cell alignment conventions are too complex to capture 
> algorithmically. Therefore, it is useful to let the author set the 
> alignment of a cell on a case-by-case basis. When existing UAs already 
> support a simple attribute for the purpose, it seems silly to make it 
> non-conforming and to ask authors to use something more complex to give 
> the appearance of Separation of Concerns when in practice the authors 
> still wants to control alignment on a per-cell basis.

A class value instead of an align value doesn't seem especially more 
complex, especially given that it also enables a lot more than alignment 
(like padding, colours, fonts, etc).

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

Received on Friday, 1 May 2009 06:03:35 UTC