[css-values-4] Logical viewport units (vi, vb, etc) and writing-mode propagation #6873

andruud · 2021-12-09T15:50:09Z

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

fantasai · 2021-12-10T01:55:47Z

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 vi but you'd want it resolving against your own writing mode, not the root's writing mode...

andruud · 2021-12-13T11:51:09Z

Sounds good, as long as it's the computed value of writing-mode we'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 · 2021-12-14T07:55:07Z

@andruud Agreed on both counts. :)

css-meeting-bot · 2021-12-15T19:00:29Z

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.

Previously the unit 'qi' (for example) would resolve against the nearest inline-axis container. However, according to a recent resolution [1] writing-mode sensitive units resolve to a physical axis based on the target element's writing mode. This simplifies the container-relative unit resolution a bit, since can always use PhysicalAxes when searching for the correct container. Being able to resolve logical units in CSSToLengthConversionData also prepares for implementation of the new viewport units [2], which include a number of new logical variants as well. (They also resolve to physical in the same way). This CL should only affect code behind the CSSContainerRelativeUnits runtime flag (status:test). [1] w3c/csswg-drafts#6873 [2] https://crbug.com/1093055 Bug: 1223030, 1093055 Change-Id: I548a613609b46a38262d5de48e294dab1131853b

Previously the unit 'qi' (for example) would resolve against the nearest inline-axis container. However, according to a recent resolution [1] writing-mode sensitive units resolve to a physical axis based on the target element's writing mode. This simplifies the container-relative unit resolution a bit, since can always use PhysicalAxes when searching for the correct container. Being able to resolve logical units in CSSToLengthConversionData also prepares for implementation of the new viewport units [2], which include a number of new logical variants as well. (They also resolve to physical in the same way). This CL should only affect code behind the CSSContainerRelativeUnits runtime flag (status:test). [1] w3c/csswg-drafts#6873 [2] https://crbug.com/1093055 Bug: 1223030, 1093055 Change-Id: I548a613609b46a38262d5de48e294dab1131853b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3387159 Reviewed-by: Xiaocheng Hu <xiaochengh@chromium.org> Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org> Cr-Commit-Position: refs/heads/main@{#961390}

Previously the unit 'qi' (for example) would resolve against the nearest inline-axis container. However, according to a recent resolution [1] writing-mode sensitive units resolve to a physical axis based on the target element's writing mode. This simplifies the container-relative unit resolution a bit, since can always use PhysicalAxes when searching for the correct container. Being able to resolve logical units in CSSToLengthConversionData also prepares for implementation of the new viewport units [2], which include a number of new logical variants as well. (They also resolve to physical in the same way). This CL should only affect code behind the CSSContainerRelativeUnits runtime flag (status:test). [1] w3c/csswg-drafts#6873 [2] https://crbug.com/1093055 Bug: 1223030, 1093055 Change-Id: I548a613609b46a38262d5de48e294dab1131853b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3387159 Reviewed-by: Xiaocheng Hu <xiaochengh@chromium.org> Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org> Cr-Commit-Position: refs/heads/main@{#961390}

@container

…st element's writing-mode, a=testonly Automatic update from web-platform-tests [@container] Resolve logical units against element's writing-mode Previously the unit 'qi' (for example) would resolve against the nearest inline-axis container. However, according to a recent resolution [1] writing-mode sensitive units resolve to a physical axis based on the target element's writing mode. This simplifies the container-relative unit resolution a bit, since can always use PhysicalAxes when searching for the correct container. Being able to resolve logical units in CSSToLengthConversionData also prepares for implementation of the new viewport units [2], which include a number of new logical variants as well. (They also resolve to physical in the same way). This CL should only affect code behind the CSSContainerRelativeUnits runtime flag (status:test). [1] w3c/csswg-drafts#6873 [2] https://crbug.com/1093055 Bug: 1223030, 1093055 Change-Id: I548a613609b46a38262d5de48e294dab1131853b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3387159 Reviewed-by: Xiaocheng Hu <xiaochengh@chromium.org> Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org> Cr-Commit-Position: refs/heads/main@{#961390} -- wpt-commits: e328f1220b9604fb03a555a78af99c08ea9f0d61 wpt-pr: 32410

@container

…st element's writing-mode, a=testonly Automatic update from web-platform-tests [@container] Resolve logical units against element's writing-mode Previously the unit 'qi' (for example) would resolve against the nearest inline-axis container. However, according to a recent resolution [1] writing-mode sensitive units resolve to a physical axis based on the target element's writing mode. This simplifies the container-relative unit resolution a bit, since can always use PhysicalAxes when searching for the correct container. Being able to resolve logical units in CSSToLengthConversionData also prepares for implementation of the new viewport units [2], which include a number of new logical variants as well. (They also resolve to physical in the same way). This CL should only affect code behind the CSSContainerRelativeUnits runtime flag (status:test). [1] w3c/csswg-drafts#6873 [2] https://crbug.com/1093055 Bug: 1223030, 1093055 Change-Id: I548a613609b46a38262d5de48e294dab1131853b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3387159 Reviewed-by: Xiaocheng Hu <xiaochengh@chromium.org> Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org> Cr-Commit-Position: refs/heads/main@{#961390} -- wpt-commits: e328f1220b9604fb03a555a78af99c08ea9f0d61 wpt-pr: 32410

… should be based on the current element's `writing-mode` https://bugs.webkit.org/show_bug.cgi?id=234373 <rdar://problem/86832561> Reviewed by Tim Nguyen. Previously, we only looked at the root element's `writing-mode`. Looking at the current element's `writing-mode` allows for non-root elements to have a `writing-mode` independent of the root element, as well as having styles based on that. This was changed in <w3c/csswg-drafts#6873>. Tests: CSSViewportUnits.AllSame CSSViewportUnits.MinimumViewportInsetWithWritingMode CSSViewportUnits.MaximumViewportInsetWithWritingMode CSSViewportUnits.EmptyUnobscuredSizeOverrides CSSViewportUnits.SameUnobscuredSizeOverrides CSSViewportUnits.DifferentUnobscuredSizeOverrides CSSViewportUnits.SVGDocument * Source/WebCore/css/CSSPrimitiveValue.cpp: (WebCore::lengthOfViewportPhysicalAxisForLogicalAxis): (WebCore::CSSPrimitiveValue::computeNonCalcLengthDouble): * Tools/TestWebKitAPI/Tests/WebKitCocoa/CSSViewportUnits.mm: (changeCSSPropertyOfElements): Added. (TEST.CSSViewportUnits.AllSame): (TEST.CSSViewportUnits.MinimumViewportInsetWithWritingMode): (TEST.CSSViewportUnits.MaximumViewportInsetWithWritingMode): (TEST.CSSViewportUnits.EmptyUnobscuredSizeOverrides): (TEST.CSSViewportUnits.SameUnobscuredSizeOverrides): (TEST.CSSViewportUnits.DifferentUnobscuredSizeOverrides): (TEST.CSSViewportUnits.SVGDocument): Canonical link: https://commits.webkit.org/250835@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@294609 268f45cc-cd09-0410-ab3c-d52691b4dbfc

[css-values-4] logical `*vi`(inline) and `*vb` (block) viewport units should be based on the current element's `writing-mode` https://bugs.webkit.org/show_bug.cgi?id=234373 <rdar://problem/86832561> Reviewed by Tim Nguyen. Previously, we only looked at the root element's `writing-mode`. Looking at the current element's `writing-mode` allows for non-root elements to have a `writing-mode` independent of the root element, as well as having styles based on that. This was changed in <w3c/csswg-drafts#6873>. Tests: CSSViewportUnits.AllSame CSSViewportUnits.MinimumViewportInsetWithWritingMode CSSViewportUnits.MaximumViewportInsetWithWritingMode CSSViewportUnits.EmptyUnobscuredSizeOverrides CSSViewportUnits.SameUnobscuredSizeOverrides CSSViewportUnits.DifferentUnobscuredSizeOverrides CSSViewportUnits.SVGDocument * Source/WebCore/css/CSSPrimitiveValue.cpp: (WebCore::lengthOfViewportPhysicalAxisForLogicalAxis): (WebCore::CSSPrimitiveValue::computeNonCalcLengthDouble): * Tools/TestWebKitAPI/Tests/WebKitCocoa/CSSViewportUnits.mm: (changeCSSPropertyOfElements): Added. (TEST.CSSViewportUnits.AllSame): (TEST.CSSViewportUnits.MinimumViewportInsetWithWritingMode): (TEST.CSSViewportUnits.MaximumViewportInsetWithWritingMode): (TEST.CSSViewportUnits.EmptyUnobscuredSizeOverrides): (TEST.CSSViewportUnits.SameUnobscuredSizeOverrides): (TEST.CSSViewportUnits.DifferentUnobscuredSizeOverrides): (TEST.CSSViewportUnits.SVGDocument): Canonical link: https://commits.webkit.org/250835@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@294609 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/245886.622@safari-613-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-613-branch@295194 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Previously the unit 'qi' (for example) would resolve against the nearest inline-axis container. However, according to a recent resolution [1] writing-mode sensitive units resolve to a physical axis based on the target element's writing mode. This simplifies the container-relative unit resolution a bit, since can always use PhysicalAxes when searching for the correct container. Being able to resolve logical units in CSSToLengthConversionData also prepares for implementation of the new viewport units [2], which include a number of new logical variants as well. (They also resolve to physical in the same way). This CL should only affect code behind the CSSContainerRelativeUnits runtime flag (status:test). [1] w3c/csswg-drafts#6873 [2] https://crbug.com/1093055 Bug: 1223030, 1093055 Change-Id: I548a613609b46a38262d5de48e294dab1131853b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3387159 Reviewed-by: Xiaocheng Hu <xiaochengh@chromium.org> Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org> Cr-Commit-Position: refs/heads/main@{#961390} NOKEYCHECK=True GitOrigin-RevId: 3a7fda23de74e6c6244766f6b640d4459bc6c9c4

https://bugs.webkit.org/show_bug.cgi?id=258722 rdar://111565488 Reviewed by Simon Fraser. Correct handling for vertical writing mode per w3c/csswg-drafts#6873 * LayoutTests/imported/w3c/web-platform-tests/css/css-contain/container-queries/container-units-in-at-container-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/css/css-contain/container-queries/container-units-selection-expected.txt: * Source/WebCore/css/CSSPrimitiveValue.cpp: (WebCore::CSSPrimitiveValue::computeNonCalcLengthDouble): Resolve logical to to physical axis based on the element writing mode. Also explicitly fall back to small viewport units to guarantee consistency. Canonical link: https://commits.webkit.org/265654@main

fantasai added Agenda+ css-values-4 Current Work i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. labels Dec 10, 2021

w3cbot mentioned this issue Dec 10, 2021

[css-values-4] Logical viewport units (vi, vb, etc) and writing-mode propagation w3c/i18n-activity#1442

Closed

atanassov added this to Can wait until 2022 in December 15 meeting Dec 15, 2021

atanassov moved this from Can wait until 2022 to Everything else in December 15 meeting Dec 15, 2021

andruud mentioned this issue Dec 15, 2021

[css-values-4] Small/large/dynamic/logical viewport units mozilla/standards-positions#605

Open

css-meeting-bot removed the Agenda+ label Dec 15, 2021

mozilla-apprentice mentioned this issue Dec 15, 2021

[css-values-4] Logical viewport units (vi, vb, etc) and writing-mode propagation mozilla/wg-decisions#707

Open

mirisuzanne added the css-contain-3 label Dec 15, 2021

fantasai added Closed Accepted by CSSWG Resolution Needs Edits labels Dec 15, 2021

mirisuzanne removed the Closed Accepted by CSSWG Resolution label Dec 15, 2021

fantasai added a commit that referenced this issue Dec 16, 2021

[css-values-4] Switch vi/vb to use writing mode of element itself. #6873

b5f3871

fantasai closed this as completed Dec 16, 2021

fantasai added Closed Accepted by CSSWG Resolution and removed Needs Edits labels Dec 16, 2021

chromium-wpt-export-bot mentioned this issue Jan 17, 2022

[@container] Resolve logical units against element's writing-mode web-platform-tests/wpt#32410

Merged

dcrousso mentioned this issue May 20, 2022

[css-values-4] logical *vi(inline) and *vb (block) viewport units should be based on the current element's writing-mode WebKit/WebKit#863

Merged

devknoll mentioned this issue Jun 29, 2022

[css-contain-3] Clarify Container Relative Lengths #7429

Open

anttijk mentioned this issue Jun 30, 2023

[CSS Container Queries] Use element writing mode for unit resolution WebKit/WebKit#15443

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-values-4] Logical viewport units (vi, vb, etc) and writing-mode propagation #6873

[css-values-4] Logical viewport units (vi, vb, etc) and writing-mode propagation #6873

andruud commented Dec 9, 2021

fantasai commented Dec 10, 2021

andruud commented Dec 13, 2021

fantasai commented Dec 14, 2021

css-meeting-bot commented Dec 15, 2021

[css-values-4] Logical viewport units (vi, vb, etc) and writing-mode propagation #6873

[css-values-4] Logical viewport units (vi, vb, etc) and writing-mode propagation #6873

Comments

andruud commented Dec 9, 2021

fantasai commented Dec 10, 2021

andruud commented Dec 13, 2021

fantasai commented Dec 14, 2021

css-meeting-bot commented Dec 15, 2021