Bug 15277 - COL element in table has 0 for offsetWidth
Summary: COL element in table has 0 for offsetWidth
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tables (show other bugs)
Version: 523.x (Safari 3)
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Daniel Bates
URL:
Keywords: GoogleBug, HasReduction
Depends on:
Blocks:
 
Reported: 2007-09-25 00:02 PDT by Bob Rose
Modified: 2014-02-21 14:33 PST (History)
10 users (show)

See Also:


Attachments
Stand alone test case shows COL element does not return offsetWidth (1.24 KB, text/html)
2007-09-25 00:05 PDT, Bob Rose
no flags Details
Patch (1.03 KB, patch)
2010-01-24 23:04 PST, Daniel Bates
no flags Details | Formatted Diff | Diff
Patch (5.38 KB, patch)
2010-03-07 17:59 PST, Daniel Bates
no flags Details | Formatted Diff | Diff
Patch (12.53 KB, patch)
2011-02-16 00:30 PST, Daniel Bates
no flags Details | Formatted Diff | Diff
Patch and layout test (19.84 KB, patch)
2011-02-21 15:48 PST, Daniel Bates
no flags Details | Formatted Diff | Diff
Self-contained col-and-colgroup-offsets.html (15.01 KB, text/html)
2011-02-21 15:55 PST, Daniel Bates
no flags Details
Work-in-progress patch and layout test (31.04 KB, patch)
2013-10-22 22:13 PDT, Daniel Bates
no flags Details | Formatted Diff | Diff
Patch and layout test (30.45 KB, patch)
2014-02-18 12:08 PST, Daniel Bates
hyatt: review+
Details | Formatted Diff | Diff
Self-contained col-and-colgroup-offsets.html (29.64 KB, text/html)
2014-02-18 12:12 PST, Daniel Bates
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bob Rose 2007-09-25 00:02:01 PDT
The offsetWidth value doesn't seem to ever change from 0.
Code sample attached.
Comment 1 Bob Rose 2007-09-25 00:05:46 PDT
Created attachment 16383 [details]
Stand alone test case shows COL element does not return offsetWidth
Comment 2 Mark Rowe (bdash) 2007-09-25 00:41:09 PDT
Thanks for the test case!
Comment 3 Bob Rose 2008-09-07 22:35:52 PDT
(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
Comment 4 Frank Manno 2010-01-21 14:04:26 PST
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.
Comment 5 Frank Manno 2010-01-21 14:26:52 PST
As an addendum... I'm running Safari v4.0.4 (5531.21.10).
Comment 6 Daniel Bates 2010-01-24 23:04:20 PST
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).
Comment 7 Frank Manno 2010-01-29 13:21:37 PST
(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.
Comment 8 Daniel Bates 2010-01-31 20:31:20 PST
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.
Comment 9 Daniel Bates 2010-03-07 17:59:44 PST
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.
Comment 10 Daniel Bates 2011-02-16 00:30:50 PST
Created attachment 82598 [details]
Patch

Updated work-in-progress patch. Needs change log.
Comment 11 Daniel Bates 2011-02-21 15:48:09 PST
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>.
Comment 12 Daniel Bates 2011-02-21 15:55:28 PST
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.
Comment 13 Daniel Bates 2011-02-22 01:15:20 PST
Comment on attachment 83227 [details]
Patch and layout test

Clearing review flag to think about this patch some more.
Comment 14 Daniel Bates 2011-04-01 13:15:16 PDT
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>.
Comment 15 Scott Trenda 2013-04-18 14:49:56 PDT
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?
Comment 16 Daniel Bates 2013-04-22 11:08:09 PDT
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>.
Comment 17 Daniel Bates 2013-04-22 11:09:32 PDT
(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.
Comment 18 Scott Trenda 2013-04-22 14:48:31 PDT
(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?
Comment 19 Daniel Bates 2013-04-28 21:30:35 PDT
(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.
Comment 20 Daniel Bates 2013-10-22 22:13:50 PDT
Created attachment 214928 [details]
Work-in-progress patch and layout test
Comment 21 Daniel Bates 2014-02-18 12:08:55 PST
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.
Comment 22 Daniel Bates 2014-02-18 12:12:58 PST
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.
Comment 23 Dave Hyatt 2014-02-20 11:21:40 PST
Comment on attachment 224533 [details]
Patch and layout test

r=me
Comment 24 Daniel Bates 2014-02-21 14:33:03 PST
Committed r164504: <http://trac.webkit.org/changeset/164504>