W3C home > Mailing lists > Public > public-fxtf-archive@w3.org > June 2019

Re: [fxtf-drafts] can SVG container elements establish containing block for absolute/fixed positioned elements? (#307)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Thu, 06 Jun 2019 18:27:21 +0000
To: public-fxtf-archive@w3.org
Message-ID: <issue_comment.created-499612420-1559845640-sysbot+gh@w3.org>
The CSS Working Group just discussed `SVG container elements`, and agreed to the following:

* `RESOLVED: svg spec says that <fO> creates a containing block for fixpos and abspos children`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: SVG container elements<br>
&lt;astearns> github: https://github.com/w3c/fxtf-drafts/issues/307<br>
&lt;TabAtkins> AmeliaBR: Filters create a containing block for abspos/fixpos<br>
&lt;TabAtkins> AmeliaBR: When specified nobody thought about SVG, because it doesn't ahve abspos.<br>
&lt;TabAtkins> AmeliaBR: But you can do a foreignContent with html that uses abpos. dbaron wondered what happens there.<br>
&lt;TabAtkins> AmeliaBR: Looking at browsers, they're non-interop.<br>
&lt;bkardell_> is this totally related? https://github.com/mathml-refresh/mathml/issues/48<br>
&lt;TabAtkins> AmeliaBR: In discussion, consensus seems to be that the foreignObject is a containing block for abspos/fixpos, so you dont' have to worry about whether an ancestor svg el has a filter or not.<br>
&lt;TabAtkins> AmeliaBR: That's what Chrome does<br>
&lt;TabAtkins> AmeliaBR: So we need to specify foreignObject better in general about hwo it provides a containing block for css content insie of it, and making this dfn makes things simpler, but it does add a new place where we're trapping fixpos elements.<br>
&lt;TabAtkins> astearns: chrishtr says that the SVG spec already defines that foreignObject defines a fixpos containing block<br>
&lt;TabAtkins> AmeliaBR: Maybe<br>
&lt;TabAtkins> mstange: I think all browsers already agreeo nthis<br>
&lt;TabAtkins> mstange: The difference amelia found might be an old versio nof chrome; i think browsers now agree<br>
&lt;TabAtkins> mstange: I think having fO be a containing block for everything makes a lot of sense<br>
&lt;TabAtkins> AmeliaBR: Weird ones that dont' match are Safari: &lt;fO> contains fixpos but not abspos. stickypos is a big untested mess too<br>
&lt;TabAtkins> mstange: We may want to add something about stick to the spec, then?<br>
&lt;TabAtkins> iank_: Maybe better as a separate issue<br>
&lt;TabAtkins> dbaron: I don't think anything special needs to happen with sticky, because I don't think it escapes very far<br>
&lt;TabAtkins> AmeliaBR: I think the dfn of what happens with it will fall out of defining it as a containing block<br>
&lt;TabAtkins> emilio: sticks is about scroll containers, not containing block<br>
&lt;TabAtkins> astearns: so what needs to be done here?<br>
&lt;TabAtkins> dbaron: larger answer is that we need a spec to centralize a bunch of this<br>
&lt;TabAtkins> dbaron: part of reason for all these questions about CBs and stacking contexts, etc are such a mess is that there are multiple specs amending dfns that don't actually exist.<br>
&lt;TabAtkins> dbaron: So someone needs to write a spec that defines these terms.<br>
&lt;TabAtkins> dbaron: So opacity/mix-blend-mode/etc can all hook that instead of defining ad-hoc<br>
&lt;TabAtkins> dbaron: simple thing is to resolve that &lt;fO> establishes a containing block for abpos and fixpos<br>
&lt;TabAtkins> flackr: I think sticky says it moves according ot th enearest ancestor with nonvisible overflow<br>
&lt;TabAtkins> dbaron: Can &lt;fO> overflow...?<br>
&lt;TabAtkins> AmeliaBR: Haven't tested<br>
&lt;TabAtkins> AmeliaBR: I think it overflows, I've done it to get a &lt;label>.<br>
&lt;TabAtkins> astearns: Let's resolve on abpos/fixpos and do sticky separately?<br>
&lt;TabAtkins> chris: Rossen wanted it to be an ICB...?<br>
&lt;TabAtkins> hober: Without him explaining why, I'm loathe to define that<br>
&lt;TabAtkins> iank_: Yeah, ICB has a lot of other implications.<br>
&lt;TabAtkins> AmeliaBR: I can take action on edits<br>
&lt;TabAtkins> TabAtkins: Ping me and elika for review<br>
&lt;TabAtkins> astearns: proposed resolution: svg spec says that &lt;fO> creates a containing block for fixpos and abspos children<br>
&lt;TabAtkins> RESOLVED: svg spec says that &lt;fO> creates a containing block for fixpos and abspos children<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/307#issuecomment-499612420 using your GitHub account
Received on Thursday, 6 June 2019 18:27:23 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 6 June 2019 18:27:24 UTC