bokand
commented
5 years ago Your observation is correct w.r.t. Chrome's behavior
Whether that's the right thing, I'm not sure. The ICB size is shrunk by the window's scrollbar so in that sense it's not crazy. Though I agree it feels inconsistent. IMHO, using the visual viewport would be obviously wrong (in terms of Chrome's direction of making pages less responsive to zoom). I think using the fixed viewport probably makes more sense than the visual viewport or ICB but I'd be a bit worried about how this would affect compat.
Re; the spreadsheet, that should be up-to-date regarding Chrome's implementation (I don't think anything's changed since). I've updated it to use "Fixed" rather than Layout, thanks for pointing it out.
On a page where the fixed viewport is larger than the ICB, what should
document.scrollingElement.clientWidthreturn?My experimentation seems to show that in Chrome it currently returns the ICB width.
Is this observation correct?
If so, is this the desired behaviour?
The spec says it should return "the viewport width excluding the size of a rendered scroll bar (if any)". Obviously, "viewport" in existing specs is ambiguous, but seeing as it's talking about scroll bars, I would think that, considering the implementation model described here, we'd want to use the scroll port width of one of the two scrollers, and the ICB width is neither.
I did look at this spreadsheet (linked from this section of the explainer doc) which lists the various APIs, but it's not clear to me whether it's up to date, as it talks about the "layout viewport" and not the "fixed viewport".
The explainer doc itself says that Chrome has moved to an "all fixed" model, which makes the current behaviour seem suprising.