paint-brush
Episode 32: How CSS works and what we aim for with CSS.by@thatdania
1,470 reads
1,470 reads

Episode 32: How CSS works and what we aim for with CSS.

by Dania MahDecember 5th, 2017
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Today, I’m going to be reflecting on a lot of theory and more behind the scenes. Not much <a href="https://hackernoon.com/tagged/css" target="_blank">CSS</a> code will happen but we will look at<strong> how CSS works and what we should aim for when coding with CSS.</strong>

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Episode 32: How CSS works and what we aim for with CSS.
Dania Mah HackerNoon profile picture

Today, I’m going to be reflecting on a lot of theory and more behind the scenes. Not much CSS code will happen but we will look at how CSS works and what we should aim for when coding with CSS.

Although hitting the books may seem a boring thing, it is good knowledge to understand and conceptualise what CSS is doing with its code and how we can then make code-decisions based on this knowledge.

I’ll try make it interesting, I promise. Note the word : try.

HOW are our CSS files are loaded?:

Other questions that could also apply to this are “where does CSS get loaded when all the other code such as HTML is getting loaded’ , “where does CSS go to in our server” and “how does CSS connect to everything?” There could be more questions, I’m just stating a few.

We know that our CSS connects to our HTML files and thus, we can conclude that the CSS and HTML get loaded in our browser. In short, in the world of the Web, data goes in and out of browsers and servers. The browser is what we see on the page (hasn’t google Chrome or any internet explorer mentioned to open your browser?) and the server is where data is stored in a bunch of computers some place, somewhere. Since, CSS and HTML are our files that we see on screen — yeah, it is in our browser.

Thus, in the browser, this is all how it takes place:

  • Firstly, the html file loads and gets decoded.
  • Whilst the html file is getting decoded, the CSS file is loaded and decoded.
  • In the CSS decoding, the CSS processes the values it’s been given and conflicting declarations.

You know how we can call the property “font-weight” on multiple classes. CSS dealing with “conflicting declarations” means that it’ll say okay “for button class, the font-weight is 200px and for the text class, font-weight is 400px. It basically differentiates the properties and values dependant on their classes. This is as an example only, there could be other cases.

Another case could also be when we are confronted with different stylesheets. A css file is basically a style sheet. A browser has its own default stylesheet. So, how will the browser choose between our style sheet and the default stylesheet. Not too sure about this, but there must be conditions to pick one over the other.

Furthermore, this part is also how a User’s action on a stylesheet is differentiated to the Author’s stylesheet (the stylesheet you make). For example, what if the user could input their colour the background can change to. Will our stylesheet be overwritten or not? It depends on the code we write and in one precedence right? That’s kind of the concept I believe and it make sense for this step to be here.

- For both HTML and CSS, after the decoding has happened, the html and css maps out into what some call “a family of trees.” As HTML and CSS has stuff like parent classes, parent elements, child classes, child elements and so on, this family tree is then mapped out and gets stored into two files.

For HTML, it is DOM (Document Object Model)

For CSS, it is CSSOM (CSS Object Model)

  • The DOM and CSSOM get rendered into a “family tree”
  • This “family-tree” then gets implemented onto the chosen browser. This step is where all the positioning, alignment happens dependant on the browser’s size. After all, we could be looking at our files on a computer or phone these days
  • Finally, it renders the window and we see the result of the HTML and CSS!

All this is happening in seconds as we normally see our website load instantly! How crazy is that! Computers outshine our labour any-day!

CSS PRECEDENCE:

I have come to the conclusion that all coding languages or most have this thing called precedence. In other words, “an order of priority” of how things get loaded. I found this quite vital information as it help us understand what css code is being called. This could be very handy when we hit a problem.

Note: All of this happens in the stage of when our CSS code is being decoded. This is probably something basic I should mention and start using now, but hey we’re all learning here. In our CSS code, the class/id name we’re calling is known as the Selector. The css property section is call the Declaration.

Let’s repeat.

body is the Selector , the {} is the declaration and the stuff inside the declaration are the properties called.

Like a card game, where some signs and numbers have higher precedence (9 beats 5, hearts beat diamonds), there is an order of elements that are more powerful than the other.

  • inline styling (Most powerful)
  • ids
  • classes
  • elements (least powerful)

Inline styling:

I believe what the course meant is that you can actually inline style the priority of the object that is being called which is !important . If we write !important in one of that declaration, the computer will put that in high regard of precedence over the other. For instance,tgi

no1priority {

font-weight: 200px !important

}

It is said to use !important only if necessary. Otherwise, in a state of emergency of last resort as precedence can be handled in calling the amount of ids and classes.

Ids & Classes

We can call selectors by the id. In our html file, we can set an id to an element like this:

<div id=“no1priority” class=“2priority> Hello </div>

Right? In css, we can call the id by putting a hash in front of the selector as such:

#no1priority {

font-weight: 30 px

}

Classes are the same, we can call classes in our selector as such:

.no 2 priority {

font-weight : 20 px

}

Don’t forget that we can call multiple ids and classes on a div or any other element as well. This is how the CS

Elements:

Things like headers, paragraphs or any other element can be called as such. These are the last in priority.

p {


font-weight: 10px}

THE THREE THINGS A CSS DEVELOPER AIMS FOR:

I’d like to think these are mantras and goals that every person should follow for CSS. Just like how a goal of writing code is to keep it simple/minimal, CSS has it’s own set of “should follow” rules or goals to aim for. Although one could set many goals when writing CSS, there are surprisingly only 3 main pillars everyone should follow. Although, these three pillars are like the pillars you see in the V&A museum, which is probably 100 times the average human size. Let’s get to it.

1. Responsive Design:

GO figure! It should be obvious that we need to have this in mind when creating our website, as most of the animations are what makes our website responsive! This is where design comes in handy because you want to make decisions that are only necessary for our elements in our CSS, and not over-do it. The goal of responsive design is so that the products we create are engaging but easy for the user.

Is Responsive Design a skill in itself? Yes, it is ( It’s something I’m not fully skilled at either even though I went to design school) Do we need this knowledge in CSS? Absolutely, as we have to balance functionality with appearance when serving up a CSS file.

These are the following pointers I grabbed the basis of what was vital in Responsive Design. Although I have so much to learn about it as well, everyone starts somewhere….

Fluid Layouts

It seems explanatory when you think about it from a responsive design perspective. We want out layouts to be fluid for any screen size whether it is for a computer, laptop or screen. Our goal here is to create wrappers (what wraps around your content), columns or content that can fit any display our app is displayed on.

CSS media queries

In this case, I found that a “media query” also written as “@media screen” in CSS helps us change our website’s design based on the display it’s presented on. It allows us to set a new set of rules to when it’s displayed on a different screen.

Responsive Images

As our website will be displayed on different screens and thus, our designs will change, our images need to change as well. We need to make sure the quality and ratio of the image is kept when we are resizing our website in different displays. Duh.

Correct Units:

This is basically a memory game of what units are used for what properties, and when we use these units, we know what percentages of units they are relating for. Probably best to remember it of by heart, but don’t sweat it, I believe it comes with experience.

Desktop first or Mobile First:

This is more of a design strategy stand-point for every website. Whether the design prioritises over desktops or mobiles, of even these days tablets. Which is going to be the main design, and which is going to be the fluid layout (by which I mean, our adaptation of the layout). It makes sense conceptually because if you know your website/app or any digital product is going to be exposed more on desktops, you would want the priority of the styling to be for the desktop rather than the mobile.

How to strategise for this is yet a mystery for me to figure out? I read these articles to get a better sense of what the course was talking about. I’ll post them here for those with a curious mind:

https://kyleschaeffer.com/development/responsive-layouts-using-css-media-queries/


CSS Units_Well organized and easy to understand Web building tutorials with lots of examples of how to use HTML, CSS, JavaScript…_www.w3schools.com

2. Maintainable and Scalable code:

For any developer who is going to work with your code (most likely), our code should be easy to read and follow to a person with barely any code knowledge but the basics. This means the following:

  • Our code is clean (no comments, no mismatched names, etc..)
  • Our code is easy to understand (the order of which we code should be according to our html file)
  • Our code should be reusable (in case someone wants to use it for another product or website the company is making)
  • Our code should be organised in the correct files (Those files should be ordered in the right way. Everything should be named correctly and everything should be in its place)
  • Our HTML should be structured (Things in the head belong in the head, whilst things in our body belongs in our body unless it really needs to happen)

3. Web performance:

Code is constantly being run through and out of severs everyday. That’s let alone for one website, and now think about the millions of websites that exist on the browser today. The supply of websites are so high that how is our website we designed for ever going to stand out? Where does it even stand a chance! At this point, let’s ignore the fact that there’s a whole marketing/branding aspect that comes into this as well.

Apart from that note, how else can we make our website stand out?

  • Less code

This is a good one to start with as the less code our CSS has, the shorter time it will take to render. What happens if we need a large amount of code?

  • Compressed code

Exactly! We don’t want to sacrifice our actual code that is needed so it can render on a page. What else we can do to compress our code?

  • Use a CSS processor (SASS)

Yes, by having a CSS processor known as SASS to help us compress our code is a useful thing to have. It’ll mean less code to render for the server and browser. What else!

  • Less HTTP requests

That’s another good one. The less amount of times we have to request from out HTTP, the better. It’s almost like reducing the amount of actions our server, browser has to do in order to output our code. Less requests means less work and faster rebuttal.

  • Less & compressed images.

Images are probably the number one thing that takes up a lot of GIG. By which I mean, a lot of space (Gigabytes, bytes get it?). It takes up a lot of memory, thus making it longer to decode our CSS. We should aim to compress our images and choose carefully which of the images we need to brand or showcase the website we’re designing for. This is probably vital that I can imagine many will forget.

Hope that theory was as direct as it could be. Comment below on any thoughts and see ya next time (maybe in the next few days, as I have to get back to reflecting on the bootcamp)

FUN FACT OF THE DAY:

I always believed in this concept that if you think of an idea hard enough, it gets sent to this aura cloud where a few people will pick up. I’m not crazy, i’m pretty sure this is a legit concept. This is why in art university, when you were having crits about the same project, three people executed ideas that you came up with but didn’t.

I was sitting alone at lunch today. I’m the mainstream group of people who hate sitting alone. I was thinking about it so hard, I was actually delaying my time of opening my meal. The moment I do, a friend taps me on the shoulder and comes to join me. Someone felt my aura and came in the right time, what are the chances of that!? I can tell you, slim.