- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 2 Jul 2009 15:39:27 -0500
- To: fantasai <fantasai.lists@inkedblade.net>
- Cc: www-style@w3.org
On Thu, Jul 2, 2009 at 1:32 PM, fantasai<fantasai.lists@inkedblade.net> wrote: > sylvain: ... why do we want these new properties introduce the ability > to overflow for these elements? > sylvain: Did we have authors complaining about not being able to overflow > replaced elements before this? > Peter: it's just an implementation artifact > sylvain: FWIW I'm just more comfortable with the existing behavior > remaining where it was, i.e. no overflow > Sylvain: Rather than requiring people to specify extra properties > Sylvain: Especially since there seems to be no demand or use case > scenario for it > Sylvain: Rounding the border shouldn't cause overflow, I just would > not expect that > <sgalineau> I just would not expect that styling the border differently > would affect overflow. > Peter: Why can't we just require people to set overflow: hidden > Bert: CSS2 currently says that overflow doesn't apply to replaced > element, it would be easy to keep it that way > Bert imagines someone creating a map with a small viewport with scrollbars > Peter is averse to special-casing things, but isn't going to hold > things up here for it > peter: we can always unwind it with further properties if necessary > RESOLVED: accept that overflow: visible does not allow replaced content > to overflow I approve of this decision. However, there *are* use-cases for true overflow, with scrollbars and everything, on a replaced element. I recently spent 10 minutes putting together some jQuery code to do image-zooming, just to see if it would be easy (it was). In order to get the zoom to work like I wanted, I had to wrap the image in a <div> with overflow:hidden on it. Then I could grow the image larger than the container on mouseover and move it around on mousemove, mimicing the expected imagezoom interface seen in many places. Depending on exactly how it worked, my implementation may have been somewhat simpler if replaced elements allowed true overflow control, and acted as viewports into their content. As it was, I had to use the container as an overflow-capable viewport. ~TJ
Received on Thursday, 2 July 2009 20:40:27 UTC