upfluence / oss

A frontend framework for the awesome people from Upfluence (Living Styleguide @ upfluence/oss-components)

OSS (117)

Deprecated and Archived

After discussions with the Upfluence frontend team, this projects has been deprecated and its files have been moved into the upfluence/oss-components project (Pull Request: upfluence/oss-components#200).

There reasons are that we have noticed that the split between this package (holding agnostic, Less CSS + assets only code) and the @upfluence/oss-components package (holding more Ember-specific code) is not viable anymore and brings some pain point that are a bit annoying:

• having to open PRs in two projects for the same tasks
• Yarn links w/ @upfluence/oss that are not always straighforward (even more if you link this package to another running app)
• Documentation being split between two packages

oss's Issues

Smaller Inputs — Comes handy for:

• Number inputs
• Selects with really small content

Dropdown Buttons

Choose Primary and a Secondary Buttons, and roll with it

Request for Comment

This is more a discussion than an issue for choosing a Primary Button and a Secondary Button between our solid Orange and Purple buttons.

By "solid" I mean buttons with background colors, in contrast with Ghost buttons which are buttons with transparent background color.

Until now, I have used upf-btn--orange and upf-btn--purple without real distinction, but as we are rolling out OSS in more projects, I think it might be good to define a upf-btn--primary and a upf-btn--secondary. Also, I don't see any use case for other types of buttons; except for Destructive Actions (which go with the upf-feedback-error color).

Only thing is, if we choose one color for the Primary Button (say, Orange) we may have to drop the other as one pattern I see in most websites and known Design Systems is that the Secondary Button is usually a Ghost one.

Would like to have your comments on that :)

Also related to buttons, what do you think of introducing Buttons modifers for:

• Link Buttons (buttons looking like normal text — removed background, borders, and maybe padding)
• Icon buttons (we don't have the case yet, but a button reduced to a simple Icon)
• Dropdown buttons (A button opening a drodpown, as seen in the Summernote's Columns dropdown)

Radio Buttons

Button mixin

What do you think about having a mixin to generate pimary button and reversed ones instead of hard code each colored buttons ?

https://github.com/upfluence/oss/blob/master/less/base/_buttons.less#L27

Little rethinking of the directory structure

Request for Comment: Rethink the files structures into a more accurate directory structure.

Actually, the current state is not bad at all. It's really organized, in fact. But we have some things that cohabit in the same folder while they should be split, notably in the base directory which holds both Core stylesheets / settings and some components we have.

That's why, I propose the following structure (highly inspired by http://thesassway.com/beginner/how-to-structure-a-sass-project)

less/
├── upfluence-oss.less
├── core/
│   ├── _all.less
│   ├── _colors.less
│   └── _fonts.less
│   ├── _typography.less
│   ├── _variables.less
├── base/
│   ├── _all.less
│   ├── _alerts.less
│   ├── _buttons.less
│   ├── _checkboxes.less
│   ├── _icons.less
│   ├── _inputs.less
│   ├── _links.less
│   ├── _navs.less
│   ├── _tags.less
│   └── _tables.less
├── mixins/
│   ├── _all.less
│   └── _progress-radials.less
├── vendor/
│   ├── _all.less
│   ├── _data-tables.less
│   ├── _summernote.less
│   └── _modals.less
├── utilities/
│   ├── _all.less
│   ├── _grid.less
│   ├── _progress-radials.less
│   └── _typography.less

As you can see, first thing is, a Master Stylesheet upfluence-oss.less which is called by applications and imports the other styles. Second important thing is the _all.less in each directory which has the role of importing the related files. One effect of this is to have a pretty light Master Stylesheet.

The directories are then as follows:

• core: Contains all of the settings that are common to all apps, and are unchangeable
• base: The styles of our base components, which are all independent, but may depend on Core and Mixins.
• mixins: Well ... Mixins. Functions used for building things.
• vendor: Because we may depend on external resources or projects with UI, here are where we style them
• utilities: Some helper classes more likely to be used in the HTML and never in the CSS itself, as we can rely on the variables (also called design tokens) there. Helper classes are useful for Layouts, where instead of creating some CSS, you can directly go with some classes for setting margins, paddings, text colors, etc.

Thanks for reading ;) And would like to have your input on this :)

Handle Empty State on Data Tables

Checkboxes

Remove Summernote-branded footers

In Summernote editor's help, there is Summernote 0.8.2 · Project · Issues link.

We should delete it, except is just a p tag with no special class. So wether

• we just display: none the p if we are sure to not using any p in the modal footer.
• or we fork summernote, and just remove it.

As far as i am concerned, i think Solution 1 is a good one as i think we should only have Actions in the modal footer, and if we need explanatory text, an inline block like a span is more suitable anyway.

Select Input

Buttons w/ Icons

Badge — Usable as tags (in presentation and inside a text field)