[Webkit-unassigned] [Bug 143609] Consider implementing Document.scrollingElement

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=143609

--- Comment #7 from Rick Byers <rbyers at chromium.org> ---
(In reply to comment #6)
> (In reply to comment #5)
> > I'd rather just fix the damn bug too.  The problem is that we're finding
> > lots of sites that have been forced to guess at the scrollingElement using a
> > UA check (here's an example:
> > https://github.com/google/closure-library/blob/
> > 32365aba43acb36c5d693256ef5d4dbe3bddddfe/closure/goog/dom/dom.js#L632, and
> > Facebook had something similar).  I need some good/simple/reliable guidance
> > for those sites to migrate to the spec-compatible behavior.  After a number
> > of failed attempts, I don't see any path for switching blink to the correct
> > behavior without first adding such an API.  Thoughts?
> 
> The problem here is the UA check for detecting behavior.
> 
> If it is just a matter of feature detection, one could change scrollTop/Left
> on body, observe which viewport has been modified, then restore the scroll
> position.

That might result in a noticeable visible artifact (especially for code that's invoking such 'find me the scrolling element' logic regularly).  If you plan to cache the result then you need to also force the page to be scrollable somehow during the test.  The polyfill referenced above addresses all these issues by creating a temporary iframe to run the test, and as a result is starting to get a little complex (hard to argue that it's a good drop in replacement for the simple UA check folks are doing).  But I can see the argument saying that's a better path forward.

> What I do not like about "scrollingElement" is that it looks like a
> temporary hack. It goes against keeping the platform simple.

I agree it would be nicer if we could correct our mistakes only through simplifying the platform API surface area.  But breaking changes (even bug fixes) are really hard to do.  Personally I'm willing to add simple, well-defined APIs when it simplifies the platform mental model even while adding more surface area.  FWIW I expect the presence of this API to simplify the spec text around all this dramatically, as it has simplified our implementation in blink - crrev.com/1075393002 (both of course could have been done by introducing the concept without exposing it).

Anyway, pragmatically it feels to me like our choices are to add an API like this to answer the exact question developers are attempting (and failing) to guess or to stick with the status quo where browsers that pretend to be WebKit in their UA (now including MS EdgeHTML) have to have a different implementation than those that don't.  I'm happy to be proven wrong if someone else wants to pick up the torch of trying to get this platform wart fixed a different way - it looks like bug 106133 hasn't had any love in awhile :-(

Also there is the minor argument Simon alluded to which says it's simpler and more reliably for library developers to use scrollingElement than to figure out they need to determine whether or not they're in quirks mode.  But I agree that's a pretty minor simplicity benefit, not enough to justify this API on it's own.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150413/f784da8b/attachment.html>