W3C home > Mailing lists > Public > www-style@w3.org > June 2014

Re: [compositing] background-blend-mode on the root element

From: Rik Cabanier <cabanier@gmail.com>
Date: Wed, 25 Jun 2014 09:26:25 -0700
Message-ID: <CAGN7qDC2Q_u=TcQuae-LEhqqJb2WPatfKv16mNSyKth-efwKgA@mail.gmail.com>
To: Alan Gresley <alan@css-class.com>
Cc: www-style list <www-style@w3.org>, "public-fx@w3.org" <public-fx@w3.org>
On Wed, Jun 25, 2014 at 9:16 AM, Rik Cabanier <cabanier@gmail.com> wrote:

>
>
>
> On Wed, Jun 25, 2014 at 6:53 AM, Alan Gresley <alan@css-class.com> wrote:
>
>> On 21/06/2014 2:42 AM, Rik Cabanier wrote:
>>
>>> On Thu, Jun 19, 2014 at 11:29 PM, Alan Gresley <alan@css-class.com>
>>> wrote:
>>>
>>>  On 20/06/2014 12:40 PM, Rik Cabanier wrote:
>>>>
>>>>  All,
>>>>>
>>>>> the background-blend-mode [1] property recently landed in Firefox and
>>>>> Chrome and we noticed that a very common design is to use it to create
>>>>> patterns with gradients. [2]
>>>>>
>>>>> The spec states:
>>>>>
>>>>> Each background layer must blend with the element’s background layer
>>>>> that
>>>>> is below it and the element’s background color. Background layers must
>>>>> not
>>>>> blend with the content that is behind the element, instead they must
>>>>> act
>>>>> as
>>>>> if they are rendered into an isolated group.
>>>>>
>>>>>
>>>>> This works for most elements except for the root element which has a
>>>>> different paint order [3]:
>>>>>
>>>>>
>>>> It's not a different painting order but different painting method.
>>>>
>>>>
>>>>  The background of the root element becomes the background of the canvas
>>>>> and
>>>>> covers the entire canvas, anchored (for 'background-position') at the
>>>>> same
>>>>> point as it would be if it was painted only for the root element
>>>>> itself.
>>>>> The root element does not paint this background again.
>>>>>
>>>>>
>>>> Note that the root element may not be <html> but something like <svg> or
>>>> possibly <any-name-element> if using XML. This is why the spec mentions
>>>> root element here since CSS can style different web languages.
>>>>
>>>>
>>>>  All browsers implement painting of the root backdrop by drawing the
>>>>> background color and images on top of a 100% opaque white backdrop.
>>>>>
>>>>>
>>>> This is not quite true. In the Firefox setting for 'Content > Colors',
>>>> IE
>>>> setting 'Appearance > Colors' and Opera setting for 'Preferences >
>>>> Webpages', I can change the background/backdrop of the root element to
>>>> at
>>>> least a minimum of 70 colors. Internally, each UA has a hidden element
>>>> wrapping the root element. For old Opera (not sure about Blink), this
>>>> was a
>>>> black backdrop.
>>>>
>>>
>>>
>>> This is unspecified behavior.
>>>
>>
>> What part of the above is unspecified behavior?
>>
>> For legacy reasons, I don't believe it is wise to remove user control of
>> the appearance of the backdrop. Some users use these browsers for
>> accessibility reasons since they can control colors.
>
>
> I didn't say that it should be removed. :-)
>
>
>
>>  Prior to blending, this did not make a difference but now we need to know
>>> that there could be another color 'layer' for the root element.
>>>
>>
>> Upon testing, I find that Firefox does *not* allow any blending of any
>> background layers that are painted to the root element but Chrome does. A
>> test.
>>
>> http://css-class.com/test/temp/blending-backdrop.htm
>>
>> Firefox shows red, lime and blue where Chrome shows cyan, fuchsia and
>> yellow since the 'background-blend-mode' has the value of 'exclusion'.
>
>
> You are correct that Firefox is different. I must have tested with the
> wrong file since I can no longer reproduce the issue there.
>
>
>>   Because of this, background images that would blend with transparency
>>>>> (which doesn't change the color), now blend with white and display
>>>>> differently.
>>>>>
>>>>>
>>>> Agree. An image with semi-transparent red rgba(255,0,0,0.5), the blended
>>>> color would paint an opaque 'salmon'. If a user had white text and black
>>>> background/backdrop for accessibly reasons, the blended color would
>>>> paint
>>>> opaque 'maroon'.
>>>>
>>>
>>>
>>> Yes, or if you use any color with 'screen', the content completely
>>> disappears.
>>>
>>
>> Not in Firefox (see test below) but yes in Chrome.
>>
>> http://css-class.com/test/temp/blending-backdrop2.htm
>
>
Ok, this is very weird since this file *is* specifying a background color
on the root, so it should be white.
This tell me that Firefox always breaks of the background-color into its
own layer.


>  My question is, should we keep it as specified and make a note in the spec
>>>>> that the root element behaves differently, or should we fix the
>>>>> implementation so background images blend on a transparent backdrop
>>>>> followed by matting and clarify the paint order in css colors?
>>>>>
>>>>> I think authors would prefer the latter but they can work around it if
>>>>> needed.
>>>>>
>>>>>
>>>> For accessibly reasons, background images should blend on a transparent
>>>> backdrop.
>>>>
>>>
>>>
>>> I agree that authors would prefer that the blending happens in a
>>> transparent group. I'm unsure what that has to do with accessibility
>>> though. Can you explain?
>>>
>>
>> If you look at the test above, you will see that Firefox has already
>> taken control of the painting of the root element. What I mean by
>> accessibility is that if I user needs to have white text of a background to
>> read, then a user should be able to override an author style sheet.
>>
>> See attached screenshot named 'colors-settings.jpg'. If I un-tick the box
>> with the text 'Allow pages to choose their own colors, instead of my
>> selection above', then I would expect to see all backgrounds of any element
>> colored black and all text colored white.
>
>
> Ok, so it seems that Firefox is following the model here where they treat
> the body's background color normally.
> WebKit and Blink seem to be adding another painting pass for the
> background color which is interfering with the background blending.
>
>
Received on Wednesday, 25 June 2014 16:26:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:22 UTC