Use Start and End semantics instead of Left and Right

[danielkatz]

• Assuming #41, use Start and End semantics instead on Left and Right for HorizontalAlignment.
• The same with Thickness.

  <TextBlock x:Name="MyText"
        Text="Hello World!"
        Foreground="Blue"
        HorizontalAlignment="End"
        VerticalAlignment="Top" />

  <Thickness ...> start,top,end,bottom </Thickness>

[MovGP0]

The Start/End semantics eases internationalization, especially if the LTR direction is not set and determined by the system locale. I would keep the Left/Right semantics for 'cognitive backward compatibility'.

[danielkatz]

@MovGP0 Consider that if you only have to use Start/End that means most of open sourced themes and styles will automatically be RTL friendly. On the other hand, if you also allow the lagacy Left/Right semantics many themes will not support RTL.

[VargrSoft]

Except that that applies exclusively to text runs and not to visual objects. There really is no concept of the start or end of a grid cell when aligning an image, for example, unless you're presuming that for layout, left=start and right=end - which is exactly counter to what your arguments are.

I do agree though, that TextAlignment should be 'start' and 'end' because that's natural.

[danielkatz]

@JeffLewisWA If you ever see a UI built for an RTL language you'll see that the direction of the UI is also flipping along with the text. The terms Start/End for the visual elements stems from the text direction associated with it. I do agree that purely visual elements like bitmaps should not be affected by FlowDirection as I said on #41. Though, I must point out that in WPF implementation FlowDirection does flip bitmaps.

[skendrot]

Left/Right doesn't mean RTL is excluded. When an element has the alignment set to Left then in a RTL theme the item is displayed on the right instead.

[birbilis]

Isn't excluded, but strange in reading if you do RTL-first development

Same applies though to left (action) and right (conext) click terms if you have them inversed

[birbilis]

...Meant to write "context"

[VargrSoft]

I'm torn on this. I see the issue: if you're a developer who works primarily a RTL language, Left/Right is distracting.. that being said, I still argue that left/right is valid regardless of your language while start/end is tied to the language (and thus text).

I wasn't aware that UI tends to get flipped in RTL language design - it make sense, but to show my point, when an RTL developer talks to another developer about the smaller box in the example below: would you say "Top left", "Top right" or "Start start" or "Start end"? Left/right is language independent. Start/end isn't. In the same way, we don't usually reverse the coordinate system to match language direction. In fact, to make it worse, I don't think there's a way to globally set a text direction preference - it's mainly done on a per item basis, isn't it?

In fact, we call them LTR and RTL languages which is 'left to right' and 'right to left'

That's why I suggest the compromise: left/right for entire controls or graphical objects and start/end for text within an object or for components within an object that should be arranged according to the language direction. Then object position stays language independent and text stays language dependent. There would have to be some compromises of course. Menus have to be language direction aware (well, technically they don't but they'd be kind of weird if they weren't - although - what about toolbars?), so all the menus would have to flip. So the position of a menu list within a menu should probably be language specific... but many controls are built that way. The position of the checkbox, for example is on the left side of the content in LTR and to the right side of the content is RTL.

While we're at it, what about languages that can be written UTD and DTU? Not everyone uses horizontal text... and no one talks about them...

[dotMorten]

I don't see how this would work. Microsoft is very clear they don't want to introduce breaking changes, so changing the enums on an existing property isn't an option. The only option I see here is to add new Horizontal/VerticalAlignment properties to Xamarin.Forms and use Left/Right/Top/Bottom there, rather than breaking all UWP and WPF apps.

[danielkatz]

@JeffLewisWA The point is that currently the semantics ARE broken. Consider that today in WPF or UWP this:

<ContentControl FlowDirection="LeftToRight">
    <Button Content="Button"
            VerticalAlignment="Top"
            HorizontalAlignment="Left">
        <Button.Margin>
            <Thickness Left="10" Top="20" Right="30" Bottom="40" />
        </Button.Margin>
    </Button>
</ContentControl>

Will render as: While this:

<ContentControl FlowDirection="RightToLeft">
    <Button Content="Button"
            VerticalAlignment="Top"
            HorizontalAlignment="Left">
        <Button.Margin>
            <Thickness Left="10" Top="20" Right="30" Bottom="40" />
        </Button.Margin>
    </Button>
</ContentControl>

Will render as:

Now ask the question:

when an RTL developer talks to another developer about the smaller box in the example below: [image] would you say "Top left", "Top right" or "Start start" or "Start end"?

IMO, the answer should be "Top Start", because this is the only description that remains true regardless of FlowDirection.

To address the UTD and DTU languages, as far as I understand they are adopting (mostly) the LTR flow, and thus using LTR flow in UI design.

[danielkatz]

@dotMorten I think that according to the faq aliasing concepts IS in the scope of the standard.

[MovGP0]

@dotMorten since XAML Standard is currently a greenfield standard, it is ok not to care about existing projects and enum types too much. There is no need for backward compatibility.

[MovGP0]

@dotMorten also, there is a backward-compatible way of doing this:

public enum HorizontalAlignment 
{
    Center = 0, 
    Begin = 1, 
    End = 2, 
    Stretch = 3, 

    [Obsolete] Left = Begin, 
    [Obsolete] Right = End 
}

[dotMorten]

it is ok not to care about existing projects and enum types too much

So existing UWP and Xamarin.Forms projects aren't important?

[birbilis]

the idea is that they'd keep working, they'd have to be renamed (tooling could help with suggestions and autoconversion) if author decided to select a .NET Standard + XAML Standard target or something

[Mike-E-angelo]

I thought Start was paired with Finish and Begin was paired with End? 🤔

[birbilis]

at ClipFlair Studio I think we ended up using "Start Time" and "End Time" for the respective Captions columns (user does movie captioning and dubbing there). Saying "Begin Time" and/or "Finish Time" sounded strange. Don't remember if SMF (Silverlight Media Framework) was using the same terminology though, probably had Begin and End now that you say it

[Mike-E-angelo]

Might be a cultural thing? Seems like it's commonly heard to hear "begin" and "end" paired together (e.g. "everything has a beginning and an end"). In my world at least. There's also start and finish line in races. So, there's that. 🤓

[insinfo]

@danielkatz This is similar to what happens on Android

[danielkatz]

@insinfo And CSS

[lokitoth]

In this case, I would actually argue for having a both the true FlowDirection-supporting identifiers "Begin", "End" as well as fixed ones: "FixedLeft", "FixedRight". That would, cognitively make more sense of the developer as to what is going on, and reduce the need to have conditional flips for elements that are not meant to flip when FlowDirection changes.