Re: [CSSWG] Minutes Telecon 2014-12-10

> 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):


When an element is resized by the user,
the user agent sets the 'width' and 'height' properties
in <a>style attribute<a> of the corresponding element in the DOM,
to the size indicated by the user,
expressed in ''px'' units.

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

If the <a>style attribute</a> of the corresponding element
already contained a declaration for 'width' or 'height',
resizing the element causes it to be replaced.
If the declaration replaced included ''!important'',
it is not retained.

The User Agent must allow the user to resize the element
within the limits set by 'min-width', 'min-height', 'max-width' and 'max-height',
and must not allow resizing beyond these limits.
Note: this implies that unless constrained by 'min-width' or 'min-height',
the user must be allowed to resize an element
down from its initial size.

Cascading and layout are performed normally.
Note: If the computed value of the ''width'' or ''height'' properties
are different from the size set by the user by resizing
(for example, because of cascading declarations using ''!important''),
the resulting box will not have the size requested by the user,
even though the ''width'' and ''height'' properties
in the <a>style attribute</a> reflect this desired size.

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.

====
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.

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...

 - Florian

Received on Saturday, 7 February 2015 04:00:48 UTC