feat: add non-component functionality

[lonix1]

🙋 Feature Request

🤔 Expected Behavior

Most who use this library want to build apps that look like azure / office365 / windows. And the components are excellent!

But there is a need for non-component features - global reset, grids/rows/cols, breakpoints, spacing, flex, form stuff/validation, css utilities, etc.

Without those it is hard to use this library. Other libraries (various bootstrap/blazor libraries, radzen, mudblazor, blazorise) have layout stuff and also components. It is tempting to use them instead, even though I want a Microsoft "look and feel".

Please consider adding those non-components things here too? Without them this library is "incomplete". The alternatives:

• building all that from scratch - bad idea
• using a static css file - bad idea, it should be converted to blazor
• using two libraries, this as well as one which supplies layouts - bad idea, I tried it and it makes everything more complex, and the output files much larger

💁 Possible Solution

I think the easiest approach would be to just use the bootstrap stuff, because that's what all the other libraries did too. And the conversion to blazor could be copied too, as all the other libraries already solved that problem.

[vnbaaij]

We are not opposed to adding some of these 'non-components'. We will however definitely not use bootstrap for this as it would bring in way too much overhead.
Let's use this space to get a discussion going on exactly what components we would want to have.

[lonix1]

You are right it would "bring in too much overhead" - but what I meant is that the "bootstrap model" for those things is good, and it used everywhere. We could pick and choose whatever makes sense.

It's good to compare to what mudblazor, radzen and blazorise did (as well as bootstrap-blazor libs like blazorstrap). The common features they "copied" from bootstrap include: global reset, grid/rows/cols, form validation and utilities, spacing, flex utilities, and so on. Any blazor app using this library will need those. And if you look at how all those libraries deal with these issues, you'll find that they do so almost identically, because the bootstrap model is so effective (and well known); even the material libraries are similar in these areas... so it's a good place to start.

[scottkuhl]

IMO, MudBlazor is quickly becoming, if not already, the best Blazor library available. It has an excellent layout library that makes it easy to create web applications that feel like native Material applications. You can drop their system into a PWA or Hybrid app and you get closer to a native feel than any other library. But it's based on Material.

Fast Blazor should aim to do for Fluent what MudBlazor did for Material. At a minimum:

1. Application shell layout controls including side navigation, top navigation, and bottom navigation.
2. Starting templates that cover the basic side navigation, top navigation / bottom navigation scenarios.
3. A color scheme that feels like it belongs in Windows.

If that is too much work, then I would embrace an existing system like Bootstrap and make alterations to its variable system and just adopt their framework and create starting templates from it.

But at its heart, you have a win if a developer can create a new Fast Blazor template from Visual Studio at the command line that has an application like structured layout that feels native on both mobile and desktop using the Fluent Design guidelines.

[vnbaaij]

Step 1) Add normalize/reset/reboot css option
After looking at a lot of the options out there, I feel most inclined to go with Bootstrap's (5.2) 'reboot approach'.
In the Bootstrap version there are a lot of css variables declared that have to do with colors, font, borders, etc. We have almost all of these already from the Fluent side (through the web-components script. I created the ones I think we need and gave them a --fb prefix (for Fluent UI Blazor). The file as it is right now is below. Looking for feedback, remarks, comments...

/*!
 * Fluent UI Web Components Reboot v0.0.1 
 * Copyright 2022 Microsoft
  * Licensed under MIT (https://github.com/microsoft/fast-blazor/blob/main/LICENSE)
 */

:root {
    --fb-font-monospace: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace;
    --fb-success: #107c10;
    --fb-error: #d13438;
    --fb-warning: #817400;
    --fb-code-color: #d63384;
    --fb-highlight-bg: #fff3cd;
}

*, *::before, *::after {
    box-sizing: border-box;
}

@media (prefers-reduced-motion: no-preference) {
    :root {
        scroll-behavior: smooth;
    }
}

body {
    margin: 0;
    font-family: var(--body-font);
    font-size: var(--type-ramp-base-font-size);
    line-height: var(--type-ramp-base-line-height);
    font-weight: var(--font-weight);
    color: var(--neutral-base-color);
    background-color: var(--neutral-fill-layer-rest);
    -webkit-text-size-adjust: 100%;
    -webkit-tap-highlight-color: rgba(0, 0, 0, 0);
}

hr {
    margin: 1rem 0;
    color: inherit;
    border: 0;
    border-top: 1px solid;
    opacity: 0.25;
}

h6, h5, h4, h3, h2, h1 {
    margin-top: 0;
    margin-bottom: 0.75rem;
    font-weight: 500;
}

h1 {
    font-size: var(--type-ramp-plus-5-font-size);
    line-height: var(--type-ramp-plus-5-line-height);
}

h2 {
    font-size: var(--type-ramp-plus-4-font-size);
    line-height: var(--type-ramp-plus-4-line-height);
}

h3 {
    font-size: var(--type-ramp-plus-3-font-size);
    line-height: var(--type-ramp-plus-3-line-height);
}

h4 {
    font-size: var(--type-ramp-plus-2-font-size);
    line-height: var(--type-ramp-plus-2-line-height);
}

h5 {
    font-size: var(--type-ramp-plus-1-font-size);
    line-height: var(--type-ramp-plus-1-line-height);
}

h6 {
    font-size: var(--type-ramp-base-font-size);
    line-height: var(--type-ramp-base-line-height);
}


p {
    font-size: var(--type-ramp-base-font-size);
    line-height: var(--type-ramp-base-line-height);
    font-weight: 400;
    margin-top: 0;
    margin-bottom: 1rem;
}


a {
   
}

blockquote {
    border-left: 5px solid var(--accent-fill-rest);
    font-size: var(--type-ramp-base-font-size);
    font-style: italic;
    padding: 2px 15px;
}


abbr[title] {
    -webkit-text-decoration: underline dotted;
    text-decoration: underline dotted;
    cursor: help;
    -webkit-text-decoration-skip-ink: none;
    text-decoration-skip-ink: none;
}

address {
    margin-bottom: 1rem;
    font-style: normal;
    line-height: inherit;
}

ol,
ul {
    padding-left: 2rem;
}

ol,
ul,
dl {
    margin-top: 0;
    margin-bottom: 1rem;
}

    ol ol,
    ul ul,
    ol ul,
    ul ol {
        margin-bottom: 0;
    }

dt {
    font-weight: 700;
}

dd {
    margin-bottom: 0.5rem;
    margin-left: 0;
}

blockquote {
    margin: 0 0 1rem;
}

b,
strong {
    font-weight: bolder;
}

small {
    font-size: 0.875em;
}

mark {
    padding: 0.1875em;
    background-color: var(--fb-highlight-bg);
}

sub,
sup {
    position: relative;
    font-size: 0.75em;
    line-height: 0;
    vertical-align: baseline;
}

sub {
    bottom: -0.25em;
}

sup {
    top: -0.5em;
}

a {
    color: var(--accent-foreground-rest);
    text-decoration: underline;
}

    a:hover {
        color: var(--accent-foreground-hover);
    }

    a:active {
        color: var(--accent-foreground-active);
    }

    a:not([href]):not([class]), a:not([href]):not([class]):hover {
        color: inherit;
        text-decoration: none;
    }

pre,
code,
kbd,
samp {
    font-family: var(--fb-font-monospace);
    font-size: 1em;
}

pre {
    display: block;
    margin-top: 0;
    margin-bottom: 1rem;
    overflow: auto;
    font-size: 0.875em;
}

    pre code {
        font-size: inherit;
        color: inherit;
        word-break: normal;
    }

code {
    font-size: 0.875em;
    color: var(--fb-code-color);
    word-wrap: break-word;
}

a > code {
    color: inherit;
}

kbd {
    padding: 0.1875rem 0.375rem;
    font-size: 0.875em;
    color: var(--neutral-base-color);
    background-color: var(--neutral-fill-layer-rest);
    border-radius: 0.25rem;
}

    kbd kbd {
        padding: 0;
        font-size: 1em;
    }

figure {
    margin: 0 0 1rem;
}

img,
svg {
    vertical-align: middle;
}

table {
    caption-side: bottom;
    border-collapse: collapse;
}

caption {
    padding-top: 0.5rem;
    padding-bottom: 0.5rem;
    color: #6c757d;
    text-align: left;
}

th {
    text-align: inherit;
    text-align: -webkit-match-parent;
}

thead,
tbody,
tfoot,
tr,
td,
th {
    border-color: inherit;
    border-style: solid;
    border-width: 0;
}

label {
    display: inline-block;
}

button {
    border-radius: 0;
}

    button:focus:not(:focus-visible) {
        outline: 0;
    }

input,
button,
select,
optgroup,
textarea {
    margin: 0;
    font-family: inherit;
    font-size: inherit;
    line-height: inherit;
}

button,
select {
    text-transform: none;
}

[role=button] {
    cursor: pointer;
}

select {
    word-wrap: normal;
}

    select:disabled {
        opacity: 1;
    }

[list]:not([type=date]):not([type=datetime-local]):not([type=month]):not([type=week]):not([type=time])::-webkit-calendar-picker-indicator {
    display: none !important;
}

button,
[type=button],
[type=reset],
[type=submit] {
    -webkit-appearance: button;
}

    button:not(:disabled),
    [type=button]:not(:disabled),
    [type=reset]:not(:disabled),
    [type=submit]:not(:disabled) {
        cursor: pointer;
    }

::-moz-focus-inner {
    padding: 0;
    border-style: none;
}

textarea {
    resize: vertical;
}

fieldset {
    min-width: 0;
    padding: 0;
    margin: 0;
    border: 0;
}

legend {
    float: left;
    width: 100%;
    padding: 0;
    margin-bottom: 0.5rem;
    font-size: calc(1.275rem + 0.3vw);
    line-height: inherit;
}

@media (min-width: 1200px) {
    legend {
        font-size: 1.5rem;
    }
}

legend + * {
    clear: left;
}

::-webkit-datetime-edit-fields-wrapper,
::-webkit-datetime-edit-text,
::-webkit-datetime-edit-minute,
::-webkit-datetime-edit-hour-field,
::-webkit-datetime-edit-day-field,
::-webkit-datetime-edit-month-field,
::-webkit-datetime-edit-year-field {
    padding: 0;
}

::-webkit-inner-spin-button {
    height: auto;
}

[type=search] {
    outline-offset: -2px;
    -webkit-appearance: textfield;
}

/* rtl:raw:
[type="tel"],
[type="url"],
[type="email"],
[type="number"] {
  direction: ltr;
}
*/
::-webkit-search-decoration {
    -webkit-appearance: none;
}

::-webkit-color-swatch-wrapper {
    padding: 0;
}

::-webkit-file-upload-button {
    font: inherit;
    -webkit-appearance: button;
}

::file-selector-button {
    font: inherit;
    -webkit-appearance: button;
}

output {
    display: inline-block;
}

iframe {
    border: 0;
}

summary {
    display: list-item;
    cursor: pointer;
}

progress {
    vertical-align: baseline;
}

[hidden] {
    display: none !important;
}

/*# sourceMappingURL=fluentui-reboot.css.map */

[vnbaaij]

Step 2) Add Class and Style parameters to FluentComponentBase
To gain more flexibility in styling components (either through css or inline styling) we add these parameters and supply code to make them maintainable from code. In MudBlazor they are re-using Ed Charbenau's BlazorComponentUtilities and I'm thinking of doing the same.
Regarding the name of the class parameter. MudBlazor uses 'Class'. DevExpress, Syncfusion and Blazor itself uses both (internal it is 'CssClass', in QuickGrid it is 'Class'). My proposal would be to go with 'Class'. There is ambiguity with class keyword in C# but works perfectly good when capitalized. Besides we are also using 'Style' and not 'CssStyle'

Again, looking for feedback, remarks, suggestions...

[lonix1]

Either way would be good. Personally I've used mudblazor's Class and it wasn't confusing, and felt "natural".

[vnbaaij]

Seems like we don't need the CSS/Style Builder classes just yet. Removed them from the list for now.

[vnbaaij]

Step 3) Add layout and utilities components
At the moment I'm thinking of adding the following components:

• FluentSpacer
• FluentStack or FluentStackPanel
• FluentLayout
• FluentMainLayout
• FluentBody or FluentBodyContent
• FluentHeader
• FluentNavMenu (with FluentNavGroup and FluentNavLink; alternative fluent-tree implementations)
• FluentDrawer
• ...

[lonix1]

approval process and other governance around creating new repos

Having non-official but compatible components and extras in any repo/org is exciting, whether official or unofficial / incubation /labs / experimental. Unike you, we users aren't concerned about the legalities and separations involved, as we have different needs. So whatever you ultimately decide will be appreciated!

But I just want to know, for something that is so different from the official FAST design - like a layout/grid system - where would that go? Would you have it in an incubation repo in the same organisation? I assumed from previous comments that you guys don't want it anywhere near the official bits... but if you're willing to put it in an incubation repo, that would be awesome.

(Sorry for belaboring the point about the grid, but really that's the sticking point here. There's no point discussing the "easy" stuff, it's the non-FAST stuff that is interesting. Without some basics that are expected from any modern spa/gui library, adoption will be difficult. It was for us.)

[vnbaaij]

@Ionix1 FUWCFB = Fluent UI Web Components for Blazor

[EisenbergEffect]

To clarify, there is no official FAST design. Rather, FAST is a collection of libraries that enables building web components, design systems, and apps based on modern web standards. We don't ship our own design system, much like there is no Angular design system or React design system. Rather, design systems like Fluent UI are implemented by using FAST's capabilities. And this Blazor library wraps those Fluent UI Web Components to make them (hopefully) easier to use for Blazor devs.

Now, Microsoft does have a design language called Fluent UI. And since the Blazor package we ship is in support of Microsoft's Fluent UI effort, we need to make sure that what we ship in that package aligns with Fluent.

For layout, because it isn't really design system specific, I think we have some leeway. What I'd like to do is put it somewhere other than our Fluent package, so that it's clear it's not Fluent. And I'd like to run it as an incubation so we can just be careful about our time/effort as well as our confidence in the final product. I think this will let us deliver something for the community while continuing to align with "official" Microsoft and protecting our contributors in terms of their commitment/investment.

[lonix1]

Thanks for the explanation.

While you guys are debating how to go forward, please take our use case into consideration... it's probably very common.

We are building office365 / teams addons - aspnet backend server and frontend app (blazor). We want our apps to be as closely aligned to Microsoft's "look and feel". We were excited to find this library, obviously.

But there is some friction due to "missing" bits and pieces that we get out of the box in other libraries (mudblazor, bootstrap, etc.) So the question is do we use those ones or this one - in both cases it's not ideal.

Hopefully in the future it will be a no-brainer for users like us to just install this library and get going. I think it will be great. What already exists is of a very high quality and we're enjoying using it so far!

[EisenbergEffect]

Great feedback. I've really enjoyed this conversation @lonix1.

To your point, what I can share is that there is an awful large amount of work going into Fluent "alignment" right now. So, I hope, from the m365 perspective, all these little issues will eventually be a thing of the past and you will be able to just drop this library in and go. Right now we're working through how to get from point A to point B; things are progressing well but it can take a while sometimes. I thank you for your patience.

[vnbaaij]

Please take a look at https://baaijte.net/blog/microsoft-fast-components-fluentui-2.0/ to see what we have added to the library and demo environment to meet these whishes.

[lonix1]

Very nice, well done for all the hard work!