RE: How is it possible to devise such a feeble system?

On Sun, 28 Oct 2001, Jeffrey Yasskin wrote:

>Goal: CSS needs to be able to reproduce in an arbitrary XML grammar the
>_presentation_ of anything currently available in XHTML.

Precisely. I take this to include *presentations* of tables, be they
visual, aural or tactile. I don't really see what this has to do with
table semantics, per se.

>So, in order to tell an aural browser how to present a table, they have
>to include some semantics.

Quite. You'll get those semantics (like heading structure, summaries and
the like) from the XML. The CSS tells you how to render the stuff. The
latter does not have to have anything to do with the default rendering of
the former. So, if you have something that is semantically a table, you
will need to tell CSS that it indeed is to be displayed as a table. This
is what the classification properties are for.

This does not mean that every stylesheet would indeed render what is
semantically a table as a visual/aural table, or refrain from showing some
non-table data precisely as a genuine table would be shown. I.e. there is
essentially no reason why one couldn't render only the caption row of what
is semantically a table as a series of auto-numbered block boxes --
rendering a table as tables are usually rendered is just a default, which
can, sometimes even should, be overridden.

>You're suggesting that in an aural browser {display:table} would encode
>semantics, but in a visual browser it wouldn't. Certainly that's a
>possible direction for the spec to go, but I don't think it's a good
>idea.

That is absolutely *not* what I'm suggesting. I'll try to summarize my
viewpoint.

1) What *is* a table and what *renders as* a table are heavily
   overlapping, but separate things; they do not depend on one another
2) All combinations along the above two axes should be permitted, i.e.
 a) sth neither is nor renders as a table (e.g. div's)
 b) sth is but does not render as a table (e.g. a stylesheet to display a
    table summary as a block of text; inline-tables collapsed into their
    caption only, rendered originally as an inline box via dynamic CSS
    gimmickry)
 c) sth isn't, but displays as a table (e.g. stuff used to do a 2D layout)
 d) sth is and displays as a table (normal XHTML tables set to be
    displayed as such in CSS; this is the way user agent default
    stylesheets treat what is semantically a table)
3) The two axes should be kept separate, with semantics coming from an
   agreed upon XML grammar (XHTML Tables module), and style coming from
   CSS; keeping the axes separate implies that:
 a) XHTML should not include *any* presentation features
 b) CSS should not include *any* semantic features
4) The media does not matter -- they should all be handled the same
 a) The examples above apply to visual, aural and tactile, separately
 b) This does not imply that one should always render tables as tables for
    aural media just because one does for visual or tactile; e.g. one
    might want to render inline tables in their full form for visual
    presentation, but back off to only voicing the table captions (as
    inline elements) in the default speech presentation (the ease rapid
    browsing)
 c) There is no essential variance in the presentation/semantics
    dichotomy as applied to the different media

I always thought all of the above was pretty much self-evident, what with
all the talk among the structured documentation folks about separating
document semantics from presentation. The goodness arising out of shared
schemata/ontology, and the possibility of achieving precisely this via
XHTML Modules and XML Namespaces, would seem to imply that what is
semantically a table should be an XHTML Table, too.

Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

Received on Wednesday, 31 October 2001 15:11:04 UTC