- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 29 Mar 2005 21:12:03 +0000 (UTC)
- To: staffan.mahlen@comhem.se
- Cc: "www-style@w3.org" <www-style@w3.org>
On Wed, 17 Mar 2004 staffan.mahlen@comhem.se wrote: > > [for abs pos blocks in rel pos inline containing blocks, UAs ignore the > following from CSS2.1:] > > "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. " > > This seems wise to me, since i believe the above definition might > yield a negative containing block width. Yes. In fact we have added the following note to CSS2.1 in 10.1: Note: This may cause the containing block's width to be negative. Despite this apparent oddity, it is still what you want in the majority of cases. Typically, an abs pos block in an inline will be anchored either to its left: or right: edge. Only by making the CB have a negative width in certain cases can you still have that working, as far as I can tell. > I suppose the above is just meant to show what edges the values > left/right/top/bottom refers to, but doesn't that suggest that > http://www.w3.org/TR/2004/CR-CSS21- > 20040225/visudet.html#abs-non-replaced-width lacks the clarification on > how to handle this case? Or am i missing something obvious here? What clarification is there to add? As far as I can tell the above just works. Yes, you get some odd results if you try to actually set both left:0 and right:0 and your CB happens to be one of those odd "negative width" cases, but what's the use case for that? (And what should actually happen, given that the aforementioned use case has to work too?) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 29 March 2005 21:49:38 UTC