We often come across css code in dire need of optimization (details have been changed to protect the guilty), and shows a misunderstanding about the power of css:

As you can see, several properties are repeated across elements.
These can (and should) be consolidated.

Let’s consolidate them first by applying very common properties to the body element:

Okay, now we see a lot of repetion is still happening here. Much of this repetition can be removed by using the comma (,) selector, which allows you to make lists of elements:

There is a pattern to the font-size, margin-height, and line-heights. We will now use this to our advantage to make life even easier.

With just a few basic css selectors, this code was cut in half.

Just hit a bug with the Textile 2.0 library:

Was producing:

Found the solution here:

You can work around the problem, by replacing these two lines (in the fList function in /textpattern/lib/classTextile.php):

foreach($text as $line) {
  $nextline = next($text);

 

with:

foreach($text as $nr => $line) {
  $nextline = isset($text[$nr+1]) ? $text[$nr+1] : false;

 

The “cascading” in “Cascading Style Sheets” has several facets: computed values, inheritance, and specificity. Understanding how these cascades work is an integral part of your css ninja training.

Computed Values

Many of the values assigned have a unit. Some of these are relative (like em and <span>), and some are absolute (like px and in). Relative values are based on their parents: an element with a width of 50 uses the element’s parent to determine the actual width of the element.

Likewise, if both the parent and child elements’ font-sizes are 1.5em, the child’s actual font size will be larger than the parent’s.

Absolute values do not change based on their parent values. These are often obvious: color: red; for example. Pixel values are absolute, though the actual value displayed by the UA(User Agent) may differ (due to display or text-size settings).

Inheritance

Inheritance is the passing on of attributes from parents to children. It works in CSS like this: An element’s font color is set to red. The color for its child elements will also be red (if left unspecified or set to inherit).

Specificity

This is how CSS decides between competing styles. Take a look at the following code:

So what color do the elements end up with? To answer that question, we need to know how the competing selectors are chosen.

Each selector has a particular weight outlined in this table:

These weights are all added up and the “heaviest” selector set wins. So using the css above, here are the results:

Links

w3.org
wikipedia
htmlhelp

On a recent project, an issue cropped up where we were exporting xml reports to a third party, who had rules about line lengths in Description fields.

So, I wrote up a quick-and-dirty character counter for the description field so the client can keep their descriptions under the 1500-word limit.

Here’s how it was done:

Now the html and javascript:

All was working well, except I underestimated the descriptions. The next morning, the thing was broken. The php side was kicking validation errors (“over 1500 characters”), while the javascript was counting a mere 1480. Why?

Turns out the data was full of bullets and other multibyte characters. To make the counts match, I needed multibyte-safe php:

Hooray! Now the counts match!

Had a problem recently where I had to update hundreds of input fields within a shopping cart, setting prices of product variants from $200 to $49.

They were named in sequence:

So I busted out the command line in Firebug.

I got in touch with my local Javascript guru who helped me come up with some code that did work:

This saved literally hours of [TAB][TAB][TAB][TAB][Ctrl+V].
Thank you Firebug!

Blogs, bulletin boards, community sites—the whole web2.0© rely on the same thing: user input. On the web, user input usually means HTML.

Some simple HTML is easy to learn, like <b>bold</b> and <i>italics</i>, but other techniques (like links, lists, and blockquotes) can be a little more daunting. For a site owner, badly written HTML can break a site.

So what are you, the site owner, to do? You shouldn’t have to learn all about HTML yourself (unless you want to), and can’t force your readers to learn HTML just to post feedback.

There are a few apps that can help people “mark up” text, and these work well, in general. The drawbacks are they can be bulky or hard to use, and suffer from technical issues including lack of browser support and buggy performance. These drawbacks make them more suited for intranets and administrators, and less suited for the rest of the World-Wide Web.

Lately, another method has resurfaced: server-side markup generators. They work behind the scenes to change easier markup into HTML. Anyone familiar with bulletin boards will know about BBCode; it generally worked like this:

But this is not really enough. Its really just HTML with replaced with [ and ]. BBCode also can’t do some of the the advanced things (lists, blockquotes) HTML still has to offer.

Along came Textile

Here at Black Dog, we use Textile to solve this problem. It is a server-side markup generator, like BBCode, but it has all of the bells and whistles you need to produce good HTML. Instead of using HTML-like syntax, it uses easy-to-remember symbols. The best part is, the symbols make sense before they are turned into HTML.

Textile also handles lists and sublists, ordered and unordered:

It also helps you out with the little things: double quotes and single quotes are made “curly,” and dashes—I love those helpful little guys—are made into their correct typographical charaters.

The best part: Textile doesn’t ruin good HTML, so you can mix-and-match HTML and Textile if you want to, but it quietly throws out bad or broken HTML so your content stays nice, clean, and readable.

Everybody wins

As a site owner, you have some additional protection against buggy HTML from users or even yourself. As a user, you can make make your text stand out without learning a bunch of HTML tags. As a reader, the web will be a little easier on the eyes.

Further Information

Textile’s entry on Wikipedia
Advanced Textile reference (hobix.com)
Textpattern (CMS built with Textile)
Dean Allen’s home page (Creator of Textile and Textpattern)

Typography on the web resembles print typography only superficially. There are important limitations with units, fonts, styles, and effects.

In web design, there are a few common units used for setting the sizes of elements. They are:

For a full list, see W3Schools.

The rub is that all of these units are converted into pixels for display on the screen. Each OS and browser use a slightly different algorithm for this conversion; generally 9pt=12px but that will vary depending on the settings of the individual computer.

These differences are relatively minor (1 or 2 pixels) when applied to text alone, but can become unbearable when specifying line height, letter spacing, word spacing, etc. When displayed on-screen, extra care must be taken to consider these uncontrollable discrepancies in font rendering algorithms.

Therefore, the following css units are generally used by Black Dog Studios for setting font sizes on fixed-width layouts:

font-size: px
line-height:
letter-spacing: em
word-spacing: em
margins: px (sometimes em)
padding: px (rarely em)

We of course do our best to match design comps which use points or an unknown unit; however Black Dog Studios cannot guarantee pixel-perfect (or sub-pixel-perfect) accuracy when making these conversions.

The following links are to articles and tools related to the conversion between px, pt, em, and %.

• 
  http://sureshjain.wordpress.com/2007/07/06/53/
• http://www.faqts.com/knowledge_base/view.phtml/aid/19491
• http://archivist.incutio.com/viewlist/css-discuss/78195
• http://riddle.pl/emcalc/
• http://www.jerekdain.com/fontconversion.html