Closed Bug 1287034 Opened 8 years ago Closed 2 years ago

Add support for logical viewport-percentage length units 'vi' and 'vb'

Categories

(Core :: CSS Parsing and Computation, enhancement, P3)

Product:
Core
Component:
CSS Parsing and Computation
Type:
enhancement

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1610815

People

(Reporter: sebo, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: dev-doc-needed) 

The CSS Values and Units Module Level 4 [defines logical direction versions of the units 'vw' and 'vh' called 'vi' and 'vb'](https://drafts.csswg.org/css-values-4/#viewport-relative-lengths).

This bug is meant to implement those units.

Sebastian
See Also: → 1287054
Priority: -- → P3
Depends on: css-values-4
Blocks: css-values-4
No longer depends on: css-values-4

Sir I am UG student from India. I have contributed before for Mozilla and I would love to implement this functionality. Can we discuss it on some irc ? or can you leave me any hint ? Let me know!

Hi, you're more than very welcome to work on this. You can jump on #layout or #developers, and I'm pretty sure there will be people happy to help. You can also ask any question you have here.

All that being said, this is not terribly complex, but also not particularly trivial. In particular, these units introduce the constraint of all possible lengths depending on the writing-mode of the root element. This means:

  • Whenever the writing mode of the root element changes, we would need to potentially restyle all elements.
  • This introduces another "priority" of properties, since now writing-mode needs to always be computed before font-size (in case you use font-size: <some-vi-or-vb> value), which itself needs to be computed before all other lengths (for em and rem units to work correctly). This extra priority means an extra pass over all the declarations again, which may be a perf issue...

So all in all this is not trivial, but again happy to discuss more if you plan to implement this.

Thanks!

After thinking a bit about them, I'm not sure vi and vb are worth the complexity they introduce, specially given the confusing behavior they'd have given all the other shenanigans that people want to do like propagating the computed writing mode from the <body> to the viewport (see https://github.com/w3c/csswg-drafts/issues/3066).

This introduces another "priority" of properties, since now writing-mode needs to always be computed before font-size (in case you use font-size: <some-vi-or-vb> value), which itself needs to be computed before all other lengths (for em and rem units to work correctly). This extra priority means an extra pass over all the declarations again, which may be a perf issue...

The writing mode is taken from the root element, so I think it won't be a perf issue since it only adds extra complexity to the root element.

(In reply to violet.bugreport from comment #5)

This introduces another "priority" of properties, since now writing-mode needs to always be computed before font-size (in case you use font-size: <some-vi-or-vb> value), which itself needs to be computed before all other lengths (for em and rem units to work correctly). This extra priority means an extra pass over all the declarations again, which may be a perf issue...

The writing mode is taken from the root element, so I think it won't be a perf issue since it only adds extra complexity to the root element.

Sure, we can avoid this extra pass in the non-root element case, but that means that the cascade function needs to be even smarter, which I'd rather avoid... Basically now we have "early" and "late" properties, this would introduce "really-early" (writing-mode-ish properties), "early" ones (font-size and co.), and "late". We can merge "really-early" properties and "early" ones if we're not the root element...

(Edit: fix typo)

Ah... So it will introduce ugly special-casing for root element, that's not good. Looks like no one has implemented it yet, we probably shouldn't be the first one for this unit...

Keywords: dev-doc-needed

I'm writing some reftests using the inline-/block-size properties and it sure would be nice to have vi/vb there...

Anyway, the spec now says:

In situations where there is no root element or it hasn’t yet been styled (such as when evaluating media queries), the vi and vb units use the initial value of the writing-mode property to determine which axis they correspond to.

Is that enough to move it from the "really-early" to the "early" category?
If not, should we raise a spec issue?

Flags: needinfo?(emilio)

Is that enough to move it from the "really-early" to the "early" category?

Not really for the root element case, as far as I can tell. For the root element case, you still need writing-mode -> font-size -> others.

That being said, I think we might want to get around it recomputing the font-size for that case in StyleAdjuster::fixup_font_stuff, so perhaps not such a huge deal after all.

Flags: needinfo?(emilio)
Blocks: 1759675
Blocks: interop2022

Note that the CSSWG changed that vi and vb units are resolved with the target element's writing mode, not with the root element one. See https://github.com/w3c/csswg-drafts/issues/6873

Can I make this bug as a dup of bug 1610815? (I wasn't initially planning to implement vi/vb units in bug 1610815 though)

Sure, sounds good!

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
No longer blocks: interop2022
You need to log in before you can comment on or make changes to this bug.