mfbs

commit

323a87f32b4eddb1c73700a266a6943beb9a19e9

parent

8f35cab3b7f7cba0cd3af72e3075248637c50a72

Author

Tobias Bengfort <tobias.bengfort@posteo.de>

Date

2017-05-09 21:04

rewrite readme

Diffstat

1 files changed, 27 insertions, 127 deletions

diff --git a/README.md b/README.md

@@ -2,6 +2,10 @@ mfbs (motherfuckingbootstap) is a CSS microframework inspired by [twitter
    2     2 bootstrap](https://getbootstrap.com/) and
    3     3 <http://bettermotherfuckingwebsite.com/>.
    4     4 
   -1     5 I found that I started every new project with mostly the same CSS code. So
   -1     6 instead of duplicating that code again and again, I distilled the base styles
   -1     7 from several projects into this little library.
   -1     8 
    5     9 It is written in [Sass](http://sass-lang.com/) and consists of variable
    6    10 definitions (`variables.scss`), some basic styling (`base.scss`) and some
    7    11 optional components.
@@ -10,14 +14,7 @@ See how it looks
   10    14 [here](https://xi.github.io/mfbs/examples/motherfuckingwebsite.html) and
   11    15 [here](https://xi.github.io/mfbs/examples/styleguide.html).
   12    16 
   13    -1 # how to use it
   14    -1 
   15    -1 First, install via bower or npm (eyeglass):
   16    -1 
   17    -1     bower install xi/mfbs
   18    -1     npm install mfbs
   19    -1 
   20    -1 Then, create a master stylesheet like this:
   -1    17 ## how to use it
   21    18 
   22    19     // First, define your own variables
   23    20     @import "variables";
@@ -26,7 +23,7 @@ Then, create a master stylesheet like this:
   26    23     @import "mfbs/variables";
   27    24     @import "mfbs/base";
   28    25 
   29    -1     // Optionally import some components
   -1    26     // Optionally import some opinionated styling
   30    27     @import "mfbs/form";
   31    28 
   32    29     // Import your own components
@@ -34,121 +31,24 @@ Then, create a master stylesheet like this:
   34    31     @import "components/navigation";
   35    32     @import "components/article";
   36    33 
   37    -1 # the fuck?
   38    -1 
   39    -1 I tend to duplicate a lot of basic styling between projects. So naturally I was
   40    -1 looking for ways to reduce that duplication. Twitter bootstrap is nice, but it
   41    -1 does so much more than what I needed. So instead I rolled my own.
   42    -1 
   43    -1 Here's the philosophy:
   44    -1 
   45    -1 -   A site using no styling except for mfbs should have decent usability.
   46    -1 -   mfbs should be as minimal as possible
   47    -1     -   no workarounds for browser bugs
   48    -1     -   opinionated styling should go into optional components
   49    -1     -   leverage default styles
   50    -1 -   apart from providing basic styling, mfbs should define and promote a
   51    -1     workflow for writing CSS
   52    -1     -   based on [OOCSS](http://oocss.org/) and [Sass](http://sass-lang.com/)
   53    -1     -   naming conventions
   54    -1     -   use variables for all colors
   55    -1     -   prefer relative units
   56    -1     -   accessibility
   57    -1 
   58    -1 # A brief introduction to web design (slightly opinionated)
   59    -1 
   60    -1 ## WYSIWYM (What you see is what you mean)
   61    -1 
   62    -1 Web design is fundamentally different from many other forms of design,
   63    -1 especially print, because you can not see the final product. Of course, you can
   64    -1 look at a webpage in your browser, but you will never be able to see or even
   65    -1 imagine that page on all possible devices, with all possible browsers and
   66    -1 browser extensions, let alone user generated content. That is why instead of
   67    -1 coding what you want to see, you should write what you mean.
   68    -1 
   69    -1 Example: You want to center some text on the screen, so increase the
   70    -1 `margin-left` to something like 1100px and it looks fine, right?  Maybe on your
   71    -1 screen, but definitely not on a mobile device. Instead, you should use
   72    -1 `text-align: center`. With this information, the browsers can understand what
   73    -1 you want and do their best to produce a usable result.
   74    -1 
   75    -1 ## Maintenance
   76    -1 
   77    -1 A website is typically never finished. Make sure that you will still be able to
   78    -1 understand your code one year from now!
   79    -1 
   80    -1 Example: Styling elements based on context (using descendant selectors) may
   81    -1 seem like a good idea, but it soon gets extremely complicated to understand
   82    -1 which rules apply to which element with which priority.
   83    -1 
   84    -1 ## Progressive enhancement
   85    -1 
   86    -1 Not all clients provide the same features. Think about small screens, outdated
   87    -1 browsers, blocked JavaScript, or assistive technology. You should never rely on
   88    -1 these advanced features. Instead, use them to optionally enhance user
   89    -1 experience if additional features are available.
   90    -1 
   91    -1 Example: Build your website for small screens by default. If more screenspace
   92    -1 is available (check via [media
   93    -1 queries](https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries))
   94    -1 you can switch to an optimized layout (this approach is called "mobile first").
   95    -1 
   96    -1 ## Separate style, functionality, and content
   97    -1 
   98    -1 The web is build with three distinct languages: HTML for content, JavaScript
   99    -1 for functionality and CSS for styling. Make sure that you have a clear
  100    -1 separation between these areas!
  101    -1 
  102    -1 Example: Do not use element selectors in CSS. They break easily when you change
  103    -1 your HTML. Instead, use semantic class names.
  104    -1 
  105    -1 ## Conventions
  106    -1 
  107    -1 People spend much more time on other peoples websites, so do not try to get
  108    -1 fancy. Just do what everyone is doing, that's just fine.
  109    -1 
  110    -1 Example: Links are much more likely to be fund if they are blue and underlined.
  111    -1 
  112    -1 ## Use appropriate units
  113    -1 
  114    -1 For some reason, people seem to be afraid of using different units in their
  115    -1 stylesheets. There seems to be a `px` camp, a `em` camp and since recently also
  116    -1 a `rem` camp. But the truth is: Each of these units is different and has their
  117    -1 specific use. Learn the meaning of each of them and when to use it!
  118    -1 
  119    -1 ## Objects, states, and modifiers
  120    -1 
  121    -1 You can not possibly think about the complete interface at once. Instead,
  122    -1 divide it into meaningful parts. Here is how I do it:
  123    -1 
  124    -1 Object
  125    -1 :   An object is a part of the UI that could stand on its own or be repeated in
  126    -1     different places. It can be anything from a link to a login form or a
  127    -1     layout structure. Objects are references by their classname, which should
  128    -1     be dashed-lowercase (e.g. `.login-form`).
  129    -1 
  130    -1     Note: Splitting your UI into objects is not as easy as you might think.
  131    -1     Take special care to get this right! For example, you might want to split
  132    -1     layout and styling into separate objects.
  133    -1 
  134    -1 Modifier
  135    -1 :   Sometimes you might want to have a slightly modified variant of an existing
  136    -1     object. In that case, create a modifier class that is prefixed with `m-`
  137    -1     (e.g. `.button.m-call-to-action`).
  138    -1 
  139    -1 State
  140    -1 :   If the state of an object can be changed on runtime, use a state class that
  141    -1     is prefixed `is-` or `has-`. Alternatively, utilize the existing pseudo
  142    -1     classes (e.g. `a.is-active`, `a:disabled`).
  143    -1 
  144    -1 ## Use variables
  145    -1 
  146    -1 If you use the same values in several places, make that explicit by defining it
  147    -1 as a variable with a semantic name. Colors are an obvious example, but this
  148    -1 also makes sense for some length values.
  149    -1 
  150    -1 ## Living styleguide
  151    -1 
  152    -1 To keep an overview of everything you have done, you should create a page with
  153    -1 examples and descriptions for all your objects, modifiers, states and
  154    -1 variables.
   -1    34 ## features
   -1    35 
   -1    36 -   mfbs on its own is completely sufficient for simple text-only websites.
   -1    37 -   It can easily be customized with variables.
   -1    38 -   The default colors were carefully picked to look nice and satisfy minimum
   -1    39     contrast requirements.
   -1    40 -   Opinionated styling for buttons, layout, and some more things is available
   -1    41     in optional modules.
   -1    42 -   Base styles have low specificity, so they can easily be extended with
   -1    43     custom components.
   -1    44 -   The small set of variables is very focused and scales well for projects of
   -1    45     any size.
   -1    46 
   -1    47 ## when to use
   -1    48 
   -1    49 -   Use the default for simple general-purpose styling
   -1    50 -   For small projects, overwrite some variables and define some custom
   -1    51     components (e.g. header)
   -1    52 -   For large projects, you probably do not want to include the optional,
   -1    53     opinionated modules. But the base styles and variables are still a solid
   -1    54     base to build on.