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

Re: [css4-image] element() comments

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 3 Feb 2014 09:34:24 -0800
Message-ID: <CAAWBYDAYwAPToV8uc2J9qzqgwmrWBE+B6hBnytJR4t+faQhttg@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: www-style <www-style@w3.org>, Nicholas Cameron <ncameron@mozilla.com>
On Sun, Feb 2, 2014 at 2:06 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> http://dev.w3.org/csswg/css-images/#element-notation
>> The function represents an image with its intrinsic size equal to the
>> decorated bounding box of the referenced element
> Giving element() an intrinsic size is actually super bad. It creates almost
> arbitrarily bad circular layout dependencies; e.g. any <li> element's size
> can now depend on the size of any other element in the document! Detecting
> and fixing the circularity isn't easy either, because you can combine this
> with existing dependencies to create cycles in all kinds of ways. Since this
> is mostly useless anyway, I propose specifying that element()s have no
> intrinsic dimensions at all.

Unless I'm misunderstanding, the spec is describing Mozilla's current
behavior.  This is illustrated by the first example in
<https://hacks.mozilla.org/2010/08/mozelement/> (the one with white
text on an orange background), and a few others in that page.

> Regarding issue #9, I think the best solution is to amend the condition "an
> element that is rendered and is not a descendant of a replaced element" to
> also require that the element have a stacking context. We could specify that
> directly, but it might be simpler for authors to just require it have
> non-auto z-index and non-static position.

Yeah, I think that requiring stacking contexts is fairly reasonable
these days.  There are tons of ways to cause that.  I'll make the
change later today.

Received on Monday, 3 February 2014 17:35:11 UTC

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