Use angular material stylesheets

[miguelcobain]

While I was doing some refactoring, I stumbled upon outdated styles from ember-paper.
Many components depend on each other.

In fact, a huge part of this project is about maintaining styles. I think we should shift a bit our paradigm: use angular material stylesheets directly. They're directly from google. All that's missing would be to port angular logic to ember logic, which isn't very straightforward either.

We're already doing that on a copy paste basis, but things get outdated pretty easily, and the real problem is versioning. If we're not careful we may be using styles from different angular versions in ember-paper. They're not necessarily compatible.

So I'm asking both if you agree on using "whitelisted" stylesheets from angular-material and for a way to do it.

There's one problem though, angular material stylesheets aren't strict scss. They have their text replacement rules or whatever for theming.

Would it be possible to:

• include angular material as a bower dependency - this would assure that we're using styles from the same angular material version
• pass its scss files through a filter (mainly for text replacement, e.g replace '{{accent-color}}' with color($accent-color-palette) or whatever our color strategy is). We may want to skip some files, so we should be able to pick with stylesheets we want
• import the resulting stylesheet files

Maybe @stefanpenner can give us some guidelines on the approach we should use for this, or if this is even possible at all within ember-cli.

Also, @mike1o1 can you briefly describe angular material theming capabilities (if your into that)? Maybe we can mimic that as well.

[stefanpenner]

@miguelcobain sounds possible, one would just need to insert the filter you described before the css was processed. Likely something that can be done via treeFor('styles')

[mike1o1]

I think this is a good long term approach, and should be evaluated again once the Angular Material project hits 1.0. For now, I feel like there is too much intwined with their stylesheets and components. A lot of times there are tweaks to stylesheets and components - I'd hate to miss out on the component functionality changes just because we're linking to their stylesheets. We'd need to make the component changes as well. What I do with ember-material-design is try and set aside an hour or two on weekends or a week night when my fiance works late and go through their commit log and update the addon commit by commit. It's definitely not the most glamorous work, but hopefully once 1.0 hits it won't be needed as much (or maybe they'll have moved on to Angular 2 :/).

Theming is done in the client and it's all JavaScript - it's not 100% part of their build process, and therefore any themes won't be included if we just link directly to their .scss/.css files. I'm not happy with the theming in ember-material-design or ember-paper, as we don't have the flexibility that their approach has. I've strongly considered just porting their theming implementation over directly, but I don't have the bandwidth.

As part of their build process, they compile the *.theme.scss files to a string, and include that string as an angular constant injected into the material.core module. From there, they parse the string on the client based on the theming rules that the user setup doing simple regex replacements, and create a style tag for each theme the user setup. The nice thing about this approach is that the consumer doesn't have to muck around with .scss if they aren't familiar with it, and it makes it a lot easier to setup multiple themes (something both EMD and EP don't support).

My approach would be to have something in the EMD or EP build process to process the .theme.scss files through sass and autoprefixer files and inject it as a meta tag or something, and then create an initializer for each theme the user wants to create. This is similar to how the angular material project does it, as they setup themes during configuration. I think this would take 2 solid weekends of work for me to implement, but I'd probably need some help with the build side of things and injecting as a meta tag (or whatever). Fortunately most of the theming setup isn't angular specific so won't be too difficult to port.

[miguelcobain]

Thank you for your input. However I remind you that we would be linking to
their styles of a specific version of angular material. In other words, we
would just bump angular material bower version if we're sure that we didn't
miss component functionality that was added in AM.
We would still be in a safe place as long as there is versioning.

A sáb, 4/07/2015, 03:55, Mike Wilson [email protected] escreveu:

I think this is a good long term approach, and should be evaluated again
once the Angular Material project hits 1.0. For now, I feel like there is
too much intwined with their stylesheets and components. A lot of times
there are tweaks to stylesheets and components - I'd hate to miss out on
the component functionality changes just because we're linking to their
stylesheets. We'd need to make the component changes as well. What I do
with ember-material-design is try and set aside an hour or two on weekends
or a week night when my fiance works late and go through their commit log
and update the addon commit by commit. It's definitely not the most
glamorous work, but hopefully once 1.0 hits it won't be needed as much (or
maybe they'll have moved on to Angular 2 :/).

Theming is done in the client and it's all JavaScript - it's not 100% part
of their build process, and therefore any themes won't be included if we
just link directly to their .scss/.css files. I'm not happy with the
theming in ember-material-design or ember-paper, as we don't have the
flexibility that their approach has. I've strongly considered just porting
their theming implementation over directly, but I don't have the bandwidth.

As part of their build process, they compile the *.theme.scss files to a
string, and include that string as an angular constant injected into the
material.core module. From there, they parse the string on the client
based on the theming rules that the user setup doing simple regex
replacements, and create a style tag for each theme the user setup. The
nice thing about this approach is that the consumer doesn't have to muck
around with .scss if they aren't familiar with it, and it makes it a lot
easier to setup multiple themes (something both EMD and EP don't support).

My approach would be to have something in the EMD or EP build process to
process the .theme.scss files through sass and autoprefixer files and
inject it as a meta tag or something, and then create an initializer for
each theme the user wants to create. This is similar to how the angular
material project does it, as they setup themes during configuration. I
think this would take 2 solid weekends of work for me to implement, but I'd
probably need some help with the build side of things and injecting as a
meta tag (or whatever). Fortunately most of the theming setup isn't angular
specific so won't be too difficult to port.

—
Reply to this email directly or view it on GitHub
#119 (comment)
.

[bj-mcduck]

That makes sense.

[peec]

I vote for using angular material directly as a dependency, right now we copy & paste scss and since components might rely on each other it will be easier to maintain.

[elwayman02]

👍 having better theming is a big issue, since right now ember-paper is littered with rgba and hex values for colors instead of having them gathered in a more consolidated location as variables.

[miguelcobain]

closed by d001c4a