W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2011

Filters on HTML question

From: Patrick Dengler <patd@microsoft.com>
Date: Wed, 30 Mar 2011 16:28:26 +0000
To: "public-fx@w3.org" <public-fx@w3.org>
Message-ID: <4A2DB3AE4504E944AF122BBFBA7FBA1F582D2DC1@TK5EX14MBXC114.redmond.corp.microsoft.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:38 UTC