| Summary: | [CSSOM View] Implement standard behavior for scroll(Left/Top/Width/Height/To/By/ingElement) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Dave Hyatt <hyatt> | ||||||
| Component: | DOM | Assignee: | Nobody <webkit-unassigned> | ||||||
| Status: | NEW --- | ||||||||
| Severity: | Normal | CC: | adele, ap, bfulgham, browserbugs2, cdumez, claude.pache, darin, dbates, diego.perini, dvoytenko, fred.wang, ian, jfernandez, joost, mathias, playmobil, rbuis, rbyers, rmondello, simon.fraser, syoichi, tonikitoo, vince.t.malone, zcorpan | ||||||
| Priority: | P2 | Keywords: | HasReduction, InRadar | ||||||
| Version: | 420+ | ||||||||
| Hardware: | Mac | ||||||||
| OS: | OS X 10.4 | ||||||||
| URL: | https://drafts.csswg.org/cssom-view/ | ||||||||
| Bug Depends on: | 161612, 182289, 182290, 182292, 188045, 143609, 171215, 182053, 182230, 182241, 182287, 189472 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
|
Description
Dave Hyatt
2005-12-07 13:28:00 PST
Need some test cases of what WinIE does in quirks and strict mode with scrollLeft/Top on both the <body> and <html> elements. See also: http://bugs.kde.org/show_bug.cgi?id=99380 which seems to apply a partial fix, but oddly only deals with setting and not with getting. Note that we do this already on the <body> element. We just need to do it for root elements as well. Either vicki or adele were working on scrolling issues like this very recently. We'll need a reduced test case for this one. Created attachment 6265 [details]
Testcase for IE strict mode
In IE, this scrolls down 100 pixels. Note that, when the DTD is left out, and IE goes in quirks mode, this doesn't work.
Created attachment 6266 [details]
Testcase for IE quirks mode
Adding a html 4 DTD to thise one, forcing IE in strict mode, makes it not work anymore...
Ok the comment on the first testcase was wrong, it's like this:
Strict Quirks
document.body.scrollTop - x
document.documentElement.scrollTop x x
The fact that document.documentElement.scrollTop works in IE is disputed by:
http://www.quirksmode.org/viewport/compatibility.html
but both me and Alexey found it to be working when testing with the above testcases.
Some more tests: http://www.xs4all.nl/~ppk/js/doctype_on.html http://www.xs4all.nl/~ppk/js/doctype_off.html > Need some test cases of what WinIE does in quirks and strict mode with > scrollLeft/Top on both the > <body> and <html> elements. For standards compliant rendering mode (document.compatMode == "CSS1Compat"), if you have access to WinIE6, then you can try these 2 pages: http://www.gtalbot.org/BugzillaSection/Bug189308_ScrollEvent.html http://www.gtalbot.org/DHTMLSection/WindowEventsMSIE6.html This has now been added to http://dev.w3.org/csswg/cssom-view/#scroll-attributes and WebKit does not match the spec. See discussion: http://lists.w3.org/Archives/Public/www-style/2009Oct/0314.html
The following code may be useful to find out which is the element in charge of scrolling the viewport:
function getScrollingElement() {
var d = document;
return d.documentElement.scrollHeight > d.body.scrollHeight &&
d.compatMode.indexOf('CSS1') == 0 ?
d.documentElement :
d.body;
}
it must be invoked before performing the actual scroll operation instead of during onload or DOMContentLoaded since the content may change later. See here for a cross browser example using the above code:
https://dl.dropboxusercontent.com/u/598365/scrollTo/scrollTo.html
This code will work when the bug will be fixed as explained in W3C CSSOM View specifications.
*** Bug 121876 has been marked as a duplicate of this bug. *** *** Bug 106133 has been marked as a duplicate of this bug. *** The issue with scrollTop/scrollLeft is actually a specific case of a general problem with that WebKit does not align on the CSSOM View Module [1], especially for quirks VS non-quirks modes. Hence I am renaming this bug to make it more explicit. There are some tests in the W3C test suite [2] that we should probably import. In particular, the following tests are relevant: * scrollingElement.html * scrolling-quirks-vs-nonquirks.html Chromium has a scrollLeftTopInterop runtime flag to implement the behavior specified in CSSOM View. Comparing Blink and WebKit code (dom/Element.cpp and dom/Document.cpp), I essentially see the following differences: 1) Chromium implements the spec's "If document is not the active document" for scrollLeft/Top (getting & setting), scrollTo/By and scrollWidth/Height. WebKit does not do that but I think it would be safe to change it without breaking existing page. I am not exactly sure how to test it, though. 2) Chromium implements the spec's behavior of scrollingElement, which can be be the root, the body or null. WebKit always returns the body (bug 143609). 3) For scroll(Left/Top/Width/Height/To/By), Chromium has specific cases to perform the operation on viewport when the element is the scrollingElement, corresponding to the "element == body or root" cases in the spec. WebKit always performs the operation on the element itself. I believe it would not be hard to import code from Chromium into WebKit in order to implement the standard behavior. The main issue I see is that it may break existing pages. AFAIK, Google still has not enabled the scrollLeftTopInterop flag for that reason [3]. @Rick: Can you please indicate the latest update on this? [1] https://drafts.csswg.org/cssom-view/ [2] http://w3c-test.org/cssom-view/ [3] https://bugs.chromium.org/p/chromium/issues/detail?id=157855#c110 (In reply to Frédéric Wang (:fredw) from comment #14) > There are some tests in the W3C test suite [2] that we should probably > import. In particular, the following tests are relevant: > * scrollingElement.html > * scrolling-quirks-vs-nonquirks.html These tests have been imported in https://trac.webkit.org/changeset/215726/ and they currently fail. (In reply to Frédéric Wang (:fredw) from comment #14) > @Rick: Can you please indicate the latest update on this? Replying to myself. Chromium is considering shipping the standard behavior for document.scrollingElement: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/X64Sg16RhT4 Sorry I missed the above question for me. Not only are we "considering" it, it's shipping in Chrome 61 (https://crbug.com/157855), current in "dev" release. We've had to do one pretty ugly hack for non-standard 'mousewheel' listeners to make this possible (https://bugs.chromium.org/p/chromium/issues/detail?id=501568#c35), but at least it has the side benefit of being a substantial scroll performance win on impacted sites. If we can pull it off then IMHO it will be worth it. For WebKit I suggest waiting until we know the fall-out of this Chrome change reaching all our users (roughly mid-september assuming we don't hit an issue severe enough to cause us to delay). Then we'll share a summary of the results more broadly and circle back here. I hope that we'll be able to get consensus across all browsers here one way or another ;-) Rick, I have been looking forward for this change hoping it would happen one day ! About browser consensus I believe Webkit was the only browser missing a correct implementation of the standard behavior as recommended by the W3C specifications where the document scrollingElement should be the root element (documentElement) and not the body element as it has been for Webkit until now. It is a great advance towards improved browser convergence. Nowadays very few people show interest into this important area. My fix for this to bridge the transition could still be of help with testing: https://gist.github.com/dperini/ac3d921d6a08f10fd10e Patience is a virtue, thank you for the efforts and the achievements. Have fun ! To follow up on comment 17, I think this has shipped in Chrome for a few versions, correct Rick Byers? Sorry for the delay. Yes we shipped in Chrome 61 which hit stable in September, and it stuck: https://www.chromestatus.com/features/6386758136627200. We did find a few impacted sites, and do have that one silly mousewheel hack, but the fallout has been quite minimal and mostly just a few semi-popular libraries being updated (less pain than I expected). See the most recent bugs blocked on https://crbug.com/157855 for details. I'd love to see WebKit update as well. With Chrome and Firefox now following the spec here, there's of course increasing risk that new code will be broken specifically on Safari - so the compat tradeoff for WebKit will shift over time. (In reply to Rick Byers from comment #20) > I'd love to see WebKit update as well. With Chrome and Firefox now > following the spec here, there's of course increasing risk that new code > will be broken specifically on Safari - so the compat tradeoff for WebKit > will shift over time. For the record, I started to work on this recently and just announced it on webkit-dev if you want to continue discussion there: https://lists.webkit.org/pipermail/webkit-dev/2018-January/029857.html What's the current status of this work? |