Summary: | Shadow hosts aren't automatically containing blocks for positioned descendants | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Antoine Quint <graouts> | ||||||
Component: | Layout and Rendering | Assignee: | Antoine Quint <graouts> | ||||||
Status: | RESOLVED WONTFIX | ||||||||
Severity: | Normal | CC: | ap, graouts, koivisto, rniwa, simon.fraser, webkit-bug-importer | ||||||
Priority: | P2 | Keywords: | InRadar | ||||||
Version: | Safari 10 | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Attachments: |
|
Description
Antoine Quint
2016-10-18 01:48:41 PDT
Created attachment 291933 [details]
Testcase
--- Source/WebCore/Modules/modern-media-controls/controls/media-controls.css (revision 207457) +++ Source/WebCore/Modules/modern-media-controls/controls/media-controls.css (working copy) @@ -23,7 +23,9 @@ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ -.media-controls, +.media-controls { + position: relative; +} .media-controls > .controls-bar { position: absolute; makes them show up Created attachment 291950 [details]
Patch
Comment on attachment 291950 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=291950&action=review > Source/WebCore/ChangeLog:12 > + instead, which removes the rendering issues. What bug tracks fixing the root cause? (In reply to comment #5) > Comment on attachment 291950 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=291950&action=review > > > Source/WebCore/ChangeLog:12 > > + instead, which removes the rendering issues. > > What bug tracks fixing the root cause? I suppose this should be kept as the bug tracking the original issue. I doubt it'll get fixed once we have a workaround though. Root cause appears to be in RenderImage (where RenderMedia inherits it). Since position:absolute makes little sense in UA shadow tree root element I don't think there is any particular desire to fix this. Not that I'm stopping anyone. (In reply to comment #7) > Root cause appears to be in RenderImage (where RenderMedia inherits it). > Since position:absolute makes little sense in UA shadow tree root element I > don't think there is any particular desire to fix this. What about RenderImage? > What about RenderImage?
What about it?
You say "Root cause appears to be in RenderImage" but don't explain what it is. The issue is about UA shadow trees of renderers derived from RenderImage using absolute positioning in their shadows. This is what I said in a mail about this "The problem appears to be that you are using absolute positioned container as the rendering root of your shadow tree. Absolute positioning inside shadow trees works the same as it does outside so your controls end up being relative to the body, not <video>. Not sure why it doesn’t show up at all, maybe something to do with the wackiness of RenderImage::layoutShadowControls." and "I’m not sure I would even call it a workaround. Using absolute positioning in the root of a shadow tree is strange since the host element is not going to be your containing block. It is very easy to get such shadow to render outside the host (for example left:0px top:0px will put it to the top left corner of the document)." Yes, it doesn't seem to make sense indeed. Can an assertion be added to catch trying to do this in UA shadow trees? Should the spec say that shadow roots always have position: relative (or words about acting as containing block and/or stacking context)? (In reply to comment #14) > Should the spec say that shadow roots always have position: relative (or > words about acting as containing block and/or stacking context)? Shadow roots have no rendering at all. Children of shadow root act like direct children of the host. The host can be also be inline. I'm not sure there is problem to solve as position:relative should generally give you what you want and position:absolute behavior is still consistent (bugs in special-renderer UA shadow trees notwithstanding). (In reply to comment #14) > Should the spec say that shadow roots always have position: relative (or > words about acting as containing block and/or stacking context)? There was a discussion to use display: block as the default styling for shadow roots: https://github.com/w3c/webcomponents/issues/426 The current discussion hinges on adding a "lightweight" way to style custom elements: https://github.com/w3c/webcomponents/issues/468 > There was a discussion to use display: block as the default styling for
> shadow roots:
Shadow hosts. And this wouldn't be useful here as the host is a replaced inline element.
The current behavior matches the spec. We need to modify the host's style in order to do this, and nobody wanted attaching a shadow root to have that kind of side-effect in style. |