    
|
|
|
Welcome to the second part of my IndexedDB article. I strongly recommend reading the first article in this series, as I’ll be assuming you are familiar with all the concepts covered so far. In this article, we’re going to wrap up the CRUD aspects we didn’t finish before (specifically updating and deleting content), and then demonstrate a real world application that we will use to demonstrate other concepts in the final article.
Let’s start off by discussing how to update a record with IndexedDB. If you remember, adding data was pretty simple:
//Define a person
var person = {
name:name,
email:email,
created:new Date()
}
//Perform the add
var request = store.add(person);
Updating a record is just as simple. Assuming that you have defined a property called id as your key for your object store, you can simply use the put method instead of add.
var person = {
name:name,
email:email,
created:new Date(),
id:someId
}
//Perform the update
var request = store.put(person);
Like the add method, you can assign methods to handle the asynchronous results of the operation.
Deleting records is done via the delete method. (Big surprise there.) You simply pass in the unique identifer of the record you want to remove. Here is a simple example:
var t = db.transaction(["people"], "readwrite");
var request = t.objectStore("people").delete(thisId);
And like every other aspect of IndexedDB, you can add your handles for the asynchronous results.
So, as I said, not terribly exciting, which is probably good. You want your APIs simple, boring, and unsurprising. Now let’s take what we’ve learned and bring it together to create a real, if simple, application.
Ok, finally we have all (well, most) of the parts we need to build a real application. Since it hasn’t been done before (ahem), we are going to build a simple note taking application. Let’s look at a few screen shots and then I’ll show you the code behind it. On launch, the application initializes an IndexedDB for the application and renders an empty table. Initially, all you can do with the application is add a new note. (We could make this a bit more user friendly perhaps.)
Clicking the Add Note button opens a form:
After entering some data in the form, you can then save the note:
As you can see, you have the option to edit and delete notes. Finally, if you click the row itself, you can read the note:
So not exactly rocket science, but a full working example of the IndexedDB specification. The notes written here will persist. You can close your browser, restart your machine, take a few years off to contemplate life and poetry, and when you open the browser again your data will still be there. Let’s take a look at the code now.
First – a disclaimer. This application would have been a perfect candidate for one of the many JavaScript frameworks. I’m sure those of you who use Backbone or Angular can already imagine how you would set this up. However – I made the bold decision here to not use a framework. I was worried both about the people who may use a different framework and those who use none. I wanted our focus here to be on the IndexedDB aspects alone. I fully expect some people to disagree with that decision, but let’s hash it out in the comments.
Our first template is the HTML file. We’ve only got one and most of it is boilerplate Bootstrap:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Note Database</title>
<link href="bootstrap/css/bootstrap.css" rel="stylesheet">
<link href="css/app.css" rel="stylesheet">
</head>
<body>
<div class="navbar navbar-inverse navbar-fixed-top">
<div class="container">
<div class="navbar-header">
<a class="navbar-brand" href="#">Note Database</a>
</div>
</div>
</div>
<div class="container">
<div id="noteList"></div>
<div class="pull-right"><button id="addNoteButton" class="btn btn-success">Add Note</button></div>
<div id="noteDetail"></div>
<div id="noteForm">
<h2>Edit Note</h2>
<form role="form" class="form-horizontal">
<input type="hidden" id="key">
<div class="form-group">
<label for="title" class="col-lg-2 control-label">Title</label>
<div class="col-lg-10">
<input type="text" id="title" required class="form-control">
</div>
</div>
<div class="form-group">
<label for="body" class="col-lg-2 control-label">Body</label>
<div class="col-lg-10">
<textarea id="body" required class="form-control"></textarea>
</div>
</div>
<div class="form-group">
<div class="col-lg-offset-2 col-lg-10">
<button id="saveNoteButton" class="btn btn-default">Save Note</button>
</div>
</div>
</form>
</div>
</div>
<script src="js/jquery-2.0.0.min.js"></script>
<script src="bootstrap/js/bootstrap.min.js"></script>
<script src="js/app.js"></script>
</body>
</html>
As mentioned above, a good size portion of this file is template code for Bootstrap. The parts we care about are the noteList div, the noteDetail div, and the noteForm. You can probably guess that these are the DIVs we’ll be updating as the user clicks around in the application.
Now let’s take a look at app.js, the core file that handles the logic for our application.
/* global console,$,document,window,alert */
var db;
function dtFormat(input) {
if(!input) return "";
var res = (input.getMonth()+1) + "/" + input.getDate() + "/" + input.getFullYear() + " ";
var hour = input.getHours();
var ampm = "AM";
if(hour === 12) ampm = "PM";
if(hour > 12){
hour-=12;
ampm = "PM";
}
var minute = input.getMinutes()+1;
if(minute < 10) minute = "0" + minute;
res += hour + ":" + minute + " " + ampm;
return res;
}
You can ignore the first function as it is simply a format utility for dates. Let’s skip ahead to the jQuery document ready block.
$(document).ready(function() {
if(!("indexedDB" in window)) {
alert("IndexedDB support required for this demo!");
return;
}
var $noteDetail = $("#noteDetail");
var $noteForm = $("#noteForm");
var openRequest = window.indexedDB.open("nettuts_notes_1",1);
openRequest.onerror = function(e) {
console.log("Error opening db");
console.dir(e);
};
openRequest.onupgradeneeded = function(e) {
var thisDb = e.target.result;
var objectStore;
//Create Note OS
if(!thisDb.objectStoreNames.contains("note")) {
console.log("I need to make the note objectstore");
objectStore = thisDb.createObjectStore("note", { keyPath: "id", autoIncrement:true });
}
};
openRequest.onsuccess = function(e) {
db = e.target.result;
db.onerror = function(event) {
// Generic error handler for all errors targeted at this database's
// requests!
alert("Database error: " + event.target.errorCode);
console.dir(event.target);
};
displayNotes();
};
Our very first action is to check for IndexedDB support. If the user’s browser isn’t compatible, we use an alert and abort the function. It would probably be better to relocate them to a page that fully explains why they can’t use the application. (And to be clear, we could also build an application that made use of WebSQL as a backup. But again – my focus here is on simplicity.)
After caching a few jQuery selectors, that we’ll use throughout the app, we then open up our IndexedDB database. The database is fairly simple. In the onupgradeneeded handler you can see one object store called notes being created. Once everything is done, the onsuccess handler will fire off a call to displayNotes.
displayNotes Function function displayNotes() {
var transaction = db.transaction(["note"], "readonly");
var content="<table class='table table-bordered table-striped'><thead><tr><th>Title</th><th>Updated</th><th>&nbsp;</td></thead><tbody>";
transaction.oncomplete = function(event) {
$("#noteList").html(content);
};
var handleResult = function(event) {
var cursor = event.target.result;
if (cursor) {
content += "<tr data-key=\""+cursor.key+"\"><td class=\"notetitle\">"+cursor.value.title+"</td>";
content += "<td>"+dtFormat(cursor.value.updated)+"</td>";
content += "<td><a class=\"btn btn-primary edit\">Edit</a> <a class=\"btn btn-danger delete\">Delete</a></td>";
content +="</tr>";
cursor.continue();
}
else {
content += "</tbody></table>";
}
};
var objectStore = transaction.objectStore("note");
objectStore.openCursor().onsuccess = handleResult;
}
The displayNotes function does what you expect – get all the data and display it. We discussed how to get all rows of data in the previous entry, but I want to point out something slightly different about this example. Note that we have a new event handler, oncomplete, that we’ve tied to the transaction itself. Previously, we’ve used events just within the actions, inside the transaction, but IndexedDB lets us do it at the top level as well. This becomes especially useful in a case like this. We have a giant string, our HTML table, that we build up over each iteration of our data. We can use the transaction’s oncomplete handler to wrap up the display portion and write it out using a simple jQuery call.
Delete, Edit, and Add Functions $("#noteList").on("click", "a.delete", function(e) {
var thisId = $(this).parent().parent().data("key");
var t = db.transaction(["note"], "readwrite");
var request = t.objectStore("note").delete(thisId);
t.oncomplete = function(event) {
displayNotes();
$noteDetail.hide();
$noteForm.hide();
};
return false;
});
$("#noteList").on("click", "a.edit", function(e) {
var thisId = $(this).parent().parent().data("key");
var request = db.transaction(["note"], "readwrite")
.objectStore("note")
.get(thisId);
request.onsuccess = function(event) {
var note = request.result;
$("#key").val(note.id);
$("#title").val(note.title);
$("#body").val(note.body);
$noteDetail.hide();
$noteForm.show();
};
return false;
});
$("#noteList").on("click", "td", function() {
var thisId = $(this).parent().data("key");
var transaction = db.transaction(["note"]);
var objectStore = transaction.objectStore("note");
var request = objectStore.get(thisId);
request.onsuccess = function(event) {
var note = request.result;
$noteDetail.html("<h2>"+note.title+"</h2><p>"+note.body+"</p>").show();
$noteForm.hide();
};
});
$("#addNoteButton").on("click", function(e) {
$("#title").val("");
$("#body").val("");
$("#key").val("");
$noteDetail.hide();
$noteForm.show();
});
Our next two methods (delete and edit) is another example of this same principal. Since none of the IndexedDB calls here are new, we won’t bother going over them. Most of the “meat” here ends up being simple DOM manipulation to handle the particular actions. The handler for clicking the add button is exactly that, so we’ll skip over that as well.
Save Function $("#saveNoteButton").on("click",function() {
var title = $("#title").val();
var body = $("#body").val();
var key = $("#key").val();
var t = db.transaction(["note"], "readwrite");
if(key === "") {
t.objectStore("note")
.add({title:title,body:body,updated:new Date()});
} else {
t.objectStore("note")
.put({title:title,body:body,updated:new Date(),id:Number(key)});
}
t.oncomplete = function(event) {
$("#key").val("");
$("#title").val("");
$("#body").val("");
displayNotes();
$noteForm.hide();
};
return false;
});
});
The next interesting tidbit is the save method. It has to use a bit of logic to determine if we are adding or updating, but even that is rather simple. And that’s it! A complete, if simple, IndexedDB application. You can play around with this demo yourself by downloading the attached source code.
That’s it for part two! The third article will take this application and begin adding additional features including search and array based properties.
]]>As many of you know, UMBC has had a large number of phishing attacks in the past few weeks. This has resulted in a number of compromised accounts which the attackers are using to setup fake web pages and send out large volumes of spam. In an attempt to better protect accounts from fake web pages, DoIT will be removing permissions from user AFS web volumes for accounts not currently using their web space (http://userpages.umbc.edu/~username).
This will not affect anyone who currently has a web page or stop anyone from creating a web page, but will stop automated attacks and make it more difficult for attackers to setup web pages on people’s accounts. The permission change is minor, and can be easily reversed by anyone wishing to use their web space moving forward.
Directions for how to re-enable your web directory, as well as general information regarding using userpages, can be found at https://wiki.umbc.edu/pages/viewpage.action?pageId=31195980. If you have questions or concerns please contact the Technology Support Center (x53838) and they will be happy to assist you.
|
|
|
|
As you know, there is a lot more to building responsive websites than width. You need sensors that give you feedback to adjust sites based on other factors.
The best way to improve our feedback from your user’s sensor, or browser, is by using a JavaScript library called Modernizr. In this article I’ll explain why, when you go beyond width, Modernizr is such an invaluable tool.
In front-end development, developers used to adjust a site to fit the constraints of the layout engine used by a particular browser. In 2003, there were only three browsers: Netscape, Internet Explorer, and Opera. Firefox, Safari, and the first mobile browser, Opera Mini, were released by 2005. Chrome wasn’t released until 2008.
Currently there are five major browsers, each with its own mobile version. Across that array of browsers, there are also older versions that users haven’t upgraded. In the same way that creating multiple layouts for multiple screen sizes eventually becomes a zero sum game, so does building multiple front-ends for multiple browsers.
We’re using responsive web design to accommodate new, cutting edge mobile browsers. But, while accommodating new browsers, it’s important not to do so at the expense of older browsers.
Historically, optimization has come as a product of building a site for the most popular browsers and then tweaking to ensure the site looks the same on a set of popular browsers. Designs would have to accommodate the capabilities of all browsers.
Progressive enhancement is one strategy to cope with browsers’ failure to support modern features. There is a temptation to build for the most up-to-date features, but, in a responsive web, the design of a site is contextual to the frame that it’s being viewed through. Responsive web design has become popular because it resolves the most obvious changing context — the size of the frame — but the context of a browser runs much deeper than it’s viewport size.
SVG makes for a great solution for high-resolution displays, but what about its support in older browsers? It’s not supported in IE 8 or older, so you have to build in a fallback if you support that browser. You could identify the browser and serve alternative styles against that browser but then you would have to serve those same alternative styles for every browser that doesn’t support SVG.
Wouldn’t it be easier if you could just write a style that would be used against every browser that didn’t support SVG? That way, you wouldn’t have to keep up with bug reports from the users of older versions. You could just set the fallback once and forget it.
Traditionally, feature detection has been accomplished by detecting the browser’s user agent. This is done through JavaScript, using the navigator object. The navigator object dates back to the Netscape days and used to be a developer’s best tool in cross-browser compatibility.
If you have Chrome and have enabled DevTools, open your browser’s web inspector by right-clicking on a page and selecting Inspect Element. Then, click on Console and, after the caret, type “navigator.userAgent” and hit Enter. This will return your current browser’s user-agent, which is a string of text used to identify the browser in use. Chrome returns the following:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.35 (KHTML, like Gecko) Chrome/27.0.1443.2 Safari/537.35
In a lot of ways, the navigator object is the one of the best sensors we have available to us to inform our system about what our user is capable of; however, it’s not very future friendly. It bases your site’s actuators on a lot of assumptions about what the browser does and does not support. It also is unreliable because users can configure it to access sites that the browser might not be able to support.
Modernizr is a JavaScript library used to detect features in the browser. It’s loaded in the head of your page and runs during a page load. Adding it to your site is as simple as adding any other JavaScript library, such as jQuery, but, once added, Modernizer gives you an incredible amount of control in rendering your page and ensuring that every user is served a quality experience.
Having been loaded, Modernizr runs a series of checks against the user’s browser to determine what features the browser supports and creates a JavaScript object that you can use to test against. Modernizr doesn’t create support for these features; it simply gives you a way to provide fallback support for modern features. For example, in the case of SVG, Modernizr enables us to provide a fallback image for browsers that lack SVG support.
Modernizr also applies a set of classes to the HTML tag, giving you the ability to modify the page’s CSS using the corresponding CSS classes. These CSS classes allow you to use CSS systems to build actuators that will adjust your pages to allow the progressive enhancements available for a page.
As opposed to using the User Agent, Modernizr detects features directly by running a series of JavaScript tests that return boolean (true or false) values. This dictates the classes that are set to the html tag and gives you the ability to use JavaScript to detect whether a feature is available.
Installing Modernizr is as simple as linking to the JavaScript library in the head of your page, but where the installation process gets complicated is creating the version that you need. Modernizr is available for download in two versions, the development version and the production version.
The development version is a full 42 KB, uncompressed file. This version is great if you’re well versed in JavaScript and want to make some tweaks to the tests it performs. Because it’s uncompressed, it’s easy to read and augment but it’s best left to developers with a firm understanding of JavaScript.
For those of you who might not be completely adept at JavaScript, or would like to quickly build a customized version of Modernizr, this is where the production version of the library comes into play. The production version building tool on the site gives you the ability to create a version with only the tests you require.
This comes in handy when you know you only need a certain set of tests. For instance, your site might not take advantage of CSS box-shadows, but it might need to support CSS gradients. Using the build tool, you can include the tests you need and exclude the ones you don’t need, keeping the source code trim and your user’s total load time down.
For our example, I’ll be working of the development version. I find that when I’m building a site, it’s best to work with the full version and then once you know what features you’ll be using in your site, trim the version down.
Let’s do some simple feature detection with Modernizr. We’ll start with a raw sample site.
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<script type="text/javascript" src="js/modernizr.min.js"></script>
</head>
<body>
</body>
</html>
Let’s use this small test to detect whether or not our browser is capable of supporting SVG. For the sake of simplicity we’ll just add two span tags to the page to detect support.
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<script type="text/javascript" src="js/modernizr.min.js"></script>
<style type="text/css">
.yes{color:green;}
.no{color:red;}
span{display:none;}
.svg .yes{display:inline;}
.no-svg .no{display:inline;}
</style>
</head>
<body>
<div>
<span class='yes'>Huzzah! You have SVG support.</span>
<span class='no'>BOO! You don't have SVG support.</span>
</div>
</body>
</html>
If you test this in a browser that supports SVG, you’ll see the message “Huzzah! You have SVG support.” whereas if you have a browser that fails to support SVG, you’ll find the “BOO! You don’t have SVG support.” message.
This example is pretty rudimentary, but it displays the core idea of using Modernizr to fix cross browser issues. If we were doing this same fix using the old user agent method, we would have to have a style sheet for each browser that doesn’t support SVG and change our CSS for each one. (For anyone interested, the only major browsers lacking SVG support are Internet Explorer 7 and under.)
By adding the svg/no-svg class to the html on the page, your CSS now has a selector that can be used to override existing CSS rules. Because it’s on the parent-most tag, it can used to override other classes on the page.
So, in this case, both span tags are given display:none;. If there is no SVG support, the display:inline declaration on the span tag with the .no class overrides the display:hidden thanks to the no-svg rule on the html tag.
Let’s try a more useful example of the same idea. We might want to have an SVG background image on the page, which falls back to a PNG if the browser doesn’t support SVG. By default we’ll use the PNG image. This way, the SVG isn’t served unless it’s needed and becomes a progressive enhancement.
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<script type="text/javascript" src="js/modernizr.min.js"></script>
<style type="text/css">
.skull{
width:300px;
height:300px;
background-image:url(images/skull.png);
background-size:100% auto;
background-repeat: no-repeat;
}
.svg .skull{background-image:url(images/skull.svg);}
</style>
</head>
<body>
<div class='skull'></div>
</body>
</html>
Now we have an awesome SVG skull that will look awesome and crisp for users with high-resolution displays, and still look good for users with older browsers.
There is a great wealth of information to be learned about Modernizr. We showed you how it does the work of cross-browser capability without having to remember or maintain a running list of which browsers support SVG.
It functions exceptionally as a system with which to serve your user actuators to create speedy and highly functional websites.
Do you use Modernizr in your projects? What other methods have you used for serving responsive content? Let us know in the comments.
Featured image/thumbnail, divergent lines image via Shutterstock.
| MacDojo’s Mac Shortcuts Pro Course – only $27! |  |
|
|
|
|
 |
Editor’s Note: This article features techniques that are used in practice by Yahoo! and question coding techniques that we are used to today. You might be interested in reading Decoupling HTML From CSS by Jonathan Snook, On HTML Elements Identifiers by Tim Huegdon and Atomic Design With Sass by Robin Rendle as well. Please keep in mind: some of the mentioned techniques are not considered to be best practices.
When it comes to CSS, I believe that the sacred principle of “separation of concerns” (SoC) has lead us to accept bloat, obsolescence, redundancy, poor caching and more. Now, I’m convinced that the only way to improve how we author style sheets is by moving away from this principle.
For those of you who have never heard of the SoC principle in the context of Web design, it relates to something commonly known as the “separation of the three layers”:
It is about dividing these concerns into separate resources: an HTML document, one or more cascading style sheets and one or more JavaScript files.
But when it comes to the presentational layer, “best practice” goes way beyond the separation of resources. CSS authors thrive on styling documents entirely through style sheets, an approach that has been sanctified by Dave Shea’s excellent project CSS Zen Garden. CSS Zen Garden is what most — if not all — developers consider to be the standard for how to author style sheets.
To help me illustrate issues related to today’s best practices, I’ll use a very common pattern: the media object. Its combination of markup and CSS will be our starting point.
In our markup, a wrapper (div.media) contains an image wrapped in a link (a.img), followed by a div (div.bd):
<div class="media">
<a href="http://twitter.com/thierrykoblentz" class="img">
<img src="thierry.jpg" alt="me" width="40" />
</a>
<div class="bd">
@thierrykoblentz 14 minutes ago
</div>
</div>
Let’s give a 10-pixel margin to the wrapper and style both the wrapper and div.bd as block-formatting contexts (BFC). In other words, the wrapper will contain the floated link, and the content of div.bd will not wrap around said link. A gutter between the image and text is created with a 10-pixel margin (on the float):
.media {
margin: 10px;
}
.media,
.bd {
overflow: hidden;
_overflow: visible;
zoom: 1;
}
.media .img {
float: left;
margin-right: 10px;
}
.media .img img {
display: block;
}
Here is the presentation of the wrapper, with the image in the link and the blob of text:
Suppose we now need to be able to display the image on the other side of the text as well.
Thanks to the magic of BFC, all we need to do is change the styles of the link. For this, we use a new class, imgExt.
<div class="media">
<a href="http://twitter.com/thierrykoblentz" class="imgExt">
<img src="thierry.jpg" alt="me" width="40" />
</a>
<div class="bd">
@thierrykoblentz 14 minutes ago
</div>
</div>
We’ll add an extra rule to float the link to the right and change its margin:
.media {
margin: 10px;
}
.media,
.bd {
overflow: hidden;
_overflow: visible;
zoom: 1;
}
.media .img {
float: left;
margin-right: 10px;
}
.media .img img {
display: block;
}
.media .imgExt {
float: right;
margin-left: 10px;
}
The image is now displayed on the opposite side:
Suppose we now need to make the text smaller when this module is inside the right rail of the page. To do that, we create a new rule, using #rightRail as a contextual selector:
Our module is now inside a div#rightRail container:
<div id="rightRail">
<div class="media">
<a href="http://twitter.com/thierrykoblentz" class="img">
<img src="thierry.jpg" alt="me" width="40" />
</a>
<div class="bd">
@thierrykoblentz 14 minutes ago
</div>
</div>
</div>
Again, we create an extra rule, this time using a descendant selector, #rightRail .bd.
.media {
margin: 10px;
}
.media,
.bd {
overflow: hidden;
_overflow: visible;
zoom: 1;
}
.media .img {
float: left;
margin-right: 10px;
}
.media .img img {
display: block;
}
.media .imgExt {
float: right;
margin-left: 10px;
}
#rightRail .bd {
font-size: smaller;
}
Here is our original module, showing inside div#rightRail:
.media,.bd {}).
.rtl .media .img {
margin-right: auto; /* reset */
float: right;
margin-left: 10px;
}
.rtl .media .imgExt {
margin-left: auto; /* reset */
float: left;
margin-right: 10px;
}
- a·tom·ic
- /ə’tämik/
- of or forming a single irreducible unit or component in a larger system.
As we all know, the smaller the unit, the more reusable it is.
“Treat code like Lego. Break code into the smallest little blocks possible.” — @csswizardry (via @stubbornella) #btconf
— Smashing Magazine (@smashingmag) May 27, 2013
To break down styles into irreducible units, we can map classes to a single style, rather than many. This will result in a more granular palette of rules, which in turn improves reusability.
Let’s revisit the media object using this new approach.
We are using five classes, none of which are related to content:
<div class="Bfc M-10">
<a href="http://twitter.com/thierrykoblentz" class="Fl-start Mend-10">
<img src="thierry.jpg" alt="me" width="40" />
</a>
<div class="Bfc Fz-s">
@thierrykoblentz 14 minutes ago
</div>
</div>
Each class is associated with one particular style. For the most part, this means we have one declaration per rule.
.Bfc {
overflow: hidden;
zoom: 1;
}
.M-10 {
margin: 10px;
}
.Fl-start {
float: left;
}
.Mend-10 {
margin-right: 10px;
}
.Fz-s {
font-size: smaller;
}
Let’s ignore the class names for now and focus on what this does (or does not):
.Fl-start {
float: right;
}
.Mend-10 {
margin-left: 10px;
}
Same classes, same properties, different values.
But the most important thing to notice here is that we are styling via markup. We have changed the context in which we style our modules. We are now editing HTML templates instead of style sheets.
I believe that this approach is a game-changer because it narrows the scope dramatically. We are styling not in the global scope (the style sheet), but at the module and block level. We can change the style of a module without worrying about breaking something else on the page. And we can do this without adding any rule to the style sheet, let alone creating a new class and rule:
.someBasicStyleForThisElementHere {...}
We get no redundancy. Selectors are not duplicated, and styles belong to a single rule instead of being part of many. For example, the style sheets that this page links to contain 72 float declarations.
Also, abandoning a style — for example, deciding to always keep the image on the left side of the module — does not make any of our rules obsolete.
Not sold yet? I hear you saying, “This goes against every single rule in the book. This is no better than inline styling. And your class names are not only cryptic, but unsemantic, too!”
Fair enough. Let’s address these concerns.
If you check the W3C’s “Tips for Webmasters,” where it says “Good names don’t change,” you’ll see that the argument is about maintenance, not semantics per se. All it says is that changing styles is easier in a CSS file than in multiple HTML files. .border4px would be a bad name only if changing the style of an element required us to change the declaration that that class name is associated with. In other words:
.border4px {border-width:2px;}
For the most part, these class names follow the syntax of Zen Coding — see the “Zen Coding Cheat Sheet” (PDF) — now renamed Emmet. In other words, they are simple abbreviations.
There are exceptions for styles associated with direction (left and right) and styles that involve a combination of declarations. For example, Bfc stands for “block-formatting context.”
Hopefully, the diagram below clears things up:
Inline styles versus Atomic CSS.
@style. It lowers style weight because rules rely on a single class, as opposed to rules like .parent .bd {}, which clocks in at 0.0.2.0 (see “CSS Specificity: Things You Should Know”).M-10 versus margin: 10px). Some classes, such as Bfc, refer to more than one style (see “Mapping” in the diagram above). Other classes use “start” and “end” keywords, rather than left and right values (see “Abstraction” in the diagram above).Here are the advantages of @style:
Because the styles of our module are tied only to presentational class names, they can be anything we want them to be. For example, if we need to create a simple two-column layout, all we need to do is replace the link with a div in our template. That would look like this:
<div class="Bfc M-10">
<div class="Fl-start Mend-10 W-25">
column 1
</div>
<div class="Bfc">
column 2
</div>
</div>
And we would need only one extra rule in the style sheet:
.Bfc {
overflow: hidden;
zoom: 1;
}
.M-10 {
margin: 10px;
}
.Fl-start {
float: left;
}
.Mend-10 {
margin-right: 10px;
}
.Fz-s {
font-size: smaller;
}
.W-50 {
width: 50%;
}
Compare this to the traditional way:
<div class="wrapper">
<div class="sidebar">
column 1
</div>
<div class="content">
sidebar
</div>
</div>
This would require us to create three new classes, to add an extra rule and to group selectors.
.wrapper,
.content,
.media,
.bd {
overflow: hidden;
_overflow: visible;
zoom: 1;
}
.sidebar {
width: 50%;
}
.sidebar,
.media .img {
float: left;
margin-right: 10px;
}
.media .img img {
display: block;
}
I think the code above pretty well demonstrates the price we pay for following the SoC principle. In my experience, all it does is grow style sheets.
Moreover, the larger the files, the more complex the rules and selectors become. And then no one would dare edit the existing rules:
In other words, we make things worse because we can get away with bloat.
Nowadays, people are accustomed to very large style sheets, and many authors think they come with the territory. Rather than fighting bloat, they use tools (i.e. preprocessors) to help them deal with it. Chris Eppstein tells us:
“LinkedIn has over 1,100 Sass files (230k lines of SCSS) and over 90 web developers writing Sass every day.”
Let’s face it: the data has to live somewhere. Consider these two blocks:
<div class="sidebar">
<div class="Fl-start Mend-10 W-25">
In many cases, the “semantic” class name makes up more bytes than the presentational class name (.wrapper versus .Bfc). But I do not think this is a real concern compared to what most apps onboard these days via data- attributes.
This is where gzip comes into play, because the high redundancy in class names across a document would achieve better compression. And the same is true of style sheets, in which we have many redundant sequences:
.M-1 {margin: 1px;}
.M-2 {margin: 2px;}
.M-4 {margin: 4px;}
.M-6 {margin: 6px;}
.M-8 {margin: 8px;}
etc.
Presentational rules do not change. Style sheets made from such rules mature into tool sets in which authors can find everything they need. By their nature, they stop growing and become immutable, and immutable is cache-friendly.
The technique I’m discussing here is not about banning “semantic” class names or rules that group many declarations. The idea is to reevaluate the benefits of the common approach, rather than adopting it as the de facto technique for styling Web pages. In other words, we are restricting the “component” approach to the few cases in which it makes the most sense.
For example, you may find the following rules in our style sheets, rules that set styles for which we do not create simple classes or rules that ensure cross-browser support.
.button {
display: inline-block;
*display: inline;
zoom: 1;
font-size: bold 16px/2em Arial;
height: 2em;
box-shadow: inset 1px 1px 2px 0px #fff;
background: -webkit-gradient(linear, left top, left bottom, color-stop(0.05, #ededed), color-stop(1, #dfdfdf));
background: linear-gradient(center top, #ededed 5%, #dfdfdf 100%);
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ededed', endColorstr='#dfdfdf');
background-color: #ededed;
color: #777;
text-decoration: none;
text-align: center;
text-shadow: 1px 1px 2px #ffffff;
border-radius: 4px;
border: 2px solid #dcdcdc;
}
.modal {
position: fixed;
top: 50%;
left: 50%;
-webkit-transform: translate(-50%,-50%);
-ms-transform: translate(-50%,-50%);
transform: translate(-50%,-50%);
*width: 600px;
*margin-left: -300px;
*top: 50px;
}
@media \0screen {
.modal {
width: 600px;
margin-left: -300px;
top: 50px;
}
}
On the other hand, you would not see rules like the ones below (i.e. styles bound to particular modules), because we prefer to apply these same styles using multiple classes: one for font size, one for color, one for floats, etc.
.news-module {
font-size: 14px;
color: #555;
float: left;
width: 50%;
padding: 10px;
margin-right: 10px;
}
.testimonial {
font-size: 16px;
font-style: italic;
color: #222;
padding: 10px;
}
The idea is to have a pool of rules that authors can choose from to style anything they want. Styles that are common enough across a website would become part of the style sheet. If a style is too specific, then we’d rely on @style (the style attribute). In other words, we’d prefer to pollute the markup rather than the style sheet. The primary goal is to create a sheet made of rules that address various design patterns, from a basic rule that floats an element to “helper” classes.
/**
* one liner with ellipsis
* 1. we inherit hyphens:auto from body, which would break "Ell" in table cells
*/
.Ell {
max-width: 100%;
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
-webkit-hyphens: none; /* 1 */
-ms-hyphens: none;
-o-hyphens: none;
hyphens: none;
}
/**
* kinda line-clamp
* two lines according to default font-size and line-height
*/
.LineClamp {
display: -webkit-box;
-webkit-line-clamp: 2;
-webkit-box-orient: vertical;
font-size: 13px;
line-height: 1.25;
max-height: 32px;
_height: 32px;
overflow: hidden;
}
/**
* reveals an hidden element on :hover or :focus
* visibility can be forced by applying the class "RevealNested-on"
* IE8+
*/
:root .NestedHidden {
opacity: 0;
}
:root .NestedHidden:focus,
:root .RevealNested:hover .NestedHidden,
:root .RevealNested-on .NestedHidden {
opacity: 1;
}
We have just released a brand new My Yahoo, which relies heavily on this technique. This is how it compares to a few other Yahoo products (after gzip’ing):
| CSS Assets | |
|---|---|
| answers.yahoo.com | 30.1 KB |
| sports.yahoo.com | 67.4 KB |
| omg.yahoo.com | 46.2 KB |
| yahoo.com | 45.9 KB |
| my.yahoo.com | 21.3 KB |
Our style sheet weighs 17.9 KB (about 3 KB of which are property-specific), and it is shareable (unlike the style sheets of other properties). The reason for this is that none of the rules it contains relate to content.
Because presentational class names have always been deemed “out of bounds,” we — the community — have not really investigated what their use entails. In fact, in the name of best practice, we’ve dismissed every opportunity to explore their potential benefits.
Here at Yahoo, @renatoiwa, @StevenRCarlson and I are developing projects with this new CSS architecture. The code appears to be predictable, reusable, maintainable and scalable. These are the results we’ve experienced so far:
style block) to it. No custom rules from third parties means no risk of breakage due to rules that have not been properly namespaced.(Note that if maintenance is easier on the CSS side than on the HTML side, then the reason is simply that we can cheat on the CSS side by not cleaning up rules. But if we were required to keep things lean and clean, then the pain would be the same.)
I was at a meetup a couple of weeks ago, where I heard Colt McAnlis say, “Tools, not rules.” A quick search for this idiom returned this:
“We all need to be open to new learnings, new approaches, new best practices and we need to be able to share them.”
(al, ea)
© Thierry Koblentz for Smashing Magazine, 2013.
]]>