Change `Alignment` enum to be direction agnostic about ratatui HOT 9 OPEN

The Alternative to this is to add VerticalAlignment and effectively use Alignment as HorizontalAlignment throughout Ratatui. We could also alias Alignment onto a new HorizontalAlignment enum.

The biggest downside I see is when passing two alignments to some method (horizontal and vertical) we lose the self describing nature of these (Alignment::Leff, VerticalAlignment::Top)

This issue is sort of a precursor to having Rects that can center inner Rects in both directions, as well as rendering widgets in vertical alignment, so getting the right enums and variants here leads to a nice ergonomic api.

from ratatui.

I suspect that our target market for the sort of people that want to write tui apps will often be backend devs just as much as frontend devs, so while CSS is informative of some of the context, I'd not lean too much on it being prescriptive.

from ratatui.

I believe in CSS Alignment uses Start and End to account for two things:

1. You can align across a vertical or horizontal axis
2. You can align left or right depending on whether your language is Left to Right or Right to Left

If hypothetically someone were building a TUI in Arabic or in another RTL language what would we want Alignment::Start to do?

I think I like the VerticalAlignment and HorizontalAlignment idea because we are not dealing with direction agnostic layouts.

from ratatui.

Sorry @Valentin271, I didn't mean it's clear (there are tons of tutorials to teach confused devs how to use it.), my point is that start/end/reverse terms are widely known by mainstream web UI developers.

There must be some self-documenting solution, I know. But if we can't reach one conclusion, the CSS pattern is a worth choice.

from ratatui.

I like this idea. I'm not certain about Stretch though - definitely worth considering and perhaps splitting this into two steps.

The main benefit of this are that we don't have to define a second alignment enum. The downside is that the alignment fields become more ambiguous. I'd like to provide a bit more of a pro/con on this before we go and implement it.

from ratatui.

A concrete use case for this would be in #617 (from this comment and below).

I agree to list the pros and cons.

• The first downside I see is ambiguity when talking/reference/using Alignment.
• Second one is if we need to impl Alignment depending on direction (kind of a false problem, we could pass a parameter. And why would we implement Alignment in the first place)

As for Stretch, I'd let it aside for now, focus on the main Alignment. We might implement it later if we end up needing it.

from ratatui.

• The first downside I see is ambiguity when talking/reference/using

Don't worry about ambiguity. I saw front-end devs talking the same terms a lot. I believe it's very common in styling or layout conversion.

For example in flex-alignment (https://flexbox.tech/)

justify-content: flex-start means left

align-items: flex-stat means top

and yes, flexbox has flex-direction to set how the direction is reversed.

from ratatui.

2 points about what @TieWay59 said.

While it is true that flexbox uses the same terms, it encounters the same problems as stated here.

• Whether we're talking about horizontal or vertical is conveyed through the field name (not the value/enum itself).
• It is unclear, you even had to clarify what they mean in your comment 😁

This has me coming down to the fact flexbox is not self documenting, seeing the below out in the wild you have no idea what that means.

flex-direction: horizontal;
justify-content: flex-start;
align-items: flex-end;

This could be countered with simpler properties, as would be done in ratatui imo.

horizontal-align: start;
vertical-align: end;

I think I prefer using different explicit enums so they are self documenting, and if needed implement From on them.

from ratatui.

Like we have style shortcuts, I wonder whether it might be nice to have alignment shortcuts. E.g.:

Line::from("foobar").centered();
Paragraph::new("foobar").centered(); // calls .alignment(Alignment::Center) and returns the paragraph
"foobar".centered(); // creates a new Line that is centered

This still leaves vertical alignment out in the cold somewhat, but perhaps that could be still (top/middle/bottom) or (align_{top, middle, bottom}).

But what this does really imply to me is that the left/center/right values are more subjectively useful than start/middle/end.

from ratatui.