At 09:43 AM 5/4/01 -0400, Leonard Rosenthol wrote:
>>Tables know their horizontal dimensions as containts.
>
> Not necessarily. HTML Tables, for example, allow for best fit,
>percentage width (50% of page), and can also allow for fixed height,
>dynamic width.
Yep. One of the key design decisions we'll need to make when choosing how
to implement tables is to decide which table model to adopt. Specifically,
the constraint system used will be one of the thorniest issues.
For example, HTML tables. Eric, Jeff, and I were core members of the web
browser team at Spyglass back when everyone was first implementing tables
for HTML. (Jeff was the lucky guy on our team who did tables for us -- he's
just that good.)
At the time, Dave Ragget and company had a number of precedents for table
constraint systems and eventually wound up choosing a rich feature set that
was, to be blunt, not entirely precise. Without going into the details,
HTML allows you to create valid tables where the exact formatting
requirements are, uh, underspecified. Depending on which constraint you
paid attention to, you'd wind up formatting the pixels in subtly different
ways.
Thus, the net effect we're all used to was determined as much by market
share -- all browser authors needed to do enough reverse-engineering to
ensure that we made the same choices at those points in our code that NSCP
did in theirs -- as it was by the official HTML spec. AFAIK, nobody
associated with W3C has ever attempted to fully rectify those ambiguities in
a later spec. Thus, anyone who *really* wants to adopt the HTML table model
will either need to redo that reverse-engineering (ick), or else study the
sources to one of those products in a way which doesn't contaminate our GPL
sources (double-ick).
At the time, I remember Jeff giving detailed comparisons of the strengths
and weaknesses of various table models, such as:
- de facto HTML
- Word
- and others with less market share
At the time, I probably even understood most of what he told me. ;-) But
that was a long time ago, and ugliness like that tends to fade from memory.
In any event, trust me ... it's a mess. Solveable, of course, but a mess.
bottom line
-----------
IIRC, when you get down far enough in the details of a complete tables
implementation, many of the potential formatting models are subtly or
grossly incompatible in what their constraint systems allow you to specify.
I know this sounds like FUD, but it may be that we'll have to choose a model
which restricts our ability to express every formatting effect allowed by
other models. If so, then off the cuff, I'd suspect that our best bet would
be to adopt the constraint system used by Word and other word processors.
It's far more important to have flawless interoperability with those
products than to be the world's most expressive web authoring environment.
However, this isn't a discussion that'll be resolved either way over email.
Not now. It can only be resolved by the small set of folks who eventually
dig in and tackle the whole hairball.
Like others on this thread who've dealt with tables code in the past, my
only goal now is to give everyone a flavor of the kind of complexity ahead
of us in this area.
Paul
