Re: [css4-images] element() behavior

On Wed, Aug 1, 2012 at 11:56 PM, Andrew Fedoniouk <news@terrainformatica.com
> wrote:

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


I think there are many use cases for the element() syntax.
In SVG (and many other graphics languages), this is a very commonly used
idiom.
We could also ask the mozilla people if they have seen much use since they
have offered this for quite some time.


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