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

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

I'm sorry I missed the call this week, and won't be there for the f2f.

I agree with your preferences there, and think your many details are a good way to move forward with this level and with what implementors are willing to do.

I think the next level should allow for more flexible/adaptive-friendly behavior, without breaking existing Web pages. So for that level, here is my proposal:

'Resize' should accept a second keyword to indicate what unit should be allowed, besides 'px'. So, for instance, 'resize: vertical em' would cause the UA to add a 'height' value to the style attribute, measured in ems, when the user dragged the resize widget. This would allow changes to the base font size (font zoom) to resize the element too.

Similarly, 'resize: horizontal percent' would set a width measured in percent to match where the user is dragging. Then if the flexible/adaptive layout changed due to changing the window size, the resized element would also grow or shrink appropriately.

Besides px, em, and percent, I would have another possible value of 'margin' for this second value keyword. This would wrap the element in an anonymous box, which would receive right and/or bottom margin (that maybe did not collapse with the margins of the element or its children). It would be positive margin to resize the element smaller in that dimension, and negative margin to make it bigger. It would have no effect if there was no restricted size container to push against, so authors would need to look out for that.

Received on Sunday, 8 February 2015 07:42:25 UTC