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

Re: HTML 4.01 Strict table attributes and downplayed errors

From: Henri Sivonen <hsivonen@iki.fi>
Date: Tue, 9 Jun 2009 12:20:17 +0300
Cc: HTML WG <public-html@w3.org>
Message-Id: <CAC41D31-3AF9-4657-9802-263A406C5C3F@iki.fi>
To: Ian Hickson <ian@hixie.ch>
On Jun 8, 2009, at 10:45, Ian Hickson wrote:

> On Mon, 8 Jun 2009, Henri Sivonen wrote:
>> On Jun 6, 2009, at 00:45, Ian Hickson wrote:
>>> On Fri, 1 May 2009, Henri Sivonen wrote:
>>>> 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.
>>> In a graphical editor all you would have to do is use unique class
>>> names (like com.example.numeric) and just ensure that those classes
>>> have the appropriate style in the style sheet.
>> Seriously? When there's already widely interoperable specific  
>> attributes
>> for this?
> You are wildly oversimplifying "this". In practice a WYSIWYG tool  
> isn't going to style a table in 90% CSS and then gain great benefits  
> by
> specifying just the vertical and horizontal alignment using  
> attributes,

The use case I put forward wasn't in the context of an overall WYSIWYG  
design tool but in the context of a GUI tool that allows users input  
content but not tweak style.

> _especially_ considering that those attributes don't even provide  
> the actual desired control (decimal alignment).

Aligning stuff right is a passable substitute in the absence of  
decimal alignment. Most fonts have monospaced digits, so you get  
decimal alignment simply by having a fixed number of digits to the  
right of the decimal point.

> Styling a table involves complicated rules for getting the borders  
> right, involves non-trivial padding even after getting the alignment  
> right,

It seems very rare to tweak the padding on data tables on a per-cell  
basis instead of delegating it to a table-wide (or site-wide) style.

> can involve per-cell colouring, etc.

bgcolor :-)

> At the end of the day, using the align="" and valign="" attributes  
> to control alignment on cells is a false economy.

I disagree about align. It's by far the most common table formatting  
characteristics that the person managing the data in the cells would  
set even if the overall visual appearance is controlled by another  

> This is made significantly worse by the cost of including these  
> attributes in the language, which is a serious hit to the  
> credibility of argument that authors should separate their styles  
> and semantics for improved accessibility, maintainability, and  
> device-independence.

You invoke a PR credibility issue. Isn't there a double-standard here?  
You are taking PR credibility risks when insisting on examining if  
@summary and @longdesc actually solve the problemes they are supposed  
to solve. Shouldn't we be scientific here and ask if making align=''  
non-conforming actually improves accessibility, maintainability or  

How does class=com.example.numeric (a class name that client software  
knows nothing about semantically) with a style sheet improve  
accessibility compared to align=right? How does it improve  
maintainability? What about device-independence?

> I firmly believe that a big part of why HTML4 failed to wean people  
> from Transitional is that it (even in Strict mode) gave credence to  
> the idea that presenational markup was ok.

Or maybe the separation of structure and style emperor isn't fully  
clothed when taken to limit and having some presentational stuff in  
HTML doesn't lead to doom and gloom but is more practical to authors  
than maintaining a full separation.

Henri Sivonen
Received on Tuesday, 9 June 2009 09:20:57 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:49 UTC