- From: Simon Fraser <smfr@me.com>
- Date: Wed, 03 Dec 2014 16:52:28 -0800
- To: Florian Rivoal <florian@rivoal.net>
- Cc: www-style list <www-style@w3.org>, Tantek Çelik <tantek@cs.stanford.edu>, francois.remy.dev@outlook.com, lea@verou.me
On Dec 3, 2014, at 1:24 PM, Florian Rivoal <florian@rivoal.net> wrote: > > This has previously been raised as > https://wiki.csswg.org/spec/css3-ui#issue47 > and > https://wiki.csswg.org/spec/css3-ui#issue53 > > The behaviour of the resize property in the spec is defined in terms of a resize factor applied internally by the UA. Regardless of the theoretical merits of this approach, it does not match what all 3 implementations interoperably do. > > The current behaviour in FF, Chrome and Safari is that as soon as the user starts resizing the element, the width and height properties are set via the style attribute to the value the user resized to. > > Since implementations agree, we should make the spec match. > > (As a side note, Presto implements a limited subset of the resize property, only applying it to textarea elements. It follows the same approach, except that it adds !important). > > With this model in place, there remains a small interop issue: > > Firefox allows the user to resize the element with no other constraints than what is imposed by min-width and max-width. Chrome and Safari will also do that, but in addition, they will prevent the user form resizing to a size smaller than the size at which it was initially laid out. > > I suggest we standardise on the firefox behaviour, because: > * It's less magic > * If you want a minimum size, you can set min-width > * with the webkit/blink behaviour, if you first resize (enlarge) an element, then resize the viewport to become smaller, you then cannot manually resize the element to the (now smaller) size it would have if we were doing the initial layout with this new viewport size, which is not very friendly. That sounds fine. Simon
Received on Thursday, 4 December 2014 00:52:59 UTC