Minimal Responsive Grid System(vladocar.github.io)
vladocar.github.io
Minimal Responsive Grid System
https://vladocar.github.io/SMART-CSS-GRID/
47 comments
There could be a genuine need for this sort of CSS "framework", for example mobile phones mess up font size quite a bit.
My site CSS has the following just to make sure that the mobile browser (from testing) doesn't make the font unreadable:
But agreed, this is getting quite ridiculous...
My site CSS has the following just to make sure that the mobile browser (from testing) doesn't make the font unreadable:
-webkit-text-size-adjust: 100%;
-moz-text-size-adjust: 100%;
-ms-text-size-adjust: 100%;
max-height: 999999px;
But agreed, this is getting quite ridiculous...
There are CSS processors that do these kinds of browser hacks and vendor prefixes. PostCSS iirc
I know you are joking .. but there are some CSS Frameworks with really terrible names and naming logic. If you have better naming system let me know.
This, or something similar, should be your guideline for naming things in CSS: https://en.bem.info
IMO a "modern CSS frameworks" should have 0 classnames and should not inject any CSS statement anywhere. They should only provide mixins for LESS/SCSS to be included by the user.
IMO a "modern CSS frameworks" should have 0 classnames and should not inject any CSS statement anywhere. They should only provide mixins for LESS/SCSS to be included by the user.
So, something like [Bourbon](https://www.bourbon.io/), which is a Sass framework like you describe.
Any CSS framework can be included as namespaced mixins in LESS.
Wouldn't that be better described as a "LESS/SCSS" framework?
The joke was that its a framework to do what is now natively supported. I would look into CSS grid.
That is the point that I'm failing to make. It is all about reusability not about the grid system. You can use one CSS layout system in multiple cases otherwise you need to define separate CSS logic for every different web layout.
I don't understand your reasoning.
In my opinion, classnames should say what the HTML element represents, and a stylesheet contains the definitions for styling and sizing.
Your HTML should not include information about the size of an element. Your HTML document should represent the content & structure of your document. Your stylesheet is then responsible for layout, design, color and dimensions.
It is all about semantics. See: https://maintainablecss.com/chapters/semantics/
By writing the column sizes in the HTML, you're effectively reinventing inline styles
In my opinion, classnames should say what the HTML element represents, and a stylesheet contains the definitions for styling and sizing.
Your HTML should not include information about the size of an element. Your HTML document should represent the content & structure of your document. Your stylesheet is then responsible for layout, design, color and dimensions.
It is all about semantics. See: https://maintainablecss.com/chapters/semantics/
By writing the column sizes in the HTML, you're effectively reinventing inline styles
There’s a problem with this approach, which I found out about the hard way.
Like you I thought I should keep my html “semantic”. The problem with this approach is that you end up tightly coupling the stylesheet and the html, because it requires you to recreate the html’s tag structure using contextual selectors.
Besides becoming very complex this means that every time you need to change the html you also need to change the css.
The other major downside is that all those mixins end up generating a ton of duplicate rules in the stylesheet.
Note that if you define everything using classes and then put those classes in the html you have none of these issues. The coupling is much more straightforward and the stylesheets can be much smaller. Besides that, contextual selectors are many times slower than a single classname.
The inline styles thing I can’t agree with, classes are much more DRY.
I found the methodologies outlined by Harry Roberts to change the ways I structure my css for the better. (www.csswizardry.com)
Like you I thought I should keep my html “semantic”. The problem with this approach is that you end up tightly coupling the stylesheet and the html, because it requires you to recreate the html’s tag structure using contextual selectors.
Besides becoming very complex this means that every time you need to change the html you also need to change the css.
The other major downside is that all those mixins end up generating a ton of duplicate rules in the stylesheet.
Note that if you define everything using classes and then put those classes in the html you have none of these issues. The coupling is much more straightforward and the stylesheets can be much smaller. Besides that, contextual selectors are many times slower than a single classname.
The inline styles thing I can’t agree with, classes are much more DRY.
I found the methodologies outlined by Harry Roberts to change the ways I structure my css for the better. (www.csswizardry.com)
I agree about the semantics. If you are building small web site or big web with the simple structure don't use CSS Framework.
Here is blog post about this (It is from 2008): http://www.vcarrer.com/2008/08/when-to-use-css-framework.htm...
Here is blog post about this (It is from 2008): http://www.vcarrer.com/2008/08/when-to-use-css-framework.htm...
I've played around a bit with CSS grid, and to me it seemed like it would just make this kind of grid frameworks unnecessary. Everything I see on that page are native CSS grid features.
After looking at the CSS, it seems entirely redundant. It's 36 lines, and only contains the basic grid setup you'd do by hand. Using CSS grid directly would not be hardly more difficult or verbose, and far more powerful than restricting yourself to the subset used in this.
What I also find strange is that this project still calculates the column width based on percentages, instead of the native support for fractions in CSS grid.
After looking at the CSS, it seems entirely redundant. It's 36 lines, and only contains the basic grid setup you'd do by hand. Using CSS grid directly would not be hardly more difficult or verbose, and far more powerful than restricting yourself to the subset used in this.
What I also find strange is that this project still calculates the column width based on percentages, instead of the native support for fractions in CSS grid.
The general idea is that because is already a grid you don't need another grid. The point of this project is not to make just another grid, but to make reusable system using the same CSS classes in your entire project.
P.S Yes, using fr is good idea..
P.S Yes, using fr is good idea..
I agree. With CSS Grid now part of the browser in Chrome/FF/Edge, we really should be ditching these frameworks and using CSS Grid directly.
You could roll your own easy enough sure, I think the author is saying "Look! I have used the tools available and built the wheel, and I am giving it to you so you can save time."... does that sound about right?
I don't understand how this is "Responsive." When I resize the browser window, it doesn't respond. All it does is go off-screen like a standard table.
Is the home page, itself, not using this responsive framework?
Is the home page, itself, not using this responsive framework?
It’s broken between 960px and 480px, that’s all.
It's responsive for me using Vivaldi 1.15
On Monday, I was at a very interesting talk about what's coming up and what's available in modern CSS. Apart from one exception, I can't use anything that was gone over in an hour's talk. Why? IE11.
Exactly. I would so much love to use css grid but it won’t be possible for the foreseeable future. Financial organizations stuck on windows 7 locked workstations represent a major part of our clients.
1000 times this. We do SaaS for the Banking industry and 72% of our traffic is IE11/Win7. In May 2018.
<crytoselfincorner />
<crytoselfincorner />
Are grids still a thing? I hardly had to use any for the last 2-3 years. I just have a `display: flex` and control the direction with media queries. Seems much more easy than learning a grid css file
CSS Grid is a newer concept than Flexbox, and solves a different problem.
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_La...
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_La...
Indeed they are. CSS even has a `grid` layout style: https://css-tricks.com/snippets/css/complete-guide-grid/
This is not responsive when resizing the browser window in Safari...
I don't understand how they're demonstrating a responsive grid framework with a non-responsive demo.
It’s not really responsive, it just stacks grid elements vertically when the viewport width is < 480px.
https://github.com/vladocar/SMART-CSS-GRID/blob/a0cfd2c730e9...
https://github.com/vladocar/SMART-CSS-GRID/blob/a0cfd2c730e9...
Same in Chrome and Firefox. Basically between 481px and 984px viewport widths, you're going to have horizontal scrolling. Can't say I've seen this approach to a responsive grid before.
edit: I think 10 second fix is to just change .main from width: 960px; to max-width: 960px; width: 100%;.
edit: I think 10 second fix is to just change .main from width: 960px; to max-width: 960px; width: 100%;.
The default of the system is less then 480px for some reason Safari doesn't resize try Chrome or Firefox..
it's not.. it's a subpar demo page.
Few words about this CSS layout solution. It is meant to be starting point. Because is only 36 lines of code you could personalise anything in the main CSS file. Example you can change the main width form 960px to 60 % or 70 em. You can change the grid margin from 10px to xyz px. You can personalise how the responsive layout works. Like I said before is only a starting point..
Minimal JS Integer Framework:
function plusOne(x) { return x + 1 }
function plusTwo(x) { return x + 2 }
function plusThree(x) { return x + 3 }
function plusFour(x) { return x + 4 }
x = plusOne(x)Lovely... but works in < 90% of browsers [0], so it's kind of for academic consideration only for now.
[0] https://caniuse.com/#feat=css-grid
[0] https://caniuse.com/#feat=css-grid
For browsers that support grid you can use grid and then have a fallback layout for browsers that don't. You can even user `@supports(display: grid)` feature query to specifically target browsers that support grid.
Or just use the fallback, and code once instead of twice.
> works in < 90% of browsers [0], so it's kind of for academic consideration only for now.
Says your particular organizations policies, why is the line drawn at 90%, why not 95%? Is this restriction based on calculations or was it simply arbitrarily chosen?
If it's arbitrary, allow me to offer an alternative, focus support only on "modern generation" browsers which auto-update by default. All popular browsers adopted auto-updates as a collective effort to improve end-user security, and so as web developers we're able to encourage this by only supporting those platforms.
As you can see on caniuse, grid support on those modern browser platforms is 100%. The only ones lacking are IE which microsoft has abandoned, and Opera Mini (I can't speak good or bad about that, I haven't examined it).
The idea that you must support as many browsers as possible is a relic of the 1990s dot com bubble when it was unclear which browser was best and there were no agreed upon standards. It's now 2018 and you're either using Firefox or Chrome and to a much smaller extent, Edge or Safari. Any other browser that wants to be taken seriously is going to support the standards set by those platforms.
Says your particular organizations policies, why is the line drawn at 90%, why not 95%? Is this restriction based on calculations or was it simply arbitrarily chosen?
If it's arbitrary, allow me to offer an alternative, focus support only on "modern generation" browsers which auto-update by default. All popular browsers adopted auto-updates as a collective effort to improve end-user security, and so as web developers we're able to encourage this by only supporting those platforms.
As you can see on caniuse, grid support on those modern browser platforms is 100%. The only ones lacking are IE which microsoft has abandoned, and Opera Mini (I can't speak good or bad about that, I haven't examined it).
The idea that you must support as many browsers as possible is a relic of the 1990s dot com bubble when it was unclear which browser was best and there were no agreed upon standards. It's now 2018 and you're either using Firefox or Chrome and to a much smaller extent, Edge or Safari. Any other browser that wants to be taken seriously is going to support the standards set by those platforms.
If you're a business with actual customers, your decision about which browsers to support and where to draw the line is going to be driven by whether not supporting them costs more money than supporting them, not by whether the dev team would prefer people to download software worth taking seriously or buy a newer phone if they wish to continue being customers.
> The idea that you must support as many browsers as possible is a relic of the 1990s dot com bubble
Your notion of forcing people to change browsers (who may not be able to for accessibility reasons, corporate policy reasons, or hardware reasons) is the real relic of the 1990's.
Remember when half the web sites you'd visit put up a big notice "Your browser is not supported. Download the latest browser here?"
Non-support is the relic. Support is what makes a business work.
The customer's money is still green, even if they're not using the latest tech.
Your notion of forcing people to change browsers (who may not be able to for accessibility reasons, corporate policy reasons, or hardware reasons) is the real relic of the 1990's.
Remember when half the web sites you'd visit put up a big notice "Your browser is not supported. Download the latest browser here?"
Non-support is the relic. Support is what makes a business work.
The customer's money is still green, even if they're not using the latest tech.
I want to check this out but I'm on my phone so there's no way to "view source" and see how to actually use the framework. All I can see is the resulting grid on the demo page. Maybe add code snippets?
Follow the github link. The CSS file itself is tiny, and the demo HTML is in the repo.
the demo is not responsive.... hmm
Simple naming system! Only 0.5KB!
Plugins available for font styles & variants!
Use our CDN! Always available!
https://mincss-fontsize.xyz/simple-font-sizes.0.3.1.min.css
https://mincss-fontsize.xyz/simple-font-styles.0.3.1.min.css
https://mincss-fontsize.xyz/simple-font-variants.0.3.1.min.c...
Changelog:
0.3.1
- Changed .sixteen to be actually 16px instead of 17px (typo)
0.3.0
- Added .sixteen for even larger text!