Now while that table may seem a little intimidating, it really isn’t. In fact there are some cool uses for the new CSS3 selectors which we’ll go into in a future post. One last note, while some of you might be thinking that you can also use a JavaScript library, like jQuery, to accomplish some of the same results in terms of selecting specific elements, which is true, the best part is with some of these new selectors there’s no need to increase the loading time of your page by including a library when it can now be done with pure CSS.

Pseudo-elements

The list of pseudo-elements in CSS3 is the same as in CSS2 — no changes here. However the syntax has changed a little. By one extra colon to be exact. A pseudo-element is now composed of two colons (::) followed by the name of the pseudo-element instead of a single colon. The new :: notation is introduced to establish a discrimination between pseudo-classes and pseudo-elements. For backward compatibility, browsers must also accept the previous one-colon notation for pseudo-elements introduced in CSS 1 and 2 (e.g :first-line, :first-letter, :before and :after).

I’ve seen code wrapped at 80 columns plenty of times before, but something about picking apart this code at that moment made me suddenly ask why. What was so special about this 80 column “standard” and why was it seen throughout the programming world? When I first started out coding this was just assumed to be the way to do things but I had never fully heard an explanation as for why this was done.

As it turns out the answer lies in old technology and tradition. In the early days of coding,  text based terminal displays were only 80 characters wide, so any lines longer than 80 characters needed to be wrapped. There just wasn’t any choice in the matter. Remember that GUIs and mice didn’t exist back then and scrolling was typically done only vertically. Some people believe that the even older computing method of using punch cards, which also typically had 80 columns, is the reason for this style of coding, however while it may have influenced the design of those old terminals, I don’t believe that punch cards directly gave way to practice of coding text at 80 columns.

Now since virtually no one uses an old terminal to write code, and today’s monitors are larger and have larger display resolution than older machines, why do we still see this? The answer? Tradition. Well that and readability. While most modern code editors will let you type a single line for as long as you want, reading that line becomes a huge pain in the ass. You’re forced to scroll horizontally to the right to read the code or comment, and then scroll back to the left to get back to the rest of the code. While an 80 column limit might seem constrictive or limiting, it actually makes code easier to read, and can help you write better code by making you find ways to shrink your code down to fit in one line. Another advantage to limiting the characters per line is code comparison. By staying with the 80 column rule you can usually fit two files side by side and examine them line by line quite easily.

Oh and while 80 columns is sort of a standard, 72 and 76 column layout are also quite common, but slightly more restrictive. Personally I am lazier than I like to admit and I often don’t pay a load of attention to how many columns each line of my code takes up. But that’s being both a bit lazy and selfish. By making your code readable, it helps you and anyone else looking at it…and you just know you’re going to need another set of eyes looking at your code at some point to help ferret out a bug down the line. And while I’m no advocate for 80 columns, if you stick with a layout that makes your code easy to read why not pick something like 100, 120, or 132 columns now that most people have larger monitors? Being lazy I also don’t think that any of this should be a rule but more of a suggestion or guideline. Bottom line, once you get your code to work the way you want it to, why not make it look good and improve the readability at the same time?

Firefox and Chrome

First off, Mozilla and Google both released updates to their web browsers. Firefox 3.6 is out now, and in addition to some bug fixes it introduces eye candy known as “personas”, stale plugin protection, downloadable web font (WOFF)  support, support for new CSS attributes such as gradients, background sizing, and pointer events, and support for new DOM and HTML5 specifications including the drag & drop and file API, which allow for more interactive web pages.

Google released the fourth version of their Chrome browser which added the ability to add extensions and sync bookmarks across multiple computers.  They also have added more HTML 5 support including  LocalStorage, Database API, WebSockets, and more. I like Chrome, but I still haven’t switched to using it as my primary browser (still Firefox). I think it’s making good strides but for the time being I still use it  mostly for testing. I like it, don’t get me wrong, it’s just that Firefox and I are old friends and well, I don’t see a need to dump Firefox just yet.

The iTablet iSlate iPad

Just yesterday Apple released their long awaited tabled, the iPad. Almost instantly the jokes about the name iPad began to circulate around the Internet with no end in sight. I admit I also cringed at the name, and was hoping for something more inventive than iPad. While Apple’s iWhatever line is certainly good branding, it’s wearing thin on me and it’s inevitable that at some point they’ll need to come up with a better solution.

Name aside, I, like many others, was a bit let down by the product that Apple released. Granted, with all the hype and rumors swirling around the tablet, it was virtually unavoidable that no matter what Apple released that it wouldn’t be as amazing as everyone had dreamed it would. A lot of reports call the iPad just a big iPhone with no camera (or ability to make calls) and since I don’t own an iPhone (can’t stand AT&T and don’t want to endure the raping they call data charges) I guess I’ll have to take their word for it. Personally I think I’ll wait until the next generation of iPads comes out before I plunk down $500+ for one. It looks like a decent start, but it has a ways to go before I see it as the “magical” and “revolutionary” product that Steve says it is.

Stop Using IE6

It’s no surprise to those of you that read CatchMyFame that I don’t support IE6 at all. If anything I create works in iE6, it’s by accident. Not only have big names like YouTube announced that they will be ending support of IE6, even Microsoft announced that it’s probably a good thing to upgrade to a more recent browser. The fact that IE6 is still alive and kicking amazes me, though I am well aware of the arguments for using it – primarily ignorance and sloth.

HTML5 and CSS3

I’m happy to see increasing support for HTML5 and CSS3, however I haven’t jumped on the bandwagon just yet. There are some really great features in these updates, however the sad fact is that until all the major browsers support the features, we’re forced to find workarounds and create special conditions to account for those features that don’t exist yet, or aren’t fully implemented, in the major browsers. Like rounded corners? I do, but since some browsers don’t understand the border-radius rule, you either need to generate a solution for those browsers that don’t get it (<cough>IE8</cough>) or ignore it and let those visitors that use browsers without CSS3 support see squared cornered.

So the dilemma is, do we forge ahead and learn HTML5 and CSS3 now, or do we wait until there’s mass support for it and most users will benefit from it? Personally I’m in the first camp and think we should learn as much about it as possible and implement it when its most accessible and least problematic. I also think that if more developers start using HTML5 and CSS3 that it will force browser developers to come out with updates for the features more quickly.

PayPal – Love it or Hate it?

I’ve been a PayPal member for a decade. That said, overall I think it’s a very good service and for web developers it’s a great way to be able to accept payments online. It’s far easier than trying to get a merchant account, a payment gateway and everything else you need to accept credit cards on the web. They offer several services that allow you to integrate their service into your website including something called Instant Payment Notification.

In a nutshell, IPN allows PayPal to send a notification to your server with transaction details whenever you receive a payment. I recently worked with NotOneBit.com to develop a system where my client could sell eBooks online and accept payment with PayPal. PayPal would notify the client’s server upon receiving payment and the customer would almost instantly be able to download their purchase. The system worked perfectly; customers were able to make purchased quickly and easily and then download the eBooks directly from the website. No fuss, no muss.

However we soon discovered a fatal flaw in PayPal’s seller protection policy after one customer claimed that their PayPal account had been hacked and someone used their information to make an eBook purchase. You see, PayPal only protects sellers where there are tangible goods that can be tracked, and since my client sold digital goods, they therefore weren’t protected. My client argued with PayPal that based upon the system that I and NotOneBit designed, that there’s no way that this claim of a hacked PayPal account could be legitimate (we send download data to the customer’s email address so this supposed hacker would have also needed to hack  this person’s  email account in addition to their PayPal account). PayPal didn’t seem to care and just reiterated their policy, so in the end, my client was out the money for the purchase (which PayPal happily refunded to the person with the supposed hacked accounts) and the eBook. In the end the person got a few free eBooks (and hopefully some bad karma). It’s really a shame that PayPal caves so easily on a topic like this when if they took a few minutes to understand what we and probably many other developers using their service to help deliver digital goods have done, then they’d see the obvious fraud.

Caveat venditor.

“The pseudo-class concept is introduced to permit selection based on information that lies outside of the document tree or that cannot be expressed using the other simple selectors. A pseudo-class always consists of a “colon” (:) followed by the name of the pseudo-class and optionally by a value between parentheses.”

There are several pseudo classes widely in use today, for example the :visited selector which is normally used like:

a.external:visited

to specify styling of links that have already been visited by the user.

The target pseudo class selector allows us to style parts of the web page that are targeted by bookmark anchor links. Again, I’ll use the W3C for an example:

“Some URIs refer to a location within a resource. This kind of URI ends with a “number sign” (#) followed by an anchor identifier (called the fragment identifier). URIs with fragment identifiers link to a certain element within the document, known as the target element. For instance, here is a URI pointing to an anchor named section_2 in an HTML document: http://example.com/html/top.html#section_2. A target element can be represented by the :target pseudo-class. If the document’s URI has no fragment identifier, then the document has no target element.”

You’re seen these links since the web began, however now we can apply styling based on the specific bookmark anchor. For example, using the URL in the previous paragraph, we could create a style that was only applied to the bookmark anchor section_2 if the URL contained #section_2. An example helps illustrate what I mean. Take a look at this page, but don’t click anything. Feel free to scroll up and down. Nothing special right? Now try clicking one of the links in the page, or go to the page again using this link /downloads/pseudo-target.html#two. Pretty cool. No JavaScript or anything else needed. What happens is that the bookmark anchor you follow gets styling applied to it only when the URL contains the bookmark anchor (e.g. #two, #six, #seven, etc.). The CSS that accomplishes this is:

dt:target {
	color:blue;
	background:#EFEFEF;
	border:1px solid #CCCCCC;
	padding:4px 2px;
	-moz-border-radius: 6px;
	-webkit-border-radius: 6px;
}

dt:target + dd {
	padding:4px;
	color:#336;
	background: #FDFDFD;
	border-bottom: 1px dotted #CCCCCC;
	border-right: 1px dotted #CCCCCC;
	border-left: 1px dotted #CCCCCC;
}

By applying the :target pseudo class selector, we can tell the browser to only style the elements on the page that match the bookmark anchor chosen. Among other things, this allows you to easily style part of a page like a FAQ and highlight the relevant link only when the user has clicked on a bookmark anchor or followed a URL that targets a specific anchor.  How many times have you followed a link that jumps you to a specific part of a long document only to not be sure that you’re seeing what you expected. This is especially true when bookmark anchor links take you to the bottom of a page when the browser can’t pull the content up to the very top of the window (i.e. link one versus link 10 in the demo).

Browser support

Since the :target pseudo class selector is a CSS3 feature, not all browsers understand it, or implement it fully. Firefox 3.5.1 and Chrome 2.x do a great job. Safari 4 almost gets it all right, and IE8 ignores it completely. Opera 9.64 seems to handle the :target selector alright, but ignores the sibling CSS (dt:target + dd).

CSS Shorthand Cheat Sheet in PDF format, or as a PNG image.

But the space? Why does the space need a special code (&nbsp; or &#160;)? Well technically &nbsp; and &#160; aren’t just spaces, they’re non-breaking spaces. What’s so special about that you ask? The difference between "just an average space" and the "non-breaking space" is that while a typical space between text will allow the text to be broken up on multiple lines, the non-breaking space does just what it’s name implies and prevents the text from breaking. Here’s a quick example. Let’s say you have some text that is being squeezed due to other elements on your page. So the text "non breaking text" ends up like this:

You can see that the text has been broken up on multiple lines. What happens if we absolutely need to have the text all on one line and want to prevent the browser from automatically breaking it? This is where the non-breaking space comes in handy. By substituting regular spaces with non-breaking ones you get:

This obviously breaks the 50 pixel width we specified, however it does keep the text from breaking. Now if you’re like me, you’ve known about the &nbsp; tag forever and never given it a second thought. You might also have run into it when looking at code from other folks or from some HTML editors, especially when people try to indent things manually like: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Section 1. Older versions of FrontPage were especially guilty of trying to be overly helpful by using &nbsp; in places that it didn’t belong, or when content was pasted into it. Older versions of Netscape also used to pitch a fit if a table cell was encountered with no content in it and the easy workaround was to throw a &nbsp; tag in the cell to appease the browser. Thankfully most of today’s better HTML editors know when to properly apply the &nbsp; tag and now so do you.

Note: Also check out the <nobr> tag (which was never a formal part of any HTML standard) and CSS nowrap attribute.

For example, take this example of a typical form:

Nothing wrong there, except that if just one of the field labels, in this case the initial password text, is longer than the other fields, the space between the other fields and their associated labels also becomes very large and you end up with this visual dead space. Of course, you could force the text to wrap by either breaking it up with markup or by imposing a width on the table cells, like this:

Again visually this is undesirable because of the opposite reason — instead of empty dead space we’re crowding text together in too little space. My least favorite option is bumping the text over to be next to the field that it belongs to, like this:

Technically there is nothing wrong with this, but visually it’s irritating. It’s almost like reading movie credits where there are two columns, the left one right justified and the right one left justified. My eyes don’t follow the flow of word logically and odds are my visitors are the same.

My solution? Borrow a page from the print world and use leading dots. Leading dots are those dots you often see in a table of contents where the space between the text and the page number is filled in with small dots. My problem was how to come up with a simple system and make it pass validation at the same time. After some trial and error I came up with a simple CSS solution that does the trick nicely. Here’s a quick example:

How is this done? Basically field label is wrapped in a div which has a small image of a dot applied repeatedly in the x direction as a background. This alone would cause the dots to flow under the text so to nullify that effect, the text itself is then wrapped in a span where the background color is set to match the color of the background of the containing element. Here is the CSS:

.dots {
background:url('dot.gif') repeat-x bottom;
}
.field {
background-color: #FFFFFF;
}
To apply this to the example form, you would just use it as: <td><div class="dots"><span class="field">Last Name</span></div></td>

This method could even be applied to displaying the data from a form or database like so: