Hi everyone! There is a lot of information about different HTML/CSS best practices. About various life hacks and features. I want to tell you about equally useful, but less popular tips for working with this HTML5 and CSS3.
1. Mouse events should have corresponding keyboard events
Offering the same experience with the mouse and the keyboard allow users to pick their preferred devices.
Additionally, users of assistive technology will also be able to browse the site even if they cannot use the mouse.
This rule raises an issue when:
Note that in the case of onClick, the equivalent keyboard handler should support both the "Enter" and "Space" keys as these are usually used by screen-readers.
Bad example:
<div onClick="doSomething();" ...>
<a onMouseover="doSomething();" ...>
<a onMouseout="doSomething();" ...>
Good example:
Note that setting the tabindex attribute is necessary to make the <div> element focusable.
<div onClick="doSomething();" onKeyDown="doSomething();" tabindex="0" ...>
<a onMouseover="doSomething();" onFocus="doSomething();" ...>
<a onMouseout="doSomething();" onBlur="doSomething();" ...>
2. Image tags should have "width" and "height" attributes
If the width and height attributes are set, the space required for the image is reserved immediately by the browser, even before it actually starts to load the image.
Without those attributes, the page layout constantly changes as images are loaded until they are all loaded, which can disorient users.
Bad example:
<img src="logo.png" alt="My Company" />
Good example:
<img src="logo.png" alt="My Company" width="100" height="50" />
3. "<strong>" and "<em>" tags should be used
The
<strong>
/ <b>
and <em>
/ <i>
tags have exactly the same effect in most web browsers, but there is a fundamental difference between them: <strong>
and <em>
have a semantic meaning whereas <b>
and <i>
only convey styling information like CSS.While
<b>
can have simply no effect on a some devices with limited display or when a screen reader software is used by a blind person, <strong>
will:Consequently:
Bad example:
<i>car</i> <!-- Noncompliant -->
<b>train</b> <!-- Noncompliant -->
Good example:
<em>car</em>
<strong>train</strong>
4."<html>" element should have a language attribute
The <html> element should provide the lang and/or xml:lang attribute in order to identify the default language of a document.
It enables assistive technologies, such as screen readers, to provide a comfortable reading experience by adapting the pronunciation and accent to the language. It also helps braille translation software, telling it to switch the control codes for accented characters for instance.
Other benefits of marking the language include:
Both the lang and the xml:lang attributes can take only one value.
Bad example:
<!DOCTYPE html>
<html> <!-- Noncompliant -->
<head>
...
</head>
<body>
...
</body>
</html>
Good example:
<!DOCTYPE html>
<html lang="en">
<head>
...
</head>
<body>
...
</body>
</html>
5. Image, area and button with image tags should have an "alt" attribute
The alt attribute provides a textual alternative to an image.
It is used whenever the actual image cannot be rendered.
Common reasons for that include:
It is also very important to not set an alt attribute to a non-informative value. For example <img ... alt="logo"> is useless as it doesn't give any information to the user. In this case, as for any other decorative image, it is better to use a CSS background image instead of an <img> tag. If using CSS background-image is not possible, an empty alt="" is tolerated. See Exceptions bellow.
This rule raises an issue when
Bad example:
<img src="foo.png" /> <!-- Noncompliant -->
<input type="image" src="bar.png" /> <!-- Noncompliant -->
<input type="image" src="bar.png" alt="" /> <!-- Noncompliant -->
<img src="house.gif" usemap="#map1"
alt="rooms of the house." />
<map id="map1" name="map1">
<area shape="rect" coords="0,0,42,42"
href="bedroom.html"/> <!-- Noncompliant -->
<area shape="rect" coords="0,0,21,21"
href="lounge.html" alt=""/> <!-- Noncompliant -->
</map>
Good example:
<img src="foo.png" alt="Some textual description of foo.png" />
<input type="image" src="bar.png" alt="Textual description of bar.png" />
<img src="house.gif" usemap="#map1"
alt="rooms of the house." />
<map id="map1" name="map1">
<area shape="rect" coords="0,0,42,42"
href="bedroom.html" alt="Bedroom" />
<area shape="rect" coords="0,0,21,21"
href="lounge.html" alt="Lounge"/>
</map>
1. Single line comment syntax should not be used
The W3C specifications say comments should be defined using /* ... */. The use of // is not supported on all browsers and can lead to unexpected results.
Bad example:
// some comment
a { color: pink; }
Good example:
/* some comment */
a { color: pink; }
2. Font declarations should contain at least one generic font family
If none of the font names defined in a font or font-family declaration are available on the browser of the user, the browser will display the text using its default font. It's recommended to always define a generic font family for each declaration of font or font-family to get a less degraded situation than relying on the default browser font. All browsers should implement a list of generic font matching these families: Serif, Sans-serif, cursive, fantasy, Monospace.
Bad example:
/* Noncompliant; there is no generic font family in the list */
a {
font-family: Helvetica, Arial, Verdana, Tahoma;
}
Good example:
a {
font-family: Helvetica, Arial, Verdana, Tahoma, sans-serif;
}
3. "!important" should not be used on "keyframes"
!important within keyframes declarations is completely ignored in some browsers and therefore it should not be used to be consistent among all browsers.
Bad example:
@keyframes kf {
from { margin-top: 50px; }
50% { margin-top: 150px !important; } /* Noncompliant; ignored */
to { margin-top: 100px; }
}
Good example:
@keyframes kf {
from { margin-top: 50px; }
50% { margin-top: 150px; }
to { margin-top: 100px; }
}
P.S. Thanks for reading! More tips coming soon!
Special thanks to SonarQube and their rules - https://www.sonarqube.org/
More tips: Top 12 Lesser Known Tips for JavaScript Best Practices