- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Wed, 1 Aug 2012 21:56:00 -0700
- 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 UTC