Interoperability and CompatibilityAs this is a modification of an existing feature which exists in all browsers, and the proposed change is still compliant to the spec, the interoperability risk is minimal. That being said, we discuss in the design document whether the spec should be changed based on some issues we’ve run into. If we decide to go that route, we will have to revisit the interoperability risks.For compatibility, this feature will change the value that Chromium surfaces to the event handlers for the mouse wheel event. Assuming we resolve the percentage to DOM_DELTA_PIXELS as they are currently surfaced today, we are presented with two problems:1. The first is that the wheel event will bubble up to all elements that have an event listener for it. These elements will not know which scroller the delta will be applied to, and so the delta largely becomes meaningless.2. Additionally, for websites that implement some custom UI which takes advantage of the wheel event but does not relate to scrolling at all (e.g. zooming on a map), a varying delta value would likely cause issues. The delta values it would receive would depend on whatever surrounding scrollers exist; and, if there are no surrounding scrollers, the delta will be based off of the window size which is likely something that is not desired.Anecdotally, EdgeHTML implemented this feature in a similar fashion, except the percentage for the wheel event (but not the scroll) was always resolved against the window size. Even though this technically did not adhere to the spec and was inaccurate, we did not see any compatibility bugs due to this.Additionally, the delta that Chromium already surfaces already is not fully accurate on high DPI monitors: https://crbug.com/1001735With these two considerations, it's likely that compatibility risk is low. That being said, we fully explore the possibilities in the section "Issues with the wheel event delta" section in the design document.We would love to get comments and opinions regarding this.
I'm somewhat confused. At the beginning, you say that a scroll tick on
Windows is 100 logical pixels. But later you say that the default
Windows behavior is to scroll by three lines. The latter matches my
expectation of the behavior, and isn't consistent with the former; at
default font sizes, 100px is 5-6 lines of text.
1. Scrollers full of text will no longer scroll by a predictable
number of lines (approximately, at least) - if the scroller is short,
it'll scroll by a smaller amount, possibly even a fraction of a line
per tick, but if it's long it might scroll by much more.
2. This seems to imply that very short scrollers will only scroll a
few pixels per tick, requiring a significant spin of the mouse wheel
to reveal the bottom of the scrollable area.
3. And similarly, for very tall scrollers, like large images, a single
tick might move the image a significant distance. Is there a limit on
this? Can it scroll by more than a screenful if the scroller is large
enough?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/317643e1-ac21-4a4d-b757-15921bb28fa8%40chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
Can one of the folks proposing the change crisply enumerate the behavior of other browsers? I see the EdgeHTML status noted, but how does this work today on Gecko, WebKit, etc?
Windows – mouse wheel & non precision touch pad: When the OS setting is to scroll by lines, hardcodes a line -> pixel conversion, and surfaces the event in terms of DOM_DELTA_PIXEL. When the OS setting is to scroll by page, scrolls by approximately one page of the intended scroller and surfaces the event in terms of DOM_DELTA_PAGE.
Windows – precision touch pad: Scrolls by the pixel amount given by DManip, surfaces the event in terms of DOM_DELTA_PIXEL.
Mac - scrolls by the accelerated scroll amount sent by the OS for both touchpad and mouse wheel and surfaces the event in terms of DOM_DELTA_PIXEL.
Linux - converts the OS event into pixels and surfaces the event in terms of DOM_DELTA_PIXEL.
Windows - mouse wheel & non-precision touchpad: Converts the OS wheel event to a percentage and resolves it against the bounds of the intended scroller. It surfaces the mouse wheel event in terms of DOM_DELTA_PIXEL. However, it resolves the percentage for the event differently than for actually scrolling; it will always resolve it against the root scroller. The delta value surfaced to javascript will therefore not be accurate for subscrollers.
Windows - precision touch pad: Scrolls by the pixel amount given by DManip, does not surface the mouse wheel event.
There might be a compromise there where the line size doesn't
decrease linearly as you get small?
Okay, so assuming this is applied to the root scroller too, it means
that on screens ~700px tall the scroll amount won't change, but if
your screen is taller or shorter each wheel tick will be larger or
smaller than it is today?
It seems like developers need to know this. Can someone create a Status entry?
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9040b54b-2eb3-4981-9f17-97fba3c2d3d0%40chromium.org.
This sounds more like a UI change than a web platform change. I'm not sure the blink-dev process applies for this?
(I'm pretty sure Chrome's UI here is the way it is intentionally.)
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
It is also ok to send out "intent to implement" just to get feedback/pushback/cheers early on. Maybe the change in the end won't need a shipping decision, but that judgment can come later on.
(No direct comment on this particular feature since I've not studied the implications)
/Daniel
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/17d97061-3a99-45d4-b380-1786526d319c%40chromium.org.
This sounds more like a UI change than a web platform change. I'm not sure the blink-dev process applies for this?
For compatibility, this feature will change the value that Chromium surfaces to the event handlers for the mouse wheel event. Assuming we resolve the percentage to DOM_DELTA_PIXELS as they are currently surfaced today, we are presented with two problems:
1. The first is that the wheel event will bubble up to all elements that have an event listener for it. These elements will not know which scroller the delta will be applied to, and so the delta largely becomes meaningless.
2. Additionally, for websites that implement some custom UI which takes advantage of the wheel event but does not relate to scrolling at all (e.g. zooming on a map), a varying delta value would likely cause issues. The delta values it would receive would depend on whatever surrounding scrollers exist; and, if there are no surrounding scrollers, the delta will be based off of the window size which is likely something that is not desired.
Anecdotally, EdgeHTML implemented this feature in a similar fashion, except the percentage for the wheel event (but not the scroll) was always resolved against the window size. Even though this technically did not adhere to the spec and was inaccurate, we did not see any compatibility bugs due to this.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/17d97061-3a99-45d4-b380-1786526d319c%40chromium.org.