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

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

From: Brian Kardell <bkardell@gmail.com>
Date: Wed, 7 Mar 2012 06:58:44 -0500
Message-ID: <CADC=+jdad10yVsv+mfKvuN0R5VNDp8XhNq2B2z232j6epUhkRQ@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style@w3.org, fantasai <fantasai.lists@inkedblade.net>
attr() in values and types draft was going to allow an argument to specify
type... if that remained, it might be nice to stay consistent... image is
an element, just a different kind right.
On Mar 7, 2012 1:55 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> On Feb 29, 2012 6:24 PM, "fantasai" <fantasai.lists@inkedblade.net> wrote:
> > On 02/29/2012 04:10 PM, Tab Atkins Jr. wrote:
> >> 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.
>
> Your assertion can't be true - the url() function is already not strongly
> typed in the way you suggest.
>
> ~TJ
>
Received on Wednesday, 7 March 2012 11:59:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 03:48:51 GMT