RE: [#293] Summary for tables

Jens Meiert wrote:

> Are tables (used for layout) really that bad...?

Yup. They make the content less accessible, and they
make it impossible for browser authors to implement
functionality which could be *really* useful for tables,
e.g. having the table header (<thead>) fixed while
scrolling, or at the top of every page when printing,
etc.

Because tables are being abused to the great extent it
is, one lacks a lot of neat table-functionality which
could be implemented into browsers if tables were used
for... *Tables*.

> I really see Accessibility problems, but these would be
> removed introducing the type attribute.

No, the content will still be plunged into wrong tags and
the content's (semantic) meaning won't be expressed
correctly. Also, the content will be locked to a certain
view which can't be altered in an easy way, neither by
the user or by the page author.

Yes, Opera's Small Page Rendering algorithm works ok, but
it isn't perfect, and it's just a hack to make HTML work
as *intended* although authors don't use it that way.

Opera is buying authors time I don't think they deserve,
and I think they really just are doing them a disservice.

> Maybe XHTML 2 will us enable a 'new beginning' (e.g. not
> needing layout tables anymore)

We don't need layout tables with HTML 4.01 either. CSS does
the magic. In fact, you can create something that visually
looks like a table, but is just a bunch of <div>'s with
'display: table-cell' and the other table-centric display
values on them.

> but maybe (and IMO likely) it is necessary to use them later,
> too, and an optional type attribute (for emergency cases,
> if you want) offers an alternative.

If you don't know how to create something similar to <table>
with <div> and CSS, it isn't a flaw in the standard; it is
you, lacking knowledge and experience.

> In general, it would be useful -->now.

But it's not necessary.

> And I think it's not important when anything is
> implemented properly by e.g. browser vendors, since it
> is characteristic for the IT landscape that there are
> many recommendations, specifications etc.

There aren't many specifications for HTML. For earlier
versions you have som ISO and W3C alternatives, but for
the later versions, W3C is the origin and they only release
one standard document per version. I don't see the problem.

> you first have to wait until you can really and properly
> use them (see the Java 1.4 introduction, or the buggy CSS 2
> support, take what you want  -- often you have to pass on
> possible features for maybe weeks, maybe years).

It's often wise to wait, but you have to stay updated as well.
Just compare Opera or Mozilla's CSS support to Internet
Explorer's. It's obvious that Microsoft stopped the development
of IE too early, and the CSS2 support of Opera and Mozilla is
no longer buggy. Not at all.

It takes time to support a standard the way it is intended,
and it takes time for the standard to maturate with erratas
and experiences in the market. But no one gains anything by
just sitting on the fence waiting for the standard to be
perfect.

> -- Last but not least, my proposal was rather an idea how
> the problem could have been solved quite earlier

The problem is already solved. It's called CSS.

-- 
Asbjørn Ulsberg           -=|=-          X-No-Archive: No
"He's a loathsome offensive brute, yet I can't look away"

Received on Monday, 28 July 2003 05:35:16 UTC