Skip to content

[Foldables] Better directionality in spec similar to block-start #138

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

Open
chris480 opened this issue Nov 29, 2019 · 5 comments
Open

[Foldables] Better directionality in spec similar to block-start #138

chris480 opened this issue Nov 29, 2019 · 5 comments
Assignees

Comments

@chris480
Copy link

Instead of env of fold-left, would it be better as fold-start?
This allows for enhanced multi-language context support support.
The functionality would be similar to how margin and border block-start were introduced.

@aarongustafson
Copy link
Member

Yes! We should be using start & end consistently.

@zouhir
Copy link
Contributor

zouhir commented Dec 26, 2019

Thank you @chris480 for filing this issue, I have been thinking about writing mode and additionally the usage logical properties you suggested above.

While I believe the idea is great, our goal with the env(fold-...) variables is to expose the geometry of a screen rect which usually aren't logical as seen in DOMRects e.g. clientBoundingRects.

This allows for enhanced multi-language context support support.

Would adding fold-bottom and fold-right improve anything here?

The functionality would be similar to how margin and border block-start were introduced.

I see this functionality closer to CSS's top, left, bottom and right of a pos abs or fixed rects -- but I am happy to be convinced otherwise.

I would love to discuss this further as I am not yet convinced logical properties are suitable for this scenario but I am happy to learn and change my mind.

@chris480
Copy link
Author

chris480 commented Jan 7, 2020

@zouhir - thank you for the detailed reply.

In my mind, I don't see why we couldn't have both top,left, bottom, right as with traditional CSS model.

As for having more block- based directionality, what I was originally thinking of could be in this example: Map-App graphic

If was a RTL vs LTR reader, could I using only CSS flip the Map and List position?

@tomayac
Copy link
Contributor

tomayac commented Jan 24, 2020

My immediate gut reaction, too, was to reject fold-left/fold-top as "archaic" and go for the "modern" logical denominations, but thinking more about it, in the concrete case this really means left and top of a device, no matter the writing direction. If you take a device like Motorola's, there's a generally agreed-on "top" and hence "left" of the device.

@zouhir zouhir changed the title [Foldable] Better directionality in spec similar to block-start [Foldables] Better directionality in spec similar to block-start Mar 19, 2020
@zouhir
Copy link
Contributor

zouhir commented Mar 25, 2020

folks, I have been thinking a bit about this topic and I believe the best path forward is to actually expose 6 fold rect variables (instead of 4) representing the fold's top, right, bottom, left, width and height

PROs of logical properties

  • if you have 2 column flex or Grid layout, you won't need to change anything when writing-mode is RTL rather than LTR. fold-start and fold-end will flip based on writing mode and you won't need to change your code.

CONs of logical properties

  • There might be future devices with more complex screen topologies, or we might consider supporting external monitors which was brought up multiple times in CSSWG comments. if you look at the topology in the picture below, you will notice start and end are not sufficient.
    Frame 36 (1)

Solved by 6 env() variables

While it's better to not have to do the code below, the solution as you can see is not too complicated to flip 2 flex columns and keep them seam-aware

[dir="ltr"] .col {
   flex: 0 0 env(fold-left);
}

[dir="rtl"] .col {
   flex: 0 0 env(fold-right);
}

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

6 participants