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

> On Dec 10, 2014, at 10:53 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> On Wed, Dec 10, 2014 at 6:39 AM, Florian Rivoal <florian@rivoal.net> wrote:
>>> On 03 Dec 2014, at 22:24, 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, Fantasai made the following observation a while back:
>> http://lists.w3.org/Archives/Public/www-style/2011Aug/0584.html
>> 
>> Doing this as suggested in my previous mail would be the first mechanism we introduce where CSS writes to the dom. Everywhere else, CSS treats the dom as read only.
>> 
>> Example highlighting consequences:
>> http://jsbin.com/likuvo/1/watch
>> 
>> Since the interoperable behavior is to set the style attribute not just when the resize property is on, but also requires the user to actually go ahead and resize the element,  and since it does not unset the style attribute if resize is set to none after resizing, this doesn't introduce any loop.
>> 
>> Personally, I am ok with that, but I thought this was worth noting as we consider specifying this behavior.
> 
> While I'm not the happiest about this (I generally agree with fantasai
> here), the interop is clear, and I'm fine with specifying that.

I think it shouldn't be standardized in a way that sucks, just because it sucks in more than one implementation somewhat consistently. I remember having difficulties getting it to do what I wanted before. One issue was that it didn't play nice with percentages. If I have the element at 100% width of its flexible-width parent (parent is percentage or auto width), and the user resizes the element to be a little less than that, then makes the window narrower, the element is no longer flexible, and now sticks out one side. This is annoying, if the reason the user resized was to make it fit inside its parent better.

I'd prefer if there was a pixel amount added or subtracted to the width or height during the calculation of the used width and height (but still limit its absolute width and height to max-width and max-height). Perhaps make it a percentage amount if the specified measurement is percentage or auto.

Further, I think resize does weird things when it is aligned to the right of its parent, because dragging on the control on the bottom right of the element causes the left side to move around. And when the element is inside a table cell, or other shrink-to-fit parent, resizing it causes the parent to change size, which I think is usually undesirable. And why must we always assume the resizing mechanism is in the lower right corner? Why not resizing by dragging on a border edge, or perhaps within a couple pixels of a border-box edge? 

What is like to see is a sort of non-collapsing extra margin get automatically added to whatever edge is being dragged, equal to the amount that is being added to the width or height, times negative one. So if you drag a left side in, it moves in without changing its parent's width. And if you resize the window, it stays offset by that amount from its parent. I don't think "the precise direction of resizing [should be] left to the UA to properly determine for the platform." It should be defined in the way that is most useful.

Received on Thursday, 11 December 2014 06:13:55 UTC