Table column resizing anomaly

[ptc-953926]

Adepters:

Let's say you have a 2-column table with this markup:

<col width="130">
<col width="*">

In the table editor, drag the cell margin to make the first column twice as wide. I'd expect to then see:

<col width="260">
<col width="*">

but, instead see:

<col width="260">
<col width="100*">

In fact, it doesn't matter how wide you make column 1, it changes column 2 to "100*" - which is vastly different from "*" when played out in HTML (IE 7). I've verified this behavior in Editor 5.2 and 5.3. Is this a bug, or is a column width of "*" not supported?

Dave

[bibach]

Dave,

I'm not sure that this matters so much, but which table model are you
using? As I recall, the CALS model would say that, in the absence of
any other columns using the * syntax, "*" and "100*" are equivalent,
since the calculation method just involves adding up all of the
"coefficients" on the "*" widths, with 1 being the default value for a
* with no number, then dividing each one by the total and multiplying
the result by the width remaining after subtracting all of the
non-relative widths from the table width.

That said, how are you generating HTML output? Perhaps the bug lies
in the interpretation of the width specifications when translating to
HTML table markup.

-Brandon 🙂

Brandon Ibach
Developer, Single-Sourcing Solutions, Inc.

[ptc-953926]

Sorry, I should have stated that we're using the XHTML table model. We're passing the XHTML pretty much straight through as HTML to IE. The bug is in how Arbortext Editor changes the column width definitions as I described. The HTML interpretation of "130" and "*" is fine. But, your description of how widths are recalculated with CALS sounds like what's happening for XHTML.

[naglists]

Hi Dave,

I was thinking "*" was supported but a quick review of one of our XML
instances reveals we always have a number preceding the *. We author with
the CALS model but publish HTML from some of our applications. We have
always recommended that authors cause their colspec table widths to sum to
approximately 100. While inexact, this allows fairly simple authoring rule
plus fairly simple post-processing to get mostly predictable HTML table
column width behavior.

[bibach]

I'm a little confused, then. If my description of the width
calculations sounds like what's happening in XHTML, then you should
see the same results with either "*" or "100*". Can you describe how
the appearance of the rendered table differs in these two cases?

-Brandon 🙂

[ptc-953926]

Yes, with "130" and "*" you get a narrow first column (sort of fixed at 130px) and a wide second column that is flexible and fills the browser width. With the second column set to "100*", you get a much narrower second column that is actually narrower than the first (as you might expect if the relative widths were 130 and 100). So, our users try to make the first column a little wider by dragging it in the Editor, but completely change the rendering in the process.

[bibach]

I did some experiments with some simple, hand-crafted XHTML. Both IE8
and FF3 show the "*" and "100*" cases quite differently, as you
describe. The "10*" case seems to follow the pattern of "100*", with
the second column being smaller, still (looks about right for a 13:1
ratio of column widths). However, the "1*" case looks identical to
the "10*" case.

The two browsers are perfectly consistent with each other, and I'm of
the opinion that they are both badly broken in this regard. Market
share may not support my opinion, but I think it's justified by the
fact that Google Chrome renders all four cases identically, which is
what I would expect from reading the various relevant specs (both CALS
and the HTML/XHTML specs). Do a little more experimentation and
you'll see that cases such as "first column 130 pixels, second and
third columns having a 3:2 ratio of remaining width", which can not be
done without numbers before the "*", seem rather impossible.

I believe this evidence supports the case that there is nothing wrong
with Editor's handling of column width values, but rather that the
dominant browsers are not in compliance with the specs they so proudly
claim to adhere to.

That said, I imagine that your business requirements are to get this
working in IE. Some massaging of the data during your XML to XHTML
transform may provide the desired results in at least some cases, such
as the trivial case where only one column uses "*" syntax. Other than
that, I'm not sure what to suggest, since there may very well be no
way to get the browser to produce the correct result for more
complicated cases, such as the "impossible" one I mentioned above.
While there may be a setting to keep Editor from changing "*" to
"100*" (though, to my knowledge, there isn't), this will not fix every
possibility.

-Brandon 🙂

[naglists]

As Lynn used to say TATSOS.

On Fri, Jul 24, 2009 at 3:19 PM, Brandon Ibach <
brandon.ibach@single-sourcing.com> wrote:

> I did some experiments with some simple, hand-crafted XHTML. Both IE8
> and FF3 show the "*" and "100*" cases quite differently, as you
> describe. The "10*" case seems to follow the pattern of "100*", with
> the second column being smaller, still (looks about right for a 13:1
> ratio of column widths). However, the "1*" case looks identical to
> the "10*" case.
>
> The two browsers are perfectly consistent with each other, and I'm of
> the opinion that they are both badly broken in this regard. Market
> share may not support my opinion, but I think it's justified by the
> fact that Google Chrome renders all four cases identically, which is
> what I would expect from reading the various relevant specs (both CALS
> and the HTML/XHTML specs). Do a little more experimentation and
> you'll see that cases such as "first column 130 pixels, second and
> third columns having a 3:2 ratio of remaining width", which can not be
> done without numbers before the "*", seem rather impossible.
>
> I believe this evidence supports the case that there is nothing wrong
> with Editor's handling of column width values, but rather that the
> dominant browsers are not in compliance with the specs they so proudly
> claim to adhere to.
>
> That said, I imagine that your business requirements are to get this
> working in IE. Some massaging of the data during your XML to XHTML
> transform may provide the desired results in at least some cases, such
> as the trivial case where only one column uses "*" syntax. Other than
> that, I'm not sure what to suggest, since there may very well be no
> way to get the browser to produce the correct result for more
> complicated cases, such as the "impossible" one I mentioned above.
> While there may be a setting to keep Editor from changing "*" to
> "100*" (though, to my knowledge, there isn't), this will not fix every
> possibility.
>
> -Brandon
>
> On Fri, Jul 24, 2009 at 4:52 PM, Hintz, David L<->
> wrote:
> > Yes, with "130" and "*" you get a narrow first column (sort of fixed at
> 130px) and a wide second column that is flexible and fills the browser
> width. ?With the second column set to "100*", you get a much narrower second
> column that is actually narrower than the first (as you might expect if the
> relative widths were 130 and 100). ?So, our users try to make the first
> column a little wider by dragging it in the Editor, but completely change
> the rendering in the process.
> >
>

[steve.thompson4]

OK, I'll bite... TATSOS?

Steve Thompson

[ptc-953422]

Though Lynn did say it, I'd like to give credit where credit is due.
From my search of the Adepters archive, it was Ed back in June 2001 who
said it first (in a response to a comment by Lynn about them) and often:
tables are the spawn of Satan.



--Jack

[AndyEsslinger]

Tables Are The Spawn Of Satan!





\ / Andy Esslinger LM Aero Tech Order Data
_____-/\-_____ (817) 279-0442 Box 748, Mail Zone 4285
\_\/_/ (817) 777-3047 Fort Worth, TX 76101-0748