Xamarin.forms: [F100] Bordered views, e.g. grid view

[PureWeen]

Rationale

Views can't easily be given borders without nesting them in frames or implementing custom renderers.

Implementation

The following properties need to be added on the BorderElement static class:

public static readonly BindableProperty BorderThicknessProperty =
     BindableProperty.Create(propertyName: nameof(BorderThickness),
         returnType: typeof(Thickness), declaringType: typeof(View));

public static readonly BindableProperty BorderColorProperty =
    BindableProperty.Create(propertyName: nameof(BorderFillColor),
        returnType: typeof(Color), declaringType: typeof(View));

And on IBorderElement: BorderThickness

Thickness BorderThickness { get; }
Color BorderColor{ get; }

void OnBorderThicknessPropertyChanged(Thickness oldValue, Thickness newValue);
void OnBorderColorPropertyChanged(Color oldValue, Color newValue);

Renderers will frame the given view using the given border properties

The following Views should implement the IBorderElement interface:

• Entry
• Button (the current BorderWidth property should be Obsoleted; setting it should result in a uniform BorderThickness).
• Frame (already done)
• Picker

Expected Result

Android

• [View].BorderThickness: should set the thickness of the border
• [View].BorderColor: should set the outline colors of the border

iOS

See Android

UWP

See Android

Implications for CSS

{border-color: coral;}
{border-width: thin;}

Backward Compatibility

This is adding a new set of properties so should be backwards compatible. Need to ensure that if the user doesn't specify any of these properties that the entry field appears normal

Need to consider how this interacts with BorderWidth which exists on Button. With this implementation BorderWidth should be obsoleted. Since these are all new properties if the user sets the Thickness and BorderWidth then Thickness should win.

Difficulty : Easy

This issue may correlate with implementing following issues:
https://github.com/xamarin/Xamarin.Forms/issues/1664
https://github.com/xamarin/Xamarin.Forms/issues/1681

[andreinitescu]

This would become extremely handy. Is View the right class to have this on? I guess so...
I was thinking about ListView cells which derive from Element and they won't get this.

Note that Frame and Button have a way to set border already.

Might as well want to nuke #1664 and #1681

[andreinitescu]

@jassmith @davidortinau It's not clear to me how this should correlate with #1664 and #1681. There are people who started working on those already. How is this going to work with those?

[PureWeen]

As far as the correlation at a minimum I just wanted to make sure the apis between the three stayed consistent. There's an IBorderElement interface that was used for CSS but I was thinking we'd add the two additional properties to that so there's a consistent spec among the elements that can specify Border properties.

Then at the platform level I just wanted the three tickets to be aware of each other because I feel like there will be consistent code between them with how borders are implemented

[hartez]

If fill color is different than Border Color you'll have | Border Color | Fill Color | Border Color | Component

@PureWeen how do we determine the thickness of the Border Color portion of that diagram?

That is, if BorderColor is Blue, Fill Color is Red, and Border Thickness is 10, how much of the border is blue and how much is red?

[andreinitescu]

I was wondering why do interfaces like IBorderElement or IPaddingElement exist instead of just having properties?
I don't see any implementation currently in XF which needs to get hold of a IBorderElement from an instance for some specific purpose.

[hartez]

Those interfaces enforce a set of properties which an Element requires for a particular set of features. This can be used to map CSS properties (take a look at AssemblyInfo.cs in the Core project); the properties can be mapped to IPaddingElement which applies to Frame, Layout, and Page right now; anything else we later mark with that interface will also support those properties.

It also gives us an easy way to write some generic methods for handling groups of properties in other places; take a look at how IFontElement is used in the platform projects.

Finally, it goes a little way to ensuring that we have consistent property names and types across the Elements.

[PureWeen]

@hartez good point added an extra property for that and some additional consideration notes

[hartez]

@PureWeen What's the rationale behind having an internal color in a Border? What are we gaining with that extra layer? When I think about adding a border to an element, I usually think of just a solid (single color) outline of a specified thickness.

[PureWeen]

@hartez that mainly came from looking around at how/what kinds of borders I saw. A very typical use case I saw would be to have a black outline on the border. Especially in cases with rounded images where it would be
Black | Color | Black

So mainly just trying to capture a larger set of the use case as I can with the API before someone has to use a renderer

But I could see the fill being split out to a feature and then just seeing if it gets traction

[andreinitescu]

@PureWeen I've personally never used border fill. How is it implemented natively exactly? Can you please describe or give a very quick example? Any platform will do

[PureWeen]

<Border>
<Border>
<Border>

But it probably doesn't make since as a parameter and more interesting borders should be implemented through a different mechanism. For example just nesting things that have borders since after this everything can have borders

[StephaneDelcroix]

see also #1754

[andreinitescu]

@PureWeen Personally I'm not in favor of the border filling idea. But I see you already edited the ticket and remove that 👍

[PureWeen]

As @StephaneDelcroix pointed out there's some related internal discussion/work going on in https://github.com/xamarin/Xamarin.Forms/issues/175. We're working out the best way to expose all of this in a simple/useful way. Once those ideas come together we'll update these sets of tickets with more thoughts on implementation details

[samhouts]

Related to #1814

[StephaneDelcroix]

Related to #1754

[PureWeen]

Some work I'm doing currently related to borders
https://github.com/xamarin/Xamarin.Forms/issues/1724

I realize this ticket expands on the concept of borders but I just wanted to make whoever works on this aware

On Android I've generalized
https://github.com/xamarin/Xamarin.Forms/blob/master/Xamarin.Forms.Platform.Android/ButtonBackgroundTracker.cs

so it can essentially be applied to any Android.Views.View but it uses the Button API currently which we probably wanted to expand. Just wanted to make a note of other current efforts in Border-land

[Mrnikbobjeff]

Is this currently ready to implement as in the proposal? I would like to work in this if this is the case.

[samhouts]

@Mrnikbobjeff Yes, it is ready! We'll reserve this issue for you. Thank you!

[Mrnikbobjeff]

I just made the BorderWidth Obsolete and decided to return -1 on a non uniform Thickness. Any other suggestions how a Thickness such as (1,2,3,4) should be returned in the deprecated property?
Also, I would like to have #3534 discussed, as it has applications for other areas of XF. Uniformity checking functions for thickness seem sensable to me.

[samhouts]

@Mrnikbobjeff Were you able to create a PR for this issue? Thanks!

[Happypig375]

Please add Editor to the list. Currently, Editor has a border, at least on UWP.

[adrianknight89]

Can we add the ability to define which sides of a view will have a border? I have at least one case where I need to add a top and bottom border and ignore the horizontal sides. The view spans across the device screen horizontally, so it doesn't make sense to add a left/right border.

[Happypig375]

You can set left, right, top and bottom separately for Thickness.

[adrianknight89]

@Happypig375 My bad. You're right! I must have been thinking of something else last night. Hopefully, Thickness will be tested properly so that a 0 on any side will not create dead space.

[titoleru]

Hi @samhouts, is it planned to extend this to Editors? There is an unexpected behavior of iOS Editor, which does not show any borders, unlike the entries do by default in iOS. Right now this can only be fixed by using a custom renderer