Re: [cssom-view] Which APIs should be 'double' vs. 'long'

I had thought an API like getScrollRect wasn't necessary because
getBoundingClientRect + fractional scrollTop/scrollLeft covered all the
scenarios.  But if there are scenarios that need fractional
scrollHeight/scrollWidth (or maybe even if it's demonstrably easier to use
getScrollRect), then I'd certainly support your getScrollRect proposal.

Rick

On Fri, Dec 18, 2015 at 12:55 PM, Trav Stone <travtrilogi@gmail.com> wrote:

> Hi Simon,
>
> Many thanks! Had no idea Range existed, but it does indeed return the
> value I need. I'd still argue that your proposed API is a bit easier to use
> than Range, but perhaps I'm in the minority with that viewpoint.
>
> At any rate, I really appreciate your response- very helpful!
>
> Trav
>
> On Fri, Dec 18, 2015 at 2:47 AM, Simon Pieters <simonp@opera.com> wrote:
>
>> 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
>>
>
>