asgaard

Pseudo elements' CSS with jQuery

Sat, 08 Sep 12 15:18:12 +0000

Further to what I wrote yesterday about this, I've written a jQuery plugin to provide a nice interface to pseudo-element CSS changes. Basically it *kind of* allows you to target pseudo-elements for the sake of CSS manipulation. It looks something like this:

$('#element').pseudoCss(':before', 'background-color', 'red');

Check out the code from GitHub. The index.html contains documentation, which you should be able to see online via this link.

Please do read the caveat section before you use it. It should work for most situations but it is inherently limited compared to $.css().[...]

On targeting pseudo-elements with JavaScript/jQuery

Fri, 07 Sep 12 17:18:47 +0000

Pseudo-elements are pretty nice things you can inject into HTML elements via CSS.

#container { 
    position: relative;
}
#container::before {
    position: absolute;
    top: 0;
    left: 0;
    display: block;
    content: "I am a block element in the top-left corner of #container and I don't exist in the markup";
}

They are very useful for adding presentational output to your DOM tree without needing to pollute the markup. But they are a bit of a pain because they don't really exist in the DOM, so accessing them programmatically with JavaScript is hard, or I think, impossible in the general case.

But depending on what you want to do, you might be able to achieve the result you want by being a bit clever...

Usually you want to target this element because you intend to manipulate its CSS. You can still manipulate its CSS! You just have to take the indirect and less commonly trodden route of using JS to create a stylesheet and writing raw rules into it. Example:

$('head').append(document.createElement('style'));
var myStyleSheet = document.styleSheets[document.styleSheets.length-1];

var myRule = "#container::before { content: \"Let's change my text\"; }";
if (myStyleSheet.insertRule) {
    myStyleSheet.insertRule(myRule, myStyleSheet.cssRules.length);
}

What we've done in the code above is to create a dedicated stylesheet for this and then injected a rule which should override the previous rule (assuming selector specifity is equal, but let's not get into that). This is obviously not as neat as simply using jQuery.css(), but we don't have too many options, so let's focus on managing the situation we've inherited.

Cool story bro, but how do I scale this?

Exactly what strategy you use to lay your code out depends on your exact problem. If you only need to consider changes to one element, just keep it simple.

But if you need to handle multiple elements individually you have to manage problems selecting them and targeting them individually. If they don't already have an ID set, you'll have to create IDs on them and use that in the rule's selector. The second parameter of insertRule is an index. We can use this to help us out; we can iterate over each of our elements initially and assign it an index (use $.data()), insert a no-op rule at that index to force it to exist, and then make sure that element may only write to that index. After doing so, we'll still have to remove the old rule which will now be in index+1, which we can do with myStyleSheet.deleteRule(index+1).

I've made a fiddle to show roughly how it works. It by no means handles all feasible cases but should give you an idea how to lay things out.

Design and Usability on the Web

Sun, 22 Apr 12 20:40:55 +0000

I have a problem with a lot of the UI widgets being deployed on websites.

Many web effects focus on *hiding* information and dedicating a large percentage of screen estate to showing the controls for showing the information. This is really silly. Sometimes there is a risk that you are showing a lot of information that the user isn't interested in and finding a way to filter it is a good idea, but let's be honest here, the main driving force behind most of these effects is that someone thought it would look good, not that it would improve usability. What usually happens is we reinvent a worse way to show information than simply laying it out flat on the page.

As developers and designers (I'm not a designer), *we* aren't in the same position as users because *we* couldn't care less about the content on the web page. We want to make the site look good and/or work, but we don't actually want to use it or read the content. This means that we often don't consider how annoying it is for a user to have to click 10 different things to get a general overview of the full information s/he's interested in. Particularly if it's for a client rather than for our own users.

On a site we did recently for a company, we had on the home page 13 different images in a horizontally scrolling element which showed approximately 2.9 images at a time. Each of these images had a title and a summary which was of some descriptive relevance to the company and by extension, of interest to its stakeholders/visitors. The image was just a simple single colour logo, not a photograph or anything like that. The way the 'design' worked was that you had to hover over each image to get the information to pop up

I implemented this (for reasons that are long and complicated), and I got a few comments of "oh yeah, it looks really good" from other people in the office. I think this demonstrates pretty well the disconnect I'm getting at. It wasn't really good at all, it was a UI nightmare. The user is presented with 2.9 cryptic logos and has to hover over each one to get any idea what it means. On the last one, they only get to see 0.9 of the text without scrolling a bit further (okay that was a design oversight). If they are interested, they have to go through this process another 4 times to see the whole set, and the fact is they might only be interested in two or three of them, which probablistically aren't going to be adjacent, so they'll have to keep scrolling back and forward through this initially interesting but now hugely annoying element.

Another good example is the lightbox, which might be acceptable in rare circumstances but generally the lightbox is awful. I hate lightboxes. If the page genuinely, and I mean *genuinely*, needs to request some user interaction before it can *genuinely* continue, then so be it, but that's a pretty rare circumstance on the web, and more often they're used to display secondary content or make the user respond RIGHT NOW to something that could have been done in a much less obnoxious manner. I see really stupid arguments for lightboxes being used for user interaction like "it lets the user focus on x without getting distracted". There is nothing more annoying than a piece of software that thinks it knows better than its user, except possibly for a piece of software that thinks it knows better than its user AND treats them like an idiot.

As for content, Lightboxes are far worse than simply opening a new browser tab because they replace useful and expected user interface functionality provided by the browser with something much less powerful, less standardised, and generally much worse implemented and much more flakey. If you open a new browser tab, you still get all the browser controls. You can still flick between the two tabs/windows. If the lightbox is used to request user interaction then there's a good chance that whatever you're requesting is coupled to the page you just made unusable and the user would have preferred to be able to view your page before deciding what to do (or whether to do anything at all) - and if it's not, then why have you interrupted that page at all?

It's another attempt at hiding content and making it as frustrating as possible for a user to interact with your page and view its content in the way they expect to be able to, for the misguided end result of making your page stand out. It does that, I guess, but not for the right reasons. I don't think I have ever seen a situation online where a lightbox has genuinely been a good choice outside of occasionally content-authoring situations (e.g. inserting an image from a media library into a rich text editor). If you need user interaction, you should be doing it like (for example) Grooveshark does, by popping up a little widget in the corner. My own jKnotify(Ui)? provides unintrusive notifications in a similar way. You don't have to use it. I'm sure there are others. But the concept demonstrated is how such dialogue should be done.