Skip to content

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

Closed

Description

@upsuper

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.

Activity

  1. bradkemper commented on May 19, 2016

    @bradkemper
    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?

  2. upsuper commented on May 19, 2016

    @upsuper
    MemberAuthor

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

  3. tabatkins commented on May 25, 2016

    @tabatkins
    Member

    Yeah, I'm fine with this.

  4. fantasai commented on May 31, 2016

    @fantasai
    Collaborator

    I'd drop the s, seems unnecessary.

  5. fantasai commented on May 31, 2016

    @fantasai
    Collaborator
  6. self-assigned this
    on Jun 22, 2016
  7. tabatkins commented on Jun 22, 2016

    @tabatkins
    Member

    We resolved in the telcon to add vi and vb.

  8. tabatkins commented on Jun 22, 2016

    @tabatkins
    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?

  9. frivoal commented on Jun 23, 2016

    @frivoal
    Collaborator

    How about simply going with the initial value of the writing-mode property, which means in an MQ context, vi=vw and vb=vh?

  10. tabatkins commented on Jun 23, 2016

    @tabatkins
    Member

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

  11. frivoal commented on Jun 24, 2016

    @frivoal
    Collaborator

    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.

  12. tabatkins commented on Jun 27, 2016

    @tabatkins
    Member

    Sounds good to me.

  13. fantasai commented on Jul 18, 2016

    @fantasai
    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.

  14. The-Peppester commented on May 8, 2017

    @The-Peppester

    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.

  15. added a commit that references this issue on Nov 15, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions