Xamarin.forms: [Enhancement] Text edit with borders

[PureWeen]

Rationale

Entry fields can't have borders added without having to add custom renderers.

Implementation

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

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

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

Renderers will frame the Entry based on the supplied Border properties

Expected Result

Android

• Entry.BorderThickness: should set the thickness of the border
• Entry.BorderColor: should set the outline colors of the border
• Entry.BorderFillColor: should set the internal fill on the border. If fill color is different than Border Color you'll have | Border Color | Fill Color | Border Color | Component

iOS

See Android

UWP

See Android

Implications for CSS

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

// Fill color possible with addition of pseudo elements
entry::borderfill
{
color
}

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

Difficulty : Easy

This is an easy change and great for a first time contributor.

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

[libin85]

Have done something similar in my code base and happy to do this @davidortinau

[programmation]

Other screen elements have BorderWidth rather than BorderThickness. Can we please avoid unnecessary new names for things (unless of course there's already a BorderWidth that's different)?

[andreinitescu]

Like @programmation said, things should be consistent.
The irony is BorderThickness is more better because it allows having a border only one specific sides.

[PureWeen]

Yea that's why I went with BorderThickness :-) The hope of these is to reduce the users need to create a custom renderer so going the extra few feet to provide customization of all four sides seemed "more better" to me

[programmation]

Consistency is way better than convenience. You can build convenience on top of consistency, but if there's no consistency you can't build anything easily. And using a Thickness fixes the number of sides at the number of Thickness parameters (currently 4). What about when the framework grows up to the point of using a Path for the border?

[PureWeen]

Unless I'm mistaken Button is the only XF element that has a BorderWidth so it doesn't quite seem like an established standard. This and a few other tickets are trying to establish a Border concept across a lot of elements so it seems like a good time to establish something more overall useful.

Maybe just obsolete BorderWidth on Button?

It also maps to border-width in css which is only 4 sides right?

[PureWeen]

Also Margin takes a Thickness

[hartez]

Folding this into #1695.

[titoleru]

Any news on this? It is simple and necessary, especially due to the unexpected behavior of iOS Editor, which does not show any borders, unlike Android or the entries in both