W3C home > Mailing lists > Public > www-style@w3.org > February 2012

[css3-ui] 'resize' and 'overflow'

From: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
Date: Thu, 16 Feb 2012 10:22:38 +0800
Message-ID: <4F3C686E.50501@csail.mit.edu>
To: WWW Style <www-style@w3.org>
8.1. ‘resize’ property

When there's conflict between 'resize' and 'overflow', currently the
spec says

  # 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’.

but the only browser that supports 'resize' on elements beyond
<textarea>, Firefox, doesn't follow the second sentence. Test case:

data:text/html,<div style="resize: both; overflow-x: scroll; overflow-y:
visible;">Test<br />Test</div>

in Firefox 10, you can still resize in both direction. More
interestingly, the computed value of 'overflow-y' becomes 'auto'.

The spec asks implementation to honor 'overflow' when there is conflict.
The other way around would be allowing 'resize' to apply to all elements
and having the 'overflow' of the resizable edges to compute to 'auto' if
the specified value is not 'scroll'. 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'. So, for the test case
I mentioned above, is this simply a bug in Firefox or there are reasons
why Firefox's behavior is preferable?

And, why would it be a bad idea if 'resize' is honored instead?

(I couldn't find similar discussions in the past so I am just raising
this as a point of discussion)

Received on Thursday, 16 February 2012 02:23:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:12 UTC