Re: HTML 4.01 Strict table attributes and downplayed errors

On Tue, 9 Jun 2009, Henri Sivonen wrote:
> 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.

But the alignment of text in a cell _is_ style.

But they can still set a class, and document some boilerplate CSS to use, 
if it comes down to it.


Incidentally, I went to Ben's list of tables that he collected, and tried 
to find a table with right-alignment. Some had align="" attribute (I 
didn't find any that had only that and not any presentational attribute, 
though). Most of the tables I found with alignment were actually styled 
with CSS and class attribute. One was styled with style="" attributes with 
'text-align' and 'color' properties.

I'm not convinced that keeping just align="" is really something that 
would help authors.


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

This doesn't really seem to be the case based on the tables I looked at, 
though for sure my sample wasn't in any way rigorously picked. It would be 
interesting to study this in more detail.


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

Universal access is more important than PR, IMHO. In this case we're just 
talking about replacing one syntax with another, we're not actually 
removing any platform features or changing the end result in any way.


> Shouldn't we be scientific here and ask if making align='' 
> non-conforming actually improves accessibility, maintainability or 
> device-independence?

If there are some studies we can make to make this a more objective 
decision, that would be great. I don't know what we can look at though.


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

I don't think it would have any effect on the accessibility of tables as 
seen by screen readers. I don't think it would affect the accessibility of 
tables in CSS-capable visual browsers. It arguably would reduce in a 
trivial way the accessibilty of tables in non-CSS capable visual browsers.

There is a risk that by saying "media-dependent markup is ok sometimes" 
that we will send a message suggesting that that is also the case in other 
situations, like using <big> instead of <h1> or <font> instead of <em> or 
whatever, and the result might be a mindset that results in less 
accessible pages. (That is, as I understand it, why we're moving away from 
presentational markup in general.) I don't know how much of a difference 
this single attribute would have. Probably not much if it's just this one 
and we only allow the value "right" and define it to mean "numeric".


> How does it improve maintainability?

It doesn't make any significant difference if the alignment is the only 
difference. It makes it a lot easier if there is ever anything else that 
is specific to numeric cells (e.g. right-padding to avoid the numbers 
being flush to the cell, or decimal alignment if that ever gets 
implemented in CSS processors, or text colour for negative values, etc).


> What about device-independence?

I don't think it affects device-independence at all.

Media-independence would be mildly improved, since this is a 
media-specific attribute. I think defining it as media-independent (as I 
suggest above, making it mean "numeric") would be a harder sell than 
making <b> and <i> media-independent.


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

I don't really buy that. The tables I looked at indicate that authors 
already have no problem doing it for tables. Indeed, for everything but 
alignment, even you seem to agree that they should do so. Having the 
alignment specifically handled separately seems like an odd choice... 
I think it would make the language feel like it was shy about fully 
committing to its goals.


On Tue, 9 Jun 2009, Lachlan Hunt wrote:
> 
> In my experience, cell alignment in data tables most commonly applies on 
> a per-column basis, such that all data cells in a given column will, for 
> example, be aligned right.  Using a per-cell alignment mechanism is 
> really a kludge that is indicative of the bigger problem of the severely 
> limited support for column-based styling in CSS.

I agree.


> Ideally, we'd be able to select cells based on which column they were 
> in, perhaps somehow selecting based on the cell's associated <col> or 
> <colgroup> element. But, unfortunately, we can't.

Yet.


> The following solutions can be considered:
> 
> * Allow align="" on col and colgroup elements
>   - Easy for authors to assign once per column.
>   - Only appears to be supported by Opera.

This turns out to be substantially difficult to implement while being 
strictly compatible with CSS. (The bug to implement this in Mozilla is the 
only open three-digit bug I know of.)

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

Received on Thursday, 2 July 2009 08:12:17 UTC