W3C home > Mailing lists > Public > www-style@w3.org > December 2014

[css3-ui] Behaviour of resize (Issue 47, 53)

From: Florian Rivoal <florian@rivoal.net>
Date: Wed, 3 Dec 2014 22:24:20 +0100
Message-Id: <FCAA7F45-DFD7-40D1-8661-8C7ED6A7F020@rivoal.net>
Cc: Tantek Çelik <tantek@cs.stanford.edu>, francois.remy.dev@outlook.com, lea@verou.me
To: www-style list <www-style@w3.org>
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.

 - Florian
Received on Wednesday, 3 December 2014 21:24:44 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:26 UTC