Re: [css-compositing] some proposals

On Thu, Nov 10, 2011 at 4:54 PM, L. David Baron <dbaron@dbaron.org> wrote:

> On Tuesday 2011-11-08 21:38 -0800, L. David Baron wrote:
> > During the meeting, I asked about how SVG handled this sort of case
> > for filters.  After reading through
> > http://www.w3.org/TR/SVG11/filters.html#EnableBackgroundProperty , I
> > realize that (while SVG's solution to this sort of case for filters
> > seems imperfect, though reasonable), SVG is substantially simpler
> > than CSS here, since (if my memory is correct) elements in SVG are
> > either containers *or* graphical elements, but never both.  I don't
> > think SVG's EnableBackground algorithm makes sense when elements can
> > be both a container and a graphical element, and it's not
> > immediately clear to me how to fix it to handle that case.  (And,
> > thus, it's not clear to me how to make a 'comp-op' property make
> > sense in HTML+CSS.)
>
> Actually, I don't think the container and graphical case is that
> hard:  I think that while the algorithm's text would need to be
> rewritten to handle that case, the model that opacity, filters,
> masks, clipping, etc., apply when including non-ancestors in the
> background but do not apply when including ancestors in the
> background still makes as much sense for HTML+CSS as it does for
> SVG.  So things like backgrounds and borders of ancestors would be
> drawn into the buffer without any opacity, etc., handling and then
> the multiple buffers (in the model of the description linked above)
> would continue to be composited together without any opacity, etc.,
> handling.
>
> The other hard piece (at least in terms of spec-writing; not
> necessarily in terms of implementations) is incorporating CSS
> painting order (Appendix E of CSS 2.1) into the algorithm.  The
> concept seems the same, though -- it's just a more complex painting
> order algorithm than SVG's.
>
>
:-) Appendix E really is elaborate.
The output of this flow diagram could be represented as a graphics tree
very similar to the SVG DOM. Conceptually, the 'comp-op' and 'blending'
styles could just move into that tree and function like they do in the SVG
model.
This would also solve the problem where content might have different
z-order because the compositing/blending would happen after that is
resolved.
I can see how blending would be hard to implement for a browser...

It seems that the CSS filters spec also needs to describe this. The draft
at
https://dvcs.w3.org/hg/FXTF/raw-file/f15131694582/filters/publish/Filters.htmlonly
mentions how to background is calculated in SVG...

Rik