-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Experimenting with adding writing mode to layout #37932
Conversation
experimenting with adding writing mode to layout
Size Change: +294 B (0%) Total Size: 1.13 MB
ℹ️ View Unchanged
|
Ths is exciting to see even as an experimental draft, thanks for working on it! Adding it to the group block could make sense, as opposed to having to add it to multiple paragraphs. On the other hand, it might be easier to handle the prominence of the feature (which I would still consider useful when needed, but still a bit of a rarity). An answer might present itself as we explore a bit further. (The Layout panel could use love regardless, it might even evolve into a tools panel on its own!) Also from the excellent conversation on the other thread, it seems like Really nice to see this, I think if we can manage the prominence right, it could be both a useful tool for language expression, as well as a nicely decorative tool for other contexts 👌 |
Thanks for experimenting with this @ramonjd ! Personally I don't see how this fits with the |
Thanks for the comment @ntsekouras !! Would you mind elaborating? If I understand correctly, the suggestion is to add the css value inline as per margin/padding? Or have it as a support flag underneath something else, e.g., typography. Or something else? I had the feeling that it's probably not the most appropriate place to add the control, but I looked first at layout for reasons mentioned over in the issue
Also, changing the writing mode required overwriting css set by the layout hooks, e.g., margin-top. I suppose we could still detect writing mode support - wherever it exists – in the layout hooks themselves and modify the CSS accordingly as we do with blockGap support. That sounds like a legit alternative approach. 👍 Now that I'm seeing it half-working 😆 I'll play around with it. Cheers! 🍺 |
Noting that I haven't thought this in depth, and just expressing my initial thoughts 😄
Exactly that! Right now the layouts we have implemented have been implemented with the default writing mode
So with the above being said, should/could this be a new layout entirely? Should we use this at a block level only? Could CSS Logical Properties help us with this if we could apply them to the existing layouts? Thanks again for experimenting with this though, because it's a way to get more answers. --cc @youknowriad if you have any thoughts about this. |
@ramonjd I'm still not sure whether this should be a layout property or its own dedicated one. The question for me is: does it make sense to apply this to a specific block or it only makes sense for container blocks? When it comes to the "layout" dependency, it seems there's no dependency if we switch the |
Thanks @ntsekouras and @youknowriad for helping here. I'm grateful for your input and the questions. 🙇
I started from the assumption that we'd be applying writing mode to containers, e.g., Group or Column, because of the way the property affects a block of content and how individual units of content flow/stack themselves within that container. For example, I assumed it would be easier to tell a Navigation block to render its children vertically, rather than set each child element individually. Looking at a few Japanese/Korean etc websites however, there's a bit of a mix: many designs apply the I think I need to experiment a bit more with what's possible in the block editor, and the balance between vertical writing for design's sake vs vertical writing as a practical content layout option. All that aside, I still think it would be great to be able to offer users the ability to create websites such as the above. 😄
This is a terrific observation! If we were to define writing mode at a container level, maybe it would be useful to address the foundation first, that is, revisit layouts with the intention of explicitly implementing horizontal writing mode but with the intention that they may be toggled to "vertical". I believe the advice that you both offer in relation to CSS logical properties and This is something I hadn't yet tested, thanks for bringing it to my attention.
I'm also still wondering at categorization. To me, it's almost a "typographic layout", as it affects the style of written language (vertically stacked characters) but also the orientation and direction of surrounding content. Thinking of a possible future, we could open up a new category – "Writing Mode or something i18n-related" – through which we'd offer control over a block's RTL property, text orientation as well as horizontal/vertical writing mode 🤷 Regardless, for now, I think to chip away at this, I can:
|
First, this is amazing to see as a work in progress.
I kind of like the idea of setting things 'by the text' and it feels like a text-align, although I know that's got some complications. |
I might move this to an issue to capture these discussions seeing as this PR might not survive. |
Just wanted to note that this PR has been an excellent test of the concept, showing opportunities and limitations. Thank you! It seems like margin control is a bit of a doozy, since it doesn't orientation with the text. I.e. if you have multiple paragraphs, something like You should still be able to select multiple paragraphs and apply it across all of them. It wouldn't solve the margin issue, but it might make it less prominent? |
Thanks for putting more thought into this! After researching/testing out different scenarios for the issue, I think I agree that beginning at the (text) block level might be the most pragmatic way to move forward. We might miss out on the "block flow" aspect, that is, multiple paragraphs with If we start smaller, hopefully it'll be more portable/amenable to iterative improvements too. |
Closing in favour of #38319 |
Description
TBD
writing-mode2.mp4
How has this been tested?
Screenshots
Types of changes
Checklist:
*.native.js
files for terms that need renaming or removal).