Repository navigation
[css-values-4] Logical viewport units (vi, vb, etc) and writing-mode propagation #6873
Description
[<lvi, svi, etc> are] equal to 1% of the size of the large viewport size, small viewport size, and dynamic viewport size (respectively) in the direction of the root element’s inline axis.
If writing-mode is propagated from body to the viewport, are these units supposed to resolve according to the propagated writing-mode (e.g. if used on e.g. the root element)? At the time we know what to propagate from body, it's too late to change any interpretation of *i,*b on root.
Can we specify that these units resolve against the computed value of writing-mode on the root element? This is what WebKit did in their implementation.
Activity
fantasai commentedon Dec 10, 2021
I think that's probably fine. But now that I'm thinking about it... wouldn't we want it to resolve against the writing mode of the element on which it is used? E.g. if you're sizing a line of text to be 50% of the viewport, you'd want to use
vibut you'd want it resolving against your own writing mode, not the root's writing mode...andruud commentedon Dec 13, 2021
Sounds good, as long as it's the computed value of
writing-modewe're resolving against.By the way, if we change vi/vb to resolve against the self-writing-mode, then we should probably make the same change for cqi/cbi.
fantasai commentedon Dec 14, 2021
@andruud Agreed on both counts. :)
css-meeting-bot commentedon Dec 15, 2021
The CSS Working Group just discussed
logical-viewport units and wm propagation, and agreed to the following:RESOLVED: Writing-mode sensitive viewport units (and analogous units) use the writing mode of the element they're used on.The full IRC log of that discussion
<TabAtkins> Topic: logical-viewport units and wm propagation<TabAtkins> github: https://github.com//issues/6873
<TabAtkins> fantasai: issue was raised to simplify some edges cases around writing modes and viewport units
<TabAtkins> fantasai: Also brought up the question - I think we got the issue wrong, as it says to resolve against the root element's writing mode, but I think generally you want the element's writing mode.
<TabAtkins> fantasai: So proposed resolution is to use the element's writing mode to resolve vi/vb, rather than the root element.
<fantasai_> s/edge cases around/edge cases around body propagation and/
<fantasai_> TabAtkins: I agree
<TabAtkins> smfr: Does tha tmake inheritance complicated?
<TabAtkins> fantasai_: No, they compute to lengths before inheritance
<TabAtkins> florian: Yeah, I think I remember that being what I wanted. If you're doing a font-size in viewport units, you want the logical axis you're using.
<TabAtkins> miriam: Might be confusing with container queries which have to be set up to be inline or block
<TabAtkins> miriam: So you set up a container with "inline", this might not match the container you've established.
<TabAtkins> emilio: What do we resolve our units against, the container or the element?
<Rossen_> q?
<TabAtkins> fantasai_: So this is about the container-relative units.
<TabAtkins> emilio: We added a way to resolve against different containers. It would be very bad if we resolved relative units against different axises for each property.
<TabAtkins> emilio: So think we should resolve them against the element's wm.
<TabAtkins> miriam: So when you use the "cq inline unit" it looks for the nearest container with inline containment.
<TabAtkins> miriam: Could potentially be confusing if the inline unit doesn't resolve against a container declaring "inline"
<fantasai_> TabAtkins: I agree that the potential of inline not matching inline is a general problem with mismatched writing modes, and agree that within an element you want inline to match what that element thinks its inline axis is
<TabAtkins> fantasai_: So proposed resolution is that viewport units (and analogues) use the writing mode of the element they're used on.
<TabAtkins> Rossen_: objections?
<TabAtkins> RESOLVED: Writing-mode sensitive viewport units (and analogous units) use the writing mode of the element they're used on.
[css-values-4] Switch vi/vb to use writing mode of element itself. #6873
4 remaining items
[@container] Resolve logical units against element's writing-mode
[@container] Resolve logical units against element's writing-mode
[@container] Resolve logical units against element's writing-mode
Bug 1750537 [wpt PR 32410] - [@container] Resolve logical units again…
Bug 1750537 [wpt PR 32410] - [@container] Resolve logical units again…
[css-values-4] logical `*vi`(inline) and `*vb` (block) viewport units…
Cherry-pick 706e306. rdar://problem/86832561
[CSS Container Queries] Use element writing mode for unit resolution
[CSS Container Queries] Use element writing mode for unit resolution
Bug 1750537 [wpt PR 32410] - [@container] Resolve logical units again…