Archive for CSS

Email protection using CSS

Email Link Protection - a graceful and user-friendly technique This post originally appeared on my personal blog in March of 2005. It is till useful a half decade later, so finally posting it here. This code is also available on Snipplr as well.

Any spambot worth its salt spawned by evil genius could "guess" email addresses by skimming for all 'alias@'s and automatically concatenate them with the site's url base and any other domains found on the page, so in the javascript I separate the '@' from the alias.

Enough about the wheres and whys, here's some cut n' paste fun for your use. This code will use javascript to display a normal, clickable mailto: link on your page and if javascript is turned off you still get a screen-readable, selectable email address displayed using a CSS trick.

<style type="text/css">
.backwards {
unicode-bidi:bidi-override; direction: rtl;font-weight:bold;
}
</style>
<script type="text/javascript">
<!--
linkAddy=('alias' + '@' + 'yourdomain.com')
document.write('<a href="mailto:' + linkAddy + '">' + linkAddy + '</a>')
//-->
</script>

<noscript>
<p>Please email me at
<strong><span class="backwards">moc.niamodruoy@saila</span>
</strong>.<br /></p>
</noscript>

Here's a version for you really paranoid folks that don't want live links at all (or maybe you just want a tiny user obstacle to ensure necessity of correspondence), but you do want your email address to appear correctly if possible but with better protection, plus insurance if javascript is turned off:

<style type="text/css">
.backwards {
unicode-bidi:bidi-override; direction: rtl;font-weight:bold;
}
</style>
Please email me at
<span class="backwards"><script type="text/javascript">
<!--
backAddy=('moc.niamodruoy' + '@' + 'saila')
document.write(backAddy)
//-->
</script></span>
<noscript><strong>alias at
yourdomain dot com</strong></noscript>

Here's a working example:

Please email me at

Here's a few other ways to protect email addresses from spam bots. If you have a preferred method not listed here, please let me know in the comments.

  • Graceful Email Obfuscation article from A List Apart takes it up a notch, with an htaccess rewrite and redirect. Could be worth setting up for a large site where you need to add email links quickly and easy.
  • Hivelogic Enkoder Form - use their form to generate some javascript. Works great but relies on javascript to work.
  • Addressmunger.com - uses ASCII, JavaScript, and scrambling of letters in your email address.
  • K'nechtology Email Encryption - encodes email addresses in to hexadecimal values. This isn't very secure as it would be extremely easy for a bot to decode hex.

Comments

Google Doctype Screams “Fork ME!”

The newly released Google Doctype is intended to be the Wikipedia of web design. There’s a video introduction on the landing page of Mark Pilgrim explaining what Google has been internally calling the the “Hitch Hikers Guide to the Web”. He’s been working on Google Doctype, said it is supposed to be the cross-platform alternative to MSDN. MSDN? I don’t know any web designers that rely on MSDN as the go-to spot for quality cross-platform client-side code! Maybe they’re targeting ASP.NET developers…and that could explain the very un-wiki linear treestyle navigation.

Google Doctype Screenshot

The Good

My own private wiki, largely comprised of web development documentation for my own projects, code snippits and links to online resources, is invaluable to me – so the potential benefits of an open wiki of this nature is obvious and I’ve often wondered why there isn’t one (with critical mass) out there already. Certainly this project, or at least the idea of it, could be an invaluable tool to professional web designers and client-side developers. Some take-aways:

  • “Written by web developers, for web developers” and by that they mean client-side developers…most of the current content is specific to JavaScript DOM stuff and cross-browser CSS considerations. I think this fills a knowledge gap as a lot of CSS and even Ajax resources are designer-oriented (lacking meaty technical details) and many developer resources gloss over or ignore web standards or a lot of the details professional programmers take for granted (like finding a viewport or using javascript to manipulate classes)
  • It’s built on the Google Project framework so you can download the whole thing via SVN.
  • The licensing is pretty unrestrictive, so you could SVN everything and put it up on an intranet statically or keep an off line copy, as was mentioned in the intro video.
  • Discrete code snippets. Rather than a long tutorial with examples that are specific to a given situation, many of the HOWTOs are broken down into more abstracted uses. This style of documentation will help a lot when your stuck on specific area of a bigger project. Personally, I learn more this way – I like the big step-by-step tutorials but when I cut and paste a lot I don’t retain very much.

The Ugly

Google suffers from chronic ugliness (IMHO) and this project is no exception. Don’t get me wrong, I’m GOOG fangirl all the way, but there always seems to be some basic user interface and user experience problems with their apps/portals/projects/whatever. And here’s where I think Google Doctype has need of improvement:

  • No indication of off-site links. Not only does a link to MSDN look just like the internal links, there are links to other Google Code project without any indications that you’re leaving Google Doctype, in fact, the logo is still Google Code. Navigation is a little confusing in general.
  • Lack of Style Guidelines. There is something to “just putting it out there” and I’m glad they did, but if a lot of people do start adding to this resource it could turn into quite a mess. It would have been ideal to have a written style established that would make sense for an open wiki. For example, statements like “generally, we recommend the following…” and “I’m not sure if this works on IE”. This type of thing would never fly on Wikipedia – now that the docs are open to the whole internets, such statements are ambiguous, lack authority and create a bad example that others are sure to follow.
  • Not really a wiki. First there’s the linear tree/node navigation pane (which seems to collapse by itself and disappear or reappear for no apparent reason) . There is no discussion page (although there are comments, sort of like PHP.net), no page history (but you can manually add a free-form line to a log file, if you notice the option), there’s no obvious way to check to see what links to a page, the list goes on.
  • Screaming “Fork Me”. A fork may be inevitable, and if a fork emerges using MediaWiki or any of a myriad of much more robust wiki platforms, I would be more likely to invest my time in that in spite of the Google mind share.

A Web Reference To Rule Them All

When I first read that Google published a web design wiki I was thrilled. I tried to think of other, similar resources. There are some great blogs, lists and forums out there but I’ve yet to find the one web reference to rule them all. If you know of one, please let me know! In the meantime I’m looking for domains…webwiki.com is just a db error, webwiki.net is a half-baked attempt at a wiki version of the Million Dollar Homepage. Hrm. If I come up with a load of extra time and a brilliant idea I will let you know. In the mean time, here are a few of my favorite web coder sites:

  • W3C.org – start at the top, right?
  • HTML Dog – very well organized reference and tutorials for CSS and (x)HTML
  • A List Apart – high quality articles published by those web standards freaks at Happy Cog.

Comments

Complex CSS Dynamic Lists

A List Apart offers yet another excellent dynamic list tutorial. As usual, it is an in depth, yet easy to follow tutorial that covers all of its bases, going so far as explaining why they don’t use Ajax for this particular trick (a usability consideration). The result of their demo isn’t exactly sexy – but I could imagine it working beautifully for a very tight, symmetrical site structure.

Comments

Unrealized CSS Selectors

I just finished reading the Selectutorial. (Actually, I’ve read it before but my CSS skills were not developed enough at the time to make any of it relevant enough to me to remember.) I must say, now that I fully understand it, it’s an different sort of excercise in frustration. Why? There are a lot of really, really useful CSS selectors that can’t be used. At least, not on a client’s site. With every new selector my excitement would build, until the summary: "…not supported by Windows Internet Explorer 5, 5.5 and 6, but are supported by most other standards-compliant browsers."

Think child selectors, adjacent sibling selectors, attribute selectors and the :before and :after pseudo-classes are just for CSS geeks? They could be regular part of your web-design diet, simplifying things like adjusting spacing conditionally depending on whether an element is right next to another. I could have used the attribute selectors to make only my little ‘off-site link’ images inline for a recent site instead of applying a class in the structural code to every freggin image tag!

It’s a shame that the worlds richest software company, fueled with hiring power and a presumably very well-educated and/or skilled workforce can’t make their browser standards compliant. If it wasn’t for Internet Explorer’s bad but predominant browser, things could be so much more efficient for everyone. Though I’ve applauded the relative dissapearance of "This site is best viewed in…" statement, I think I would now welcome "Best viewed in a standards compliant browser (Internet Explorer, try Firefox ).

Comments