W3C home > Mailing lists > Public > www-style@w3.org > January 2009

Re: [css3-background] does border-radius round the border-image ?

From: Brad Kemper <brad.kemper@gmail.com>
Date: Thu, 22 Jan 2009 10:29:47 -0800
Cc: www-style@w3.org
Message-Id: <75A4BFEC-86C3-40E2-A278-AD246CDD96E1@gmail.com>
To: Bert Bos <bert@w3.org>


On Jan 21, 2009, at 10:41 AM, Bert Bos wrote:

> The text says now: "Other effects that clip to the border or padding
> edge (such as ‘overflow’)". However, 'overflow' doesn't clip to the
> border or padding edge, but to the content edge.

Even though it is the content (box) that gets clipped, it is the  
padding edge that currently is WHERE the content is clipped. "Visual  
Effects" of CSS 2.1 (CR) says that "Whenever overflow occurs, the  
'overflow' property specifies whether a box is clipped to its  
****padding**** edge..." [1].

> I don't think content should be clipped because of 'border-radius',  
> even
> if the radius is so large that the border ends up behind the content.
> If you set 'overflow: scroll', you assume that all content can be made
> visible by scrolling, but if the corners are clipped, those parts
> remain unreachable.

My view is that the expectation of all content being reachable by  
scrolling is is less than the expectation that the content will be  
clipped by the apparent edge of the box.

In any event, you cannot always actually expect that all content can  
be made visible by scrolling, even now:

1) Even in simple cases, if black text overlaps a thick black border,  
it will not really be "visible", practically speaking. In such cases,  
whether the curves clip or not, it is up to the author or designer to  
ensure that if the text is supposed to be readable in the corners,  
that he/she takes measures such as preventing it from extending into  
the curve (via padding, for instance) or making sure the box does not  
overflow.

2) Things the author do may allow other elements outside the box to  
overlap it. Thus, it is the author's responsibility to determine if it  
is appropriate to make sure text is readable in the box. The  
"overflow" property is one of the controls for that, but by itself  
does not produce any guarantees in that regard.

3) Even when the author may expect a scroll box to not obscure  
content, there are cases where it does so anyway, already. I found  
such a case last year, involving absolutely positioned contents [2].

> (On the other hand, scrolling mechanisms that can scroll beyond the 0%
> and 100% marks will have to be introduced by browsers at some point
> anyway, because there are already many pages that have content off the
> left side (because the content is centered, but wider than the window)
> and the only way to make that content visible currently is to turn off
> the style sheets...)
>
> Remark 1:
>
> The fact that a scrollbar looks even more ugly on an element with
> rounded corners than with rectangular ones suggests that browsers
> should use a different scrolling mechanism, reserving the scrollbars
> just for the viewport.

I don't disagree with the idea, but CSS does not (so far) dictate the  
scrolling mechanism. I rather like the iPhone's scroll bars that  
appear over the box as needed, but which are otherwise invisible (and  
do not effect layout).

> Maybe one solution is a combination of moving
> content with the mouse (hand cursor) and a panner that pops up in a
> corner of the element when the mouse hovers over the content. It's
> probably also a good idea to allow the overflowing element to get the
> focus (by tabbing) and scroll with the cursor keys.
>
> Maybe one can also pop up a tooltip-like window of reasonable size  
> (with
> scrollbars) that shows more (or all) of the content of the element,
> while allowing the user to continue interacting with the rest of the
> document.
>
> (We also have the marquee effect and in the future maybe paged  
> elements,
> which allow the user to flip through the hidden content of an element;
> but those two effects are probably only to be applied when the  
> designer
> asks for them with the 'overflow-style' property.)
>
> Remark 2:
>
> Clipping the content seems not very useful,

That depends largely on the content, I suppose. If my "auto"  
overflowing object (with no padding of its own) contains a solid- 
background block that extends edge-to-edge in that container, I would  
not expect it to go outside the curved corners when it was scrolled to  
the top. For instance.

With text as the immediate child of the overflowing box, it is  
admittedly more of an edge case, but could be an interesting effect,  
if the readability of that box is less important than its general  
impression (a big block of names in small print, for instance).

> but *shaping* the content
> and reflowing it would be cool. (Though probably too difficult for  
> CSS,
> except in a few easy cases, such as with the contour keyword[1,2].)

Yes it would. That would be a property of its own though, right? I had  
been thinking of this too, with something like this:

padding-shape: contour | rectangle

...where "contour" would create a padding and content shape that  
followed the shape of the edge (from border-radius or image-border,  
perhaps), and where "rectangle" would make it work as it currently  
does in implementations.



[1] http://www.w3.org/TR/2007/CR-CSS21-20070719/visufx.html#overflow-clipping
[2] http://bradclicks.com/cssplay/scrolling%20lists.html (second to  
last example on the page)
Received on Thursday, 22 January 2009 18:30:27 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:15 GMT