Re: [css4-images] element() behavior

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.**

Based on your questions below, you're reading too much into that line.
 It's just meant as a clarification to the "you can redraw" bit.
However, your questions are valid in themselves. ^_^

> 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?

The image will have that alpha, yes.  The spec is very clear about
this - the element is drawn as normal, over an infinite transparent
canvas.

> What if an ancestor has a css filter (or blending/compositing), would the
> element() return part of the filtered bitmap?

As written today, filters from ancestors are honored.  It may be
better to change this, and ignore filters from ancestors, just like we
ignore transforms from ancestors.

> 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?

Here is a place where it's detectable whether they're redrawn or just
blitted.  You'd have to redraw, and this may change the
blending/compositing result (since the ancestors will no longer be
there to blend/composite with).

> 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.

That doesn't seem necessary.  It appears that in practice it should be
implemented by drawing in a software path, perhaps with some holes
poked into it so you can blit hardware-decoded video or the like.

~TJ

Received on Wednesday, 1 August 2012 04:26:10 UTC