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

Re: [css4-images] element() behavior

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Wed, 1 Aug 2012 23:56:57 -0700
Message-ID: <CALRQH7_2AgQWUUwaHs0-0JhBmBS1ZdTQc3TeO-i_OO_wgmcJhg@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: www-style list <www-style@w3.org>
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.

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.

-- 
Andrew Fedoniouk.

http://terrainformatica.com

>
> As you rightly point out, the #src element has no idea that element was
> applied to it later.
> This is the one of the arguments: people don't want non-inherited properties
> to have an effect when the element is pulled in using the element() syntax.
>
> Rik
>
> On Wed, Aug 1, 2012 at 9:56 PM, Andrew Fedoniouk <news@terrainformatica.com>
> wrote:
>>
>> Thanks Rik but your explanation didn't make this phrase:
>> "the element has alpha from an ancestor"
>> anyhow clearer.
>>
>> 'opacity' is not inheritable.
>> And the #src has no opacity defined on it so it shall be rendered
>> in #dst background with default opacity:1 value.
>>
>> So it is not clear where "alpha from ancestor" idea comes from.
>>
>> --
>> Andrew Fedoniouk.
>>
>> http://terrainformatica.com
>>
>>
>> On Wed, Aug 1, 2012 at 11:12 AM, Rik Cabanier <cabanier@gmail.com> wrote:
>> > For instance:
>> >
>> > <style>
>> > #src { color: white; background: lime; width: 300px; height: 40px; }
>> > #dst { color: black; background: element(#src); padding: 20px; margin:
>> > 20px
>> > 0; }
>> > </style>
>> >
>> > <div style="opacity:.5;">
>> >   <p>more text</p>
>> >   <p id='src'>I'm an ordinary element!</p>
>> >   <p>even more text</p>
>> > </div>
>> > <p id='dst''>I'm using the previous element as my background!</p>
>> >
>> >
>> > The text with id 'src' is rendered with opacity.
>> > Internally, the alpha will cause the browser to create a stacking
>> > context
>> > [1] (which is basically a bitmap).
>> > The 3 text blocks are rendered into this bitmap and then alpha is
>> > applied to
>> > it.
>> >
>> > At no point will the browser have a transparent version of just the text
>> > with id 'src' in memory, nor does it know what will happen to the text
>> > while
>> > it's rendering it.
>> > This means that the code behind element() has to find out how to do
>> > this.
>> >
>> > 1:
>> >
>> > https://developer.mozilla.org/en/CSS/Understanding_z-index/The_stacking_context
>> >
>> > On Tue, Jul 31, 2012 at 9:20 PM, Andrew Fedoniouk
>> > <news@terrainformatica.com> wrote:
>> >>
>> >> This "the element has alpha from an ancestor"
>> >> is not clear. What does it mean?
>> >>
>> >> --
>> >> Andrew Fedoniouk.
>> >>
>> >> http://terrainformatica.com
>> >>
>> >> On Tue, Jul 31, 2012 at 9:05 PM, Rik Cabanier <cabanier@gmail.com>
>> >> wrote:
>> >> > I'm a bit puzzled by this statement in the spec [1] (highlight is
>> >> > mine):
>> >> >
>> >> > Implementations may either re-use existing bitmap data generated for
>> >> > the
>> >> > referenced element or regenerate the display of the element to
>> >> > maximize
>> >> > quality at the image's size (for example, if the implementation
>> >> > detects
>> >> > that
>> >> > the referenced element is an SVG fragment); in the latter case, the
>> >> > layout
>> >> > of the referenced element in the image must not be changed by the
>> >> > regeneration process. That is, the image must look identical to the
>> >> > referenced element, modulo rasterization quality.
>> >> >
>> >> >
>> >> > Does this mean that if the element has alpha from an ancestor, the
>> >> > element()
>> >> > will generate a bitmap with that alpha, or is the alpha ignored or
>> >> > blended?
>> >> > What if an ancestor has a css filter (or blending/compositing), would
>> >> > the
>> >> > element() return part of the filtered bitmap?
>> >> > What if one of your child elements has alpha and is alpha blending
>> >> > with
>> >> > an
>> >> > ancestor. Will element() return a bitmap with alpha, or a blended
>> >> > image?
>> >> >
>> >> > I can see the intent of the spec, but it seems hard to implement.
>> >> > Maybe you could say that element() can only reference elements that
>> >> > establish a context or elements that don't contain another context.
>> >> > The browser could then use the rasterized image of the context or
>> >> > raster
>> >> > the
>> >> > element at that point. This might be easier to define and certainly
>> >> > implement.
>> >> >
>> >> > 1: http://dev.w3.org/csswg/css4-images/#element-notation
>> >
>> >
>
>
Received on Thursday, 2 August 2012 06:57:28 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:58 GMT