📜 ⬆️ ⬇️

15 sure ways to break your CSS

Free Article 15 surefire ways to break your CSS . Posted by Rob Glazebrook. Italics are my additions.

Missing semicolon
CSS rules consist of pairs of descriptions - a property-value, separated by a semicolon. According to the CSS specification, the latter description may not end with a semicolon, because the brace separates the whole rule from the rest like a wall. For example:
body {
background-color: #444;
color: #eee
}

The only problem is that if you decide to add another description to the rule, you can easily forget to put a semicolon in the last description:
body {
background-color: #444;
color: #eee
font-family: Helvetica, Arial, sans-serif
}

As a result, the description of the font-family will never work, because the parser will consider the “font-family” part of the value of the color property. I always add the last semicolon - it somehow adds organization to the code. And a few extra bytes in the size of the css-file do not play a big role, especially when browser caching is enabled.


Missing colon
Typically, this error occurs if people are trained in typing speed on the keyboard, and not in writing CSS code. This error is very difficult to see, because it is in the middle of the line. Compare these two lines:
body { font-family Helvetica, Arial, sans-serif; }
body { font-family: Helvetica, Arial, sans-serif; }

')
Missing brace
{Curly brackets} around CSS rules - this is how the life cycle is constant, natural and expected. And if you miss a curly bracket (usually closing, for any reason) - it's like you have a mummy who refuses to die (yes, the author I look is a jester and a merry fellow) - you will get chaos.

When the unsuspecting browser comes to parsing this pair of rules:
body {
font-family: Helvetica, Arial, sans-serif;
#wrap {
width: 960px; }

he just chokes. Two opening braces and only one closing: everything from #wrap (in this example) will be ignored. As you can see, the code highlighting parser did not cope with the task either.

It is very easy to correct such a mistake - just check that there is a closing brace before each new rule. As already noted, they mostly forget to put it down.

Mistakes in the name of the css-properties
Generally speaking, I am a competent person. However, when I am “in the process,” I type the text as quickly as my fingers cope with this task, and of course I sometimes make mistakes. In ordinary communication, mistakes are not very important - people can almost always determine what exactly I wanted to say. Unfortunately, the computer is more whimsical.
div { border-bototm: 5px; }

The easiest way to track such errors in editors who are able to highlight the code (awesome discovery and advice :)) . For example, Notepad ++ or Adobe Dreamweaver. If the property is not highlighted, then there is a syntax error in it.

Typos in Values
Typos are found not only in the names of properties. Sometimes they happen when writing values ​​and it can be harder to catch them:
#wrap { padding: 10px 20pz 25px 20px; }

As you can see a typo in the dimension - instead of px there is pz. Because of this, the whole rule does not work.

Typos in class names or IDs
It doesn't matter how often I created a div with the ID “navigation” - I still find these rules in my code:
#navigaiton { float: left; }

This annoying error is very difficult to catch, because even the code highlighting in the editors will not help here.
To avoid such errors - I very rarely type class names or identifiers when editing css-files manually. Ctrl + c from html and ctrl + v in css.

Wrong order of values
Some CSS properties are complex, i.e. You can write the values ​​of several properties separated by a single line space. Unfortunately, most of these properties are very demanding on the order of importance:
div { font: 2em Helvetica, Arial, sans-serif; }
a { font: "Times New Roman", serif 1.5em; }

The first rule is correct and the text of all divs will receive a specific style and size. The second rule is incorrect, since The order of properties is not followed.
The correct order of values ​​in such properties can be found in the CSS specification . By the way, I always confuse this order, so these properties usually also write copy-paste, i.e. copying from somewhere

Dimensions without unit
All measured properties must have values, with the indication of the unit of measurement:
#wrap { margin: 3; }

Three what? Ems? Inches? Pixels?
Pro units of measurement can also be viewed in the CSS specification.

Duplicate rules
In large CSS files there are completely the rules of the same elements. The last always works - then don't be surprised why the indent is not 2em, but 10px;
ul li { margin: 0 2em;
... ...
ul li { margin: 0; padding: 10px; }


Competing rules
A similar problem may occur when you do not expect it at all. For example, if you have the following XHTML:
<div id="navigation" class="nav">...</div>

You can refer to this element by class name or by id. The problem arises if both the class and id are referenced:
.nav { width: 50%; }
... ...
#navigation { width: 500px; }

The last rule that works is the same as in the previous paragraph.

We refer to the class as an ID (or vice versa)
This is probably my most frequent mistake - every time I confuse - to put a full stop or a lattice :) :
.navigation {
float: left;
width: 100%;
height: 4em; }

And nothing happens, because element has id = navigation, not a class.

Using non-existent properties
Not all CSS properties are intuitively named. For example:
body { text-size: 3em; }

The problem is that although the property is supposed to belong to text properties, font-size is used. Here, of course, again, code editors with the ability to highlight should help.

Use non-existent values
Error similar to the previous one:
td { vertical-align: center; }

To avoid such errors, carefully study the specification.

Incorrect property and value mapping
This CSS definition may seem correct even for a trained eye:
a { text-transform: italic; }

However, we see that the correct value is incorrectly assigned to the correct property.

Not closed comment
What not dislike about css is the lack of single-line comments.
Can you find differences in these two descriptions?
/* Navigation goes here. */
#nav {
float: left;
width: 100%;
height: 3em; }

/* Navigation goes here. /*
#nav {
float: left;
width: 100%;
height: 3em; }

The only difference is that in the second rule, the closing comment characters are: / * instead of * /. Accordingly, all the second rule will be commented out.

From myself I will add:
There are also errors associated with misunderstanding of the short spelling of complex properties of the margin, padding.
Here are some spelling examples:
div#mark {
margin: 0;
margin: 0 10px;
margin: 0 10px 6px;
margin: 8px 12px 10px 8px;
}

So - the general format of the values ​​of this property is as follows:
margin: [top] [right] [bottom] [left];
if not all values ​​are indicated, the following rules apply
 margin: [top] = margin: [top] [top] [top] [top];
 margin: [top] [right] = margin: [top] [right] [top] [right];
 margin: [top] [right] [bottom] = margin: [top] [right] [bottom] [right];

those. the previous example is identical
div#mark {
margin: 0 0 0 0;
margin: 0 10px 0 10px;
margin: 0 10px 6px 10px;
margin: 8px 12px 10px 8px;
}


To zero, the unit of measurement is optional, it is logical - doesn’t all equal zero units of what?

Thanks for attention. Read the documentation :)

Cross-post from my site (see profile)

Source: https://habr.com/ru/post/55683/


All Articles