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

>  One way to avoid that would be to say that <foreignObject> establishes such a containing block, but I'm not sure if that would be web compatible.

That is probably the most logical approach, and most useful. 

The SVG 2 specs define [`<foreignObject>` as creating a stacking context](https://svgwg.org/svg2-draft/render.html#EstablishingStackingContex), so that already covers containing absolutely-positioned elements.  I don't think there is any argument against that.

Fixed positioning is a little more complicated, since currently filters & transforms are the only things that contain fixed elements, and I don't think there's any spec that says SVG should have an effect. But nonetheless, browsers seem to agree that it does, although they don't agree in all the details.

I'm using [this Codepen](https://codepen.io/AmeliaBR/pen/50bbeed851a7c2009ec4b9ddb0c76c4f), which is a modified version of [this WPT test](https://github.com/web-platform-tests/wpt/blob/master/svg/extensibility/foreignObject/containing-block.html).  The WPT test is very problematic; the [failures](https://wpt.fyi/results/svg/extensibility/foreignObject/containing-block.html) are about how `offsetLeft` is calculated, while the passes (Chrome vs WebKit) don't actually agree on layout!

Anyway, here are my results for latest stable Chrome, Edge, Safari & Firefox Dev edition:

- Static (Spring green) and relative (Rebecca Purple)  elements:
  * all browsers position as expected, except that Safari collapses the margins through the edge of the foreignObject container, while the others contain margins.

-  Absolute (Alice Blue) element:
   * Chrome, Firefox & Edge all position relative to the foreignObject parent.
   * Safari positions relative to the initial containing block, I think.

- Fixed (Firebrick) element:
   * All 4 browsers position the element relative to the foreignObject bounds
   * _However_, Chrome then fixes its position relative to scroll on the body, although it disappears if you scroll enough so that is completely outside of the foreignObject bounds.

- Sticky (Steel Blue) element:
   * MS Edge crashes the tab (the element is commented out in the pen to avoid this)
   * Firefox and Chrome position it as expected from static layout, then scrolls it stickily (relative to scroll on the body) while containing it within the foreignObject bounds.
   * Safari doesn't support sticky positioning (I didn't try with `-webkit-`).

So, in conclusion:

I'd say your proposal isn't a web compat problem, but we need some specs & tests to match, and then some bugs filed on browsers.

> The proper resolution to this boils down to "actually define how SVG operates in the CSS box model finally", correct?

That would cover a lot of it, yes...

-- 
GitHub Notification of comment by AmeliaBR
Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/307#issuecomment-410383866 using your GitHub account

Received on Friday, 3 August 2018 21:43:18 UTC