W3C home > Mailing lists > Public > www-style@w3.org > March 2012

Re: [css3-images] [css3-gcpm] element() and element()

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 29 Feb 2012 16:10:22 -0800
Message-ID: <CAAWBYDBwbwPLey6A0qWvHmJH748Nm9MbVrqJv=Vpr5265YS==w@mail.gmail.com>
To: Simon Fraser <smfr@me.com>
Cc: fantasai <fantasai.lists@inkedblade.net>, www-style@w3.org
On Wed, Feb 29, 2012 at 3:57 PM, Simon Fraser <smfr@me.com> wrote:
> On Feb 29, 2012, at 3:45 PM, fantasai wrote:
>> GCPM defines an element() function, which returns an element
>>  http://dev.w3.org/csswg/css3-gcpm/#running-elements
>> and Images defines an element() function, which returns an image
>>  http://dev.w3.org/csswg/css3-gcpm/#running-elements
>> They are not the same, and they are both acceptable as input to 'content'.
>> I don't have a solution, but there is a conflict here.
> element() in the CSS Image case doesn't immediately strike me
> as meaning a snapshot of the targeted element. Maybe we should
> use something more descriptive, like:
> snapshot() (even though it updates)
> replica()
> element-image()
> imageof()

My intent is that, eventually, element() will be usable by other
properties as well that need to refer to an element.  When it's used
in an <image> context, it means what Image Values says.  When it's
used in some other context, it means whatever that context wants.

The only problem occurs if you want a property to accept both <image>s
and whatever other type accepts element().  I doubt that this conflict
will be much of a problem.

(GCPM's conflict doesn't count - it's doing something *completely
different* and just happens to share the name.)

Received on Thursday, 1 March 2012 00:11:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:13 UTC