Re: [css-compositing] some proposals

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.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂

Received on Thursday, 10 November 2011 23:56:09 UTC