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

FremyCompany has just created a new issue for 

== [css-2][css-position-3] Absolutely positioned boxes in inline 
relatives: not interoperable ==
**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

> 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 
- 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.

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

Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/609 using your GitHub 

Received on Saturday, 15 October 2016 03:48:07 UTC