This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 17076 - Please clarify how seamless should interact with scrollbars
Summary: Please clarify how seamless should interact with scrollbars
Status: RESOLVED NEEDSINFO
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-16 10:59 UTC by contributor
Modified: 2012-11-06 02:30 UTC (History)
4 users (show)

See Also:


Attachments

Description contributor 2012-05-16 10:59:15 UTC
Specification: http://www.whatwg.org/specs/web-apps/current-work/
Multipage: http://www.whatwg.org/C#attr-iframe-seamless
Complete: http://www.whatwg.org/c#attr-iframe-seamless

Comment:
Please clarify how seamless should interact with scrollbars

Posted from: 173.164.128.209
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.3 Safari/536.11
Comment 1 Eric Seidel 2012-05-16 11:02:09 UTC
For example, this section:

In visual media, in a CSS-supporting user agent: the user agent must force the height of the initial containing block of the active document of the nested browsing context of the iframe to zero.

This is intended to get around the otherwise circular dependency of percentage dimensions that depend on the height of the containing block, thus affecting the height of the document's bounding box, thus affecting the height of the viewport, thus affecting the size of the initial containing block.

This would cause user agents to add scrollbars in their initial computation, since the containing block starts at 0px, no?

Similarly, what about child documents in quirks mode?  There the body/html are expected to fit to the viewport size?  For now in WebKit I've disabled this quirk when the document is seamless, but that doesn't feel 100% right.

Some explanation of how the scrollbar negotiation should work would be helpful. :)  Presumably it should work exactly as <div style="scroll: auto"> would, but it's a bit tricky due to the assumption of html/body as being the root (at least in the code).  Presumably we should treat html/body as just normal blocks inside the seamless iframe block.
Comment 2 Simon Pieters 2012-05-16 13:01:07 UTC
> Similarly, what about child documents in quirks mode?  There the body/html are
> expected to fit to the viewport size?

That's not expected. It's what WebKit does, but Opera and Gecko don't. I'm not sure, but I think IE9 in non-compat-view quirks mode also doesn't. The quirks mode spec specifies the Opera/Gecko behavior. http://simon.html5.org/specs/quirks-mode#the-percentage-height-calculation-quirk
Comment 3 contributor 2012-07-18 17:32:10 UTC
This bug was cloned to create bug 18172 as part of operation convergence.
Comment 4 Ian 'Hixie' Hickson 2012-09-04 22:01:03 UTC
Where would the scroll bars come in? Do you have an example?
Comment 5 Ian 'Hixie' Hickson 2012-11-06 02:30:40 UTC
eseidel: ping. I don't understand this bug.