W3C home > Mailing lists > Public > www-style@w3.org > July 2014

RE: [CSS2.1] Interop Issue in regards to fixed/absolute positioned children inside of inline-relative containers

From: Gérard Talbot <www-style@gtalbot.org>
Date: Tue, 15 Jul 2014 14:52:46 -0400
To: Greg Whitworth <gwhit@microsoft.com>
Cc: W3C www-style mailing list <www-style@w3.org>
Message-ID: <f3a2cf03730d25f7db0fbb4702e5b71f@gtalbot.org>
Le 2014-07-15 10:30, Greg Whitworth a écrit :
>> This is just a quick reply.
>> 
>> 
>> We have CSS2.1 tests testing abs. pos. inlines inside an rel. pos 
>> inline but I
>> believe we do not have tests testing abs. pos. blocks inside an rel. 
>> pos. inline.
>> 
>> ----------
>> 
>> These 2 tests were removed because the CSS2.1 spec changed (§ 10.1) 
>> and
>> became less stringent:
>> 
>> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/containing-
>> block-031.html
>> 
>> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/containing-
>> block-032.html
>> 
>> See
>> http://wiki.csswg.org/spec/css2.1#issue-215
>> 
>> "
>> Summary
>>      Make it undefined what containing block is formed by a relpos 
>> inline that
>> splits across multiple lines "
>> 
>> ----------
>> 
>> If the rel. pos. inline is broken into several line boxes, then 
>> containing block
>> for its abs. pos. children is unknown, undefined in CSS
>> 2.1
>> 
>> Draft test for now:
>> 
>> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/abs-pos-child-
>> inside-rel-pos-inline-001.html
>> 
>> Gérard
> 
> Thanks for the reply! We found this bug while fixing another so I
> would prefer to specify it if possible.


Absolute Example: http://jsfiddle.net/eUV76/1/embedded/result/

Without frame:
http://fiddle.jshell.net/eUV76/1/show/light/

Fixed Example: http://jsfiddle.net/4MvcD/2/embedded/result/

Without frame:
http://fiddle.jshell.net/4MvcD/2/show/light/

You wrote:

> _Chrome_:
> (...)
> Absolute child that is block is strangely offset even when the 
> inline-relative has
> left:0px; this strange offset is added to inline-relative's left offset 
> when it is
> specified; vertically the element is moved by the offset as in IE.

In your example, just for precision here, the relatively positioned 
inline has 'left: auto'.

If the relatively positioned (parent) inline is broken into several line 
boxes, then the containing block for its absolutely positioned block 
child is undefined.

http://www.w3.org/TR/CSS21/visudet.html#containing-block-details

Where to position absolutely positioned boxes is often a matter of 
determining what/where (from and to) is their respective containing 
blocks.

And a statically positioned block box inside a relatively positioned 
inline will break such relatively positioned inline into several line 
boxes:

http://test.csswg.org/suites/css2.1/nightly-unstable/html4/inline-box-002.htm

I could be wrong here: the strange horizontal offset (absolutely 
positioned block child in 'left: auto' relatively positioned inline) 
that you see in Chrome seems acceptable with the current CSS2.1 spec.

> As I noted I think IE's
> implementation makes the most sense in this case as we treat all of
> the elements and their offsets consistently which is good for authors.

I am all for consistency of rendering, layout, etc... and all for wide 
agreement, consensus from mainstream browser manufacturers in their 
rendering engines.

I do not have or use IE11 and some web-based services ( browsershots.org 
, netrenderer.com ) do not always or do not necessarly use the latest 
most updated version of IE11.

> Would you be the one to work with in getting something like spec'd?

Huh... no :)

What I mostly do is:

- help others create CSS tests for test suites

- review CSS tests in test suites

- create CSS tests in test suites which may not exist in current test 
suites

... but I have to be aware of issues in CSS 2.1

I believe Bert Bos could be the leader/writer in charge of writing CSS 
2.2:

Re: [CSS21] Tests to be written for errata changes
http://lists.w3.org/Archives/Public/www-style/2014Jan/0381.html

and

http://wiki.csswg.org/spec/css2.2

and we would need tests to reflect the changes, the errata.


> I
> can write up what we currently do (I summarized it briefly) if there
> is agreement that IE's implementation is the preferred one.
> 
> Greg


One thing I believe could help here is to split these 2 tests into 6 
reduced, minimized tests ( no frame, no dummy.js , no result-light.css ) 
which would each individually identify their expected results. Another 
idea is to split these 6 tests into 12 tests where 6 tests use only 1 
block box child and the other 6 tests use 1 inline box child (the <i> 
element in your 2 tests).

Gérard
Received on Tuesday, 15 July 2014 18:53:25 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:23 UTC