Live data from Hacker News

A modern responsive front-end framework based on Material Design

materializecss.com

71–80 of 96 posts

Re: A modern responsive front-end framework based on Material Design

#72
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.

Re: A modern responsive front-end framework based on Material Design

#73
post #59

Earlier quoted context omitted.

I'll take the opposite side - pastel colors are horrible and disgusting. I can't imagine why anyone would like pastel colors.

Ugh, I don't understand you color fanatics. I like my user interfaces black and white - you know, like on an amber monitor. /s

Your comment obviously wasn't serious, but the color choices in most designs these days are pretty arbitrary. A good design should work in b/w for accessibility reasons alone.

Re: A modern responsive front-end framework based on Material Design

#74
post #66

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…

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

Let me know what you think!

Re: A modern responsive front-end framework based on Material Design

#76

"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?

In every real project I've done, where a nested templating system is used to generate the markup and templates might contain javascript code, I always load some javascript libraries in the head. Typically that's Modernizr and jQuery, and if I'm using them jQuery Validate and Microsoft's jQuery Unobtrusive Validation.

This lets my templates contain initialization functions inside of $(document).ready(function() {...}); calls without running into a "$ not defined" error.

The alternative would be to somehow bubble up from my templates a list of initialization functions to call, or to have every page load run through a bunch of tests to find things that need to be initialized. I think the tradeoff of loading jQuery early is worth it, especially since I usually load it from Google's CDN so it's probably cached.

Re: A modern responsive front-end framework based on Material Design

#77
post #2

Looks great. However, I've never really understood this sort of approach: Alvin Alvin Alvin Alvin 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...

My personal experience is:

Using element names instead of class names can be problematic. In some frameworks you may need to use a different element or an element that wraps another element to achieve certain functionality.

Some use generic names like "button large" as class names, but, again in my personal experience, it often causes problems. You might have other elements that need to be "large" and may need to be inside a button - but which "large" do you mean.

So to keep things predictable, I've adopted the following practices:

- Always namespace components.

- Always ensure that selectors work even if the child has a wrapper around it.

- Whenever possible use classnames instead of element names.

And to ensure I don't get tendonitis (not sure if everyone agrees with this):

- If possible provide a shorthand for at least the most used components (i.e. "col"/"col-i" for "collection"/"collection-item"

Re: A modern responsive front-end framework based on Material Design

#78
post #64

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.…

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.

Re: A modern responsive front-end framework based on Material Design

#79
post #61

Earlier quoted context omitted.

Performance is penalized too. Since CSS rules are parsed from right to left and you have probably a lot of "li" tags, the rule would be very inefficient. Of course this doesn't matter in small pages.

It does not matter in any real life pages.

It did for Trello, to name an example (search for speed in http://blog.trello.com/refining-the-way-we-structure-our-css...).
Post reply on HN