On Feb 15, 2012, at 7:24 PM, Ojan Vafai wrote:
> On Wed, Feb 15, 2012 at 7:19 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 2/15/12 9:22 PM, Kang-Hao (Kenny) Lu wrote:
> # The â€˜resizeâ€™ property applies to elements whose computed
> # â€˜overflowâ€™ value is something other than â€˜visibleâ€™. If
> # â€˜overflowâ€™ is different in a particular axis (i.e. â€˜overflow-xâ€™
> # vs. â€˜overflow-yâ€™), then this property applies to the dimension(s)
> # which do not have the value â€˜visibleâ€™.
>
> http://dev.w3.org/csswg/css3-box/#overflow1 clearly says:
>
> The computed values of â€˜overflow-xâ€™ and â€˜overflow-yâ€™ are the same as
> their specified values, except that some combinations with â€˜visibleâ€™
> are not possible: if one is specified as â€˜visibleâ€™ and the other is
> â€˜scrollâ€™ or â€˜autoâ€™, then â€˜visibleâ€™ is set to â€˜autoâ€™.
>
> So the only way to have overflow be "visible" in one direction but not the other is for the other direction to be "hidden". Though I believe an earlier version called for that to become "auto" in the "visible" direction as well? Certainly that's what Gecko does right now
>
>
> Firefox's current implementation is
> somehow in the middle as 'resize' doesn't apply to elements of which
> both 'overflow-x' and 'overflow-y' are 'visible'
>
> Yes, because those actually stay as "visible" in the computed style.
>
> The overall question about what the right behavior is remains, of course.
>
> I don't really see why we tie resize to overflow state at all. Is there any harm in making resize work for overflow:visible. It most cases it would be a strange user experience, but I can conceive of legitimate uses.
I would be pretty awkward to draw the resize widget on top of the overflowing content. Might make it kind of hard to find.