- From: Simon Pieters <simonp@opera.com>
- Date: Fri, 18 Dec 2015 11:47:54 +0100
- To: www-style@w3.org, "Trav Stone" <travtrilogi@gmail.com>
- Cc: "Rick Byers" <rbyers@chromium.org>, "Emil A Eklund" <eae@chromium.org>, "Boris Zbarsky" <bzbarsky@mit.edu>
On Wed, 02 Dec 2015 09:42:13 +0100, Trav Stone <travtrilogi@gmail.com> wrote: > Hi, > > Jumping in this thread; it would definitely be helpful to have some API > that returns the exact values that the browser is operating upon. See the > following bugs I posted: > > https://code.google.com/p/chromium/issues/detail?id=559245 > https://bugzilla.mozilla.org/show_bug.cgi?id=1226695 > > In my use-case, what's of interest is knowing (via JS) when the browser > is > generating an ellipsis. Most of the time this works with integers, but > there are cases where it fails. Unfortunately in the application I'm > working on there's sufficient data being displayed to almost guarantee > that > the problem will surface on any given page. > > Also worth noting: in my use-case I'm working with text in a TD element, > so > getClientBoundingRect isn't an option unless I want to add extra markup. > Given that our application is so data-intensive (with corresponding > markup > complexity), extra markup is a fairly onerous burden. > > I understand the issues with changing the int values of the existing > API(s), so I am strongly in support of making a new API to resolve the > issue. > > Many thanks! OK, thanks for your feedback. A proposal for getting accurate scroll* information: [[ partial interface Element { [NewObject] DOMRect getScrollRect(); } 1. Let document be the element’s node document. 2. Let rect be a new static DOMRect with x/y/width/height set to 0. 3. If document is not the active document, return rect and terminate these steps. 4. Let window be the value of document’s defaultView attribute. 5. If window is null, return rect and terminate these steps. 6. If the element is the root element, follow these substeps: 1. Set rect's x to the x-coordinate, relative to the initial containing block origin, of the left of the viewport, or zero if there is no viewport. 2. Set rect's y to the y-coordinate, relative to the initial containing block origin, of the top of the viewport, or zero if there is no viewport. 3. Let viewport width be the width of the viewport excluding the width of the scroll bar, if any, or zero if there is no viewport. 4. Set rect's width to max(viewport scrolling area width, viewport width). 5. Let viewport height be the height of the viewport excluding the height of the scroll bar, if any, or zero if there is no viewport. 6. Set rect's height to max(viewport scrolling area height, viewport height). 7. Return rect and terminate these steps. 7. If the element does not have any associated CSS layout box, return rect and terminate these steps. 8. Set rect's x to the x-coordinate of the scrolling area at the alignment point with the left of the padding edge of the element. 9. Set rect's y to the y-coordinate of the scrolling area at the alignment point with the top of the padding edge of the element. 10. Set rect's width to the width of the element's scrolling area. 11. Set rect's height to the height of the element's scrolling area. 12. Return rect. ]] This is the same information as scrollLeft/scrollTop/scrollWidth/scrollHeight, but without the quirks mode nonsense (the body never maps to the viewport here), and x/y/width/height are unrestricted double. Thoughts? In your case, I think it should be possible to use getBoundingClientRect() on the cell; it should give the same result as the above API for a table cell. To measure the width of the *text* in the cell, without extra markup, you should be able to use https://drafts.csswg.org/cssom-view/#extensions-to-the-range-interface Something like http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3789 <!DOCTYPE html> <table><tr><td width=100 id=cell>asdf</table> <script> var range = new Range(); range.setStartBefore(cell.firstChild); range.setEndAfter(cell.lastChild); w(range.getBoundingClientRect().width) </script> -- Simon Pieters Opera Software
Received on Friday, 18 December 2015 10:48:37 UTC