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