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

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

From: Dirk Schulze <dschulze@adobe.com>
Date: Sat, 1 Dec 2012 20:51:53 -0800
To: Rik Cabanier <cabanier@gmail.com>
CC: Lea Verou <lea@w3.org>, "public-fx@w3.org" <public-fx@w3.org>, www-style list <www-style@w3.org>, fantasai <fantasai@inkedblade.net>
Message-ID: <232E6D2D-5058-47F2-955B-17D1722656DD@adobe.com>

On Dec 1, 2012, at 2:54 PM, Rik Cabanier <cabanier@gmail.com> wrote:

> I concur with everything Dirk says.
> 
> On Sat, Dec 1, 2012 at 1:22 PM, Dirk Schulze <dschulze@adobe.com> wrote:
> 
> On 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.
> 
> I agree, <blend-style> should be defined once and then referenced where needed.
> 
> >
> > 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. 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)
> 
> I agree, everything with '-color' implies a <color> values (like 'flood-color', 'stop-color' and others already do). I would rename it to 'mask-blend' (to match its counter part 'mix-composite').
> 
> Another issue that I see is the shorthand 'mix', which combines multiple properties that are not all prefixed with 'mix-'. This is unusual in other specs. The longhands should just be 'mix-composite' and 'mix-blend' IMO.
> 
> >
> > 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. 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 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.
> > 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?

Btw. Webkit already implements '-webkit-background-composite' and '-webkit-mask-composite'. Both are not part of their shorthands at the moment. The definitions in Compositing and Blending are based on an implementation. Just for clarification.

Greetings,
Dirk

> 
> This is a general issue for a lot more specifications and not just Compositing and Blending. As you said, it is an issue with Filter Effects, but with clipping and masking from CSS Masking as well. Therefore, I fully agree that it would be awesome to have a common solution. But I would be really careful with graphical interaction of different paint operations on an element. We have multiple painting operations right now (foreground, background, text selection, border …). It should not be possible to combined two painting operations with one filter or blend operation, if another paint operation is between them.
> 
> >
> > 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.
> 
> We still have this issue in Filter Effects and it was a request by different CSS WG members before (last time fantasai?).
> 
> Greetings,
> Dirk
> 
> >
> >
> > [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 Sunday, 2 December 2012 04:52:30 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:03 GMT