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