Tag Archives: css

How To – 12 Column Grid Library From Scratch

As web developers we’ve used countless UI libraries that give us an interface for creating grids. Now things have become much easier thanks to Grid and Flexbox in CSS, but it is still nice to have everything arranged in nice consistent classes for production use. Recently, I set out on a mini-mission to find a grid library for our new design system. In my search, I had to go through many libraries, their features and their source code. Most of them were 90% fit for my use case, but then I’d find some flaw that’d put me off. This continued for a couple of hours, at the end of which I uttered the golden developer words “I know, I’ll just implement my own grid library”. The old folks here know what follows. They also know, irrespective of whether you know if this is a bad idea, the temptation to start working in an empty file without any dependencies is too real to just ignore.

Anyway, after spending some time baking my own grid library, and slowly realizing that in probably a week or so, I’ll end up with exactly the kind of code that I’d rejected earlier, given how similar everything was looking, I decided to go with something readybaked. But this little exercise of trying to make a grid library taught me a lot about how these libraries are implemented. I wish to share some of that excitement, the learnings with you in this article.

By the end of this article, I want you to have at least a basic understanding of how a grid library is written and be confident to dig into the source code in case you need to customize a library to fit your needs. Note that I’m using Flexbox. Bootstrap 3 used widths and floats, and Bootstrap 4 uses Flexbox. I believe you can also use CSS3 Grids. Use what feels natural to you.

What’s a grid system?

A grid means what you’d expect it to mean. It is a two dimensional cellular structure, like a cupboard or a chess board, and you can put/place stuff on/in it. In the context of web development and design, grids usually just define the vertical or columnar properties. The reason is that we do not want to design for horizontal scrolling, and assume that all navigation on a page will be based on vertical scrolling. As a result, whatever the screen width is, we take that as 100% and divide it into the number of columns that we prefer.

First step is to set the number of columns that we’d like the designs to use. 12 is commonly used because with 12, we can divide the page into 1, 2, 3, 4, 6 and 12 parts (notice that those are just divisors of 12). Then we set the gutter size. Gutter is the gap between two columns. Usually we set it to 1rem which, if we haven’t modified, should be 16px.

12 column grid with gutters (taken from MDN CSS Grid Layout)

After that, we set breakpoints. Breakpoints are points where our UI changes in response to a change in the screen size. For modern websites, we have to cater to a wide variety of browsers and screen sizes, and defining a set of screen sizes is our first step towards it. For example

  • 0-450px can be considered to be small mobiles
  • 450px-750px can be large mobiles
  • 750px-1000px can be tables
  • 1000px+ can be desktops

This is all very arbitrary, of course. we can set whatever sizes fit most of our users’ device types or just copy what Bootstrap or other popular libraries do (in general, when in doubt follow the standards).

Next is to actually implement designs that adhere to this grid system. Here we make an assumption that we have a UI hi-fi design mockup that was built using the same 12 column grid as base. For ease of implementation, we can define the CSS classes that we frequently use, which while not absolutely necessary, is helpful.

Basic CSS

While I mentioned that it isn’t absolutely necessary to have CSS classes that help us with grids, more often than not we’ll want to have some of them. The way we do it is we write classes for all the possible widths that a div might take on the screen, right from 1/12 to 12/12 (which is essentially 100% width).

.row {
  display: flex
}
.col-1 {
  flex-basis: 8.3333333% // (1/12)*100 
}
.col-2 {
  flex-basis: 16.666666% // (2/12)*100
}
// and so on

In this short snippet, a .row would be the wrapper class for one or more .col-X classes.

Styling our HTML

Consider the simple markup. This is a typical layout for a blog with a navigation section on the left, blog content in the center and a sidebar on the right with some widget.

<main class="row">
  <aside   id="navigation"></aside>
  <article id="content"></article>
  <aside   id="blog-roll"></aside>
</main> 

Now, if we want to split the page into three columns; left sidebar (25% or col-3 containing the “.navigation”), main content (50% or col-6 containing “.content”) and right sidebar (25% or col-3 containing “.blog-roll”), we just have need to add the relevant classes to our markup

<main class="row">
  <aside    id="navigation" class="col-3"></aside>
  <article  id="content"    class="col-6"></article>
  <aside    id="blog-roll"  class="col-3"></aside>
</main> 

It should give you a grid like the following.

Notice how they just stick with each other without any padding. The purple border is Firefox developer tools showing us the layout.

Gutters

If you ignore the basic styling and borders, you’ll notice that there’s still no spacing between the columns (or gutters) here. We need spacing because otherwise we’ll have to add internal padding to all the columns and we do not want content from one column sticking to the content from another. To have some of that, we define a gutter variable and add half gutter width padding on right and left side of our columns.

:root {
  --gutter-half-width: .5rem
}
.row {
  & > *[class^="col-"] {
    padding-left: var(--gutter-half-width
    padding-right: var(--gutter-half-width
  }
}

Note that --gutter-half-width is just a variable in CSS that we access with the var() function. & > *[class^="col-"] selects all direct descendants of row class which have the col-* class set. :root selects the document root.

We don’t want gutters on the extreme left and extreme right of our grid. We compensate for that with negative margins on the .row class.

.row {
  margin-left: calc(var(--gutter-half-width) * -1
  margin-right: calc(var(--gutter-half-width) * -1
}

If you were to re-run the CSS again, we’d have something like the following.

Nice and tidy

Mobile responsiveness

At this point, our grid system is ready. Ready for one screen size, that is. Let’s see what happens if we switch to mobile view?

Eww!

I mean, it kind of does what we asked it to do, but if those columns were in fact two sidebars and one main content section, and this being displayed on a 320px screen, your users would be pretty irate (or worse, your website becomes popular on r/CrappyDesign). You don’t want that, don’t you?

To fix that, we’ll use the breakpoints that we had discussed about earlier. Essentially, we want to have three columns on desktops (which we’ve already made), one on tablet and one on mobile phones in a row. We start off with writing the media queries for each of our breakpoint.

@media only screen and (max-width: 449px) {
  // classes for mobile view
}
@media only screen and (min-width: 450px) {
  // classes for tablet view
}
@media only screen and (min-width: 768px) {
  // classes for desktop view
}

Next, we write the column CSS classes for each media query (same code, but we’ll rename them a bit so that we can tell which class is for which viewport). Notice the col-[viewport-name]-[column-width] format. You’ll might recognize this from libraries like Bootstrap (for example, col-md-3 or col-xs-6).

@media only screen and (max-width: 449px) {
  .col-mobile-1 {
    flex-basis: 8.3333333%
  }
  .col-mobile-2 {
    flex-basis: 16.666666%
  }
  // col-mobile-3 to col-mobile-10
  .col-mobile-11 {
    flex-basis: 91.666666%
  }
  .col-mobile-12 {
    flex-basis: 100%
  }
}
@media only screen and (min-width: 450px) {
  .col-tablet-1 {
    flex-basis: 8.3333333%
  }
  .col-tablet-2 {
    flex-basis: 16.666666%
  }
  // col-tablet-3 to col-tablet-12
}
@media only screen and (min-width: 768px) {
  .col-desktop-1 {
    flex-basis: 8.3333333% 
  }
  .col-desktop-2 {
    flex-basis: 16.666666% 
  }
  // col-desktop-3 to col-desktop-12
}

Now, we can edit our HTML to use these new classes. For each viewport, we add a class which tells the browser how wide it needs to be on that viewport. For example, our article section is 50% in width (or 6 out of 12 columns) on desktop, while 100% on tablet and mobile (or 12 out of 12 columns).

<main class="row">
  <aside   class="col-desktop-3
                  col-tablet-12
                  col-mobile-12" id="navigation"></aside>
  <article class="col-desktop-6
                  col-tablet-12
                  col-mobile-12" id="content"></article>
  <aside   class="col-desktop-3
                  col-tablet-12
                  col-mobile-12" id="blog-roll"></aside>
</main> 

This will ensure our columns are 100% width on tablet and mobile screens. And because our classes are inside of media queries that only fire at the viewport width breakpoints, only the relevant class gets applied. As you can imagine, one can really fine tune how things look by selecting a higher number of breakpoints and designing for a more consistent UI across the spectrum of screen sizes.

Bonus – Hiding sections

Let’s say we decide that the blog-roll section isn’t super important on mobile screens, and should be removed. This is a common usecase; hiding specific blocks on specific viewports. And there’s a very easy way of doing this right in the grid system.

The little trick is to add hidden classes, just like our column classes, to our viewport media queries.

@media only screen and (max-width: 449px) {
  .col-mobile-hidden {
    display: none
  }
}
@media only screen and (min-width: 450px) {
  .col-tablet-hidden {
    display: none
  }
}
@media only screen and (min-width: 768px) {
  .col-desktop-hidden {
    display: none
  }
}

Now, to hide the blog-roll on mobile phones, we just add the hidden class to its classlist.

<main class="row">
  <aside class="col-desktop-3
                col-tablet-12
                col-mobile-hidden" id="blog-roll"></aside>
</main> 

Code

I’ve posted truncated snippets above. The whole thing would look something like the following.

  
:root {
  --gutter-half-width: .5rem
}
.row {
  & > *[class^="col-"] {
    padding-left: var(--gutter-half-width
    padding-right: var(--gutter-half-width
  }
  margin-left: calc(var(--gutter-half-width) * -1
  margin-right: calc(var(--gutter-half-width) * -1
}
@media only screen and (max-width: 449px) {
  .col-mobile-1 {
    flex-basis: 8.3333333%
  }
  // ...
  .col-mobile-12 {
    flex-basis: 100%
  }
  .col-mobile-hidden {
    display: none
  }
}
@media only screen and (min-width: 450px) {
  .col-tablet-1 {
    flex-basis: 8.3333333%
  }
  // ...
  .col-tablet-12 {
    flex-basis: 100%
  }
  .col-tablet-hidden {
    display: none
  }
}
@media only screen and (min-width: 450px) {
  .col-desktop-1 {
    flex-basis: 8.3333333% 
  }
  // ...
  .col-desktop-12 {
    flex-basis: 100%
  }
  .col-desktop-hidden {
    display: none
  }
}

Possible extensions

The flexbox standard defines various ways of arranging things inside the container both along the flex-direction axis (called the main axis) and the cross axis (the axis perpendicular to the main axis). If we were to extend this, we could define helper classes like .col-reverse (flex-direction: reverse) or .col-spread-out (justify-content: space-between) using these properties depending on our use cases.

In closing

The flexbox standard is pretty elaborate, and extremely well documented. There are also good libraries build around Flexbox that provide what we just build, and much more than that, out of the box. In production, one should try to stick to libraries and not reinvent the wheel.

Having said that, it is also important to understand the libraries that we use. Now we know what actually happens when we use that familiar col-md-6 class from Bootstrap, and if need be, we won’t shy away from editing the source code to make the library fit our needs!

Thank you for reading!

HTML For Semantics, CSS For Visual

The best way to learn is to teach, they say. I totally agree, and that’s one reason I have so many articles on my blog explaining random topics. Part of the goal was always to understand the topic better myself.

I got reminded of it while I was preparing for a workshop on introduction to web technologies for my fellow Berliners who wish to get into tech. Then something interesting happened. I found the root of a problem that I was struggling with for some time at work. I will jot down some notes of this entire experience, and try to tell you about the lessons learned.

Our Styleguide

We maintain a frontend styleguide (think: company-specific UI library). We have many HTML elements and CSS classes that make our text, buttons and cards look the way we want them to look across the webapps. There’s a little issue. Most textual styles are defined on HTML elements. So to get a large heading styled with our predefined font-size, font-family, color and a bunch of other styles, one would just use h1 (notice: no class needed).

This worked for us until now, and wherever a big heading was required, we would just throw in an h1. Similarly for paragraphs, lists and other textual elements. This made a lot of sense in the past as accessibility or SEO weren’t a concern. But things changed.

Multiple h1s

It all started when our contracted SEO agency told us that we had two h1s on a page. We looked at the page, and it made total sense. There were two ‘headings’ of super large size, and our styleguide’s h1 made total sense from a purely visual perspective. But the second heading was just a title in large font. It had no semantic significance. Now, our product’s main title and some random text have the same precedence on the page.

This is bad for SEO, no doubt, but this is also bad for screen readers and all mini browsers (like Apple Watch and the like) which rely on the HTML to convey semantic information, and not visual.

Thinking and problem solving

I went to our designers and had a discussion. I could just hack and overwrite the styles, but that wasn’t the point. I asked what could be done. We could change the design, create a new class the resembles heading-1s and then use that on a span and so on. But we couldn’t think of why we’ve met with this problem. Maybe we’re missing something, something obvious, we thought.

Conference on web basics

I attended a developer conference a couple of weeks ago. There we had the good fortune of listening to Hakun Lie and Bruce Lawson. What struck me, apart from how much they cared about web standards and saving the web from the bloat hell that we’re hurtling towards, is how much one can accomplish just by sticking to web standards. One of the examples used was of the Apple Watch, and the website in question was developed much before anyone imagined a browser on your wrist. If one just uses semantic HTML, one can be sure that their website would work on any device, whether in existence or yet to arrive. And just like that, millions of well-designed websites started to work on the special Apple Watch browser.

This is important to note because there are usually multiple ways of doing something on the web. More often than not, there are a couple of right and many wrong ways. Part of our job as web developers is to ensure that our website isn’t just pretty visually but also correct semantically and structurally. This is to futureproof our creation.

The workshop

I was preparing for this workshop and thinking of various ways I could introduce web development to complete beginners. I referred to some nice articles and tried to understand the meaning of HTML and CSS myself. I tried to understand why reset.css and normalize.css are used, even though I’ve been using them for years. I came up with interesting analogies to explain the basic pillars of the web and as a result, improved my understanding of these constructs.

Lightbulb moment

After the workshop, when I went back to my codebase, I could see the problem staring right back at me. We had styled the HTML elements, and not created separate classes that we could then attach to our elements. This is the result of forgetting the basics and doing something the wrong way because it saves you from writing class="" for every HTML element, which to be fair, doesn’t seem that bad when you don’t differentiate between HTML and CSS and use a combination of the two to get the design right.

Conclusion

There are a couple of conclusions for me from this article. One is to learn and follow web standards. Semantic HTML is not at all hard, just some 120 tags in total. Then, understand what a markup language means, and how the semantics of a document is different from how it looks or works. Learn the rules of CSS selectors and how cascading works. Learn that HTML and CSS are declarative, and use them as much as possible. Only where it makes sense, introduce Javascript. In general, keep abstractions to a minimum.

Thank you for reading.

Let’s Talk About CSS

CSS can be deceptively complex. And to most programmers, rightly so. We programmers tend to find patterns that help us relate the new information to what already exists within us, draw parallels and think of real world analogies. That is one reason learning your second or third programming language is much faster than learning the first if they share some paradigms. But with CSS, many of us have a memorize-first approach. While it works, it is more fun (and easier to debug) if we understands a little bit of the under-the-hood stuff.

In this post, let’s try to demystify some of the aspects of CSS that we as engineers should’ve asked when we got started with CSS. Better late than never, right?

Understanding The Browser

Starting with something basic: When you request a webpage, and it is downloaded to your system (computer, mobile phone etc), it is in the form of HTML code (at the application layer, that is). The browser then parses the html, line by line, downloading any external resources that it finds with separate HTTP requests. The HTML that is parsed is structured as a DOM tree, which can be thought of like a family tree, but with HTML elements. DOM defines the structure of the page; what goes where and what information does each node have.

On the side, the browser (in that, the rendering engine) is also processing the CSS files. CSS files are processed, and then styles for each node (HTML element, that is) is calculated, and applied to that node. The end result is ‘painted’ and rendered to the client’s screen.

So as you can tell, it is pretty straightforward. What’s interesting is the process of calculating the styles to be applied to each node, and that’s what we’ll be talking about for the rest of this article.

CSS Parsing

There are a couple of challenges when deciding what style applies to a particular element.

  • The engine has to first parse the CSS and get all the values for each property.
  • Then the engine has to decide what set of properties get applied to each element depending upon the specificity of the selectors, inherited and default values (since each element may have multiple rules that seem to style it).
  • Then the selected styles are converted into pixel values (we may have used rems, ems, percentages or vh/vw in our CSS code) as that’s what browsers understand.

In particular, the CSS engine looks for the following when dealing with a style and deciding if it really applies to a given node.

!important

If a property has !important in the value, it is immediately selected for the final processing irrespective of the specificity and code order.

Specificity

To put it simply, specificity deals with how ‘specific’ is the selector (based on concrete rules). For example, if you have some list-items, each with a class selector and CSS background-color: red; and one of them also has an ID selector with the CSS background-color: green;, then which background-color do you think gets applied to that particular list-item? It is the style in the ID selector.

Similarly, if the ID selected list-item had an inline style, the inline style would take precedence. Formally the hierarchy is

Inline style > ID selector > Class selector > Element selector

Browsers maintain an internal tuple of the form (0,0,0,0) representing the counts of each selector hierarchy viz. (inline-style, ID, class, element). For the selector h1.heading#top-heading, the tuple will look like (0,1,1,1), that is, one for ID, one for class and the last for element selector.

Suppose you had another selector h1.heading#top-heading#blue-color. Now the tuple for this would look like (0,2,1,1) as there are two ID selectors. If the browser had to choose between the former and this, it would choose this one as it has a higher specificity.

Source Order

Now what happens if specificity of two selectors match? Simple, the last selector in the source code (even in case of multiple files) gets selected for application.

Cascade

Cascade (n): A process whereby something, typically information or knowledge, is successively passed on.

The term Cascading in Cascading Style Sheets says something about the priority scheme that’s used to determine what style gets applied to an element when multiple rules match. In simpler words, if body has font-family: Arial; specified and the h1 has font-family: Helvetica;, Helvetica gets applied to the h1. However, if font-family on h1 wasn’t explicitly declared, Arial would’ve been selected by inheritance. This is how inheritance works in CSS.

Not every property is inherited. And it doesn’t make a lot of sense to inherit everything either. For example, setting margin: 0 10px; on body doesn’t automatically apply it to every child of body which doesn’t have an explicitly declared margin property. The ones which don’t have an explicitly declared margin get a default margin of 0px. This is how default properties work in CSS.

The obvious followup question is, how to tell if something will be inherited or default value will be selected? Honestly, I’m not sure. I usually just ask myself if it makes sense to have this property inherited or defaulted. More often than not, that’s enough. In case you’d want to explicitly make a property to inherit or default a value, use inherit and initial keyword respectively.

In Closing

That’s it for this little primer. I hope you found it useful. For a nice illustrated guide on this, check out this article on Mozilla. Thank you for reading.

CSS Crash Course

I have a friend, who happens to be a good C and assembly programmer, but simply hates anything related to web, then be it HTML, CSS or anything way too much abstracted for that matter. Since it was compulsory for us to make our own web application project for college, he struggled to learn it (CSS and HTML) from here and there, cursing it at the same time. Hence this little guide, for all those of you who hate it, but still want to get your work done.

A thing or two about CSS

CSS isn’t a markup language. It is a styling language, and hence, it won’t really work if you have no document in the first place. Creating a document simply means adding some data to HTML tags in a web page. Here onwards, document would mean the HTML page that we are working on. Let us create one as an example.

<!DOCTYPE html>
<html>
<head>
  <title>Testing</title>
</head>
<body>
  <h1>Awesome Site</h1>
  <h3>A little heading</h3>
  <p>A paragraph containing some text</p>
  <h3>Some information</h3>
  <p>More text...</p>
</body>
</html>

This is a very basic example that would display something like the following. You can guess what each tag stands for here, if not, ‘h’ tag stands for heading, ‘h1’ being the largest to ‘h6’ being the smallest. ‘p’ stands for paragraph, and there are many such tags, which are used as and when required.

Now it is time to style our document. I will place all the CSS styling in a <style> tag, which I will be placing into the <head> of the document. Now you must know that I could do the exact same thing by using an external CSS file and linking it, or by styling individual elements using inline CSS. We will see what those are later. I think the main heading should be red, the subordinate headings should be green and the paragraphs should be orange. I also think the background should be a little off white. Let’s see how that translates into CSS.

body {
  background-color: #eee
}
h1 {
  color: red
}
h3 {
  color: green
}
p {
  color: orange
}

Now that we have styled our page, let’s take another look at it.

Looks like it works, although it is looking ugly. Anyways, what we have used here is the element selector of CSS which, not surprisingly, selects the elements matching the tag name and applies the properties defined for it.

ID and Class selectors

Now, there may be times when you have multiple elements with same tag names but you want to apply CSS properties to only specific element(s). That is where the ‘id’ and the ‘class’ selector comes in. Note that however, the class here does now refer to anything from your object oriented programming books. It only gives those elements with that class a particular grouping. You can use any one of ‘id’ and ‘class’ as per your liking for now, but conventionally, we use ‘id’ for uniquely identifying elements and ‘class’ for grouping similar elements. Technically, there is an additional difference of precedence here, with the ‘id’ having more precedence than ‘class’. My personal rule is that, for custom CSS use ‘id’, since frameworks like Bootstrap (which we will check out later on) usually use ‘class’.

Now we shall rewrite the document adding an id attribute to each tag name.

<body>
  <h1 id="logo">Awesome Site</h1>
  <h3 id="heading">A little heading</h3>
  <p id="content">A paragraph containing some text</p>
  <h3 id="other-heading">Some information</h3>
  <p id="other-content">More text...</p>
</body>

and we shall change the CSS accordingly

#logo {
  color: red
}
#heading {
  color: green
}
#other-heading {
  color: olive
}
#content {
  color: orange
}
#other-content {
  color: purple
}

The resulting page looks something like this, with each of the individual elements appearing in different color.

Note that we could have well written ‘class’ instead of ‘id’ in our document, but then instead of #logo it would have been .logo, which is the class selector. Having learnt two selectors, we can now combine them to get the desired result. For example, h3#heading { color: blue; } would turn blue all the h3 tags that have a id=”heading” attribute declared. Similarly, h3.heading { color: blue; } would result in the same thing to all the h3 tags with class=”heading”.

Group selectors

Group selectors are used to apply properties to multiple elements at once. Multiple elements are separated by commas.

#logo {
  color: red
}
#heading {
  color: green
}
#other-heading {
  color: olive
}
#content {
  color: orange
}
#other-content {
  color: purple
}
/* Selecting all three tag names at once. */
h1, h3, p {
  background-color: yellow
}

Which will look like

Descendant selectors

Sometimes, CSS properties needs to be applied only to tags within a specific tag or id. In such situations, the descendant selector comes in handy.

<!DOCTYPE html>
<html>
<head>
  <title>Testing</title>
  <style>
    ul em {
      font-size: 1.25em
    }
  </style>
</head>
<body>
  <p>Look what I've <em>got for ya!</em></p>
  <p>
    <ul>
      <li>item 1</li>
      <li>item 2</li>
      <li>item 3</li>
      <li><em>this looks abnormal</em></li>
      <li>item 5</li>
    </ul>
  <p>
</body>
</html>

And this will render

Look how the emphasis at the top is normal but the one in the ‘ul’ is enlarged. There is another similar selector called the child selector. It works similar to descendant selector but demands the child to be DIRECT descendant of the parent. For example, p > a { color: green; } will cause only the anchors directly children to any paragraph to look green. These are the various selectors that you would see and probably use when dealing with web applications. Simple enough, aren’t they?

<div> and <span>

Although div and span are html tags, any modern web application that you will write will heavily make use of these to group sections of the web page together. You might be familiar with the layouts of most websites these days, with a header on top, one or two column in the center with content and other options, and a footer at the bottom. Even on my blog, you’ll notice these three things. How are they made, and how to make them look so distinct that on the first glance, your visitors know what their purpose is. The answer lies in making proper divs and adding appropriate CSS to it. Div is a block element, which means that it is used to style multiple elements at once. Span, on the other hand, is inline, that is, it is used to style little chunks of content.

I will write the 4 sections of a website I mentioned earlier, using divs. Read the code and you would understand what is happening.

<!DOCTYPE html>
<html>
<head>
  <title>Testing</title>
  <style>
    * {
      text-align: center 
    }
    #header {
      background-color: red
      height: 50px
    }
    #container {
      width: auto
      margin: 0 auto
    }
    #body {
      width: 75%
      float: left
      background-color: grey
    }
    #side {
      width: 25%
      float: right
      background-color: blue
    }
    #footer {
      background-color: green
    }
  </style>
</head>
<body>
  <div id="header"><h3>Header Text</h3></div>
  <div id="container">
    <div id="body"><p>Content goes here</p></div>
    <div id="side"><p>Sidebar</p></div>
  </div>
  <div id="footer"><p>Copyrights</p></div>
</body>
</html>

This sure looks beautiful, doesn’t it?

This completes the CSS syntax part. I did mention that you can write all your CSS in a file.css and include them in your document head with <link href="/assets/style.css" rel="stylesheet"> so that it is easier to maintain the code. There is yet another way to add CSS, which makes use of @import syntax. It is better avoided for the linked reasons.

Now that you are well equipped with the necessary things to learn some actual and practical CSS, you must be really excited to read from w3schools. It is a great site to begin, and since it comes on top each time you search for anything related to CSS (or web programming, for that matter), you may use it as your sole reference guide. Nothing bad, but keep in mind that after leaving your nutshell, you should avoid that site, and start using some reputed docs instead, like the ones from Mozilla.

CSS Frameworks

To speed up the development process, you might want to check out some libraries out there that would ease your life. One of the best is Bootstrap. It would enable you to do rapid development, with minimal typing. Bootstrap comes with jQuery, a Javascript library which also helps a lot dealing with web application stuff you are about to deal with. There is not much point reading the official docs if you only want to get the work done. Instead, I would suggest you to Google out things, pick up code on the way, keep going. That is exactly how I used to do stuff back then, when I hated to write CSS and HTML. Bad advice, but gets the job done most of the times.

Outro

CSS is amazing. Web is amazing. Today is a time when you either have to love the web, or keep fighting a losing battle convincing yourself that you don’t need it. Either way, knowing a thing or two about how the web pages that you spend more than half of your time on, are styled, is always a plus. As always, for anything, the comment box is always there. Corrections, please. Liked the article? Suggest it to your friends! Thank you for reading.