CSS Styling and FlexBox

DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai
edited February 2017 in Xamarin.Forms Evolution

Summary

Xamarin.Forms should support CSS as a method of creating styles. In addition to the CSS style theming, we will include FlexBox style layout support. This model allows for a developer familiar with web technology and css to more easily adapt their layouts in Xamarin.Forms.

Note: The demos below are intended to be short to showcase the API. A lot of them do otherwise silly things.

API Changes

Introduces quite a bit of new API, some of which is still being worked out. However, the bulk of it will be the following:

public class FlexLayout : Layout<View>
{
    // Attached BP's with public get/set methods
    public bool FlexEnabled;
    public bool IsIncluded;
    public float Flex;
    public float Grow;
    public float Shrink;
    public float Basis;
    public FlexAlign AlignSelf;

    // BP's with get/set properties
    public Direction Direction;
    public FlexDirection FlexDirection;
    public FlexJustify JustifyContent;
    public FlexAlign AlignContent;
    public FlexAlign AlignItems;
    public FlexPositionType Position;
    public FlexOverflow Overflow;
    public FlexWrap Wrap;
}

Enum values are pending implementation details.

CSS Demo

page.xaml:

<ContentPage StyleSheet="page.css">
    <StackLayout>
        <Label Text="Foo" StyleClass="test" />
        <Label Text="Bar" />
        <ContentView>
            <Label Text="Baz" StyleClass="test" />
        </ContentView>
    </StackLayout>
</ContentPage>

page.css:

label {
    background-color: green;
    font-size: 12pt;
}

label.test {
    background-color: yellow;
    color: grey;
}

StackLayout>label.test {
    background-color: purple;
}

CSS Implementation

CSS pages are embedded into the app via the resource dictionary. Each page can contain multiple different CSS files which define its full theming. The properties used in the CSS are named after the CSS properties, and not the Xamarin.Forms properties. They simply map down to Forms properties.

CSS files are in practice just a different way to define a Xamarin.Forms.IStyle.

Relationship selectors are supported as defined here: http://www.w3schools.com/cssref/css_selectors.asp

Note - All CSS embedding techniques shown here are just placeholders as the API around that is being reworked and finalized.

CSS Selectors

All major CSS selectors will be supported. This functionality is not currently planned to be exposed through any mechanism other than CSS.

Flexbox Demo

page.xaml

<ContentPage StyleSheet="page.css">
    <FlexLayout>
        <FlexLayout StyleId="MainContainer">
            <BoxView StyleClass="ABox" WidthRequest="100" HeightRequest="100" />
            <Label Text="{Binding Content}" />
            <Label Text="{Binding Content1}" />
            <Label Text="{Binding Content2}" />
            <Label Text="{Binding Content3}" />
            <BoxView StyleClass="ABox" StyleId="EndBox" WidthRequest="100" HeightRequest="100" />
        </FlexLayout>
    </FlexLayout>
</ContentPage>

page.css:

flexlayout {
    display: flex;
}

#MainContainer {
    flex-direction: row;
    flex-wrap: wrap;
    justify-content: flex-end;
}

.ABox {
    align-self: center;
}

FlexBox Implementation Details

  • Flex layouts support the same properties as available in the CSS model and uses the same layout mechanics
  • Automatic overflow behaviors with scrollbars are not supported
  • Nesting of non FlexLayout layouts into a FlexLayout is not supported

More details about how exactly the flexbox model allows for flexible layouts can be found here:
https://www.w3.org/TR/css-flexbox-1/

Supported Flex Properties:

  • align-items: Specifies the alignment for items inside a flexible container
  • align-self: Specifies the alignment for selected items inside a flexible container
  • bottom: Specifies the bottom position of a positioned element
  • flex: Specifies the length of the item, relative to the rest
  • flex-basis: Specifies the initial length of a flexible item
  • flex-direction: Specifies the direction of the flexible items
  • flex-flow: A shorthand property for the flex-direction and the flex-wrap properties
  • flex-grow: Specifies how much the item will grow relative to the rest
  • flex-shrink: Specifies how the item will shrink relative to the rest
  • flex-wrap: Specifies whether the flexible items should wrap or not
  • justify-content: Specifies the alignment between the items inside a flexible container when the items do not use all available space
  • left: Specifies the left position of a positioned element
  • order: Sets the order of the flexible item, relative to the rest
  • position: Specifies the type of positioning method used for an element (static, relative, absolute or fixed)
  • right: Specifies the right position of a positioned element
  • top: Specifies the top position of a positioned element
  • z-index: Sets the stack order of a positioned element
0
0 votes

Rejected · Last Updated

This proposal has been rejected in its current form.

«1

Posts

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    Xamarin.Forms should support CSS as a method of creating styles.

    No, it shouldn't. This isn't HTML. XAML has had an established way of creating Styles for over a decade. No need to fix what isn't broken.

  • DonFitzsimmonsDonFitzsimmons USMember ✭✭

    I think this is a great idea. One of the biggest problems with native UI development is that each platform re-invents the wheel when it comes to layout. We end up with all sorts of odd conventions like AutoLayout. HTML and CSS provide the best, most familiar UI solution to date.

    This would also lower the barrier to entry for many Web developers considering making a move to mobile development. If the UI layout and styling is familiar, that's one thing we don't have to learn.

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    HTML and CSS provide the best, most familiar UI solution to date.

    Not to XAML developers. There are tens if not hundreds of thousands of WPF developers from the last decade that have never dealt with HTML. The Xamarin noobies should get up to speed with the existing XAML conventions, not make all the experienced developers abandon what they have known and used for years.

    Web developers already have a big learning curve anyway, styles or CSS won't amount to much of a difference. There is no reason to try to foist all that CSS/HTML on to the existing XAML developer base. Not to mention SOOO MANY other things the folks at Xamarin could be fixing/working on, other than making a second style system when there is already a perfectly good one in place and has been in place for a long time.

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    @ClintStLaurent > @ClintStLaurent said:

    HTML and CSS provide the best, most familiar UI solution to date.

    Not to XAML developers. There are tens if not hundreds of thousands of WPF developers from the last decade that have never dealt with HTML. The Xamarin noobies should get up to speed with the existing XAML conventions, not make all the experienced developers abandon what they have known and used for years.

    Web developers already have a big learning curve anyway, styles or CSS won't amount to much of a difference. There is no reason to try to foist all that CSS/HTML on to the existing XAML developer base. Not to mention SOOO MANY other things the folks at Xamarin could be fixing/working on, other than making a second style system when there is already a perfectly good one in place and has been in place for a long time.

    @ClintStLaurent we're not suggesting to remove anything or replace XAML here. This proposal is to add support for an alternative that will allow other devs to be productive. If you don't need or want to use it, you'll still have everything you need.

  • voidvoid DKBeta ✭✭✭
    edited February 2017
    Seems like a waste of resources and a lack of focus.
  • DavidDancyDavidDancy AUMember ✭✭✭✭

    By contrast it's yet another DSL that developers not intimately familiar with web technologies will have to learn. I'm sure it's very powerful but it's desperately ugly and the syntax is very obscure. I would be very disappointed if it became the only way to create styles in Xamarin.Forms, especially since the existing way works well. Preferring CSS over the current system seems to me to be a re-hash of the old XML-is-bad-JSON-is-good argument.

    I'm not against this move per se. I'd be the first to admit that the current layout system is hard to work with. HorizontalOptions and VerticalOptions very often don't do what I expect them to; I'm always having to add "filler" BoxView objects to get the StackLayout to work properly; and so on. If the proposed FlexLayout solves those issues elegantly I'd be keen to adopt it.

    But please leave CSS out of it. I have a feeling that this small implementation will be the thin end of the wedge and we'll get more and more requests for "just this little bit of CSS" functionality. If that happens we might as well all give up and go with ReactNative.

  • DH_HA1DH_HA1 USMember ✭✭✭

    Facebook yoga (https://github.com/facebook/yoga) has a Xamarin wrapper. Maybe use this as the engine?

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    Please note this from the Proposal:

    The properties used in the CSS are named after the CSS properties, and not the Xamarin.Forms properties. They simply map down to Forms properties.

    CSS files are in practice just a different way to define a Xamarin.Forms.IStyle.

    If you like CSS, you can use it. If you wish it would die in a fire, just pretend it doesn't exist. We are not proposing replacing the existing styling.

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    @ClintStLaurent we're not suggesting to remove anything or replace XAML here. This proposal is to add support for an alternative that will allow other devs to be productive.

    Can you picture what the result of that would be? Picture a solution where someone has built half the styles in CSS and then another developers does some XAML styles using BasedOn and tries to point to the CSS styles.

    I have to agree with @DavidDancy

    Leave CSS out of it.

    I'm sorry if it hurts the feelings of web developers but the simple truth is... You need to get up to speed with the paradigms and technologies used for building applications - that run on the local hardware. IE: Desktop/platform executables. Programs are not web pages.

  • DavidDancyDavidDancy AUMember ✭✭✭✭

    The only justification I can find for working on a new layout system right now is that the old system is too bad to make it work fast enough on Android. If FlexLayout can solve the Android performance issues I'm all for it.

    BUT - and it's the biggest BUT I can summon - I'm sure Xamarin peeps do realise that there's a ton of legacy layout code that will need to be rewritten to take advantage of any speed increases that might come as a result of FlexLayout.

    Like somehow we're going to get managerial approval for tearing up all our stuff and doing it all over again - not.

    So my issue is not with the merits of FlexLayout per se. I like it. I even have some issues with the current layout system. But why now? Is it really proving impossible to get the current system to work well enough?

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    @ClintStLaurent said:

    @ClintStLaurent we're not suggesting to remove anything or replace XAML here. This proposal is to add support for an alternative that will allow other devs to be productive.

    Can you picture what the result of that would be? Picture a solution where someone has built half the styles in CSS and then another developers does some XAML styles using BasedOn and tries to point to the CSS styles.

    I have to agree with @DavidDancy

    Leave CSS out of it.

    I'm sorry if it hurts the feelings of web developers but the simple truth is... You need to get up to speed with the paradigms and technologies used for building applications - that run on the local hardware. IE: Desktop/platform executables. Programs are not web pages.

    I hear you. Understood.

    I primarily here want to make sure we clearly articulate the proposal so we all understand it, and can have good discussion about it.

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    @DavidDancy

    The only justification I can find for working on a new layout system right now is that the old system is too bad to make it work fast enough on Android.

    I hear ya. Though I did just read in another thread that Xamarin is working on an upgrade roadmapped for March release that should fix a lot of the performance lag in Android.

    I totally share your frustration, but would prefer to see man-hours spent on FIXING the parts that are bad, rather than patching over bad with a band-aide. We've all worked on those programs and its terrible. Putting that scheme in place within the Xamarin ecosystem would just kill it altogether.

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    @DavidDancy said:
    The only justification I can find for working on a new layout system right now is that the old system is too bad to make it work fast enough on Android. If FlexLayout can solve the Android performance issues I'm all for it.

    BUT - and it's the biggest BUT I can summon - I'm sure Xamarin peeps do realise that there's a ton of legacy layout code that will need to be rewritten to take advantage of any speed increases that might come as a result of FlexLayout.

    Like somehow we're going to get managerial approval for tearing up all our stuff and doing it all over again - not.

    So my issue is not with the merits of FlexLayout per se. I like it. I even have some issues with the current layout system. But why now? Is it really proving impossible to get the current system to work well enough?

    This isn't intended as a way to address deficiencies in our existing layout system. One of the major value propositions of Xamarin.Forms is as a productivity tool. We are more productive expressing our UI once and having it render to multiple platforms with a high degree of fidelity.

    This proposal is in keeping with that. We are seeing that many developers find this a productivity boost in terms of familiarity with their existing skills and as an ongoing way to quickly express styling and layout.

    Is that going to be true for 100% of developers, in particular those comfortable and productive with XAML and existing methods of styling? Likely not.

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    Per conversation with @DavidDancy I've adjusted the current status of this proposal. I initially set it to "In Progress" to indicate it's not an "up for grabs" task, and the team has done some investigation. What I didn't intend to express was, we are actively integrating this into Forms today, right now, this past week, etc.

  • TiborTthTiborTth HUMember
    Xaml based flex layout is OK but CSS based styling is nonsense.
  • DepechieDepechie BEInsider, Developer Group Leader ✭✭
    I totally agree with @TiborTth !
    A web dev has enough power with the webview control to show css styled HTML in Xamarin apps ( look at newspaper apps )!
    A Xaml dev would not touch css but, for me personally, would rather have a richer Xaml set. Uwp solved a lot for responsive design apps with Relative panel and visual state triggers. Set your prio on bringing that over to Xamarin forms.
  • r2d2rigor2d2rigo GBMember

    While I think the FlexLayout is a good idea, please don't even think on adding the CSS feature. It's a spec full of patches and workarounds (!important comes to mind) and it's the last thing we need the Xamarin team to focus on.

    Let's stop the trend on converging every technology into an HTML/web based approach. They are popular but they aren't the best option always.

  • ChaseFlorellChaseFlorell CAInsider, University mod

    My opinion is that CSS should stay a library on it’s own and NOT be brought into Forms officially. It adds ambiguity on how styling should be done. Some things (as cool as they are) are better off as plugins or add-ins and not as a part of the official library.

  • AdamPAdamP AUUniversity ✭✭✭✭✭
    edited February 2017

    @DavidOrtinau

    FlexLayout = yes (once existing layout system stabilized), CSS = no.

    The existing XF layout engine is already completely riddled with minor bugs that cause many issues. (I should really file bug reports for these, but I'm only one guy and I get paid for building working apps, not filing bug reports :) )

    • RecycleElement and HasUnevenRows causes cells to not get right height in 2.3.4
    • Frame margin property isn't included in parent width calculation in 2.3.2
    • Horizontal StackLayout elements require WidthRequest or will now crash in 2.3.4
    • Opacity causing crashes in Android (though this one was lodged by someone else and confirmed)

    I just mentioned these to highlight, I'm having enough trouble with layout system as it is, without introducing another way to define things via CSS, and hence introduce more issues.

    If the XF team developed far more comprehensive UnitTests than they have now with the Layout System, which they really should do, to stop these continuous regressions, then I might be more open to further expansion of the Layout system.

    Just to note, that last paragraph isn't said with any anger, just constructive criticism. I really think their layout system unit tests are lacking and need more focus.

  • David.RettenbacherDavid.Rettenbacher ATMember ✭✭
    edited February 2017

    FlexBox layout: fantastic! Having a more flexible layout would be great! (wrapping,...)

    I would love to see css-based styling baked in!

    I have the impression that the resistence seen above comes from the fear that

    • working on this delays other well-known and needed fixes/improvements
    • the Xaml styling will be left behind

    As David pointed out, this will not influence the roadmap (performance improvements,...).

    I initially set it to "In Progress" to indicate it's not an "up for grabs" task, and the team has done some investigation. What I didn't intend to express was, we are actively integrating this into Forms today, right now, this past week, etc.

    Xml vs Css

    As David also pointed out, css-styles compiles down to generated Style-objects - the same Style-objects that you are now used to write in XML.

    CSS files are in practice just a different way to define a Xamarin.Forms.IStyle.

    Compare writing styles in xml to writing styles in css:

    Css:

    Button
    {
        BackgroundColor: #333333;
        ForegroundColor: White;
        FontSize: 25;
        Grid.Column: 0;
    }
    

    Xml:

    <Style TargetType="Button">
        <Setter Property="BackgroundColor" Value="#333333" />
        <Setter Property="ForegroundColor" Value="White" />
        <Setter Property="FontSize" Value="25" />
        <Setter Property="Grid.Column" Value="1" />
    </Style>
    

    Xml is overly verbose, distracts with many characters not needed to express the essence of your intended styling.
    And this is just a simple style.

    Vanilla Xaml-Styles vs Css

    Css offers you more than Xaml-Styles can give you.

    • Ever wanted to inherit from multiple styles to a new one? Currently you can only inherit from one base-style (BasedOn). In css just add some css classes.
    • Ever wanted to use the same style for multiple types of controls? Have a named style and update all control's Style-properties with a verbose markup-extension like {StaticResource nameOfStyle}. In css just add the css class.
    • Ever wanted to combine multiple styles i.e. for setting TextColor to Red on all inputs with validation errors? Currently you have to create an inherited style and switching it back and forth, remembering the previous one. Or setting the dependency-properties on the controls directly. In css just add a css class like validation-error.
    • Ever wanted semantic styles, like important, warning, default? Not available in xaml.
    • Ever wanted to style by where in the ui-hierarchy a control is? Not available in xaml.

    In css this all is a no-brainer. (scss is even more powerful, but don't go off-topic)

    Adobe Flex: MXML and Css

    Had anyone of you used Adobe Flex with MXML and css? In that point it was a great combination and a pleasure to work with (I used it at work on a daily basis)!
    Adobe Flex Stylesheet Documentation "Using external style sheets"


    XamlCSS

    (Disclaimer: I'm the dev behind XamlCSS)
    Has anyone of you took the time and tried XamlCSS?
    Played around with it a little?
    It's free! It's here today!

    • You can use markup-extensions like Binding, StaticResource, DynamicResource
    • You can use the property-names you already know

    With additions to css like nested-selectors, variables, mixins you can get very productive and your styles concise.


    Property-Names

    Now to a point in the proposal I worry about:
    Not using property-names as-is, i.e. background-color instead of simply BackgroundColor could be a problem in the long run.
    Without a mapping there is no mapping which has to be updated.

    On Css being a Pain...

    Without any offence intended to anyone:
    Who of you are really using css in their daily work?
    It is true, you can misuse css, you can get in a messy situation. But in my experience it mostly happens only if you use many different foreign css-stylesheets (from libraries, from cool website templates,...)

    But if you use it right it is a flexible, powerful and very concise way of expressing your styling.

    Endnotes

    Please let us not focus on if someone already knows or doesn't know, likes or doesn't like css - let's focus on what all of those knowing and/or willing to use css will gain if it were part of Xamarin.Forms!

    (Sorry, this post got pretty long ;))

  • DonFitzsimmonsDonFitzsimmons USMember ✭✭

    If this is just an option, the ability to use CSS and FlexBox, that is - it's fully optional - and it doesn't hinder the progress of other features, why wouldn't it be a good idea? You don't like it, don't use it. Some of us would truly appreciate using this.

  • JanHannemannJanHannemann CAUniversity, Developer Group Leader

    I really think its a waste of resources. But as long as it does not come at the cost of other things, knock yourself out. The argument that Web Devs can benefits by transferring their skillset to XAML is weak. Microsoft tried that with WinJS.

  • NicoVermeirNicoVermeir BEUniversity ✭✭

    not a fan.

    why not focus on bringing more styling features over from "real" XAML? The people using Xam Forms are mostly XAML devs anyway. (oh and I really, really don't like CSS but I do love XAML)

  • As Janneman said: Microsoft tried with WinJS to bring over the batch of Web Devs, it didn't work. Web Devs got their ways of doing cross platform, XAML devs got Xamarin Forms. Rather put effort in bringing over RelativePanel and VisualStateTriggers like Depechie proposed.

    CSS (in combo with multiple browsers) is the reason I don't do Web Dev. CSS and multiple OSes feels a lot like the same over again.

  • voidvoid DKBeta ✭✭✭
    edited February 2017
    Please focus on doing full XAML instead. And if you must get distracted, move XAML and all to iOS and Android when it is robust on Forms.

    Wouldn't it be nice if we could use iOS/Droid XAML user controls in Forms instead of always doing renderers? Wouldn't it be nice to have a single UI editor for Forms and platform UI? The list of synergies could go on.

    What is the Xamarin vision these days ? What are you guys aiming for in the mobile development department if not XAML/MVVM/.Net/etc ? I'm asking because suggestions like these makes me doubt that I understand where we are headed.
  • KarlShifflettKarlShifflett USMember ✭✭

    With all due respect, this makes **ZERO **sense. XF is XAML. Period, end of story.

    Now that XF is part of Microsoft, the XF team must focus on **fixing **the current XF XAML grammar to match other Microsoft XAML stacks. How Height became HeightRequest is beyond me. Not DataContext but BindingContext, CRAZY.

    Microsoft, please normalize your XAML grammar, this will make it much easier for Enterprise and LOB developers to adopt your XF platform. Will also make it MUCH easier for XAML tooling (if we ever get that).

    Best,

    Karl

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    Morning read: Catching up on all the comments over night.
    Trend I noticed: Many experienced WPF XAML developers (that would be the strongest base for Xamarin.Forms, right?) all saying the same thing:
    1. Fix all the broken bits,
    2. finish importing the missing bits
    3. standardize what you have to the existing microsoft XAML spec (Height v. HeightRequest etc.)

    Something I notice nobody saying, but I think really needs to be said:
    Whether you agree or disagree with CSS as a second way to do styles is beside the point. Xamarin right now has PROVEN they can't or won't fix broken bits. How many Bugzilla reports do we all know about that have yet to even be confirmed/prioritized? My biggest fear is that this drive to bring in more web developers through CSS is going to backfire HUGE. Xamarin isn't taking care of the existing WPF migrators. If they split their man-power to hastily adding CSS all that's going to happen is there will be TWO BROKEN STYLE SYSTEMS, and that doesn't help the developers; and that doesn't help the eco-system.

    The last thing any of us want is to see Xamarin die the death of Silverlight. Xamarin has amazing potential and if they would just stay focused on making one complete, rich and functional system it could rule the mobile development market.

    If the folks at Xamarin want to add CSS as a way to bring in more developers - as a second system - more power to you. I hate the idea personally. But as long as it doesn't make things worst then I don't care if it is there since I can ignore it. But for Pete's sake PRIORITIZE. Fix all the existing problems and when you run out EXISTING XAML NEEDS to support, then start looking for stuff to bring in from other disciplines such as web.

    You guys at Xamarin are developers too, right? You know that if you have a busted foundation adding more weight on top is going to cause a collapse. Don't make that happen here by adding the weight of a million web devs piling on top of a system that already has issues. If you don't give everyone a solid foundation now, then 2018 will be the year we are all lamenting about how Xamarin joined all the other failed Microsoft technologies.

  • WilliamSRodzWilliamSRodz BRInsider, University, Developer Group Leader ✭✭

    I'm wondering when we will have bindings to listview select item event, datepicker/timepicker, and other issues. What I'm seem is focus on novelty not on basic things or bugs.

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    Several of the comments here are about what the Xamarin.Forms team should be focusing on in the larger scope of the toolkit. That's fair, and I hear you loud and clear. The reason we have put this proposal into the forum is to give that added visibility, and if it meets with criticism, we need to know that.

    I'd like to ask that we focus the discussion on the proposal itself.

    If you don't think css/flexbox adds any value to the platform regardless of who proposes it, we welcome that perspective based on arguments of the merits of the proposal itself. We greet and welcome all other proposals with that same spirit, and I think it's fair to ask everyone do the same here.

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    @ChaseFlorell said:
    My opinion is that CSS should stay a library on it’s own and NOT be brought into Forms officially. It adds ambiguity on how styling should be done. Some things (as cool as they are) are better off as plugins or add-ins and not as a part of the official library.

    That's an interesting point. Does having multiple ways to do something like styling and layout create confusion? We can do layout in a few different ways today: XAML or code. Some of it is personal preference, and some of it is performance related.

    I think having these in a separate package would be a performance hit due to added reflection, but I could be wrong there.

  • ChaseFlorellChaseFlorell CAInsider, University mod

    @DavidOrtinau when XAML was first introduced in the insiders forum, it was a huge deal. XAML is foundational to what Forms has become, and Forms wouldn't have the developer base it has without it. The same can be said for CSS in that there are a lot of developers out there who know CSS, and having it available might increase the user base. That being said however, I personally see this as a bell or a whistle, and not pivotal to the framework.

    As I said previously, keeping XamlCSS as a Nuget would be my vote. It's already mature(ish), has a user base, and is OSS for others to improve if need be.

  • ChaseFlorellChaseFlorell CAInsider, University mod

    @DavidOrtinau said:

    @ChaseFlorell said:
    My opinion is that CSS should stay a library on it’s own and NOT be brought into Forms officially. It adds ambiguity on how styling should be done. Some things (as cool as they are) are better off as plugins or add-ins and not as a part of the official library.

    That's an interesting point. Does having multiple ways to do something like styling and layout create confusion? We can do layout in a few different ways today: XAML or code. Some of it is personal preference, and some of it is performance related.

    When multiple devs work on a project, you know as well as I do that the guidelines are just that "guides". Dev 1 will just shim in a Style because that's what they know, and Dev 2 will meticulously maintain their CSS because maybe they came from web... so yeah, it's another layer of confusion.

    1. CSS
    2. Global Styles (app.xaml)
    3. Page Styles
    4. Quick and dirty on the element

    contrived

    <ContentPage StyleSheet="page.css">
        <ContentPage.Resources>
            <ResourceDictionary>
                <Style x:Key="LabelPageHeadingStyle" TargetType="Label">
                    <Setter Property="FontAttributes" Value="Bold" />
                    <Setter Property="HorizontalOptions" Value="Center" />
                    <Setter Property="TextColor" Value="{StaticResource HeadingTextColor}" />
                </Style>
            <ResourceDictionary>
        </ContentPage.Resources>
        <StackLayout>
            <Label Text="Title" Style="{StaticResource LabelPageHeadingStyle}" />
            <Label Text="Foo" StyleClass="test" />
            <Label Text="Bar" />
            <ContentView BackgroundColor="Green" Margin="10,20" Padding="8">
                <Label Text="Baz" StyleClass="test" />
            </ContentView>
        </StackLayout>
    </ContentPage>
    
    label {
        background-color: green;
        font-size: 12pt;
    }
    
    label.test {
        background-color: yellow;
        color: grey;
    }
    
    StackLayout>label.test {
        background-color: purple;
    }
    
  • ChaseFlorellChaseFlorell CAInsider, University mod

    Also, even thought I disagree with Xamarin introducing this as an officially supported/integrated library, I will stay that I'm looking forward to leveraging it in my next project! It's wonderful!

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭
    edited February 2017

    How about this notion, and I base this off of an earlier comment pointing out that CSS and XAML take different approaches to achieve the same result.

    Css:

    Button
    {
        BackgroundColor: #333333;
        ForegroundColor: White;
        FontSize: 25;
        Grid.Column: 0;
    }
    

    Xml:

    <Style TargetType="Button">
        <Setter Property="BackgroundColor" Value="#333333" />
        <Setter Property="ForegroundColor" Value="White" />
        <Setter Property="FontSize" Value="25" />
        <Setter Property="Grid.Column" Value="1" />
    </Style>
    

    Let's also not forget you can do all this same things in C# for those that don't like making UI in markup... And also in F#

    When you consider that the language doesn't really matter because it all gets compiled down anyway...
    The need remains that all the broken bits need to be fixed... {Just look at the volume of unhandled Bugzilla tickets}
    And the missing bits need to be written. For example: No merge dictionaries ala WPF. No multi-binding!? Not so much as a ListBox equivilent that can show horizontally and something more than a vertical scroll list. I know I'm not the only dev tired of hunting for 3rd party WrapLayout or FlowLayout for example. These are basic tool... But I digress..

    @DavidOrtinau said:
    I'd like to ask that we focus the discussion on the proposal itself.

    Okay... Here's my proposal for how this proposal could be met:
    If the under-pinnings that EITHER markdown language would use and compile down to, would get finished THEN any and all languages and markdowns could hook into the same functions/controls/tools/bits/piecy-parts... it really becomes a personal preference for the developer. But until the low level parts ARE THERE to hook in to this proposal is a moot point. It doesn't matter if you want to bring in CSS or XSS or ABCSS if those languages try to make use of a function that Xamarin still hasn't gotten around to fixing or making.

    Fix and finish the underlying tools... Then let one team hook into those tools via XAML and another team can write the CSS parser. And in 5 years another team can write the new Widget markup parser... then the Thingie markup parser... It really doesn't matter which language you want.

  • StephaneDelcroixStephaneDelcroix USInsider, Beta ✭✭✭✭

    The original proposal isn't clear, and the wording might be a little wrong, generating quite a few of heated answers. So let me try to clarify a few things.

    1. This is actually 2 different and orthogonal proposals. Most of you have figured that out by now. The first one is introducing a new Layout (FlexLayout), the second one is about "CSS" (read more to understand the quotes).
    2. The CSS part is probably misnamed. What this proposal is about is adding StyleSheets to the actual styling capability of XF. More specifically adding styling selectors, like in stacklayout>label.test meaning "only apply this style to a label of class tests having a stacklayout as parent. If you never fell the need for this, or if you don't think this will be helpful in your application, you should totally stick to Styles. The default standard for having selectors is CSS, and that's why CSS was pushed forward. That doesn't mean we couldn't have Selectors on Styles...
  • BenBishopBenBishop USBeta ✭✭

    If Forms could understand CSS, we could incorporate apps like Zeplin into our workflows. It would be nice to be able to just plug this into a project:
    https://www.dropbox.com/s/qmhu8p3r7sreb2r/Screenshot 2017-02-12 13.48.09.png?dl=0

    A designer could design in Sketch, export to Zeplin, organize Zeplin, and then a developer could use that CSS to lessen their load work.

    With that said, I don't think this has be a runtime thing. If there was a Xamarin Studio or Visual Studio plugin that could generate the XAML to be compiled, I'd be happy to use that. It could also alleviate some concerns of taxing the Xamarin.Forms developers. This kind of work could be shifted to the IDE engineers (though they are most likely just as busy.)

    Ideally, this might be a good opportunity for a 3rd party shop, side project, school project, open source community, etc...

  • NMackayNMackay GBInsider, University ✭✭✭✭✭

    The only reason I can see this been added is to try and tempt away NativeScript devs I guess....still if they like coding in JavaScript I doubt that would happen (beyond help :) ).

    Just my opinion but doesn't get my vote, once the roadmap has been implemented and is stable (as can be based on platform breaking stuff you can't foresee) then fair enough but it's a feature I'd never use.

  • DrazenDotlicDrazenDotlic FRUniversity ✭✭

    I don't want to repeat what the others have already said, except for one thing: there are better ways to serve your customers than to spend time on this. The styling isn't broken as such and I don't see almost anyone complaining about that.

    OTOH, many people still have issues with not-so-trivial bugs popping up all the time. If you can, fix what is broken, not what isn't.

    Also, CSS isn't really known as a cool, well thought out technology - just look at it as it is today and its evolution; it's a patchwork of things at best. Differently put, if you feel you absolutely must introduce an alternate way of styling XAML, please don't take CSS as an example syntax.

  • IrrealIrreal RSUniversity ✭✭✭

    As Stephane mentioned, the only real benefit to CSS is the selectors. But we currently have a painfully slow layout system, and I don't see the selector support doing anything else than further slowing it down.

    Sure, I'd love to add a class or select labels that are immediate children of a certain type of stackalyout. That's useful, but it's nowhere near urgent or most important to work on.

    The most painful thing about this is the deafness of the development team towards us, the core developers who push for Xamarin usage, who live and breathe Xamarin each day.

    Ever since Microsoft bought Xamarin, XF has been going down a very very bad path. We got "free" Xamarin... Well, no, nothing is free in life. Instead of paying for a product that keeps trying to be better, we are now getting a free product that keeps trying to sell us Azure subscriptions and get more and more web devs to also buy into azure. All that at the cost of the team actually improving the product.

    Xamarin Exec's top priority is marketing and amassing more and more developers. Building in CSS is so much better at attracting new devs than fixing a bug or improving performance is. Us existing developers are worthless to them since we stopped paying Xamarin subscriptions. Just sell sell sell those azure plans.

    Thanks Microsoft :neutral:

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    Us existing developers are worthless to them since we stopped paying Xamarin subscriptions.

    @Irreal I'm very sorry you feel that way. That troubles me deeply. We are presently working on bug fixes and performance improvements. Please msg me and let me know how else we might be able to help you. We need to keep the focus of this thread on the proposal, but I don't want to seem to ignore this.

    Also, CSS isn't really known as a cool, well thought out technology - just look at it as it is today and its evolution; it's a patchwork of things at best. Differently put, if you feel you absolutely must introduce an alternate way of styling XAML, please don't take CSS as an example syntax.

    @DrazenDotlic I'm reading a growing consensus here that CSS as it is practiced on the web isn't useful or practical for mobile development.

    The primary gain we are considering with CSS as @StephaneDelcroix points out is the ability to use selectors. This isn't something you can do with just XAML and Styles.

    Given that the proposal is to map CSS properties to Styles, it is perhaps more appropriate to call it "css-like" or "css-inspired"? We certainly don't want to inherit unnecessary complexity as seen on the web. We do want to leverage power and productivity improvements of something like selectors.

    But we currently have a painfully slow layout system, and I don't see the selector support doing anything else than further slowing it down.

    @Irreal, yes a very very real concern.

«1
This discussion has been closed.