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 21:56:00 -0700
Message-ID: <CALRQH79BGGtfJMRhEPqy-ruUC1feZbUZ7x9Y12N92jLQz4xHrw@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: www-style list <www-style@w3.org>
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 04:56:27 GMT

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