[css-logical] Mapping of logical values in 'resize'

[Loirooriol]

In https://drafts.csswg.org/css-logical/#directional-keywords, every subsection specifies whether the mapping of the logical values uses the containing block or the element itself.

• caption-side uses containing block
• float and clear use containing block
• text-align is defined in CSS Text 3 (uses element itself)

The only exception is resize, which has no description.

I believed that the resolution in #3013 (comment) was that all but text-align used the containing block, but I just double-checked and it just says

resolve on proposal to have values that effect alignment compute in containing block. Value effect alignment of content of a box o f an element are computed in writing mode of element itself

resize isn't related to alignment so it doesn't seem to fit in that resolution.

[fantasai]

Points to consider:

• Resizing affects the size of the box and thus its relation with other items on the page. Whether it can grow in any particular direction is largely a function of that layout, so making it relative to the containing block makes sense.
• Resizing is often used to allow the user to create a larger area for editing text, and in that case what matters is the contents, so relative to the element itself makes sense.
• Resize works by modifying the preferred size properties, whose logical counterparts are resolved relative to the element itself, maybe we want to be consistent with that.

Can't say I find any of these arguments particularly convincing one way or another, so I don't have much opinion. Agenda+ to ask the WG.

[css-meeting-bot]

The CSS Working Group just discussed [css-logical] Mapping of logical values in 'resize', and agreed to the following:

• RESOLVED: have the logical value of resize that of the element itself

The full IRC log of that discussion

<dael> Topic: [css-logical] Mapping of logical values in 'resize'
<dael> github: https://github.com//issues/3281
<dael> oriol: The thing is that as css logical spec added logical values for existing properties. For each question of if they should resolve using writing mode of element or its containing block
<dael> oriol: Some past resolutions on this. text-align we resolved we should use writing mode of element. Float and clear which effect element we use writing mode of containing block.
<dael> oriol: Question is on resize property
<dael> oriol: Impl don't agree with this.
<dael> oriol: FF doesn't obey previous resolutions. For float, clear, and resize they use writing mode of element.
<dael> oriol: They shipped
<dael> oriol: In Chromium I used containing block for these three properties but it's behind a flag
<dael> oriol: In issue fantasai provided some points to consider. resizing can effect size of box but also available space for contents. You can see it both ways and it's not clear which we pick
<dael> oriol: No strong opinion, just want to decide on something
<dael> Rossen_: Don't know if folks have read through 3 points from fantasai. Wanted to hear if there are strong opinions
<dael> florian: Weak opinion to favor element
<dael> TabAtkins: same
<dael> smfr: Any version where those are physical?
<dael> florian: Yeah, you can. Quesiton is when you say inline.
<dael> Rossen_: Also more inclined to element
<dael> Rossen_: Anyone who prefers to have inline refer to containing block?
<dael> Rossen_: Some of fantasai points are that layout and resize of element usually effect containing block and might make sense to have this as function of containing block. That's why other option is considered
<fantasai> I think I have a mild preference to containing block.
<fantasai> Use cases are things like sidebars and textarea
<dael> Rossen_: Still hear if we resize based on element's inline for same purpose I think that although this is layout effecting it makes sense to be element itself
<dael> smfr: Logical versions of overflow-x and -y? I can't find it.
<dael> florian: I think so.
<fantasai> https://www.w3.org/TR/css-overflow-3/#logical
<emilio> q+
<dael> smfr: Was thinking resize should match overflow.
<dael> oriol: Overflow uses element writing mode
<dael> smfr: Argument for resize to do same
<Rossen_> ack emilio
<dael> emilio: Did we decide...for float and clear computed value needs to be logical. What FF impl is these logical properties where logical value is computed to phsyical at computed time which doesn't work for containing block. Where we use writing mode of containing block computed value needs to be logical value
<dael> fantasai: Yeah. Value is always itself and never computes phsyical
<dael> emilio: Makes sense. Could effect inheritence
<dael> Rossen_: Obj to have the logical value of resize that of the element itself?
<dael> RESOLVED: have the logical value of resize that of the element itself
<fantasai> s/inheritance/inheritance, but most of these don't inherit/