- From: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
- Date: Thu, 16 Feb 2012 10:22:38 +0800
- 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) Cheers, Kenny
Received on Thursday, 16 February 2012 02:23:04 UTC