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

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

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 29 Feb 2012 18:21:27 -0800
Message-ID: <4F4EDD27.10602@inkedblade.net>
To: www-style@w3.org
On 02/29/2012 04:10 PM, Tab Atkins Jr. wrote:
> On Wed, Feb 29, 2012 at 3:57 PM, Simon Fraser<smfr@me.com>  wrote:
>> 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()

I think this is a good usability point.

> 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.

Actually, in CSS, all of our values are strongly typed. They don't
depend on context. Introducing a function whose interpretation depends
on context is therefore inconsistent. If we're an <image> type, we're
always an <image> type. Various parsing situations depend or will depend
on this. The 'background' and 'content' properties are two examples where
many types can collide, but the principle is general.

Received on Thursday, 1 March 2012 02:22:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:50:17 UTC