Re: [compositing] Various small fixes for Compositing & Blending Level 1

On Sun, Apr 26, 2015 at 8:41 PM, Amelia Bellamy-Royds <> wrote:

> Thanks for the follow-up Rik.
> On 26 April 2015 at 21:14, Rik Cabanier <> wrote:
>> During the last TPAC, it was decided that the <svg> element creates a
>> stacking context. Previously, the spec called out this element as not
>> causing isolation but people felt that consistency was more important.
>> So, the special case was dropped and someone was going to update (or
>> create?) a spec to clearly say what causes stacking contexts.
> Ah, glad there has been a clear decision on this.  Does the same decision
> also apply to the root element of any document type?  That was the other
> area where I found cross-browser inconsistency: Firefox treats the root as
> isolated, with a transparent black background if no background property is
> set, while Blink blends content into the opaque white canvas.
> E.g., see which re-creates the
> additive color figure using absolutely positioned HTML elements.

Yes, that was decided as well. The Firefox implementation is behaving as
Tab updated CSS Color level 4 to clarify where the color of the document
comes from:

The default background of the root element must be transparent. The default
color of the canvas (the surface on which the document is painted) is
UA-dependent, but is recommended to be white, especially if the above
colorrules are used.  [1]

See also

1: (sample???)

The table for  `background-blend-mode`  says "Applies to:All HTML
>>> elements".  However, it could apply to any XML content that uses a CSS
>>> layout model.  That includes a top-level inline SVG element; in practice
>>> (and probably in SVG 2) it would also include a root <svg> element.
>>> A more useful and future-proof description would be "Applies to: Any
>>> element that renders the `background-image` property".  Another way to make
>>> the same distinction is to use the language from the Transforms spec
>>> is "elements with (or without) associated CSS layout box".
>> That would be a normative change which would push the spec back.
>> Maybe we can address this in level 2?
> Fair enough.  I'm fairly certain all implementations will apply it to any
> content with a CSS rendering model, HTML or otherwise, but I wouldn't want
> such a fussy wording change to throw the whole spec back on the
> recommendation track.

Received on Monday, 27 April 2015 04:09:23 UTC