Minimal Responsive Grid System
vladocar.github.io
vladocar.github.io
Simple naming system! Only 0.5KB!
.ten { font-size: 10px; }
.eleven { font-size: 11px; }
.twelve { font-size: 12px; }
.thirteen { font-size: 13px; }
.fourteen { font-size: 14px; }
.fifteen { font-size: 15px; }
.sixteen { font-size: 16px; }
Plugins available for font styles & variants! .bold { font-weight: bold; }
.italic { font-variant: italic; }
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!
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
Here is blog post about this (It is from 2008): http://www.vcarrer.com/2008/08/when-to-use-css-framework.htm...
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)
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.
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;
No doubt there are some breaking cases still!But agreed, this is getting quite ridiculous...
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.
P.S Yes, using fr is good idea..
Is the home page, itself, not using this responsive framework?
<crytoselfincorner />
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_La...
https://github.com/vladocar/SMART-CSS-GRID/blob/a0cfd2c730e9...
edit: I think 10 second fix is to just change .main from width: 960px; to max-width: 960px; width: 100%;.
function plusOne(x) { return x + 1 }
function plusTwo(x) { return x + 2 }
function plusThree(x) { return x + 3 }
function plusFour(x) { return x + 4 }
Using this framework, you can truly adhere to the DRY principle: instead of repeating x++ all around your codebase, you can simply do: x = plusOne(x)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.
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.