Re: [css4-image] element() comments

On Mon, Feb 3, 2014 at 12:11 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> On Tue, Feb 4, 2014 at 6:34 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>
>> 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.
>
> Good point. Our implementation doesn't support list-style-image:element()
> yet, and so element() intrinsic size currently can't affect layout in Gecko.
> But we're adding that now and hitting this problem. So either we add a
> parameter to the object-sizing algorithm to distinguish between the cases
> where object sizing can affect layout and those where it can't, or we change
> our behavior. I prefer the latter since object sizing is already too complex
> for my taste.

I'm okay with making this change, then.  Just wanted to make sure I
was reading the situation correctly. ^_^

(I see that you don't support it in 'content' either, presumably for
the same reason.)

~TJ

Received on Monday, 3 February 2014 20:45:24 UTC