W3C home > Mailing lists > Public > www-style@w3.org > December 2013

[css-masking] reference boxes (was: Re: [css-masking] Comments)

From: Dirk Schulze <dschulze@adobe.com>
Date: Wed, 11 Dec 2013 07:36:01 -0800
To: fantasai <fantasai.lists@inkedblade.net>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <0C498F7C-B72B-4EA8-8507-A997963CDA43@adobe.com>

I title this thread as “reference boxes”. It is the main part of this discussion.

On Dec 11, 2013, at 11:46 AM, fantasai <fantasai.lists@inkedblade.net> wrote:

>   3. In the definition of 'no-clip'...
>        # The painted content is not restricted (not clipped).
>        # The mask painting area is set to the bounding client rect.
>      I don't think this is what we want. Various effects are drawn
>      outside the bounding client rect, for example box-shadows,
>      border-images with outset, and content that overflows the box.
>      If the intent is that the painted content is not clipped, then
>      this definition is wrong.

We discussed this before. The “mask painting area” is the reference box for sizing and positioning mask images. It is correct that content can flow outside of the "border box”. This is exactly the reason why we chose "bounding client rect”. It allows the author to size the mask according to the size of the content (as done for Filter Effects and SVG filters for example). It also allows to position the mask on one of the edges measured on the size of the content.

I do see a major advantage to use bounding client rect for origin and sizing on “no-clip”. It is not there by mistake.

>   4. The reference boxes for masking and clipping seem to be
>      dramatically different. Afaict, masking uses the boxes as
>      defined for backgrounds and borders. But clipping uses the
>      "bounding client rect”.

That is the current behavior on Firefox (implemented unprefixed!), WebKit and Blink (prefixed). For compatibility reasons and consistency with SVG masking and SVG filters I recommend to leave it that way.

>      Consider a box that has been split across three columns of a
>      multi-col element on one page and into the first column on a
>      second page. If I use an elliptical mask stretched to 100%,
>      then the clipped perimeter will be an ellipse stretched across
>      the height of the reconstructed box, and split across the
>      fragments. But if I use an elliptical clip-path stretched to
>      100% this will not be the case. If the element stretched just
>      across the first 3 columns, then the elliptical clip-path would
>      stretch across the rectangle containing the 3 columns. Across
>      pages, I don't even know what would result…

The behavior of bounding client rect is clear. The result can be seen in browsers today and is mostly constant.

>      Using the same shape for a mask and for a clip-path should
>      result in the same effect.

It does for SVG masking and clip-path for instance. clip-path is implemented in Firefox unprefixed as well and has exactly this behavior. (Ditto for WebKit and Blink but prefixed there.)

>   5. clip-path should not be defining the origin and percentage
>      basis of <basic-shape>s directly, but define what the
>      "reference box" is.
>        http://www.w3.org/TR/2013/WD-css-shapes-1-20131203/#reference-box

The reference box is bounding client rect. That is what the spec says. CSS Shapes uses the reference boxes as defined for background and borders, which makes sense for CSS Shapes.

Received on Wednesday, 11 December 2013 15:36:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:37 UTC