Bug 15277 - COL element in table has 0 for offsetWidth
: COL element in table has 0 for offsetWidth
Status: RESOLVED FIXED
: WebKit
Tables
: 523.x (Safari 3)
: Macintosh Mac OS X 10.4
: P2 Normal
Assigned To:
:
: GoogleBug, HasReduction
:
:
  Show dependency treegraph
 
Reported: 2007-09-25 00:02 PST by
Modified: 2014-02-21 14:33 PST (History)


Attachments
Stand alone test case shows COL element does not return offsetWidth (1.24 KB, text/html)
2007-09-25 00:05 PST, Bob Rose
no flags Details
Patch (1.03 KB, patch)
2010-01-24 23:04 PST, Daniel Bates
no flags Review Patch | Details | Formatted Diff | Diff
Patch (5.38 KB, patch)
2010-03-07 17:59 PST, Daniel Bates
no flags Review Patch | Details | Formatted Diff | Diff
Patch (12.53 KB, patch)
2011-02-16 00:30 PST, Daniel Bates
no flags Review Patch | Details | Formatted Diff | Diff
Patch and layout test (19.84 KB, patch)
2011-02-21 15:48 PST, Daniel Bates
no flags Review Patch | 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 PST, Daniel Bates
no flags Review Patch | Details | Formatted Diff | Diff
Patch and layout test (30.45 KB, patch)
2014-02-18 12:08 PST, Daniel Bates
hyatt: review+
Review Patch | 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 From 2007-09-25 00:02:01 PST
The offsetWidth value doesn't seem to ever change from 0.
Code sample attached.
------- Comment #1 From 2007-09-25 00:05:46 PST -------
Created an attachment (id=16383) [details]
Stand alone test case shows COL element does not return offsetWidth
------- Comment #2 From 2007-09-25 00:41:09 PST -------
Thanks for the test case!
------- Comment #3 From 2008-09-07 22:35:52 PST -------
(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 From 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 From 2010-01-21 14:26:52 PST -------
As an addendum... I'm running Safari v4.0.4 (5531.21.10).
------- Comment #6 From 2010-01-24 23:04:20 PST -------
Created an attachment (id=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 From 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 From 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 From 2010-03-07 17:59:44 PST -------
Created an attachment (id=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 From 2011-02-16 00:30:50 PST -------
Created an attachment (id=82598) [details]
Patch

Updated work-in-progress patch. Needs change log.
------- Comment #11 From 2011-02-21 15:48:09 PST -------
Created an attachment (id=83227) [details]
Patch and test case

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 From 2011-02-21 15:55:28 PST -------
Created an attachment (id=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 From 2011-02-22 01:15:20 PST -------
(From update of attachment 83227 [details])
Clearing review flag to think about this patch some more.
------- Comment #14 From 2011-04-01 13:15:16 PST -------
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 From 2013-04-18 14:49:56 PST -------
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 From 2013-04-22 11:08:09 PST -------
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 From 2013-04-22 11:09:32 PST -------
(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 From 2013-04-22 14:48:31 PST -------
(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 From 2013-04-28 21:30:35 PST -------
(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 From 2013-10-22 22:13:50 PST -------
Created an attachment (id=214928) [details]
Work-in-progress patch and layout test
------- Comment #21 From 2014-02-18 12:08:55 PST -------
Created an attachment (id=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 From 2014-02-18 12:12:58 PST -------
Created an attachment (id=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 From 2014-02-20 11:21:40 PST -------
(From update of attachment 224533 [details])
r=me
------- Comment #24 From 2014-02-21 14:33:03 PST -------
Committed r164504: <http://trac.webkit.org/changeset/164504>