
A modern responsive front-end framework based on Material Design - czottmann
http://materializecss.com/?
======
pan69
Looks great. However, I've never really understood this sort of approach:

    
    
        <ul class="collection">
          <li class="collection-item">Alvin</li>
          <li class="collection-item">Alvin</li>
          <li class="collection-item">Alvin</li>
          <li class="collection-item">Alvin</li>
        </ul>
    

Rather than assigning a "collection-item" class to each "li", would you not
simply style the "li" in the context of "collection"?

Bootstrap does a similar thing. Drives me nuts...

~~~
weego
It's so you don't clobber the underlying styles, otherwise you end up having
to reset on top of the frameworks resets and styles on the odd occasion you
want one of the collection li's to not have the styles.

I tend to agree with you, but I was heavily chastised by lead the front end
dev at my last gig for ever directly applying design styles to tag entities as
doing it as above is considered best practice at the moment (until the cycle
comes around again to another best practice).

~~~
bbx
Tell your lead front dev this approach isn't best practice at all.

You want one collection li's to not have the style? Use an alternative class
on the ul: "collection collection-alt".

You want nested li's to not inherit the styles? Use ".collection > li" in your
CSS.

In any case, assigning a class on _each_ li goes exactly against CSS best
practices, because it prevents taking advantage of the inheritance of property
values or of advanced selectors.

~~~
drinchev
I don't agree with this. Do you have some references about your statement.

I think the whole community went to separating the HTML tag names from the
styles and work only with class names [1].

If you start styling your tags directly it imminently increase the code debt
if you scale. Let's say you just want to add another element inside the tag. I
can give you example :

    
    
        <ul class='collection'><li></li></ul>
    
        .collection > li { color: red; }
    

and later on you add a anchor as a child you would need to force the specificy
to this element

    
    
        <ul class='collection'><li><a class='collection-link'></a></li></ul>
    
        .collection-link { color: blue; } // this will not work
        .collection > li .collection-link { color: blue; } // increased complexity
    

I would almost always advice against styling tag names, except when you are
doing css reset.

1: [https://en.bem.info/articles/side-effects-in-
css/](https://en.bem.info/articles/side-effects-in-css/)

~~~
brlewis
Thank you for pointing to the interesting BEM article.

As to this specific case, though, I was surprised to see your "this will not
work" comment and tested it. It worked:
[http://jsfiddle.net/brlewis/p0Locwgp/](http://jsfiddle.net/brlewis/p0Locwgp/)

~~~
drinchev
Yeah, sorry for the mistake. Yes, you are right in this case bad code would
look like :

    
    
        <ul class='collection'>
            <li>
              Is red
              <ul class='collection'>
                <li class='collection-special'>Should be blue</li>
              </ul>
            </li>
        </ul>
    
        
        .collection > li { color: red; }
        .collection-special { color: blue; }
    

[http://jsbin.com/tulenoxutu/1/edit?html,css,output](http://jsbin.com/tulenoxutu/1/edit?html,css,output)

------
spdustin
Many comments here use the phrase "best practices" as a means to shut down
opposing opinions or practices. That feels very wrong to me.

I am often heard saying (in classes, public presentations, etc.), "I don't
like the phrase 'best practice'. It implies that someone knows your
requirements better than you. So I don't use it. What's 'best' for me might
_suck_ for you. So I say: the best practice is, in many cases, simply to have
a practice that you and your team adhere to. One which meets your
requirements, now and foreseen."

Class-itis, div-itis, selector-nesting-itis... They all have a place in the
Real World.

~~~
tehchromic
i think this is a good perspective. at the some practices are clearly better
than others, and sometimes it is appropriate to say "best practice", because
in certain narrowly defined circumstances, there really is a best. but the
idea of team practice as the goal overall, and best practice as something that
is both personal and defined by external circumstance is solid.

------
V-2
Nice.

I'm not a Google fanboy, but I believe Material is the best visual language
for UI. Okay, there are different contexts, but it's best thought-through, and
most modern.

For instance, the use of animation is finally mature and at the same rich and
amplifying user experience (rather than being an eye-candy).

And I think it's very compatible with web apps.

A Material-ish popular chess site:
[http://en.lichess.org/](http://en.lichess.org/) (I'm in no way associated,
but a happy user)

~~~
Karunamon
What? Why? I personally find Material to be _hideous_ because of its color
abuse. It makes your UI look like an over-saturated Fischer-Price toy because
of all the bright primary colors everywhere, and that's before we get into the
lack of shadow and shading that seems to have infected "modern" design.

~~~
V-2

        and that's before we get into the lack of shadow
    

So we are not talking about the same thing, because Material uses shadows
extensively - certainly more so than older versions on Android. See
[https://developer.android.com/training/material/shadows-
clip...](https://developer.android.com/training/material/shadows-
clipping.html) and [http://www.google.com/design/spec/what-is-
material/objects-i...](http://www.google.com/design/spec/what-is-
material/objects-in-3d-space.html#objects-in-3d-space-elevation-android-) for
more details

~~~
Karunamon
It's supported, sure, but that doesn't mean it's going to be used by a lot of
people. I can't look it up right now, but I recall the official Google apps
look rather flat.

~~~
coke12
Shadows are a huge part of Material UI. They are used to create layering
between materials, which creates the illusion of depth and space.

------
bjterry
One thing I've noticed about Material Design is that most of the examples of
"best designs" have elements that are overlapping to some extent, but none of
the frameworks that I see make it easy to have overlapping elements with
defaults like grid layouts. I guess this isn't limited to just material design
though. It seems like many times overlapping visual elements is a subtle
indicator of a more professional design. Is there a solution to this problem
using CSS (I mean, I know how to overlap elements, but ideally there would be
something more structured or principled) or is it just doomed to be difficult?

~~~
DougWebb
I don't know any frameworks that do it, but it seems like you could have an
element that fits into the normal grid, and then inside that have an element
with a "breaks the grid" class applied which uses positioning raise it up and
make it overlap grid boundaries. You might need a special class on the parent
element too so you can prevent it from collapsing. This seems like something
that can be done in a fairly generic way.

~~~
bjterry
Yeah, I think in isolation stuff like that can be useful, but I feel like
there should be a better abstraction. I'm not enough of a designer to know
what that abstraction would be, and it seems like unexplored territory in CSS
frameworks now as far as I can tell.

------
bjrnjs
This looks really good, but the jQuery dependency makes it unfortunately less
interesting. It should be possible to have the jQuery dependency optional,
possibly only for legacy browser support.

~~~
biot
Agreed. I'd love to see an AngularJS port of this.
[https://material.angularjs.org](https://material.angularjs.org) seems to lack
some of the polish that this has.

~~~
sosuke
You might also like [http://ui.lumapps.com/](http://ui.lumapps.com/) then.
Rumor has it they are going to merge with that project eventually, or help
out.

------
Taig
This framework really impressed me when I first saw it and made me immediately
wanna use it. However, when I took a closer look I found a few things that
annoyed me:

\- The required HTML classes seemed kinda bloated and not semantic, but I
intended to fix that with Sass (well, officially they're on Less)

\- The input elements have weird animation on page load

\- When I just dropped in some basic elements, like an input field (with its
wrappers) nothing was really working. Things were not properly aligned and I
had to add all this container/row/column stuff, even though I just came for
the widgets

And last but not least what made me finally ditch it:

\- To display form validation errors, I have to supply a data-error attribute
which will then get rendered via css as a pseudo ::after to the label. That is
just weird. I then checked how it works without JavaScript and saw labels
overlapping placeholders.

It looks beautiful and I like how comprehensive it is. Really hope they'll
improve on some of these technical flaws.

~~~
andres
If you have a second check out MUI, which is a lightweight Material Design
framework that addresses some of your technical concerns:
[https://www.muicss.com](https://www.muicss.com)

Let me know what you think!

------
ozten
Overall, very cool project!

The menu animation is really slow on Firefox 37 on Mac OS X. The way pages
load and then more animations happen seems jarring. I've not used any material
based apps, so maybe I'm just not used to how things work.

------
they4kman
I'm using this library for a side project, whose main application is on
mobile. The layout system and styles are absolutely fantastic, but the library
falls short on forms.

Specifically, the range input uses a bubble on mouseover, which is not touch-
screen friendly. I've also had minor issues with the select widget not closing
after a selection is made. Additionally, the styles for labels is inconsistent
amongst different input types.

For everything else, this library is wonderful. The forms area could use some
polish.

------
smoe
I have started using it this week and really like it so far.

But there were two annoyances: Select elements (without .browser-default
class) are display:none and only shown, when initiated via javascript and
similarly checkboxes are put off screen and thus invisible if there's no
corresponding label (in my case the ones to select rows in a table).

Of course they were easily fixed. But it seems odd to me, to make unexpected
things like that the default behavior and – in the case of the selects – risk
making your site/app unusable if something goes wrong in your js just to avoid
a flash of unstyled content.

------
smrtinsert
Been playing with this project. The team is energetic and responsive,
submitted a bug and it was fixed literally in a few hours. They seem committed
to producing a top css framework, and of course its already gorgeous.

Great work.

------
ben_hall
I've been using it for the past six months, very powerful however it's
important to try and understand the underlying Google Material Design
guidelines otherwise elements can look out of place.

------
Raphmedia
I understand that the localisation of the text is done by JS, but god that
flicker on the menu annoys me. You should hide the menu and only display it
after the work has been done. Make it fade in or use some other material
design animation.

Edit: Why is this getting downvoted? This is a page made to present a
framework based on material design. Flickering instead of smoothly presenting
content is the anti-thesis of material design. If your demo page features a
big annoying issue, this is giving a very bad impression to your users.

------
zhte415
This looks really nice, and I will try it in a project. The responsiveness
doesn't seem to totally work though, perhaps an environment not tested.

Desktop:

I tried this by progressively shrinking my (desktop) browser window width to
around 200px, and the main content seemed to get stuffed under the left menu
with no responsive re-layout. [IE 11 on Windows 8.1].

Mobile:

I tried on my mobile (Android 4.4.2 480*800, Firefox - worked OK on default
browser) the design was definitely for mobile (no problem like the above)
apart from a ~20px white margin for the content on the right.

------
subpixel
This is impressive. I'll just have to override the form styling - personally I
find the material approach to forms to be a case of trying to fix something
that isn't broken.

------
northm
FWIW Some of us have built a nice ember.js wrapper around Materialize :)

[http://sgasser.github.io/ember-cli-
materialize](http://sgasser.github.io/ember-cli-materialize)
[https://github.com/sgasser/ember-cli-
materialize](https://github.com/sgasser/ember-cli-materialize)

------
starikovs
It's really cool. They use flexbox in some places! I don't understand why
bootstap hasn't do that yet.

~~~
roughcoder
If it was not for the need to have a fallback for IE9 I would be using flexbox
as standard, its a great feature with deals with so many of the common page
layout issues, including vertical align.

Bootstrap is quite web focused still so I guess it will come when support for
IE9 is not expected.

Though if you are doing an mobile/tablet only solution I would probably use
flexbox only now. As long as you keep to the 2012 spec, you should be ok.

[http://caniuse.com/#feat=flexbox](http://caniuse.com/#feat=flexbox)

Bring on the death of IE9!!

------
Animats
What a blast from the past! It's like looking at Flash sites from a decade
ago.

Compare [https://www.straphq.com/](https://www.straphq.com/) with Jennifer
Estep (author) 2009 [1]

Compare: [http://danielangel.media/](http://danielangel.media/) with Girbaud
(designer jeans, now defunct) 2005 [2] 2012[3]

[1]
[https://web.archive.org/web/20070408092333/http://www.jennif...](https://web.archive.org/web/20070408092333/http://www.jenniferestep.com/)

[2]
[https://web.archive.org/web/20051130094152/http://www.girbau...](https://web.archive.org/web/20051130094152/http://www.girbaud.com/eng/home.html)
[3]
[https://web.archive.org/web/20120207224137/http://www.girbau...](https://web.archive.org/web/20120207224137/http://www.girbaud.com/eng/)

------
ac360
This looks beautiful and it's wonderful to have more options than Bootstrap. I
also recommend Skeleton for anyone who wants a super minimal UI framework:
[https://github.com/dhg/Skeleton](https://github.com/dhg/Skeleton)

------
Tankenstein
Have been using this in production for about 4 months now, still has a lot of
quirks to iron out, but nothing you can't solve pretty fast. It's noticeably
(and obviously) less mature than bootstrap, but it's definitely worth a shot.
I quite recommend it.

------
tinussky
Bootstrap material design has something similar, although it is not matured
yet: [https://github.com/FezVrasta/bootstrap-material-
design](https://github.com/FezVrasta/bootstrap-material-design)

~~~
skore
The main issue with bootstrap-material is that this project is afflicted by
the dreaded "developer thinks he needs his own license" bug[0][1].

It's effectively CC BY-SA-NC which is rather bold when you consider that it's
adopting a design framework from Google for a css framework from Twitter.

[0] [https://github.com/FezVrasta/bootstrap-material-
design/blob/...](https://github.com/FezVrasta/bootstrap-material-
design/blob/master/LICENSE.md)

[1] [https://github.com/FezVrasta/bootstrap-material-
design/searc...](https://github.com/FezVrasta/bootstrap-material-
design/search?q=license&type=Issues)

~~~
hughstephens
+1. Saw this earlier, thought "looks good, I should use it for a project",
then read license and went "hahahahhaha no chance, not using a normal/standard
licence is way too high risk for me, no matter the project".

~~~
skore
If you follow the discussions on github, the latest consideration is to use
AGPL. For a CSS library. But fear not!

> There will be a commercial license as well. [0]

Well, if he goes that far, perhaps Google or Twitter lawyers will finally put
an end to this.

[0] [https://github.com/FezVrasta/bootstrap-material-
design/issue...](https://github.com/FezVrasta/bootstrap-material-
design/issues/410#issuecomment-73026734)

------
hbhakhra
"Generally it is wise to import javascript files at the end of the body to
reduce page load time."

Does this really make a difference? Even if it did, wouldn't it lead to seeing
a jump in the content after the CSS loads?

~~~
chucksmash
CSS files must be in the head element. JS files can be in either the head or
the body.

~~~
chucksmash
(Though IIRC all linked resources in the head are retrieved and processed
prior to rendering so unless your JS is crucial to correct display of the page
your preference should be to load JS as late as possible.)

------
pachydermic
Outstanding work - now I have to fight the temptation to go haywire with this
and try putting it everywhere... Looks great, though!

------
theVirginian
At first I was like "not another framework" but then I looked at it and this
is actually very nice.

------
rattray
This really does look incredible. I'm curious, how much heritage does it share
with Bootstrap?

------
drikerf
Looks awesome!

