- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 29 Feb 2012 18:21:27 -0800
- 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. ~fantasai
Received on Thursday, 1 March 2012 02:22:01 UTC