On Sun, Apr 26, 2015 at 8:41 PM, Amelia Bellamy-Royds < [email protected]> wrote:
> Thanks for the follow-up Rik. > > On 26 April 2015 at 21:14, Rik Cabanier <[email protected]> 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 http://fiddle.jshell.net/q53w90j0/1/ which re-creates the > additive color figure using absolutely positioned HTML elements. > Yes, that was decided as well. The Firefox implementation is behaving as specified. 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 https://lists.w3.org/Archives/Public/public-fx/2015JanMar/0053.html 1: http://dev.w3.org/csswg/css-color-4/#sample (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. >
