Category: Web Apps
We launched a new feature on a site I am working on, and to highlight the new feature we decided to put one of those new images right next to the link. The link to the new feature is in several places, so the new image was going to have to be in several places.
There were a couple of issues with adding the image, but the most painful one being that at some point the feature wouldn’t be new anymore and someone was going to have to go and remove all the images later (the application isn’t totally in an MVC style framework at present so there are several places to update).
Instead of adding the new image next to the links, we fudged it with CSS. We just created a new class for the new feature links - .newfeature or whatever - and in the class definition added the new image with background and padding. For example:
.newfeature {
...
background: url(/images/new.gif) no-repeat;
padding-left: 30px;
...
}
Then when the feature isn’t new anymore, we can just remove the background and padding from the CSS class.
It’s a simple solution, but we almost overlooked it. It obviously wouldn’t work all the time, but I think it was a nice technique that will save some time later. Moral to the story: CSS is used for styling ;)
[...] Original post by rob [...]
I have recently discovered just that - putting images into the CSS and less images into the HTML makes the styling so much more flexible and easier to update. I have started doing this as much as possible.
The ideal way of doing this with CSS is not as a background image, but like this:
.newfeature:after
{
content: url(/images/new.gif)
}
Allowing you much more control and flexibility than the background image method.
Of course, this way doesn’t work with IE6 (not sure about IE7?) so might not be possible for everyone.
Nice tip, Rob. Thinking ahead, though, and trying to think semantically — both of which are always dangerous, I realize — wouldn’t it make more sense to leave the CSS alone and go remove the “newFeature” class from the links when the target is no longer new? That way when something else is new, the CSS is still there to support the presentation of new items, and it is just a matter of flagging links to new things with the appropriate additional class. And if your site is based on some sort of content management tool, just make the tool smart enough to include the “newFeature” class on links to pages that are new or updated…
@Peter: That would be definitely be better, but sadly we have to support IE6 :-/
@Ron: Good thoughts - I actually wasn’t clear. The “newfeature” class in the example is really the name of the feature. So the CSS class wont get removed once the newnesss faded. I was using the generic name as an example.
The class will still be need even after the feature isn’t new for bold, underline, etc etc. If this didn’t need a specific class of it’s own, we could still probably do it with a more complicated rule: div.sidebar, li, thing.newfeature { … or whatever. But it just happened to work out in this instance.
I like your idea of a generic newfeature class. It would be nice to extend a css class with the newfeature class then unextend when it wasn’t needed anymore - I don’t think that’s possible though… hum…
@rob:
Sure, it’s possible to extend a CSS class with another CSS class, like Ron was suggesting:
In CSS:
.foo {
font-weight: bold;
font-family: Comic Sans, Eye-Gouge;
font-size: 30em;
}
.newfeature {
background: url(/images/new.gif) no-repeat;
padding-left: 30px;
}
<span class=”foo newfeature“>Some new feature</span>
This way you can just tack on the “newfeature” class to any tag on the page.
@Adam
Yeah totally, but you still have to go to each place then and remove the “newfeature” class, which is more or less the same as just adding an img tag with the new graphic - which is what we were trying to avoid ;)
To clarify I was thinking something more along the lines of:
newfeature { … }
.myforeverclass extends .newfeature {
… styleing …
}
(which is not possible) Then later remove the extends part. I mean, we could do this (which is what we do now)
.myforeverclass { … }
.myforeverclass { [the new feature addition parts] }
but it would easier to just have all the styles in one class.
@Rob: What would prevent you from extending the class? The only thing I can think of would be the site’s organization (too many file would have to be updated, etc) because you can use multiple classes on the same object. You could have your standard class and a new class.
.standard {
definitions
}
.new {
definitions only for new items
}
someObject class=”standard new”
Then when the item isn’t “new” anymore remove the space and new class from the object.
“(the application isn’t totally in an MVC style framework at present so there are several places to update).”
I don’t know how widely this is supported, but what about using the matching capabilities of CSS to flag the links with something like this:
a[href="newstuff.html"] {
styling…
}
Any A element with an HREF attribute that matches the string (i.e., “newstuff.html” in this case) gets the styling applied. As long as you are consistent in setting up the link to the new stuff, all of your links to it should get the styling applied without you having to do anything else… in a perfect world, where all of the users you care about use a browser client that supports the CSS standard.
I wish attribute selectors were fully supported, but I know for sure they are not in IE.
That’s an ahead-of-your-time solution ;)
I’ve been wanting to use them for a long time to do stuff like input[type="checkbox"]. I am pretty sure they are supported in Firefox and Safari (as are |= and ~= I *think*), so someday… someday…