Re: Filters on HTML question

On Mar 30, 2011, at 10:15 AM, Dean Jackson wrote:

> Apologies for not getting a draft out.
> 
> On 31/03/2011, at 3:28 AM, Patrick Dengler wrote:
> 
>> 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)
> 
> Did you forget a link here?
> 
>> 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. 
> 
> I agree.

Yep.

>> 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. 
> 
> Also agreed. We might need some wording on how to calculate the bounding box for some effects (SVG allows it to be specified, but CSS shortcuts shouldn't). 

It should be just like shadows.

> 
> The tricky part about drawing outside the element bounds is that implementations which use hardware compositing may not be able to respect this easily. 

Nah, we handle this for shadows just fine (the implementation just has to be able to determine the extent of the the filtered content). Just like SVG, you do run into issues where the filtered content can be very large.

> 
>> 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. 
> 
> Also agreed.

This is a little confusing, as you say ".. then any clipping...", then " CSS effects such as 'clip'". I think CSS clip would be applied before filtering, but overflow would be after.

> 
>> 
>> =>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
> 
> This bit is a little confusing. Is there really a big use case for these shortcuts? Why would you filter "border" only?
> 
> It also makes the filter property a little more confusing. I was hoping it could provide an ordered list of filter effects, eg.
> 
> filter: sepia() blur(4px);
> 
> If you add {shortcut} in there the syntax will have to be more complex.

I think we should avoid attempting to filter background/border/content etc separately in the first pass.

Simon

Received on Wednesday, 30 March 2011 18:13:47 UTC