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

Re: Overflow-clipping of filters with fixed-pos/abs-pos descendants

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 12 Jan 2015 12:16:46 -0800
Message-ID: <CAAWBYDApN5KcAu0ZDfnzQiSVWbSFwB2yq07fWhLiXF6P6LoyEw@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>, "public-fx@w3.org" <public-fx@w3.org>
On Wed, Jan 7, 2015 at 7:52 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> On Thu, Jan 8, 2015 at 4:29 PM, Amelia Bellamy-Royds
> <amelia.bellamy.royds@gmail.com> wrote:
>> A) Calculating filter effects region
>> When applying SVG filters to HTML content should the filter effects region
>> be calculated based on the official bounds of the element with the filter
>> property, or based on a bounding box for all child content?
>> Test case: http://fiddle.jshell.net/r8cya98f/
>> Currently Chrome and Firefox both create a bounding box for the combined
>> parent and child content.  (The yellow div isn't clipped, despite the fact
>> it extends more than 25% outside the bounds of the parent.)  I'm pretty sure
>> that this is a change in behavior for Firefox compared to earlier
>> implementations; I remember having problems with just this issue last year.
>> The filter effects spec doesn't currently define bounding box for non-SVG
>> content.  However, the masking spec uses it to mean border-box.  The masking
>> spec, however, is currently rather problematic when it comes to applying SVG
>> masks to HTML content, particularly in how it has re-written the definition
>> of objectBoundingBox units so that 1 user coordinate=1 CSS px instead of 1
>> user coordinate=100%.
>> http://www.w3.org/TR/css3-transforms/#bounding-box
>> http://www.w3.org/TR/css-masking/#valuedef-objectboundingbox0
> Hmm, I thought this was defined somewhere, but I can't find it now.
> I think the "SVG bounding box" of non-SVG elements should be the union of
> the CSS border-boxes of all boxes generated by descendant content. This
> isn't exactly what Firefox does, but it's close and we can easily fix it. It
> should match the "scrollable overflow area" (in Gecko terms) which browsers
> already calculate to decide how far to scroll in an overflow:auto element.

The term you want is "decorated bounding box", defined here:
<http://dev.w3.org/csswg/css-images-4/#decorated-bounding-box>.  And
yes, it matches what you think it should do.

Received on Monday, 12 January 2015 20:17:34 UTC

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