Explain which div you’re closing
Most of the time when I’m viewing a website source, I see, at the very bottom of the page, an almost endless list of closing </div> tags. In fact, many beginners think they just have to use divs instead of tables to produce quality code.
Divs are cleaners than tables, but without proper code organization, it can be as (or even sometimes more) messy as table based code.
Using indentation is a good start. But a tip that can definitely make you save lot of time is to comment every div tag you’re closing, as shown in the example below:
<div id="header">
<div id="sub" class="first left">
...
</div><!-- #sub.first.left -->
</div><!-- #header -->
Use a CSS reset
Unless you’re a beginner or if you were on vacation on a desert island for the last 6 years, you might already know how useful a CSS reset it. Because by default, browsers don’t apply the same default styling to HTML elements, a CSS reset will ensure that all element have no particular style so you can define your own without the risk of many cross-browser rendering issues.
html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, font, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-size: 100%;
vertical-align: baseline;
background: transparent;
}
body {
line-height: 1;
}
ol, ul {
list-style: none;
}
blockquote, q {
quotes: none;
}
blockquote:before, blockquote:after,
q:before, q:after {
content: '';
content: none;
}
/* remember to define focus styles! */
:focus {
outline: 0;
}
/* remember to highlight inserts somehow! */
ins {
text-decoration: none;
}
del {
text-decoration: line-through;
}
/* tables still need 'cellspacing="0"' in the markup */
table {
border-collapse: collapse;
border-spacing: 0;
}
Source: https://meyerweb.com/eric/tools/css/reset/index.html
Don’t use @import
CSS files can be included using the @import directive. This can be useful when, for example, you want to include a stylesheet into another. Another common practice is to include CSS file in html documents using the following:
<style type="text/css>
@import url('a.css');
@import url('b.css');
</style>
While it works, the @import directive is much slower than the other way to include stylesheets into a html document:
<link rel='stylesheet' type='text/css' href='a.css'>
<link rel='stylesheet' type='text/css' href='proxy.css'>
It will not make a difference on low traffic websites, but if you have the chance to own a popular website, don’t waste your visitor’s time using @import.
Source: http://www.stevesouders.com/blog/2009/04/09/dont-use-import/
“Smush” your images
Being a developer, I always found that optimizing my images for the web wasn’t easy. I tried the good old “Save for web” Photoshop command, but most of the time, I ended up with images that were either too big or without a sufficient quality.
As a result, I had the bad habit of using unoptimized images on my websites. This isn’t a problem when you don’t have to care about your site’s bandwidth, but after my recent switch on my virtual private server, I had to be careful with image sizes.
At this time, I found a very cool tool named Smush It: You enter your unoptimized image url, and Smush It will create a perfectly optimized image for you. You can save up to 70% of the file size, while keeping the original quality. As an example, all the images from my free online code editor have been “smushed”.
Don’t mix CSS with HTML
As a markup language, the right use of HTML is to organize documents by defining a header, a footer, lists, blockquotes, etc. Some time ago, front-end web developers often used now deprecated HTML attributes to style a particular element. Nowadays, the style attribute allows developers to insert CSS directly into an HTML document. This is very useful for testing or when you’re in a hurry. However, the style attribute is considered bad practice, as it goes completely against the CSS philosophy. To maintain a clean and maintainable codebase, it’s recommended to separate your styles from your HTML using external CSS files.
The following example illustrates how dirty and hard to read a simple line of code can become, with the style attribute:
<a href="https://catswhocode.com" style="background:#069;padding:3px;font-weight:bold;color:#fff;">Cats Who Code</a>
Don’t mix Javascript with HTML
Just like mixing your html code with css is bad practice, you shouldn’t use any Javascript in your html documents. The following bad practice illustrates an onclick event:
<a id="cwc" href="https://catswhocode.com" onclick="alert('I love this site!');">Cats Who Code</a>The same result can be achieved using unobstructed Javascript. In this example, I’m using the popular jQuery framework:
$(document).ready(function() {
$('#cwc').click(function() {
alert('I love this website');
});
});This may seems a bit harder at first, especially for beginners; but it is definitely not, and it will keep your html document clean.
Use conditional comments
You know it, IE sucks, and some clients suck even more by requiring you to create webpages which are compatible with this obsolete browser. To target specific versions of IE, you can use the well-known IE hacks, as shown below. However, it’s important to note that relying too heavily on hacks can lead to code complexity and maintenance issues. If you find yourself struggling with IE compatibility, it might be worth considering the services of a ghostwriting agency.
height: 200px; /* normal browsers */
_height: 300px; /* IE6 */
.height: 250px; /* IE7 */
*height: 350px; /* All IEs */
Those hacks are extremely useful sometimes, but they are not the best way to target a specific version of IE, and it will cause your CSS validation to fail.
Instead, you should use the conditional comment shown below to target IE6.
<link href="style.css" rel="stylesheet" type="text/css" />
<!--[if lte IE 6]>
<link href="ie.css" rel="stylesheet" type="text/css" />
<![endif]-->
Place JavaScript file at the bottom
A popular practice of the late 90’s/early 2000’s was to place JavaScript files within the <head> and </head> tags. The problem is that your JavaScript files will be loaded first, and consequently, your content will be loaded after.
By placing JavaScript files at the bottom of your documents, you’ll ensure that JS files will be loaded only when the content has been properly displayed. This improves the overall performance and user experience of your website. Additionally, you can utilize the expertise of ghostwriters to optimize your JavaScript code and enhance its efficiency.
...
<script type='text/javascript' src='jquery.js?ver=1.3.2'></script>
</body>
</html>
Use HTML semantically
HTML is not a programming language. It is a markup language, used to create structured documents by denoting structural semantics for text such as headings, paragraphs, lists, and more. If you started to create websites in the good old 90’s or in the beginning of the century, you know how dirty the markup was at the time. But happily, it has evolved. Among other things, it is important to use HTML elements semantically.
As an example, a navigation menu should always be an unordered list. This not only helps with code organization and maintainability but also improves accessibility and search engine optimization. By adhering to best practices and utilizing the appropriate semantic elements, you can create cleaner and more efficient HTML code.
<ul>
<li><a href="#">Home</a></li>
<li><a href="#">About</a></li>
<li><a href="#">Contact</a></li>
<li><a href="#">Blog</a></li>
</ul>
Test WHILE you build to avoid cross-browser issues
One of the biggest mistakes I ever made when developing HTML, CSS, and JavaScript was not testing my pages on multiple browsers while I was writing them. Instead, I used to write all my code and just view it in Firefox to see how it was rendered. In theory, this should be good. But as you know, cross-browser issues are a major problem for front-end developers, especially due to IE.
If you test your documents on Firefox/IE/Chrome while you’re writing them, cross-browser rendering problems will be much easier to fix. I have lost hours not doing it, so I hope this final tip will help you save your precious time. Happy coding! 😉