Re: [CSSOM View] Extensions to Element.scrollLeft and Element.scrollTop are not valid WebIDL

On Wed, Jul 30, 2014 at 6:05 PM, Kip Gilbert <kgilbert@mozilla.com> wrote:
> On 2014-07-30, 2:45 PM, Tab Atkins Jr. wrote:
>> On Tue, Jul 22, 2014 at 7:39 PM, Kip Gilbert <kgilbert@mozilla.com>
>> wrote:
>>> I would like to suggest that the scrollTop and scrollLeft
>>> attributes remain as double data type only, and that a separate
>>> method be added to the Element interface for scrolling with
>>> ScrollOptions:
>>>
>>> void scrollTo(double x, double y, optional ScrollOptions
>>> options);
>>>
>>> Calling this method would be equivalent to setting both the
>>> scrollTop and scrollLeft attributes while simultanously
>>> specifying the ScrollOptions.
>>
>> I don't think this signature is quite right.  It requires you to
>> set both x and y, while setting the attributes lets you do only one
>> or the other if you want.
>>
>> I'd prefer subclassing ScrollOptions into containing top/left
>> members, and having scrollTo just take a ScrollOptions object.
>> Give top/left a default of null, and have that mean "no scrolling
>> in this axis".
>>
>> Otherwise, I'm fine with this.
>
> Would it be appropriate for such a subclass to also contain
> "scrollRight", "scrollBottom", and possibly an attribute that is
> sensitive to LTR vs RTL direction?  Perhaps this could be an
> opportunity to address the issues in Koji Ishii's comment.

Yes, adding right/bottom/block/inline is a good idea.

> If so, what would be the best action to take if the attributes are
> over-constrained on an axis?  Would the order of precedence would
> differ in LTR and RTL direction?

This is JS, not CSS; we don't have to grin and bear it when you
overconstrain. ^_^  We can just throw if you have incompatible
non-null values: mixing left/right, or top/bottom, or
physical/logical.

~TJ

Received on Wednesday, 30 July 2014 23:16:35 UTC