- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 9 Oct 2012 13:55:04 -0700
- To: Ojan Vafai <ojan@chromium.org>
- Cc: www-style@w3.org
On Fri, Sep 7, 2012 at 3:30 PM, Ojan Vafai <ojan@chromium.org> wrote: > http://www.w3.org/TR/CSS2/visudet.html#containing-block-details > "If the element has 'position: absolute', the containing block is > established by the nearest ancestor with a 'position' of 'absolute', > 'relative' or 'fixed', in the following way: > > In the case that the ancestor is an inline element, the containing block is > the bounding box around the padding boxes of the first and the last inline > boxes generated for that element. In CSS 2.1, if the inline element is split > across multiple lines, the containing block is undefined. > Otherwise, the containing block is formed by the padding edge of the > ancestor." > > http://dev.w3.org/csswg/css3-sizing/#extrinsic-sizing > "less the box's inline-axis margins, borders, and padding." > > Should the extrinsic size of position:absolute elements include the padding > or not? My feeling is that it shouldn't for the purposes of things like > fill-available and auto-sizing perpendicular writing-modes, but I could be > convinced otherwise. Nothing to change here, luckily - you just misread that section. ^_^ The m/b/p that you're subtracting is the abspos's *own* m/b/p, because we are specifically defining the *inner* size. The containing block doesn't have anything subtracted. > Not that we can change it now, but it's not clear to me why CSS2 chose the > padding box in the first place. What's the use-case this addresses? fantasai thinks that this was because of compat issues. ~TJ and fantasai
Received on Tuesday, 9 October 2012 20:55:51 UTC