Re: [css-compositing] Move CSS Compositing spec to WD

On Mon, Jul 30, 2012 at 4:31 PM, L. David Baron <dbaron@dbaron.org> wrote:

> On Monday 2012-07-30 13:03 -0700, Rik Cabanier wrote:
> > You can find the latest version here:
> > https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html
> > Please let us know if you have feedback on the current spec.
>
> Some comments on the current spec follow.  In particular, the
> version I'm commenting on is
> https://dvcs.w3.org/hg/FXTF/rawfile/38457829e592/compositing/index.html
>
>
> 1.1. What is compositing
> ========================
>
> The title of this section should either have a question mark "What
> is compositing?" or should have the final two words reversed "What
> compositing is".
>

Good point! Fixed in new version.


>
> I find the description of shape in this section to be rather
> confusing.  Is it trying to describe the same concept that the
> section "5.2.3. Clip to self behavior" describes?  If so, the latter
> section is clearer.
>

I agree that is very abstract, but it's a reasonable introduction to
compositing.
I think a diagram would help a lot here.

A "shape" is just an abstract element here and could be anything with a
color.


>
> 1.2. simple alpha compositing
> =============================
>
> It may be worth mentioning that the color formula given here applies
> to each color component.
>
> It seems confusing that this section tries to work with a mix of
> premultiplied and non-premultiplied colors in the first part,
> especially given that it doesn't explain the difference until later.
>

The spec talks about color and alpha and then goes to:

Often, it can be more efficient to store a pre-multiplied value for the
color and opacity. The pre-multiplied value is given by

cs = Cs x αs

with
cs: the pre-multiplied value
Cs: the color value
αs: the alpha value

After this, we use premultiplied alpha in the formulas.


Furthermore, the formula near the end in terms of pre-multiplied
> colors could be simplified from:
>   co = cs + Cb x αb x (1 - αs)
> into:
>   co = cs + cb x (1 - αs)
> by using the premultiplied color of the backdrop as well.
>

That was an oversight. Fixed.


>
>
>
>
> 4. Compositing Groups
> =====================
>
> Group invariance doesn't hold for CSS, because creating a group
> changes z-ordering by establishing a new stacking context.  This is
> necessary because, by default, external elements can interleave
> between some of the descendants of an element, but that doesn't make
> sense for things composited in interesting ways.  Therefore, what
> establishes a group needs to be described.  (For example, in CSS,
> having 'opacity' != 1 establishes a group; probably many of the new
> properties in this spec need to do the same for all of their
> non-default values.)
>

This section is how it generally is supposed to work. Exceptions for CSS
are called out in chapter 7.
Basically, there are no "groups" in CSS until you add blending,
compositing, filtering or opacity.


>
> 4.3. Knockout Groups
> ====================
>
> Not clear how knockout groups work in CSS (rather than SVG) because
> it's not clear what drawing operations are atomic, though perhaps it
> could be defined by saying that anything that has its own item in
> Appendix E of CSS 2.1 is an atomic drawing operation.
>

That's correct.


>
> 5.2.1. Isolated groups and Porter Duff modes
> ============================================
>
> What does "bottom element in a group" mean?  Does it mean the
> element establishing the group, i.e., the element closest to the
> root?
>

It's the element that first draws which in the case of CSS depends on the
stacking [1][2].


>
> 7.1. Behavior specific to CSS
> =============================
>
>   #  If an element specifies non-default blending, compositing or
>   #  ‘opacity’, its renderstyle and that of all of its children will
>   #  revert to ‘flat’.
>
> This is the first occurrence in the spec of "renderstyle" and
> "flat"; I don't know what they are.  Is this referring to
> 'transform-style'?


yes. I added a link and reworded the sentence.


> And does this apply to all of the properties in
> the section?
>

It's only for those that apply to an element (just like 'opacity').


>
>   #  The application of non-default blending or compositing to an
>   #  element formatted with the CSS box model also establishes a
>   #  pseudo-stacking-context the same way that CSS ‘opacity’ does.
>   #  One of the consequences is that elements with z-index will not
>   #  honor the depth of elements outside of the group.
>
> I think the intent here is to create a stacking context, not a
> pseudo-stacking context.  A pseudo-stacking context doesn't affect
> z-index.


Fixed.


> And again, this should be clear exactly which properties
> "non-default blending or compositing" refers to.
>
>   #  Order: first filtering is applied, followed by blending and
>   #  then compositing.
>
> I'd think you need to define the order of:
>  * 'filter'
>  * 'mask'
>  * 'clip-path'
>  * 'clip'
>  * 'overflow'
>  * blending
>  * compositing
> Though, maybe "filtering" is a term for a bunch of the above?
>

I agree that the current definition is naive. Do you know of a place that
defines the order that I can reference or re-purpose?


>
>   # Conceptually all HTML elements are part of a group that consists
>   # of the following sub groups, each containing a single element.
>   # In stacking order:
>   #
>   #  the box shadow
>   #  the background layers
>   #  the text shadow
>   #  the text and nested elements
>
> This is incorrect.  The correct stacking order is described in
> Appendix E of CSS 2.1, though that doesn't include box-shadow or
> text-shadow.  It does, however, include text decorations, and
> describe the interaction of nested elements with the other layers
> correctly.  It also describes when (most cases) the contents of an
> element interleave with the contents of other elements in z-order.
>

hmm, I have to ponder this a bit.
With this new information, it might not make sense to have blending on
'nested elements'.


>
> All of the properties described should have a "Computed value: as
> specified" line.  They should also not be animatable in CSS terms
> (since there's no way to interpolate the values).


Fixed.


> (Perhaps we
> should have called that line "Interpolable".  I suppose we still
> can.)
>

That's a funny word! I'd be happy to change it.
(BTW there were some request to be able to interpolate between blending
modes. It's technically feasible; the trick is what to return for computed
style)


>
> I'm not especially happy with the large number of properties added
> for different blend modes, or with adding the matched lists to
> text-shadow and box-shadow.
>

I agree. That is why there is an alternate proposal in the spec.
It will cut down on the number of new properties, but will be more verbose
for case that targets shadows and the box content.


>
> It's not clear to me why 'foreground-blend-mode' takes a list of
> values.


That was an oversight. I fixed it.


> I also think "text or nested elements" may not a sensible
> grouping of things in CSS the way it is in SVG.


Yes, I asked other people if this concept had a name.
It's applied to the drawing at 7.2.4 from
http://www.w3.org/TR/CSS21/zindex.html

Thanks for your feedback!

Rik

1:
https://developer.mozilla.org/en/CSS/Understanding_z-index/Stacking_without_z-index
2: https://developer.mozilla.org/en/CSS/Understanding_z-index/Adding_z-index