This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 26294 - CSSOM-View extensions to Element.scrollLeft and Element.scrollTop are not valid WebIDL
Summary: CSSOM-View extensions to Element.scrollLeft and Element.scrollTop are not val...
Status: NEW
Alias: None
Product: CSS
Classification: Unclassified
Component: CSSOM View (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Simon Pieters
QA Contact: public-css-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-08 22:27 UTC by Kearwood "Kip" Gilbert
Modified: 2014-09-25 14:09 UTC (History)
2 users (show)

See Also:


Attachments

Description Kearwood "Kip" Gilbert 2014-07-08 22:27:42 UTC
In the CSSOM-View Specification, in the "7 Extensions to the Element Interface" section, extensions to Element.scrollLeft and Element.scrollTop are described using invalid WebIDL.

The WebIDL described in the extension:

  attribute (double or ScrollOptionsVertical) scrollTop;
  attribute (double or ScrollOptionsHorizontal) scrollLeft;

In order to retain backwards compatibility with the existing scrollTop and scrollLeft attributes, a different (double) data type would need to be returned by the getter than in the setter (union of a double and dictionary).

Either the WebIDL specification needs to be extended to support different datatypes for getters and setters, or the CSSOM-View extensions to the element interface needs to be altered.

Perhaps this could be solved by replacing the extensions to scrollTop and scrollLeft with additional methods on the Element interface for performing the scrolling smoothly?
Comment 1 Boris Zbarsky 2014-07-09 00:26:13 UTC
> Either the WebIDL specification needs to be extended to support different
> datatypes for getters and setters

Note that this idea has been floated before and the general consensus has been that this is not very good API design.
Comment 2 Kearwood "Kip" Gilbert 2014-09-16 17:53:52 UTC
Feedback on w3.org is requesting that new scrolling API's support both physical and logical coordinates for the scroll offset:

http://lists.w3.org/Archives/Public/www-style/2014Jul/0385.html

In order to include writing-mode and rtl agnostic scroll offset support, I propose that
we create a new function, Element.scrollTo, which takes a dictionary derived from
ScrollOptions.

Proposed WebIDL
---------------

dictionary ElementScrollOptions : ScrollOptions {
  double left;
  double top;
  double right;
  double bottom;
  double blockStart;
  double blockEnd;
  double inlineStart;
  double inlineEnd;
};

void scrollTo(optional ElementScrollOptions options);

Members
-------

Various combinations of ElementScrollOptions members can be passed to scrollTo to
select the scroll destination with a physical or abstract offset:

left:
  - Number of pixels that an element’s content is scrolled to the left.  Equivalent
    to setting the "Element.scrollLeft" attribute.
  - If the direction of the element is ltr (left-to-right) then "left" is 0 when the
    scrollbar is at its leftmost position (at start of the scrolled content) and then
    increases as you scroll towards the end of the content.
  - If the direction of the element is rtl (right-to-left) then "left" is 0 when the
    scrollbar is at its rightmost position (at start of the scrolled content) and
    then increasingly negative as you scroll towards the end of the content.

right:
  - Number of pixels that an element’s content is scrolled to the right.
  - If the direction of the element is ltr (left-to-right) then "right" is 0 when the
    scrollbar is at its rightmost position (at the end of the scrolled content) and
    then increasingly negative as you scroll towards the start of the content.
  - If the direction of the element is rtl (right-to-left) then "right" is 0 when the
    scrollbar is at its leftmost position (at the end of the scrolled content) and then
    increases as you scroll towards the start of the content.

top:
  - Number of pixels that the content of an element is scrolled upward.  Equivalent
    to setting the "Element.scrollLeft" attribute.
  - "top" is 0 when the scrollbar is at its topmost position (at the start of the
     scrolled content) and then increases as you scroll towards the bottom of the
     content.

bottom:
  - Number of pixels that the content of an element is scrolled downward.
  - "bottom" is 0 when the scrollbar is at its bottommost position (at the start of
    the scrolled content) and then increasingly negative as you scroll towards the top
    of the content.

blockStart:
  - "blockStart" is an offset relative to the side that comes earlier in the block
    progression, as determined by the writing-mode property.
  - In horizontal-tb mode, is equivalent to setting value of "top".
  - In vertical-rl mode, is equivalent to setting value of "right".
  - In vertical-lr mode, is equivalent to setting value of "left".

inlineStart:
  - "inlineStart" is an offset relative to the side from which text of the inline
    base direction would start.
  - With a direction value of ltr, this is the line-left side.
  - With a direction value of rtl, this is the line-right side.

blockEnd:
  - "blockEnd" is an offset is relative to the side opposite block-start.

inlineEnd:
  - "inlineEnd" is an offset is relative to the side opposite inline-start.

For a complete list of all combinations and their equivalent physical mappings, see [2].

Rules
-----
- "left", "top", "right", and "bottom" represent physical scrolling offsets.
- "blockStart", "blockEnd", "inlineStart", and "inlineEnd" represent offsets
  in flow-relative directions [1].
- Values assigned to "blockStart", "blockEnd", "inlineStart", and "inlineEnd" are set
  to the equivalent physical offsets of left, top, right, and bottom as per
  "6.4 Abstract-to-Physical Mappings" in the "CSS Writing Modes Level 3"
  specification [2].
- If physical scrolling offsets are mixed with offsets in flow-relative directions, an
  exception will be thrown.
- If non-finite values (NaN, -Infinity, Infinity) are passed to any member of
  ElementScrollOptions, an exception will be thrown.
- The scrolling offset is considered over-constrained if more than one offset for any
  axis are passed simultaneously.
  - "left" and "right" are mutually exclusive
  - "top" and "bottom" are mutually exclusive
  - "blockStart" and "blockEnd" are mutually exclusive
  - "inlineStart" and "inlineEnd" are mutually exclusive
- If the scrolling offset is over-constrained, an exception will be thrown.
- If a scrolling offset for an axis is not passed, then the position of that axis
  at the start of the scroll will be used as the destination position for that axis.
- If no scrolling offsets are included in ElementScrollOptions, the scrollTo call
  will perform a scroll with the destination set to the current scroll offset.  This may
  cause a smooth scroll [3] to be interrupted.  If ScrollOptions and the smooth-scroll
  CSS property evaluate to a smooth scroll, then a smooth scroll to the current position
  is performed to end the scroll at the specified offset in a UA defined smooth fashion.


[1] CSS Writing Modes Level 3 - Flow-relative directions
http://dev.w3.org/csswg/css-writing-modes/#block-start

[2] CSS Writing Modes Level 3 - 6.4 Abstract-to-Physical Mappings 
http://dev.w3.org/csswg/css-writing-modes/#logical-to-physical

[3] CSSOM View Module - 4.1 Scrolling
http://dev.w3.org/csswg/cssom-view/#scrolling
Comment 3 Simon Pieters 2014-09-16 20:00:38 UTC
Thanks Kip! I'm working on this and came up with the same syntax, but I think it would be good to have scrollBy also to replace `scrollLeft += 10`. Maybe also throw in scroll() since it exists on window?

I'm also looking into making ScrollOptions the first argument for the scroll methods on window. It would be nice if they were consistent I think. WDYT?

(There is also an open issue about making the object the first argument for scrollIntoView().)
Comment 4 Kearwood "Kip" Gilbert 2014-09-16 20:22:01 UTC
(In reply to Simon Pieters from comment #3)
> Thanks Kip! I'm working on this and came up with the same syntax, but I
> think it would be good to have scrollBy also to replace `scrollLeft += 10`.
> Maybe also throw in scroll() since it exists on window?
> 
> I'm also looking into making ScrollOptions the first argument for the scroll
> methods on window. It would be nice if they were consistent I think. WDYT?
> 
> (There is also an open issue about making the object the first argument for
> scrollIntoView().)

Thanks Simon,

Taking this further, with element.scrollBy, window.scrollTo, and window.scrollBy seems natural.

Perhaps the ElementScrollOptions dictionary could be renamed if it is used for both element and window?  Or would you suggest that window and/or scrollBy methods accept a different set of members?

Cheers,
  - Kearwood "Kip" Gilbert
Comment 5 Simon Pieters 2014-09-16 20:39:48 UTC
Yeah I'd name it something else.
Comment 6 Simon Pieters 2014-09-25 14:09:12 UTC
https://dvcs.w3.org/hg/csswg/rev/c678078eb0a9
https://dvcs.w3.org/hg/csswg/rev/6f00ba0f95ab
https://dvcs.w3.org/hg/csswg/rev/4784c9824e02

These are not done yet:

  double right;
  double bottom;
  double blockStart;
  double blockEnd;
  double inlineStart;
  double inlineEnd;