Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-values] Logical equivalents for vw/vh units #113

Closed
upsuper opened this issue May 16, 2016 · 13 comments
Closed

[css-values] Logical equivalents for vw/vh units #113

upsuper opened this issue May 16, 2016 · 13 comments

Comments

@upsuper
Copy link
Member

upsuper commented May 16, 2016

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.

@bradkemper
Copy link
Contributor

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
Copy link
Member Author

upsuper commented May 19, 2016

is and bs means inline-size and block-size which are the logical equivalents for width and height in CSS Logical Properties spec.

@tabatkins
Copy link
Member

Yeah, I'm fine with this.

@fantasai
Copy link
Collaborator

I'd drop the s, seems unnecessary.

@fantasai
Copy link
Collaborator

Btw, here's the www-style thread on this: https://lists.w3.org/Archives/Public/www-style/2015Sep/0253.html

@astearns astearns removed the Agenda+ label Jun 4, 2016
@tabatkins tabatkins self-assigned this Jun 22, 2016
@tabatkins
Copy link
Member

We resolved in the telcon to add vi and vb.

@tabatkins
Copy link
Member

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?

@frivoal
Copy link
Collaborator

frivoal commented 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
Copy link
Member

I suppose we should be using the same concept as (overflow-block), but that doesn't appear to actually be well-defined.

@frivoal
Copy link
Collaborator

frivoal commented 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
Copy link
Member

Sounds good to me.

@fantasai
Copy link
Collaborator

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
Copy link

The-Peppester commented 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: 1 or something.

frivoal pushed a commit to frivoal/csswg-drafts that referenced this issue Nov 15, 2018
Add description for experimental API in polyfill/README.md
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants