Styling - a big challenge these days

I don’t wanna derail the thread too much, but I’m curious what made you choose Semantic UI over the other options. I used to use Bootstrap, though only for the grid. I don’t like their components. I just recently switched to Material UI. I love the fact that it’s all React components! Though it sometimes is finicky and requires some hacking in those cases. Semantic UI looks really clean too, though now I think I’m spoiled having all the UI elements as React components.

2 Likes

This is interesting @awatson1978.

Hm, I find myself not that excited about ‘surviving CSS’, I would prefer to use styles in a way that my work can thrive.

Any clue how to do this, what are my options. It sounds like SASS/SCSS is the best option? Could you point me to any resource about how to use nested CSS classes? I’m an idiot when it comes to css.

Cool, good to know

Sounds fun, maybe useful, I will try it out!

Hm, this sounds like a flaw of these tools. Seems like if mixins were implemented in JS, they could be pretty useful. DRY, right?

…I always wonder why I need CSS file that’s 10K or 30K lines long… when I can write a pretty awesome app in under 1K lines of JS. This is extra crap the browser has to deal with and parse, there is some cost to downloading and parsing especially on mobile.

I don’t think this is derailing the conversation, this is the kind of things that I’d like to know too… I will derail the conversation some more. Semantic UI seems ok but terribly bloated, I like simplicity.

About Material UI, how easy have you found it to customize? I tried to use it once or twice, but all these frameworks occur to me like a rats nest of too much stuff, way too complex. I would love to find or come up with a simpler/more minimalist solution.

Not easy at all. What they really need (but I’m sure no one on the team has time to build) is a site that shows every component possible, and then has a sidebar that lets you alter the color variables (primaryColor1, primaryColor2, etc) and lets you see how it affects the components. Then hit save, and boom, you get your JS CSS printed out for you.

If that existed, theming would be a lot easier. Right now it’s guesswork trying to figure out how changing a color variable will affect the components. Plus, some of the stylings are weird… I don’t like how the Badge has its notification count so far away from the icon. If you put it in a toolbar, it messes up the layout. The Slider is pretty terrible on touch devices too. When I have time, I plan on contributing to the project and hopefully cleaning up some of these things, because I believe in the project and I really like that it’s so integrated with React!

3 Likes

Wow @ffxsam, that kind of sounds like putting lipstick on a pig!

Why wouldn’t you just design the thing so that there are logical ways to pass down the correct parameters to the component without generating a bunch of useless code?

Apparently nobody has thought through the problem before starting to write code.

It’s pretty simple. Just make sure your precompiler supports nested class syntax (most all of them do).

/* nested class have hierarchical structure, similar to HTML*/
#aboutPage{
  padding-top: 50px;

  .logo{
    top: 100px;
    height: 100px;
  }
  .customTitle{
    top: 200px;
  }
}

/* compiles to these classes */
#aboutPage{
  padding-top: 50px;
}
#aboutPage .logo{
  top: 100px;
  height: 100px;
}
#aboutPage .customTitle{
  top: 200px;
}

To make this work, your template needs a wrapper div with the same name as the template. Also, notice how the nested CSS class hierarchy mirrors the HTML document object hierarchy:

<template name="aboutPage">
  <div id="aboutPage">
    <img class="logo">
    <h2 class="customTitle">
  </div>
</template>

With that methodology, CSS styles don’t leak outside their component, and everything becomes much easier to manage and debug. IMHO, it’s the killer feature of CSS precompilers. All the other stuff they provide is useful, but has pros/cons (e.g. functions, mixins, etc. are usually brittle and resistant to moving files around and refactoring).

And yes, I’ve been finding that adding mixins via JS has been pretty awesome. When taken to it’s logical conclusion, implementing all the mixin functions and variables in JS basically amounts to implementing a Theme object.

2 Likes

Well, you can pass styles and colors into Material UI components. Though I’d prefer to theme everything instead, as it would probably be cleaner. But no one has bothered to document how all the different theme color variables affect the components.

Ok, now I’m confused. Why would it be cleaner to generate a bunch of code/CSS than to do it the functional, React way?

From my experience I’ve decided to avoid css frameworks completely (with the exception of a flex box grid abstraction). Frameworks are bloated, opinionated and lead you to make compromises.

Instead i use sass with a mix of custom global and component level style definitions. So far so good.

Although now that I’m experimenting with react … I’m still making my mind up about inline js styling.

2 Likes

You can see how a palette from a base theme is used to create a MUI theme when you call getMuiTheme() here.

If you don’t like what getMuiTheme does to some components you can just call it in a wrapper function and modify the theme before passing as part of the react context.

You’re right though, it is a pain to look at the base theme, mui theme, and the component file to determine how the base theme styles a component.

Hi,
Have you got a good read about those two points ? Thanks!

To contribute to the topic, I use nested css with separate file for each “component” along with postcss with cssnext, autoprefixer, and all. I keep some css files for common classes that I use everywhere and that I try to document in a style guide. That´s why my css files are packed in some kind of a pattern library and the style.scss file with all the import get exported to meteor. I think this is not ideal, it will be better to have close to the html and js file. I also think of writing a separate file for each component media query.

Meteor Cookbook - Animations

2 Likes

I think it’s a set of trade-offs. Sometimes they can be bloated, and are often opinionated, but would you rather spend the time building a bunch of UI components like modals, forms, etc from scratch? Depends on how quickly you need to get something done I suppose. :smiley:

2 Likes

Well, depending on how simple you want, maybe check out Skeleton (and it’s associated Atmosphere package). It’s about as simple as you can get.

Yeah it’s definitely a trade off but after trying bootstrap foundation and
materialize I do prefer it. You’ll have more control and most probably
smaller payloads. When I need something like a modal, there are plenty to
choose from on github. Or you can write your own like I’ve done with blaze.

It would be awesome if we could use CSS Modules and CSS imports in JS components. So we could do something like: https://github.com/css-modules/css-modules/blob/master/examples/theming.md

There is even something like: https://github.com/css-modules/css-modules-require-hook but it needs Node.js v0.12.x (or higher).

I would like to see it in Meteor 1.3 or maybe 1.3.1 :wink:

(There is a Meteor package but it is replacement for ‘ecmascript’ package and it operates on .mss https://atmospherejs.com/nathantreid/css-modules , maybe with Meteor 1.3 it could be done better?)

1 Like

Can you elaborate on how inlining css effects what can be GPU optimized?

1 Like

That’s a little unkind. The whole project is maintained by a very small number of volunteer contributors, and they’re working flat-out to fix bugs, refactor old code, overhaul the internals, including theming, simplify and better document the API, implement new components, and support users. Many of whom don’t read the docs first.

http://www.material-ui.com/#/components/badge

 <Badge badgeStyle={{top: 12, right: 12}} >

Ahem! :wink:

1 Like

Cheater, it have to be “the correct way” by default and from everybody’s perspective, or it does not count :smiley:

My vote will also go for “CSS modules” way for kinda auto-BEM.
Standard BEM is nice, but kinda annoying to write.
It needs some way how to define kinda component/file wide namespace, or block scoped.

And when we are pushing small reusable components, inline styles can feel also OK.

I didn’t mean it as a complaint at all, just stating very matter-of-factly. I’d love to build something like I described above (a theming site) when I get the time, and plan on making my own contributions to Material UI.