The problem with all of these responsive grid systems is that they are opinionated about how a component responds.
Responsiveness is not a document level problem, it's a component level problem and each component has it's own concerns. One component might keep the 2up grid from desktop to mobile, another might collapse to single column half way, and so on. Having generic desktop and mobile class names ala bootstrap doesn't solve this. You end up with components that have to collapse at pre-defined points and a massive amount of class soup on your containers.
This is related to the fact that components respond to the window width and not their parent containers size. Components are very dumb right now, we need smart components that understand their surroundings beyond the window. Then we will have truly portable components!
The problem with all of these responsive grid systems is that it's so easy to do a grid in plain CSS with flexbox and media queries that they're close to zero added value in almost all cases.
It's sad really. Table-based layouts have been considered bad practice for years but CSS is only just now becoming a superset. That is if you're lucky enough to be free of old browsers. If you want everything to "just work" tables are still the practical choice to this day. Kudos to PG for sticking to what he learned in the 90's when he built HN.
Yes! It's sad that table-based layouts became "bad practice". Generally they're a lot simpler to understand than the mess of CSS and bizarrely named divs we have today.
An important reason that table based layouts became obsolete in HTML is because the way table cells are rendered is not the same as how `div`s are rendered. It's shockingly difficult to get a table cell to keep a consistent size. This makes some sense if you're using it as a simple data container, but doesn't work at all if you're trying to use it as a generic content container the way we use `div`s
Also, if by "bizarrely named divs" you mean things like "section", "article", "header", "footer", etc., I have to disagree; I think these are a huge improvement in terms of readability and allowing a developer to communicate the intended purpose and structure of the code, and they offer significant advantages in accessibility as well. You ask me, the semantic web is a wonderful thing
I think part of the reason tables became considered "bad" was that back at that time most web pages were built by interspersed HTML and ASP or PHP code and getting all the TR and TD tags balanced especially with rowspans or colspans thrown in quickly became a mess. Every page was a standalone thing also, it was much less common to see templating systems used to establish the overall structure of the site. So if you ever got the assignment to "reskin" a website, it was a huge amount of very tedious work making repeated similar changes to all the tables and other markup on every page.
Today we have much better ways to create an overall layout and separate markup from content. Using tables today would be a lot less of a problem than it was when they were decreed to be "bad."
From what I could tell, it is because HTML tables have a specific structural meaning, which is among other things used by screen readers. So if used properly, a person who needs a screen reader could reliably have the contents of a table read to them, but if it's used for layout the result is useless. There seems to be enough people conscious of this that use of tables for layout has always been frowned on. Now there are better hints for screen readers, ,but tables are still useful for screen readers "out of the box."
In any case, tables are not nearly as flexible as a true responsive layout.
Yeah a huge part of this too was, for whatever reason, old search engines not being able to index what was inside of tables. I imagine it's not even like that anymore.
> Components are very dumb right now, we need smart components that understand their surroundings beyond the window. Then we will have truly portable components!
This is the iceberg problem. Component based programming has been around since probably the 60's. The easy part is making components. The hard part is making them (and this is the Holy Grail), portable. Pipes and Filters in the Unix OS is a simple example of one form of component development that actually works well.
This is what I feel is missing from web components. Some sort of generic api for components to reason about their immediate environment. Similar to the Unix OS pipes and filter api that means every program understands how to get some information about the context that it is being run in.
It's not difficult to imagine a calendar component that needs to visually display vastly differently depending on how much space it's parent gives it. Currently there is no generic way to solve this.
> It's not difficult to imagine a calendar component that needs to visually display vastly differently depending on how much space it's parent gives it. Currently there is no generic way to solve this.
Maybe I'm being naive here, but isn't this solved really by getting the width of a block level element rendered by the Calendar component?
Yeah it does mean you need to get the width and then render everything else, but it's doable.
I think a lot of these grid systems and layout libraries are overkill, and in turn, make the designs they are being used for, more complicated than they need to be.
Sure, it would be great to have a more component focused tool for FE development, but I think creating separate, fixed-width designs for tablet, phone, and desktop, with containers does the job fairly well. When the designs try to resize components for every use case you get more headache than it's worth.
I think the sole exception to this might be a full-blow library for Material Design since it's the only open standard we have right now, and it's very, very good.
> Responsiveness is not a document level problem, it's a component level problem and each component has it's own concerns.
Responsiveness is both (you build responsive pages/documents, but you can only reuse responsive components) and that's very much the issue: the tooling only supports responsive documents, but not responsive components.
One of the demos on the EQCSS website is a responsive grid where the breakpoints are based on the grids own width, not the width of the browser. This seems to be what the parent comment was talking about.
Hey rohitkrai03, good on you for creating something that is useful to you and putting it out there for others on the chance it is useful for them too. There are so many approaches to styling web content. I enjoy finding all the projects that get brought up (and beat up) in these threads. CSS is all about figuring out what works for you. Cheers.
Or, just write the display:flex you need, where you need it, as little as you actually need.. easy as pie unless your deadline was days-ago. This here might save you 10 minutes of manual work, at the expense of further code-base bloat, external-lib-dep accumulation, technical debt. OK fair game for your MVP-landing-page-A/B-split-test-shenanigans, granted.
Besides lack of good cross-browser support until recently, I think there are a few reasons why flexbox is still less popular than float- or margin-based grids:
- Steeper learning curve and less accessible than adding a class like "col-3" or "grid--1/2". The latter is almost self-explanatory.
- Requires an existing or new CSS class to bind the styles to. If it's a new class, you have to figure out a good name (which isn't always easy, naming things is hard).
- Requires editing CSS/Less/Sass, which (depending on your setup) can require waiting for it to compile. The wait time for compiling/bundling HTML is usually negligible.
- Traditional grid systems just work, and they work well enough for most things. When you have more important & interesting problems than a CSS grid system, there's a bias towards shipping what works and moving on.
That being said, flexbox is really powerful and a great tool for many things. But for many simple layouts, traditional grid systems can get the job done just fine without requiring much initial investment. On interdisciplinary teams where non-frontend devs can contribute, end-user simplicity is sometimes more important than language sophistication.
This is horrible, IMHO. Flex containers will layout the flex items, which are by definition its direct descendants. If by some reason [1] you get an extra DOM element between the flex container and the item you intend to layout, then you're in for a rewrite of the CSS and maybe some extra classes.
Yes! Flex box has lots going for it, but it breaks a "feature" that many web developers and framework developers have relied on since the earliest days: it being mostly harmless add an extra layer of element at a whim anywhere. One could argue this is a lousy feature (and I would agree). But lots of developers and lots of frameworks do it.
Adding elements just because (and, above it all, just for styling purposes) is wrong, of course. But having - or forcing - a tight coupling between structure (DOM) and layout/styling (CSS) is also wrong. IMHO, standards should try to move in the direction of decoupling; they did the opposite with Flexbox.
Anyway, the most present case for me is really Angular, where DOM elements are usually added because they are needed (and actually beneficial, if you like a component-based architecture and DRYness). Angular 1.x deprecated the `replace` option for element directives a few months ago (i.e. your <my-directive> will be in the DOM). Also, AFAIK, it never supported the `replace` behaviour in components (which are always elements). This means that, currently, Angular and Flexbox don't play very well together...
I would call technical debt to writing it as you go, since there are many small bugs and inconsistencies that (hopefully) are fixed by these libraries. Just a couple of random examples:
True, I thought it was widely know but there's a whole Flexbugs project [1] and that there are many Known Issues with flexbox [2]. Some with solution, some without them.
Please explain to me: What happened to the philosophy behind http://csszengarden.com ? Back when CSS needed evangelizing, the main selling point was "never touch the DOM for styling".
CSS Zen Garden was more close to art than to real world production work. It existed to draw a line between the old days' table-based layouts and what CSS brought to the table.
In those days CSS was perceived as not powerful and flexible enough, and capable only of boring boxy layouts (which is in fact the favoured aesthetic nowadays) and CSS Zen Garden and other similar sites existed to disprove that notion.
Also, some of the core ideals of the time, like obsessing over having 100% semantic markup and the ability to change styles without having to touch the markup turned out not to be that important.
And, lastly, if you look at the provided source in CSS Zen Garden you can see that it has a lot of DOM affordances like classes, IDs and even some extra markup to make sure that the CSS author had everything she needed to make his design work.
Nothing went wrong. The philosophy behind CSS Zen Garden is alive and well in some quarters, and in others it's not. It's the CSS world's version of EMACS vs VIM.
When you have 5 front-end developer working on and off on a project, you can't simply throw media queries around.
Hence the adding of classes. With classes based grid system, I can setup my grid (as the front-end guy) and have the back end guys simply add the right class and the website will stay responsive.
That being said, the classes are only there for the skeleton of the website. The rest of it is going to be done via the CSS itself.
Let's use Zurb's Foundation as an exemple. I can have the entire skeleton of the website done using the classes. This allow everyone to share the same base and this makes sure that the website will always be responsive.
When I need to do some extra styling on the element itself where classes would not make sense (and would break the philosophy behind good CSS), I simply thrown in @include grid-column(4); in my Sass code. This way, I have all the power of the class based grid but only in the CSS and not in the markup. (this is equal to doing class="row-4")
The appification of the web is what went "wrong". For non-app sites, a bloated DOM-grid is probably a bad choice (though there was a lot of interesting experimentation with Compass/Blueprint like a decade ago). For webapps, it may be a good choice.
Because IE 9 is still (unbelievably) a top 10 browser. But, it won't be for much longer, at which point I'll start converting. (https://www.w3counter.com/globalstats.php)
I created one grid system exactly like this [1] a couple of years ago as part of Picnic CSS [2].
However it was limiting in several factors, so I rewrote it from scratch as a flexbox solution, called it Flexpoint [3] and I love it. Now I need to integrate it back into Picnic.
For instance, can you change elements order? How do you account for an undetermined number of elements (same size, full width total)?
They should be filled up to the size of the tallest one if I'm not mistaken. Though so far I've only tried it with uniform elements so I don't know first hand.
Really nice, though these days flexbox should kill libraries for that. Also I hate when you have fixed break points. Sometimes you need elements to be visible hidden on different screen width and frameworks like this limit the ability to change the breakpoints.
Take as an example the smashing magazine [1] and count the breakpoints there
I've found https://milligram.github.io/ very nice. Sure, it's a bit more than a grid system (it uses flexbox) but it's very nice and doesn't take up much bandwidth.
I don't get the author's pain point. `col-md-12` looks like pretty self-explanatory class name (or `medium-12 columns` in foundation). I mean, you're already writing HTML where `img` means "Image" and `div` means "arbitrary container", so unless you don't understand (or don't care about) the value of a 12 columns grid I don't see what's so bad about bootstrap's column names. Especially if you're already OK with having presentational classes in your markup.
this is great. I really like how he breaks down the three types of grid systems out there. And "just memorize the cryptic codes like col-md-6 or whatever from their favourite CSS Framework like Bootstrap" is so true. I knew there had to be a better way and pills could be it. I starred it and forked it.
It's awkward at first, becomes second nature after you use Bootstrap for a while.
I guess a grid only framework makes sense if you only use the grids from the big frameworks, but it's not my use scenario since i use LOTS of stuff from Bootstrap .
Whilst 'three' is better than 'col-3', it's still based on a 12-column way of thinking. Try Avalanche (https://github.com/colourgarden/avalanche) for a grid system based on percentages or fractions (you choose) </plug>
It will never not be faster to roll your own based on the project needs. Aside from knowing how to use Bootstrap, I can appreciate the work on these CSS grid systems and frameworks but I don't see any need for most of them. Do people use Blueprint anymore?
Well, usually grid systems are used for responsiveness and the ability to have a specific design for individual screen sizes. As far as I read through the docs, unlike bootstrap, this library does not allow to target specific screen sizes like xs,md,lg, etc...
This framework is getting posted everywhere and it's not even really responsive. I saw this junk on Reddit too. People were defending it saying it had mobile and desktop sizes. What?
Pardon my cynicism but the adjective 'simple' has been abused to the point where it repels me when I find it in framework descriptions.
Calling something 'simple' is a subjective statement which is a meaningless waste of words, especially from the author of the framework. Of course you perceive your own framework as simple. Nobody designs a framework to intentionally make something more complicated.
The word 'simple' is repeated 8 times in the first 2 paragraphs of your description. It reads like something thrown together in a thoughtless hurry. Your framework could be wonderful but it leaves the reader wondering if the code has the same level of investment as the description.
As Rich Hickey argues[1], 'simple' can be an objective statement. Though I agree that without an explanation of what exactly makes this library 'simple', the better word may be 'easy'.
I created SlenderGrid [1] a while ago which I believe is really all you need. It's 16 lines of code and you define your OWN actual semantic grid classes.
At NextBigSound.com, we've found that a nestable fractional-based grid is generally easier, faster, and more flexible to work with than traditional N-column grids:
Adding my own me-too onto the pile of "I made something just like this:" https://github.com/secondparty/arrange — I built it out of curiosity, and have used it in my projects, (shrug emoji). These types of projects are fun.
Wrote this [0] more than a year ago, it generates a tiny CSS grid template using attribute selectors. Should work with any amount of columns. Might be useful for someone here.
Honestly, I see one~three of these simple, responsive, lightweight CSS frameworks every week on HN. I wonder how many people actually get to use these new shiny frameworks over the reputable ones. I personally use bootstrap, and will try foundation next, but none of these new ones.
One difference from bootstrap would be it handles desktop and tablets using fluid layout instead of breakpoints. The only breakpoint in the grid is for mobile.
a css grid for humans... First thought flexbox for distributing people waiting for the subway.
On a more serious tought... the great thing about bootstrap whille I admit is sometimes a bit messy is the fact that you can use different sizes for different breakpoints which is something this method apparently does not allow.
Responsiveness is not a document level problem, it's a component level problem and each component has it's own concerns. One component might keep the 2up grid from desktop to mobile, another might collapse to single column half way, and so on. Having generic desktop and mobile class names ala bootstrap doesn't solve this. You end up with components that have to collapse at pre-defined points and a massive amount of class soup on your containers.
This is related to the fact that components respond to the window width and not their parent containers size. Components are very dumb right now, we need smart components that understand their surroundings beyond the window. Then we will have truly portable components!