Re: [css3-transforms] Missing text about transforms inducing an abs-pos containing block

On Wed, Aug 8, 2012 at 1:15 PM, Øyvind Stenhaug <oyvinds@opera.com> wrote:
> On Wed, 08 Aug 2012 10:56:40 +0200, Aryeh Gregor <ayg@aryeh.name> wrote:
>> Were you reading an outdated draft?
>> As is generally the case at the W3C, we don't mark them clearly
>> enough, so people sometimes get confused.
>
>
> That ED is dated 28 January 2012, whereas
> http://dev.w3.org/csswg/css3-transforms/ is dated 27 July 2012.

I think this conclusively proves my point about the W3C not clearly
marking outdated drafts!  I'm supposed to be an editor of the spec,
and I just went to the first hit on Google, saw it was an ED, and
figured it was the right one without reading the title closely . . .

> The latter says
>
> "In the HTML namespace, any value other than ‘none’ for the transform
> results in the creation of both a stacking context and a containing block.
> The object acts as a containing block for fixed positioned descendants."
>
> and
>
> "Any value other than ‘none’ for the transform results in the creation of
> both a stacking context and a containing block. The object acts as a
> containing block for fixed positioned descendants."
>
> which is less clear (though "acts as though position: relative" was
> misleading too, and should not be reinstated).

Yeah, I think "containing block" here is meant to mean "containing
block for absolutely-positioned elements", I think.  Which it doesn't
mean.  Especially since, as you point out, elements are not containing
blocks.

> Seems to me that it would be better to explicitly say how
> http://www.w3.org/TR/CSS21/visudet.html#containing-block-details is
> modified. A containing block is a rectangle, not a box or element or
> whatever the term "the object" is supposed to refer to.

This is annoying, because CSS 2.1 is frozen and provides no hooks for
us.  I don't suppose there's a CSS 3 spec where we could update the
definition of containing blocks so that it explicitly allows other
specs to modify the definition?  The way we're doing things now is
more or less like COMEFROM, where different CSS specs are expected to
arbitrarily modify others with no clear interfaces, so that
interactions are completely undefined if two different specs happen to
modify the same behavior independently.  (By contrast, stacking
context creation is explicitly extensible, for instance.)

But I guess that's a bigger issue.  To fix this specific case, I filed
a bug, with proposed resolution:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18500

Received on Wednesday, 8 August 2012 10:52:31 UTC