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

Re: [CSSWG] Minutes and Resolutions 2009-07-01

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 2 Jul 2009 15:39:27 -0500
Message-ID: <dd0fbad0907021339x126d39cfmfa75a0d7e88791a8@mail.gmail.com>
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.

Received on Thursday, 2 July 2009 20:40:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:27 UTC