Hi All, I was directed here from a firefox bug. I'll try to present the problem as clearly as I can.
The issue: I recently had an issue where the scrollbar UI element was not rendering due to overflow:hidden being applied to the body. The document was larger than the viewport but an overlay, hidden by a script/the user, doesn't allow for the script to execute the change to overflow:visible. Upon digging into it I found the behaviour seems to be contrary to standard. Relevant information: https://www.w3.org/TR/CSS2/visufx.html#overflow "UAs must apply the 'overflow' property set on the root element to the viewport. When the root element is an HTML "HTML" element or an XHTML "html" element, and that element has an HTML "BODY" element or an XHTML "body" element as a child, user agents must instead apply the 'overflow' property from the first such child element to the viewport, if the value on the root element is 'visible'. The 'visible' value when used for the viewport must be interpreted as 'auto'. The element from which the value is propagated must have a used value for 'overflow' of 'visible'." https://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#viewport "User agents for continuous media generally offer users a viewport (a window or other viewing area on the screen) through which users consult a document. User agents may change the document's layout when the viewport is resized (see the initial containing block). When the viewport is smaller than the area of the canvas on which the document is rendered, the user agent should offer a scrolling mechanism. There is at most one viewport per canvas, but user agents may render to more than one canvas (i.e., provide different views of the same document). " https://www.w3.org/TR/CSS2/visufx.html#overflow-clipping "A descendant box is positioned absolutely, partly outside the box. Such boxes are not always clipped by the overflow property on their ancestors; specifically, they are not clipped by the overflow of any ancestor between themselves and their containing block" The logic, as I read it (caps added to indicate RFC language): The viewport standard recommends that the UA SHOULD offer a scrolling mechanism if the content is larger than the viewport. The general of overflow-clipping outlines a situation where clipping can occur while position:absolute elements can remain visible. In the presented situation, overflow:hidden breaks the ability of the user to use a scrollbar to access this content if it's also outside the viewport. The overflow standard is a bit harder to parse, however, as I understand it, it requires that: 1) The overflow property MUST be applied to the root element (presumably overflow:auto unless otherwise specified) 2) If a BODY/body element has an overflow property it MUST apply it to the viewport only if (1) is overflow:visible 3) When (2) occurs it MUST be overflow:visible 4) When overflow:visible MUST be interpreted as overflow:auto 5) When (4) occurs a scrolling mechanism SHOULD be provided (see: overflow:auto) There are several things FF is doing that do not adhere to this standard: 1) Computed values show it's being interpreted as overflow:visible not overflow:auto for the root element, this is allowing overflow properties to propagate from the body inappropriately 2) overflow:hidden (and other values) are being propagated from the body element despite the standard requiring this only be done if the BODY/body's overflow property is set to 'visible' 3) viewport standard is ignored, possibly intentionally(?), however, it leaves the user without a scrollbar in situations where one is desired, including the one presented in #overflow-clipping 4) overflow:auto is ignored both in interpretation and scrollbar implications Regards, JDev _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
