- From: Patrick Dengler <patd@microsoft.com>
- Date: Wed, 30 Mar 2011 16:28:26 +0000
- To: "public-fx@w3.org" <public-fx@w3.org>
I know some good progress was made here. I believe last we talked there were some input/layering issues around filters on HTML. Have we considered: (If we follow the painting , from draft spec) How the 'filter' property applies to content formatted by CSS (e.g HTML) The application of the ‘filter’ property to an element formatted by CSS establishes a pseudo-stacking-context the same way that CSS 'opacity' does, and all the element's boxes are rendered together as a group with the filter effect applied to the group as a whole. The ‘filter’ property has no effect on the geometry of the target element's CSS boxes, even though ‘filter’ can cause painting outside of an element's border-box. The compositing model follows the SVG compositing model: first any filter effect is applied, then any clipping, masking and/or group opacity. These effects all apply after any other CSS effects such as 'clip'. As per SVG, the application of ‘filter’ has no effect on mouse event hit-testing. =>Then if we created a filter shortcut syntax: filter= url(#) {shortcut} none - presumes ‘in’ expressed by SVG filter; and if SVG Filter has none, it presumes SourceGraphic (which maps to ‘content’ below) background – overrides ‘in’ on SVG Filters using the background layer in HTML border – overrides ‘in’ on SVG Filter and uses the border content – includes all content / children of the elements that are in that z-index so filter:url(#textShadow) content I'd love to hear feedback here and make some movement (unless I missed some)
Received on Wednesday, 30 March 2011 16:29:01 UTC