Re: HTML 4.01 Strict table attributes and downplayed errors

On Apr 30, 2009, at 23:02, Ian Hickson wrote:

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

You don't generally set the font based on a per-cell basis. I guess  
one might argue that you could set text/bg color depending on the type  
of cell you have. (Such as red for negative numbers in accounting or a  
different bg for cells that contain a calculation result.)

I've previously argued separately that we should have <font color=red>  
for color-based emphasis. As for backgrounds, I don't care enough to  
debate them either way.

> If the selectors problem is a problem, it's a problem for all  
> properties.

I'm sticking to my story that cell alignment is a qualitatively  
different compared to all other possible CSS properties you might set.

> In fact, why doesn't the style="" attribute solve the problem for you?

Style is an overkill. Furthermore, if I want to have a simple GUI  
table editor, I don't want it to allow arbitrary styling but I want to  
be able to set cell alignment, because that's a thing you usually set  
on data tables. A simple tool like that shouldn't have to have a CSS  
parser for reading back alignments from style attributes in order to  
provide UI for cell alignment state.

> There is a lot of credibility to be gained from being consistent in  
> not having any presentational markup at all.

Frankly, I think there's no credibility to be gained from suggesting  
style='' as a solution for anything except rapid prototyping. style=''  
is like <font> on steroids. If you are taking the stance that <font>  
is bad, it's illogical to position style='' as something that's OK.

> It's a lot harder to argue the media-independent line when the  
> language still has legacy presentational markup.

On the contrary, when visual presentation is tightly coupled with  
implied semantics, it's easier to argue that putting in the DOM rather  
than into screen style sheet makes it easier for renderers for other  
media to mine best-guess semantics from things that authors are  
accustomed to conveying visually.

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

So if I want to have a relatively simple GUI table editor that can  
read back what it has written but doesn't allow arbitrary styling to  
avoid breaking the consistent design of the site, I have to not only  
parse style='' values but parse arbitrary CSS and resolve class  
selectors?

My concern isn't authoring in a text editor.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Friday, 1 May 2009 17:15:16 UTC