Simple File Icons For Document Attachments
Displaying lists of files attached to documents is something we've all had to do. When doing so, it's a nice touch to show an icon next to each file, which denotes the type of document, as in the image to the right.
This isn't exactly difficult but I've seen some overly-complicated solutions used and wanted to share what I think has to be the simplest, cleanest and cleverest. All it uses is a smidgen of CSS. The attachment are listed as a set of <li> tags where the class name is the same as the extension of the file. Like so:
<ul class="download"> <li class="pdf">link to PDF file here</li> <li class="xls">link to Excel file here</li> <li class="mp3">Music file link here</li> </ul>
The CSS is divinely simple. You just add a background image to the list item. You can add a new rule for each file type you want to cater for. All other file types are covered by the default case of the generic file image. Here's a simplified look at the style used (note their order is important — generic must be first):
ul.download li { background-image:url(generic_file_small.gif); } ul.download li.xls{ background-image:url(XLS_small.gif); } ul.download li.ppt{ background-image:url(PPT_small.gif); }
To create the HTML. Just use a simple @Function like this:
@Implode("<li class=\"" + @LowerCase(@RightBack(@AttachmentNames; ".")) + "\"><a href=\"/"+@WebDbName+"/0/"+ @Text(@DocumentUniqueID)+"/$file/"+@AttachmentNames+"\">" + @AttachmentNames + "</a></li>"; @NewLine)
You can see a working demo here (read only, for obvious reasons). All the images, CSS and code is wrapped up rather nicely in the zipped-up copy of that database.
Freakin' Sweet !
So simple it hurts, top marks again Jake.
Jake says:
Below you should see all the actual files as Domino so kindly renders them for us:
adding the reserved field $V2AttachmentsOptions
set to "0" will hide those ugly document links
Best Regards,
Barry
Dear Jake,
The icons themselves are not clickable. Is there a solution for that?
All these small icons are individual server request. There are css techniques to diminish the number of requests to only one:
{Link}
In Firebug you will see an improvement in total page load speed once you implement this technique. Especially since the Notes server is not the fastest image rendering server around.
Damn, Jake!
That's truly clever!
Cheers,
Charlie
Barry, search this site for Jake's nice little Attachment Manager (published a couple of years ago) and you'll notice, that he left the Domino rendering in place simply for comparison.
Larry, I'm sure you meant to say "image server", as Domino will hardly render these images for us. Keep in mind, that Jake's solutions makes no assumptions about where the images come from. Could be file attachments (in which case I would agree with your performance concerns), could be image resources, could be static files in the site's html directory. They could even be loaded from a completely different source.
If you ask me, using sprites for this specific purpose is a bit over the top. Keeping the number of requests low is definitely a good thing, but is it really worth it here? The CSS get's more complicated and bigger and not all users might even need all the icons they are forced to load. Browser side caching will remove some (though not all) of the burden associated with multiple graphics.
There's one more drawback of sprites (and for me, this is a big one), even if it is mentioned rarely: Everybody talks about clean and semantically correct markup. But what about the CSS? I find it very helpfull, if CSS is as clean self-explanatory as possible. That's where sprites definitely fail.
@ larry:--
If you want to make the icons clickable, use the :before pseudo to add the icon to the link (instead of using a background image):
ul.download li.xls a:before {
content: url(xls.gif);
}
Guys. Don't give me any credit for this! I'm merely passing on a trick I learnt while harvesting ideas from a project I out-sourced to CSS gurus not so long ago.
Sprites are a great idea but I think they would make the solution less clean. It would mean having an element inside each LI that was the size of the icons (12px square) to position each sprite in. Possible but messier than the current solution.
Making the clickable is also possible, as Stan kindly showed us. Although his soution won't work with IE6. An alternative would be to add "space" to the link. Might look in to this and report back.
Jake
Didn't mean to say that sprites are good in all situations. In my case using a combination of different optimalisation techniques (including sprites, but also by combining all js files into one large js) has helped me to reduce the average page load time from 1.5 seconds to 0.5 seconds. This was mainly achieved by reducing the number of server calls from 15 to 5 per page.
When downloading pages, quite often one of the images would lag, thus reducing the download time of the whole page.
Considering what I know of Jake's latest activities (creating 20.000 blogs for a university and investigating script to optimize the windows onload event) I hope this technique may help him.
For the positioning I use four non-braking spaces. It is not clean, but it is fast ;-)
Thanks for the tip Stan!
I also show icons for each of my 'file' links but instead of adding a 'pdf' class or whatever to a list item, I add it to the link itself.
i.e <a class="pdf" href="blah.pdf">My PDF</a>
I then have this CSS to give a bit of padding to fit in the image and also increase my line height slightly to ensure the icons aren't cropped:
a.pdf [, a.doc, a.ppt, etc]{
padding-left:20px;
line-height : 1.6em;
a.pdf{
background : url(/icons/icons/acrobat_16.gif) no-repeat 1px 1px;
}
a.pdf:hover{
background : #eee url(/icons/icons/acrobat_16.gif) no-repeat 1px 1px;
}
This means the image is inside the link and is thus clickable.
Thanks Jono. The obvious answer to having them clickable is to move them in to the link. Don't know why I didn't think of that.
BTW: You could save some space by having
a.pdf:hover{background-color : #eee;} instead of repeating the image and offset bits.
Jake
Hi Jake, Well it's unusual for me to be able to post something useful for once! :)
I have a combined rule (a.pdf, a.doc, a.xls) for the offsets but yeah - good point I could've used the background-color on the hover entries, woulda saved me repeating the icon images etc. Cheers!
p.s I still use Multimedia Xplorer {Link} to grab the icons - you found anything better yet?!
dur. just realised u were on about the 1px 1px offsets.... soz - you can delete that para if you like! :)
There's a reason I've gone with the content before rather than the background image, and that's that the content before version is visibly clickable (provided, of course, that the text links are suitably styled). Backgrounds inside the link are clickable, but the user wouldn't know that unless they experimented a bit.
(Okay, maybe I've gotten a little bit anal about usability lately, but actual testing has revealed a lot about the assumptions I used to make. And no, neither WGAG nor s.508 help a whole lot -- watching seniors and casual users fumble with your perfectly compliant pages is somewhat humbling to say the least.)
Hi
This is great !!
Will I get more icons of different files ?
It will help me in distinguish files.
Thanks
I wrote this using a different method last year!
{Link}