Pills: A simple responsive CSS grid for humans
github.com
github.com
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!
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.
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.
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.
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.
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.
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."
In any case, tables are not nearly as flexible as a true responsive layout.
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
The concepts looks good, bu I haven't seen anyone recommending it .
Element query grid demo: http://elementqueries.com/demos/element-query-grid.html
- https://github.com/picnicss/picnic/issues/79
- https://github.com/picnicss/picnic/issues/64
So you can have a half-baked solution with 10 more minutes or use a tested and documented one and save 10 minutes.
Doesn't come close to replacing Bootstrap 3 (and similar) grid systems IMO.
- 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.
Also, this bug in Webkit is rather inconvenient: https://github.com/philipwalton/flexbugs/issues/115
[1] For instance, if you create an Angular element directive.
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...
What went wrong?
The devs convey intent to the stylers through classes.
I could go into more detail, but I think most people will concur.
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.
source: I got a design published in the garden a long time ago http://www.csszengarden.com/110/
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")
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)?
[1] http://web.archive.org/web/20150713011953/http://www.picnics...
Take as an example the smashing magazine [1] and count the breakpoints there
How are these DIV's with presentational class names any better?
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 .
.something
{
width: calc(33.33% - #{$spacing-small*3/2});
margin-left: $spacing-small;
&:first-of-type
{
margin-left: 0;
}
}
.something
{
width: calc(33.33% - #{$spacing-small*2/3});
margin-left: $spacing-small;
&:first-of-type
{
margin-left: 0;
}
} .something {
width: calc(33.33% - .66em);
margin-left: 1em;
}
.something:first-of-type {
margin-left: 0;
} .something {
width: calc(33.33% - #{$spacing-small * 2/3});
+ .something {
margin-left: $spacing-small;
}
}https://github.com/doximity/vital/blob/master/source/stylesh...
Just pointing this out :D
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.
so for instance:
.content {
@include box-size(3/4);
}
.sidebar {
@include box-size(1/4);
}
<div class="grid--1/2 grid--2/3@M">
<div class="grid--1/3"></div>
<div class="grid--1/3"></div>
<div class="grid--1/3"></div>
</div>
<div class="grid--1/2 grid--1/3@M"></div>This is a really nice grid system. I love the simplicity and the website. Keep it up!
When I resize the window, the demo (http://arkpod.in/pills/) reflows exactly like I'd expect.
e.g. what is the difference from Bootstrap? both 12 columns, grid based on floats. Is there any difference than naming?
Mark Boulton wrote some amazing articles about grid design long before grid frameworks were a thing http://www.markboulton.co.uk/journal/five-simple-steps-to-de...
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.
https://github.com/r-medina/grid
thanks for sharing!