So, I just wanna say I am absolutely, incredibly excited for this. I've loved the design of paper-elements, but I don't want to attempt integrating Polymer into my projects.
That being said, the use of BEM is a huge turn off. The markup for a simple card uses seventeen different classes, which is absolutely a nightmare to memorize. For comparison, a card from Materialize uses only five to seven classes (depending on the type of card).
However, since this is built in SASS, I assume you could use the extend keyword to combine a lot of the frequently used together classes into something more manageable. I haven't really used SASS in this way, so I'm not sure how that'd work.
Thanks for the feedback. We used BEM as we find it helps with the long-term maintainability of CSS/SASS codebases (there's also copy/paste support on all of our snippets). That said, if you find the use of BEM a turn-off, we welcome folks just taking our styles and adapting them to the naming scheme that makes most sense for them. Anything that helps.
I was overall impressed with what I saw, but when I saw the amount of classes required to achieve a simple button my jaw hit the ground at the level of commitment to BEM that bordered on what I'd consider absurd. To be fair, one could create their own snippets in an editor or in the case of React their own components to remove the need for all the boilerplate.
Now, a simple question is why would I want to use this over materializecss.com? I saw this from the FAQ:
>That said, the large, diverse number of implementations available are often quite liberal with their interpretation of the spec (not their fault!) and their opinions don’t always reflect what the Material Design team would consider ‘correct’.
It doesn't specifically point out what these guys are doing wrong and I personally can't see much that is being done differently. Are there any specific examples you can point me toward?
Why make a completely new project rather than working with the communities out there? If the spec is too liberal it should be updated and issues posted under these projects, so these projects can properly follow the spec, unless they specifically choose to deviate from it.
I'm curious, what's keeping you from trying Polymer? Its paper-elements are a very good implementation of Material Design, and the library is very light weight.
I've used Polymer in two projects now. It's simply not ready for real production use in my opinion. Too many issues overriding / styling their components (modal is awkward as hell to style the content) and it's simply too slow on start-up. Firefox literally freezes for many seconds to load several components (chrome doesn't but it's still not very fast).
I want web components to be a thing but Polymer is not the path forward in its current state.
Tried Polymer in a recent project for a basic social webapp last month. Within 2 days we found ourselves reading github issues about to-be-released customization options - options that we needed. The basic features are present alright, but the customization options aren't enough. Integrating modals with custom scrolling, wanting more than 5 options for spacing in the header - why give yourself a hard time when materialize and foundation are waiting with their arms open?
What's keeping me from using Polymer is that nobody can tell me if Web Components is going to last. In fact, I don't know what's even in the running anymore.
I was considering using Polymer. It worked great in Chrome. Then I tried using it in Firefox. It took a whole extra 1 second longer for Polymer to bootstrap itself on every page load, even when all assets were cached.
The blog post mentions speedups in Chrome and Safari. It does not mention Firefox.
This is actually not true. If you're using polymer with the full webcomponents.js polyfill, there's a known bug which breaks contenteditable execCommand calls (which means a lot of rich text editors break when you include the polyfill) [1]. The big heavy polyfill is also pretty slow on some browsers.
If you use the newer, lighter-weight shady-dom version of the polyfill, which is a lot more responsive on non-Chrome browsers and doesn't introduce the bug indicated in [1], you must do all DOM manipulation via polymer's local DOM api, in order to properly distribute dom elements.[2]
That means, if you want to use polymer, you cannot use angular or ember (for example). Specifically, DOM manipulation via those libraries ends up just using regular calls against element.appendChild, but those appended elements, if they are polymer elements, end up not properly working (event listeners don't attach and styling modifiers don't apply), because you didn't use polymer.dom to go via polymer's local dom API.
I found out about all of this the hard way, and now I have a webapp that works great on chrome, but users cannot use the rich text editor on anything except chrome. Which eliminates all iOS browsers entirely.
Great news that Google has started this library. This will help MD implementors like me.
"That said, the large, diverse number of implementations available are often quite liberal with their interpretation of the spec (not their fault!) and their opinions don’t always reflect what the Material Design team would consider ‘correct’."
Nevertheless I found a number of deviations from the design specs:
- Disabled buttons should not have a z level
- FAB ripples should originate from the center
- Icon buttons should have a touch area of at least 40px
- The same goes for slider knobs (at least 30px, already small)
On the website:
- The scrollable tabs on the site are scrolled just a couple of pixels per arrow click, instead of scrolled per tab
- Scroll areas should have -webkit-overflow-scrolling: touch, the current site is not scrollable on Mobile Safari
Great implementation of Material Design, the best I've seen so far. With other material design implementations [1] I ran into problems with checkboxes, sliders and other design choices, as well as problems on mobile. I appreciate the design choices made for MDL. It also runs smooth on mobile and the form elements like checkboxes and sliders work really nice.
Also, useful documentation along with codepen and easy clipboard buttons.
The ripples drive me crazy. Everytime I click a button my mind gets yanked into "what just went wrong?" because of the inconsistent nature of the ripples. Even though I know it's going to happen.
I dislike the abundance of color schemes with low saturation. This lower contrast, and I can imagine I'd have to turn up screen backlight to the max if I used it in sunlight.
I tried to use colleague's android and I found it unintuitive to use too (it wasn't obvious what elements you can interact with, and animations were annoying).
It's like saying in a Windows 10 thread you dislike the MetroUI/ModernUI design.
I prefer the material design in Android 5+. And I like the iOS 7+ design and Win7 Aero design. But I cannot live with the ModernUI of Win8/XboxOne - who choose those ugly colors?
I think we need to be careful of treating Material as an all encompassing solution. A lot of UI / UX folks I know are full on embracing it without taking a step back and seriously evaluating what problems it will and won't solve. I'm not saying I dislike it, I just think that there are different solutions for different situations. There is no silver bullet in our industry.
I was thinking the same. I initially thought based on the name I could pick a single component to use but its an entire framework, so it still suffers from bloat.
Yes, your solution is correct! I discovered this issue too late for launch, but I have a PR open with this.
It needs some extensive testing because there might be weird interactions with our layout component and all the different header modes it has (scrolling header, waterfall, etc). Working on it :)
Are you saying that's a good thing mainly for performance reasons?
I ask mainly because I vaguely remember someone running the numbers and finding out that js animations surprisingly beat CSS animations in a number of not-unrealistic scenarios.
(I know there's other reasons for favouring CSS animations)
Well, there's a slight distinction there. CSS animations are faster than jQuery which is important to remember. You can get the same boost from CSS Animations and even better performance if you're using GSAP (Green Sock Animation Platform) which uses Javascript to give the same benefits you see in CSS animations.
The results confirm what is widely reported on the web - CSS animations are significantly faster than jQuery. However, on most devices and browsers I tested, the JavaScript-based GSAP performed even better than CSS animations (by a wide margin in some cases, like on the Microsoft Surface RT GSAP was probably at least 5 times faster than the CSS transitions created by Zepto, and on the iPad 3 iOS7 transforms were significantly faster when animated with GSAP instead of CSS transitions)
If there are any animations at all you find are janky, could you file and we'll look at it soon? We've been performance testing on a wide range of devices/browsers but I'm certain there are plenty of areas we can improve on.
Lead for MDL here. Glad you like the idea, spoiler :) Thanks for catching the low contrast issue with the dashboard navigation - is it the same as https://github.com/google/material-design-lite/issues/739?. If not, would you mind filing an issue on the repo and we'll try to get that fixed up soon?
The Material Design Lite website (http://www.getmdl.io) breaks scroll behavior on mobile Safari.
If you're promoting a UI/UX product, you really shouldn't be bungling scrolling. Because if you can't get your own site working well, I'm not trusting your libraries on my site.
Ohh the BEM bummer. All those __ and -- makes my eye hurt. Write decent line of code in HTML file with BEM classes and it looks worse than inline styles (visually).
For the rest of library, I'm still trying and testing, but I don't think I'll be moving any of my main projects to this library because of BEM.
Thank you for this. I still feel like the Material Design implementation within Polymer is rough around the edges. Having issues with Firefox, for example, in terms of optimization and documentation is still very incomplete. Looking forward to working with both libraries, though!
Outstanding library. I like this version of material more than the other with polimer that's completeley flat.
There are some issues with scrolling in general and with scrolling with tooltips open on ios, but will follow and see if they eventually get around those.
Agreed. This project is awesome but without usable form elements (there's more to forms that text fields) this isn't really usable for anything a little more complex.
Is there a site using this does something useful and is better than a vanilla site? One that isn't a portfolio, resume, demo, or Material Design promotion? There's a site of "15 awesome examples"[1], but they're mostly promotions for material design, or very basic sites.
Wow, this is really nice, considering the fact that it's coming directly from Google. However, I really urge you to also try the Material Design theme from Semantic UI framework - I can tell you honestly that I haven't seen a framework as comprehensive and elegant as it. It's a pleasure to not having to write a custom class because what you want is already provided by the framework in some form or the other. Just my humble opinion.
Material Design Lite is the framework that is most true to MD guidelines and requires less code to implement. That being said, it is still early in development.
I tried Polymer for 6 months ago. It looked, but it was every early, and I was developing with Angular. Later, I switch to React which is a better fit for me than Angular. But I still wanted MD, so I tried both Material_UI and Materialize. Material-UI is a React implementation of MD and Materialize uses jQuery. I quickly discarded them.
MDL is as the name says very small and mostly built with CSS. You can customize the CSS classes easy, if you need to. I like BEM. It might be difficult for some to use, but long-term in large production apps, it is great for easy maintenance.
I encourage everyone that like MD to try it out and file issue requests for bugs or feature requests if you are missing something.
That being said, the use of BEM is a huge turn off. The markup for a simple card uses seventeen different classes, which is absolutely a nightmare to memorize. For comparison, a card from Materialize uses only five to seven classes (depending on the type of card).
However, since this is built in SASS, I assume you could use the extend keyword to combine a lot of the frequently used together classes into something more manageable. I haven't really used SASS in this way, so I'm not sure how that'd work.