[CSS3-UI] 'resize' issues 47, 53 - was Re: [CSSWG] Minutes Telecon 2014-12-10
Tantek Çelik <tantek <at> cs.stanford.edu>
2015-03-04 05:16:43 GMT
On Fri, Feb 6, 2015 at 8:00 PM, Florian Rivoal <florian <at> rivoal.net> wrote:
>> On 12 Dec 2014, at 04:52, Simon Fraser <smfr <at> me.com> wrote:
>> On Dec 11, 2014, at 11:15 AM, Tab Atkins Jr. <jackalmage <at> 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.
> 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.