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

Re: [css4-images] element() behavior

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Tue, 31 Jul 2012 21:20:45 -0700
Message-ID: <CALRQH7_G0eFkc3NDKZrYtwYhe+br+FYSjq4obk5E5iw58sZ_Sw@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: www-style list <www-style@w3.org>
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 Wednesday, 1 August 2012 04:21:13 GMT

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