Add support for logical viewport-percentage length units 'vi' and 'vb'
Categories
(Core :: CSS Parsing and Computation, enhancement, P3)
Tracking
()
People
(Reporter: sebo, Unassigned)
References
(Blocks 1 open bug, )
Details
(Keywords: dev-doc-needed)
|
||
Updated•7 years ago
|
|
||
Comment 1•5 years ago
|
||
This is in Level 4: https://drafts.csswg.org/css-values-4/#viewport-relative-lengths. Not Level 3.
|
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
||
Comment 2•5 years ago
|
||
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!
|
||
Comment 3•5 years ago
|
||
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 (foremandremunits 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!
|
|
||
Comment 4•5 years ago
|
||
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).
|
|
||
Comment 5•5 years ago
|
||
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.
|
|
||
Comment 6•5 years ago
•
|
||
(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)
|
|
||
Comment 7•5 years ago
|
||
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...
|
Reporter | |
Updated•5 years ago
|
|
||
Comment 8•4 years ago
|
||
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?
|
|
||
Comment 9•4 years ago
|
||
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.
|
|
Reporter | |
Updated•3 years ago
|
|
||
Comment 10•3 years ago
|
||
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)
|
|
||
Comment 11•3 years ago
|
||
Sure, sounds good!
|
|
Reporter | |
Updated•3 years ago
|
Description
•