- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Thu, 22 Jan 2009 10:29:47 -0800
- To: Bert Bos <bert@w3.org>
- Cc: www-style@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 UTC