Bug 15277 – COL element in table has 0 for offsetWidth

• Component: Tables
• Status: RESOLVED FIXED

[Bob Rose]

The offsetWidth value doesn't seem to ever change from 0.
Code sample attached.

[Bob Rose]

Created attachment 16383 [details]
Stand alone test case shows COL element does not return offsetWidth

[Mark Rowe (bdash)]

Thanks for the test case!

[Bob Rose]

(In reply to comment #2)
> Thanks for the test case!
> 

Hey folks, any update on this bug?  I filed it almost a year ago. It's somewhat important for doing dynamic table cell adjustments.

thanks!
Bob

[Frank Manno]

I've just run into this bug myself.  Any attempts at querying a <col> element's offsetWidth returns zero.  Same goes for attempting to read the CSS style associated with the <col> element (using getComputedStyle).

Any word on this bug?  I would greatly appreciate it.

[Frank Manno]

As an addendum... I'm running Safari v4.0.4 (5531.21.10).

[Daniel Bates]

Created attachment 47314 [details]
Patch

Work in progress.

Passes the stand alone test case <https://bugs.webkit.org/attachment.cgi?id=16383&action=edit>.

Currently, returns 0 if the width of the <col> is a percentage.

I am open to suggestions on how to resolve this as well as whether this patch represents the correct approach (that is, to override the method RenderTableCol::offsetWidth).

[Frank Manno]

(In reply to comment #6)

Daniel,

Is it possible to return the pixel width, of a<col> with a percentage width, based on its parent container?  So if the parent container has a width of 500px and the <col> has its width set to 25%, we could simply return 500*.25 = 125px?

Just a thought.  Not sure if it makes sense in this context.

[Daniel Bates]

Can you elaborate on what you mean by the parent container? Do you mean the table? the ambient container that contains the table?

Never mind my comment earlier about getting 0 when <col> is a percentage value.

(In reply to comment #7)
> (In reply to comment #6)
> 
> Daniel,
> 
> Is it possible to return the pixel width, of a<col> with a percentage width,
> based on its parent container?  So if the parent container has a width of 500px
> and the <col> has its width set to 25%, we could simply return 500*.25 = 125px?
> 
> Just a thought.  Not sure if it makes sense in this context.

[Daniel Bates]

Created attachment 50183 [details]
Patch

Work in progress.

Resolved issue with percentages. Confirmed offsetWidth is correct for test case as well as for the sample table in section 11.5 of the HTML 4 spec. <http://www.w3.org/TR/html401/struct/tables.html#h-11.5>.

Also implemented offsetLeft, offsetTop, and offsetHeight. But offsetLeft and offsetTop seem to be off by 1 pixel from the values reported for the top-most table cell in each column. From observation, offsetHeight looks reasonable, but will need to confirm.

[Daniel Bates]

Created attachment 82598 [details]
Patch

Updated work-in-progress patch. Needs change log.

[Daniel Bates]

Created attachment 83227 [details]
Patch and layout test

This patch implements offset{Left, Top, Width, Height} for table columns and column groups and hence passes the test case "Stand alone test case shows COL element does not return offsetWidth".

For some reason, offsetLeft and offsetTop for table columns and column groups always return 0 in IE 7 and greater (why?) (see remark (*)). Therefore, I chose to mimic IE's behavior and hardcode returning 0 for offsetLeft and offsetTop because these properties are IE extensions (i.e. not defined in a W3C spec.). Compare this behavior to Firefox.

(*) I was unsure of the best forum to report this issue. I couldn't find an IE bug tracker. So, I described this issue on the Microsoft Connect "Internet Explorer Web Development" forum: <http://social.msdn.microsoft.com/Forums/en/iewebdevelopment/thread/08597d1f-7153-4ebe-b834-4ac2883c2447>.

[Daniel Bates]

Created attachment 83230 [details]
Self-contained col-and-colgroup-offsets.html

For convenience, a self-contained version of the layout test included in the patch.

[Daniel Bates]

Comment on attachment 83227 [details]
Patch and layout test

Clearing review flag to think about this patch some more.

[Daniel Bates]

On 03/14/2011, I proposed for consideration to www-style that we change in the CSSOM View spec offset{Left, Top, Width, Height} for <col> and <colgroup> so that we return non-zero values: <http://lists.w3.org/Archives/Public/www-style/2011Mar/0322.html>.

[Scott Trenda]

Daniel, has this been sufficiently tested by now? It's still an issue in the latest versions of Safari and Chrome, and makes it extremely difficult to accurately analyze table structure and dimensions in WebKit-based browsers. Is there any particular reason there's been no advancement on this item in over two years, especially when [it looks like] a solution has already been fully developed?

[Daniel Bates]

As of CSSOM View Module draft 04/16/2013 the properties offset{Left, Top, Width, Height} are applicable to elements that have a computed "display" property of table-column or table-column-group; => these properties are applicable to <col> and <colgroup>elements.  At the time of writing (draft 04/22/2013), offset{Left, Top, Width, Height} should return a non-zero value for any "CSS layout box" and <col>s and <colgroup>s are considered to have a "CSS layout box": 

[[
The term CSS layout box refers to the same term in CSS. For the purpose of the requirements in this specification, elements that have a computed value of the 'display' property that is table-column or table-column-group must be considered to have an associated CSS layout box (the column or column group, respectively).
]]

For completeness, Simon Pieters responded to my proposal, <http://lists.w3.org/Archives/Public/www-style/2011Mar/0322.html>, in his email, <http://lists.w3.org/Archives/Public/www-style/2013Apr/0359.html> (sent 04/16/2013). The CSSOM View module draft was amended in <https://dvcs.w3.org/hg/csswg/rev/f34dc20f58fb>.

[Daniel Bates]

(In reply to comment #15)
> Daniel, has this been sufficiently tested by now?

The proposed patch had sufficient test coverage when it was written. I'll review the proposed test coverage following the amendment of the CSSOM View spec (see comment 16 above).

> It's still an issue in the latest versions of Safari and Chrome, and makes it extremely difficult to accurately analyze table structure and dimensions in WebKit-based browsers. Is there any particular reason there's been no advancement on this item in over two years, especially when [it looks like] a solution has already been fully developed?

Progress on this bug was blocked pending proposed changes to the CSSOM View spec (remarked in comment 14). As of CSSOM View draft 04/16/2013, the spec was amended to support offset{Left, Top, Width, Height} for <col> and <colgroup> elements. I'll look to move forward with this patch shortly.

[Scott Trenda]

(In reply to comment #17)
> Progress on this bug was blocked pending proposed changes to the CSSOM View spec (remarked in comment 14). As of CSSOM View draft 04/16/2013, the spec was amended to support offset{Left, Top, Width, Height} for <col> and <colgroup> elements. I'll look to move forward with this patch shortly.

Wow, crazy coincidental timing! I wasn't even aware of that. Thank you!

Out of curiosity, how long does it usually take for changes like this to make their way into an official Chrome/Safari release?

[Daniel Bates]

(In reply to comment #18)
> [...]
> 
> Out of curiosity, how long does it usually take for changes like this to make their way into an official Chrome/Safari release?

I don't know. Each WebKit vender decides when a fix will be included in a release. I'll look to inform interested parties and provide support to help expedite the process if applicable.

[Daniel Bates]

Created attachment 214928 [details]
Work-in-progress patch and layout test

[Daniel Bates]

Created attachment 224533 [details]
Patch and layout test

Updated patch.

We currently fail almost all of the offset{Height, Top} sub-tests in the included layout test because these values depend on the offset{Top, Height} of one or more table row groups (RenderTableSection) and we don't compute such offsets correctly for row groups in the separate border model. See <https://bugs.webkit.org/show_bug.cgi?id=128988> for more details.

[Daniel Bates]

Created attachment 224534 [details]
Self-contained col-and-colgroup-offsets.html

Updated self-contained test to compute offsets for cols and colgroups under the separated and collapsed border models.

[Dave Hyatt]

Comment on attachment 224533 [details]
Patch and layout test

r=me

[Daniel Bates]

Committed r164504: <http://trac.webkit.org/changeset/164504>