[css-2][css-position-3] Absolutely positioned boxes in inline relatives: not interoperable

@atanassov

CSS 2.2 leaves this behavior undefined:

If the direction is ltr, the top and left of the containing block are the top and left content edges of the first box generated by the ancestor, and the bottom and right are the bottom and right content edges of the last box of the ancestor.
http://www.w3.org/TR/CSS22/visudet.html#containing-block-details

CSS Position 3 says "top,left" are relative to the first fragment, and "bottom,right" the last.

In CSS 2.2, if the inline element is split across multiple lines, the containing block is undefined.
https://drafts.csswg.org/css-position-3/#def-cb

Testcases

https://jsfiddle.net/pu494kg8/ (rtl)
https://jsfiddle.net/pu494kg8/1/
https://jsfiddle.net/pu494kg8/2/ (ltr)
https://jsfiddle.net/pu494kg8/3/
https://jsfiddle.net/pu494kg8/4/

ltr: Edge and Chrome consider "right" to be the left of the first fragment.
ltr: Firefox considers "bottom" and "right" to be the bottom/right of the first fragment.
rtl: Implementations are not interoperable at all.

I recommend we change the spec to match Edge/Chrome behavior for ltr (and mirror it for rtl), except if we intend to fix. I am not willing to have us move away from the Webkit/Blink behavior if we don't have a clear signal promising a fix for at least one of those, given the compat risks.
Thoughts?

// cc: @atanassov @fantasai @tabatkins @grorg @dbaron

Resolved to continue discussion on github in today's call

I wrote some testcases.

I'm happy to standardize on the Edge behavior, which I believe matches Chrome for ltr, and does the equivalent for other directions (whereas Chrome does different and sometimes bizarre things for other directions).

In particular, as I understand it, that behavior is:

form a containing block from the block-start and inline-start padding-box edges of the first fragment and the block-end and inline-end padding-box edges of the last fragment
If that containing block has a negative width or height, turn each negative width or height into 0 by keeping the edge (in that dimension) that came from the first fragment the same, and changing the edge that came from the last fragment to be equal to the edge from the first fragment

I'd note that I didn't thoroughly test different sorts of overlap situations. However, I haven't seen any places Edge deviates from the above description (with EdgeHTML 14.14393).

Now that it is described in that way, I am even more in favor of clarifying the spec to match our implementation (and therefore Chrome in the left-to-right case). It actually makes sense.

@dbaron

CSSWG RESOLUTION: Accept Edge and Chrome in the LTR case as the proposed behavior as explained by @dbaron above.

@eaenet

@eaenet and I were just talking about this. We may need to tighten the wording further for when we fragment in the block direction. For example:

<style>
.container {
  column-count: 2;
}
</style>
<div class=container>
<span class=cb>
<span class=abs1></span>
  text which spans<!-- column break --> over two columns.
<span class=abs2></span>
</span>
</div>

In the above example two fragments are produced.

"text which spans"
"over two columns"

Which fragment should the .abs1 and .abs2 elements "anchor" to?

I think anchoring to the fragment which would have contained the absolute child if it wasn't out of flow makes the most sense?

I forgot to add - in the multicol case, what is top and bottom based off for both .abs1 and .abs2?

[css-position-3] Specify the Chrome behavior for inline CBs when the …

Navigation Menu

Repository navigation

[css-2][css-position-3] Absolutely positioned boxes in inline relatives: not interoperable #609

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-2][css-position-3] Absolutely positioned boxes in inline relatives: not interoperable #609

Description

Activity

FremyCompany commented on Oct 26, 2016

dbaron commented on Nov 8, 2016

FremyCompany commented on Nov 9, 2016

atanassov commented on Nov 17, 2016

bfgeek commented on Dec 14, 2016

bfgeek commented on Dec 14, 2016

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions