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

I concur with everything Dirk says.

On Sat, Dec 1, 2012 at 1:22 PM, Dirk Schulze <> wrote:

> On Dec 1, 2012, at 1:01 PM, Lea Verou <> 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?
> 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]:
> > [2]:
> >
> > Lea Verou
> > W3C developer relations
> > ✿ @leaverou
> >
> >
> >
> >
> >
> >

Received on Saturday, 1 December 2012 22:55:02 UTC