W3C home > Mailing lists > Public > www-style@w3.org > December 2012

Re: [css-compositing] Some feedback on section 7.5

From: Rik Cabanier <cabanier@gmail.com>
Date: Sat, 1 Dec 2012 14:47:37 -0800
Message-ID: <CAGN7qDA7x-RwYz_UgkSh4RShKUs3SFBM5qioZg=zRBGvUCkfSw@mail.gmail.com>
To: Lea Verou <lea@w3.org>
Cc: public-fx@w3.org, www-style list <www-style@w3.org>, fantasai <fantasai@inkedblade.net>
On Sat, Dec 1, 2012 at 1:01 PM, Lea Verou <lea@w3.org> wrote:

> (CCing www-style and fantasai, since the FXTF is considering to add
> properties to CSS Backgrounds & Borders [1].)
> Dirk’s agenda request [1] reminded me of this [2], so I decided I’d have
> another look. Personally, I see many issues with this section, both
> editorial and more substantial. In ascending order of significance:
> 1. [Editorial] The title of the section (“Specifying blending and
> compositing in the element background”) does not reflect its contents. The
> properties it defines are not only about backgrounds but also shadows.
> 2. [Editorial] <blend-style> is defined multiple times throughout section
> 7.5. Moreover, the exact same values are accepted in the `mix-color`
> property, without any indication they’re the same. This is repetitive and
> error prone, both for editors and readers. In most CSS specs, something
> like that is defined once and then referred to.

These sections are still drafts.
My hope is that they transition to a specification where they make more
sense (such as Backgrounds and Borders).
If they don't, I agree that they need to be better integrated.

> 3. The `-mix-color` suffix, as well as the `mix-color` property, are
> incredibly confusing names. The author perception is that the
> element/background/shadow is blended in a way that involves their backdrop,
> few do (or should) care about the low-level operations involved for the
> R,G,B components of their pixels.

I'm unsure what you mean. The spec is split out so you don't have to know
the math.
For instance the CSS properties just list the blend modes; they don't say
how they are calculated.

Blending involves the background. An author that uses these concepts has to
know this.
In addition the spec also has to clearly define how the algorithms are
supposed to work since it's also for browser implementors.

> Furthermore, the convention that CSS properties ending in `color` usually
> accept <color> values, makes it even more confusing (background-color,
> border-color, outline-color, color etc)

This was a suggestion from Tab. I personally have no strong opinion but
would like the term to be descriptive.
In this case, blending's purpose is to 'mix colors' so it seems a
technically correct name. 'mix-blend' is probably more recognizable but
strange since mix and blend mean the same thing :-)

> 4. Most importantly (and the primary reason I’m sending this), I think
> it’s suboptimal to require a bunch of CSS properties to be added to a bunch
> of CSS modules, to support more granular compositing control.

Compositing and blending doesn't work the same everywhere. For instance,
painting of shadows, background images and stacking contexts is very

> Not only does it break the goal of loosely coupled CSS modules, it’s also
> inelegant and will become even uglier in the future. What if we want
> another CSS effect (e.g. filters) to apply to different parts of elements
> as well? What if we want to enable different layers of the element to be
> blended in the future, even ones that don’t yet exist? We’ll just add MOAR
> properties?

I don't think more properties are needed. The syntax of existing properties
might be extended.
One example that you have brought up before, was to filter the backdrop of
a blended element.
This could easily be done by extending mix-color. ie mix-color:
Another example is blending for shadows and text. I believe that those
should just become extra properties on text-shadow and box-shadow.

> I think it should be solved in a more generic and decoupled way. For
> example:
> a) An @rule that can be referenced from the mix-color or mix-composite
> property with background-image, text-shadow etc as descriptors.

That seems very complex. Can you give an example?

> b) A property that accepts property names as values, akin to
> transition-property.
Yes, in that case it won’t be possible to apply different blending modes to
> different shadows/background images of the same element, but is that really
> such a common use case to warrant this kind of design complexity and
> verbosity?

I can't speak on how authors are going to use this.
However, I know that most of the effects in our graphical application use
combinations of multiple blend modes, isolation and knockout so it seems
prudent that we allow it.

> I presume this has probably been discussed before (I remember it was an
> ISSUE in the draft, which is now gone (=resolved?)), but I think it’s quite
> serious and IMO should be reconsidered.
> [1]: http://lists.w3.org/Archives/Public/public-fx/2012OctDec/0056.html
> [2]:
> https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#cssbackgroundsyntax
> Lea Verou
> W3C developer relations
> http://w3.org/people/all#leahttp://lea.verou.me ✿ @leaverou
Received on Saturday, 1 December 2012 22:48:07 UTC

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