You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-values] Logical equivalents for vw/vh units #113
People may need to use viewport units in a writing-mode-aware way, so probably we should add logical equivalents for vw and vh. They could be called vis and vbs or something like that.
I understand i for inline, and b for block, but what does s stand for?
I assume the dimension would remain constant based on the writing mode of the root element only, and not vary relative to the element they are used in?
Hm, unexpected complication: I'm defining them to take their direction from the root element, but what do we do when you evaluate them in a context without an element? Like, in MQ we define rem without reference to a root element. Do we have a usable notion of writing mode at the document level, without referencing elements or CSS?
I agree it should be the same for both, and I think that going with the initial value of the writing mode property (i.e. vertical is block, horizontal is inline) is the sane thing to do.
I am soooo pumped for this. Ben waiting 20 some odd years to have something like vi and vb. Also, you rlly need to additionally add ci and cb which will stand for content inline (width) and content box (height) so you can dynamically scale your content to the size of its contents. To be honest, im just plain tired of all this crazy hacky, exhausting css whcih makes developers lives alot harder. If web browsers added in just theese 4 units, then CSS would be a billion times easier. Btw. I dont care about how hacky or inefficient the polyfill is for them, I just want em now! By the way, to avoid recursion, which theese units would make pretty easy, just make it so that the max recursion levels is like 1, or decideable by CSS like unit-recursion-levels: 1 or something.
Activity
bradkemper commentedon May 19, 2016
I understand i for inline, and b for block, but what does s stand for?
I assume the dimension would remain constant based on the writing mode of the root element only, and not vary relative to the element they are used in?
upsuper commentedon May 19, 2016
isandbsmeansinline-sizeandblock-sizewhich are the logical equivalents forwidthandheightin CSS Logical Properties spec.tabatkins commentedon May 25, 2016
Yeah, I'm fine with this.
fantasai commentedon May 31, 2016
I'd drop the s, seems unnecessary.
fantasai commentedon May 31, 2016
Btw, here's the www-style thread on this: https://lists.w3.org/Archives/Public/www-style/2015Sep/0253.html
tabatkins commentedon Jun 22, 2016
We resolved in the telcon to add
viandvb.tabatkins commentedon Jun 22, 2016
Hm, unexpected complication: I'm defining them to take their direction from the root element, but what do we do when you evaluate them in a context without an element? Like, in MQ we define
remwithout reference to a root element. Do we have a usable notion of writing mode at the document level, without referencing elements or CSS?[css-values] Per WG resolution, added vi and vb units. For #113.
frivoal commentedon Jun 23, 2016
How about simply going with the initial value of the writing-mode property, which means in an MQ context, vi=vw and vb=vh?
tabatkins commentedon Jun 23, 2016
I suppose we should be using the same concept as (overflow-block), but that doesn't appear to actually be well-defined.
frivoal commentedon Jun 24, 2016
I agree it should be the same for both, and I think that going with the initial value of the writing mode property (i.e. vertical is block, horizontal is inline) is the sane thing to do.
tabatkins commentedon Jun 27, 2016
Sounds good to me.
[css-values] Resolve issue about using vi/vb in MQs by using the init…
fantasai commentedon Jul 18, 2016
Tab, this goes into L4. Which hasn't forked yet because we've got outstanding issues on L3 and can't republish CR. I've commented it out for now.
The-Peppester commentedon May 8, 2017
I am soooo pumped for this. Ben waiting 20 some odd years to have something like vi and vb. Also, you rlly need to additionally add ci and cb which will stand for content inline (width) and content box (height) so you can dynamically scale your content to the size of its contents. To be honest, im just plain tired of all this crazy hacky, exhausting css whcih makes developers lives alot harder. If web browsers added in just theese 4 units, then CSS would be a billion times easier. Btw. I dont care about how hacky or inefficient the polyfill is for them, I just want em now! By the way, to avoid recursion, which theese units would make pretty easy, just make it so that the max recursion levels is like 1, or decideable by CSS like
unit-recursion-levels: 1or something.Merge pull request w3c#113 from jeonghee27/master