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

Re: [css4-images] element() behavior

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 2 Aug 2012 10:02:34 -0700
Message-ID: <CAAWBYDDD5M9TJEdromGqywdOQ7-1udC0mz=Mgu4MK4iZDtwZ3w@mail.gmail.com>
To: Andrew Fedoniouk <news@terrainformatica.com>
Cc: Rik Cabanier <cabanier@gmail.com>, www-style list <www-style@w3.org>
On Wed, Aug 1, 2012 at 11:56 PM, Andrew Fedoniouk
<news@terrainformatica.com> wrote:
> On Wed, Aug 1, 2012 at 10:14 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>> I was talking about appearance, not CSS inheritance.
>> The image will look as if it has alpha and should render with alpha
>> according to the element() spec. The stacking context that #src belongs to,
>> has alpha.
> And where this "should render with alpha according to the element() spec"
> comes from?
> Do you mean this:
> "That is, the image must look identical to the
> referenced element, modulo rasterization quality." ?
> If "yes" then "look identical" term appears as quite
> permissive by itself. Two boxes can be treated as looking
> identical even they use different fill color.

I have no idea what definition of "identical" you're using where
different fills can be considered "identical".

> Term "rasterization quality" in CSS specification looks enthetic.
> Why it is mentioned there at all?
> And the whole element() thing treats rendering with
> transform:skew(30deg); and without it for example as identical
> for some reason. Looks like an artificial hack trying to solve
> particular use case.

Uh, no.  That's not "treating it as identical".  I shut off ancestor
transforms for a specific reason - it seems unlikely that it will
match what's expected (especially when you're referring to, say, a
canvas), and because it makes the rendering harder.

Received on Thursday, 2 August 2012 17:03:23 UTC

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