Proposal Add ConstraintLayout

[insinfo]

It would be great to have this kind of layout in XAML, for Smarter, Responsive and Fluid Layouts

[dotMorten]

As part of this, it would be nice to also be able to expose Anchors on controls that other controls can constrain themselves to. For instance you might want a control to be aligned with an element inside another control. That control could expose the Anchor of the inner element, without having to expose the actual element (iOS has a capability like this and is very powerful).

[insinfo]

@dotMorten This behavior you described is what happens in RelativeLayout of Android, where each child control has a binding anchor to another control to do alignment this

[insinfo]

@dotMorten I believe that in this new XML standard we have the opportunity to search for things that work on other platforms and technologies to build a modern, robust, easy and fast standard. We also have the opportunity to see what does not work. Obtaining things that are happening in the WEB standard (HTML5, CSS, JS, SVG), Android, IOS among others, has a lot of good things around, for example native support for SVG in XAML

[mossyblog]

Ideally you'd likely defer this behaviour to anchor management and move the scaling to camera mechanics. For example if you dock something in the upper right and state that at the time of design my width/height was 200x200 px.

On an iPad that will be 200x200 px but then put it on a 1440 DPI device that will obviously need to scale upward depending on the authors needs.

Instead, the ability to state that a camera control has a variety of modes the define the rules behind this behaviour - Constant Pixel Size, Scale with Screen, Constant Physical Size.

Bare in mind that XAML could describe easily 2D and 3D implementations so the notion of what "depth" (Z) would look like and not just XY.

See https://docs.unity3d.com/Manual/script-CanvasScaler.html

Also you'll likely want to discourage Layout Event Bubbling within the vocabulary as it leads to performance issues around reconciling the platform limitations with the intended rule(s) defined.

[dotMorten]

@insinfo RelativeLayout only works with named controls you declare. It doesn't work with sub-controls inside a custom control, since those controls aren't named or exposed. However that custom control could expose a anchor that internally points to an internal control ie.

public class MyControl : Control
{
    public Anchor TopOfTextAnchor => _internalTextElement.TopAnchor;
}

This means that if MyControl decides to move/animate _internalTextElement to a different location, you can have another control follow it around, and always stay on top of that text, without even actually knowing about the internal text element. Lots of iOS controls does this to create nicer alignments between elements and also to follow other controls around nicely.

[mdtauk]

Having declared/named anchor points within a control could make a lot of sense. It could lead to some interesting visualisations, and would be useful for Microsoft's Fluent Design, for animation/physics animation in the future. It would also make sense for Android if that has a concept of control anchor points.

[birbilis]

@dotMorten could maybe bring back Adorners from WPF and use them also for the scenario you mention above - https://github.com/Microsoft/xaml-standard/issues/101

[rodrigoelp]

I was about to suggest exactly this.

Having developed WPF and UWP applications for a very long time, and inspecting what other frameworks (iOS and Android) offer to deal with multiple screen sizes, aspect ratios, etc. I would like the new specification to include constraints between elements.

I know this can be achieved via all the sorts of panels, margin and padding of the UI elements, but AutoLayout in iOS is extremely powerful (and annoying at times) when declaring relationships between UI elements. I have always felt WPF/UWP is lacking this functionality.

[xioxu]

I suggest exactly this also, I had work in winform/wpf, and when I tried with android contraintlayout, I'm sure wpf needs this feature, it will save us many time for UI development !