W3C home > Mailing lists > Public > www-style@w3.org > September 2015

Re: [css-break] border-radius across fragmentation

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 16 Sep 2015 18:34:27 -0400
To: Dirk Schulze <dschulze@adobe.com>, www-style list <www-style@w3.org>
Message-ID: <55F9EE73.3010701@inkedblade.net>
On 12/31/2013 05:45 AM, Dirk Schulze wrote:
> Hi,
> For sliced box-decoration the spec says: “[…] at a break […] ‘border-radius’ does not apply to its corners”[1]
> I interpret the rest of the text that the behavior of ‘border-radius’ should be unchanged. Is that correct? My question is about ‘border-radius’ on one of the original corners that overlaps a break. See example in the fiddle:
> http://jsfiddle.net/QBK7W/
> The border-radius in the example is 80px and therefore in the middle of a break. The behavior of Safari/Chrome, Firefox and IE differ between each other.
> 1) Safari/Chrome do as I interpret the spec. The border-radius continues on the next fragment.
> 2) Firefox changes the border-radius (individually for top and bottom border) so that it fits in the current fragment and does not continue on the next fragment.
> 3) IE behaves like box-decoration-break: clone was specified. The corners on the break have a border-radius.
> The spec is clear that behavior 3) is not wanted. I think the spec implies that 1) is the correct behavior. Would it be possible to get normative text or an example in the spec that clarifies the correct behavior?

The intended behavior is 1. Normative text has been updated to say

   # The effect is as though the element were rendered with no
   # breaks present, and then sliced by the breaks afterward:
   # no border and no padding are inserted at a break;
   # no box-shadow is drawn at a broken edge; and backgrounds,
   # border-radius, and the border-image are applied to the
   # geometry of the whole box as if it were unbroken.

Let me know if this is good, or if you have any improvements
to suggest to the wording.

Received on Wednesday, 16 September 2015 22:34:59 UTC

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