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

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

From: Brad Kemper <brad.kemper@gmail.com>
Date: Tue, 31 Dec 2013 09:34:18 -0800
Cc: www-style list <www-style@w3.org>
Message-Id: <FEFE21C2-3CC3-45DF-BE39-48B2A5FBD761@gmail.com>
To: Dirk Schulze <dschulze@adobe.com>
On Dec 31, 2013, at 2:45 AM, Dirk Schulze <dschulze@adobe.com> 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?
> 
> Greetings, 
> Dirk
> 
> [1] http://dev.w3.org/csswg/css-break/#break-decoration

WebKit seems to be doing the right thing. What wording is there that would justify what Gecko is doing? I'm not opposed to clarifying the text, but I don't see how it is confusing enough to say that Firefox's behavior is anything but a bug. 
Received on Tuesday, 31 December 2013 17:34:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 31 December 2013 17:34:52 UTC