W3C home > Mailing lists > Public > www-style@w3.org > March 2015

[CSS3-UI] 'resize' issues 47, 53 - was Re: [CSSWG] Minutes Telecon 2014-12-10

From: Tantek Çelik <tantek@cs.stanford.edu>
Date: Tue, 3 Mar 2015 21:16:43 -0800
Message-ID: <CAEV2_WaOOtAb1V=fCRXQUqX0bZ7veXCjFzvPwTzbPbraxS669w@mail.gmail.com>
To: Florian Rivoal <florian@rivoal.net>
Cc: Simon Fraser <smfr@me.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
On Fri, Feb 6, 2015 at 8:00 PM, Florian Rivoal <florian@rivoal.net> wrote:
>
>> On 12 Dec 2014, at 04:52, Simon Fraser <smfr@me.com> wrote:
>>
>> On Dec 11, 2014, at 11:15 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>
>>>
>>>> - RESOLVED: Implementors may directly manipulate width and height
>>>>     elements on the style attr being changed and change "resize
>>>>     factor" to "resize function" to address fantasai's concern
>>>>     (issues 47 and 53)
>>>
>>> I object to keeping the optional hidden resize factor.  Nobody does
>>> it, and to the best of my knowledge nobody plans to; I wouldn't be
>>> surprised if there is code depending on resize causing explicit style
>>> attribute changes.  We should just spec the actual interoperable
>>> behavior and require that, rather than maintaining the polite fiction
>>> of an imagined better world.
>>
>> I agree. This resolution was pushed through at the last minute during the call, and people didn't have sufficient time to consider the options and voice opinions.
>
> Just so that we have something concrete written down, resolving in favor of this objection (which I agree with) would mean changing to text of the spec to something like this (instead of the text that starts with "When an element is resized by the user", until the example):

<snip> suggested text

I had made simpler edits to address this resolution per what was
recorded during the f2f, however, I took a look at some of the details
in the suggested text.

In particular

> If an element is resized in only one dimension,
> only the corresponding property is set, not both.

This seems like desired behavior and given at least some
implementation we can take it.


> If the 'resize' property is altered after the user has resized an element,
> including if it is changed to ''none'',
> the <a>style attribute</a> is not reset.

This was my expectation as well, but since it was not explicit, I did
add some related text as such.

> ====
> Most of this is what all browsers interoperably do. There are only 2 points where they differ from eachother, and I'm picking favorites between existing behaviors:
>
> 1) "If an element is resized in only one dimension,
> only the corresponding property is set, not both."
>
> webkit and blink always do this. Gecko does it when resize is ''horizontal'' or ''vertical'', but not when it is ''both'' and the user resizes in along one axis only.

Again I think this is reasonable and if we run into interop issues on
this point we can address during CR.

> 2) "The User Agent must allow the user to resize the element
> within the limits set by [...]"
>
> Gecko does this, but Webkit/Blink don't, as they block resizing down from the initial size, which is kind of bad, especially if the page's layout changes after a window resize, screen rotation, etc...

The existing text said "should" per the last time we as a group
discussed the limits (I believe it was on a telcon) and I think that
does a good job of indicating both what we think is better (and is
implemented) behavior, while not having to make it at-risk due to
there being only one implementation.

If we get multiple implementations during CR, I think it is reasonable
to change that to a must.

Thanks,

Tantek
Received on Wednesday, 4 March 2015 05:17:48 UTC

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