Re: [css4-images] element() behavior

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.

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 05:14:59 UTC