ExpressionEngine creates very descriptive, keyword-rich URLs. And while the URLs are friendly, they can get quite long (this page’s URL is 77 characters long). But every ExpressionEngine entry also has a ‘short URL’ in the form of its ID number. And when used in a URL, the ‘URL title’ is interchangeable with the ID.

So http://www.sundog.net/sunblog/posts/simple-short-urls-with-expressionengine/

can become http://www.sundog.net/sunblog/posts/3487/ with very little effort.

We can get the URL shorter still, but we’ll need to create a new template group. The shortest a template group name can get is a single letter, and I chose ‘e’ (for ‘entry’). PHP parsing needs to be enabled for the index page, with parsing order set to ‘Output’.

The code in the template is very simple:

{exp:weblog:entries}
<?php
        header("Location: {url_title_path=sunblog/posts}", true, 301);
        exit;
?>
{/exp:weblog:entries}

The EE tags are parsed first (because PHP parsing order is set to ‘output’), which dynamically (based on the entry id) fills in the location for the PHP redirect. The url_title_path is the full text URL.

Using this method we have reduced this:

(77 characters) - http://www.sundog.net/sunblog/posts/simple-short-urls-with-expressionengine/

down to this:

(25 characters) - http://sundog.net/e/3487

Keeping the domain name in the link adds authenticity and credibility. That’s important because third party services can be used to distribute malware. And because the entry id in ExpressionEngine is the permanent identifier for all entries, the short URL will still work even after changing the url title of the entry.

I have added the short URL to the bottom of our entry template, so it is now available for all our blog posts. Feel free to use them for all of your link posting needs.

The id Attribute

Most web developers are familiar with the id attribute in some way. It is a unique identifier for elements in HTML. Because all ids on a page must be unique, they are very useful for specific targeting with CSS and Javascript. The ids themselves are most effective when they are descriptive, such as:

<div id="header"></div>
<div id="content"></div>
<div id="footer"></div>

IDs are also used for inner-page links. Let's say you want to create a link to mysite.com/products.html, but want to jump directly to the content of the page. This would be done by giving the content area an id of 'content', and then creating a link like this:

<a href="http://mysite.com/products.html#content">My Content</a>

The #content at the end of the link represents the specific element to which to jump.

The name Attribute

Before XHTML, the name attribute was mostly used the same way the id attribute is now. It was usually a unique identifier, just like the id. But in XHTML and HTML 5, their function has become focused on interaction and forms.

Form elements can have both name and id attributes. The id attribute on form elements serves the same purpose as I described above...unique identifiers. But the name attribute is different, and in certain circumstances doesn't need to be unique.

When a form is submitted, the page is redirected to the location indicated in the action attribute in the form tag. The values entered into the form are added to the new page as name/value pairs in the HTTP header. Those values can then be accessed with Javascript or a server-side script, where they can be processed or added to a database. The name attribute is what is used for the name in the name/value pair.

Checkboxes and radio buttons have the same name attribute when they are grouped together. This is how they are associated with each other. So a series of checkboxes would look like this:

<label><input type="checkbox" name="colors" id="blue" value="blue"> Blue</label>
<label><input type="checkbox" name="colors" id="red" value="red"> Red</label>
<label><input type="checkbox" name="colors" id="yellow" value="yellow"> Yellow</label>

As you can see, they have the same name, but unique ids. So when the form is submitted, if Blue and Red are checked, the HTTP header will include colors:blue and colors:red.

I hope this has helped clear any confusion you may have had when creating forms. When used together, the id and name attributes can give you a lot of control over HTML.

My advice for mocking up data tables in Photoshop? Don’t bother. There are plenty of other tools that design tables with less effort. And since a mockup’s final destination is a website, why not start with HTML?

HTML and CSS give an enormous amount of control over the design of tables. I always start with a table of fake data, including headers and footers. The markup looks something like this:

    <table>
        <thead>
            <tr>
                <th>Facilisi Formas</th>
                <th>Ullamcorper</th>
                <th>Usus</th>
                <th>Feugiat</th>
                <th>Humanitatis</th>
            </tr>
        </thead>
        <tfoot>
            <tr>
                <td colspan="5">This is the FOOTER</td>
            </tr>
        </tfoot>
        <tbody>
            <tr>
                <th>Row 1</th>
                <td>Parum Lius</td>
                <td>Minim</td>
                <td>$1,799</td>
                <td>Quod</td>
            </tr>
            <tr>
                <th>Row 2</th>
                <td>Ex Amet Erat</td>
                <td>Quinta</td>
                <td>$4,342,099</td>
                <td>Vulputate</td>
            </tr>
            <tr>
                <th>Row 3</th>
                <td>Nonummy</td>
                <td>Sed Seacula</td>
                <td>$325</td>
                <td>Et Dolore Iis</td>
            </tr>
            <tr>
                <th>Row 4</th>
                <td>Doming</td>
                <td>Tation Nunc</td>
                <td>$99</td>
                <td>Nunc Futurum</td>
            </tr>
            <tr>
                <th>Row 5</th>
                <td>Adipiscing Est Id</td>
                <td>Nonummy</td>
                <td>$41,799</td>
                <td>Putamus</td>
            </tr>
        </tbody>
    </table>

I reuse this code for almost any design. Using CSS3 selectors, just about any table element can be targeted for styling. Here is the CSS for the above table:

    table {
        font: normal 12px/1 Helvetica;
        border-collapse: collapse;
        padding: 0;
        border: 1px solid #6a7180;
        text-align: left;
        width: 500px;
    }
    
    tbody tr:nth-child(even) {
        background: #ddd;
    }
    
    th, td {
        line-height: 1.2;
        font-size: 11px;
        padding: 5px 6px;
        border: 1px solid #999;
        border-top: 0;
        border-bottom: 0;
    }
    
    th {
        font-weight: bold;
        background: rgba(163,169,183,.40);
        border-left: 1px solid #6a7180;
    
    }
    
    thead th, tfoot td {
        background: #a3a9b7;
        white-space: nowrap;
        padding: 12px 6px;
        text-transform: uppercase;
        font-weight: bold;
        border: 1px solid #6a7180;
    }
    
    th:nth-child(4), td:nth-child(4) {
        text-align: right;
    }

There are several things to note about this CSS. Alternating row colors (zebra striping) is a great way to make tables easier to read, but it’s normally accomplished by setting a class to every other row in the markup, or through Javascript. It’s much easier using CSS3’s :nth-child(even) pseudo-class selector, which automatically targets every even table row.

Since I want the zebra striping to show through the header column, I am using CSS3’s rgba(red,green,blue,alpha) color value. The ‘a’ in RGBa adds transparency as a decimal value between 0 (completely transparent) and 1 (opaque).

To give the ‘price column’ a right-alignment, I am again utilizing the :nth-child() pseudo-class. In this case, I am targeting the fourth column in each row with td:nth-child(4).

Now load this HTML into your browser (Safari, Chrome, or the latest previews of Firefox or Opera) and take a screenshot. Open the screenshot in Photoshop, crop, and drop it into the mockup. Here is a screenshot of the above sample (from Safari):

Updating the mockup in Photoshop is now done with a simple two-step process of deleting or hiding the current screenshot and dropping in a new one. Easy-peasy.

A note of caution: this HTML and CSS will need to be modified for a live website. Older browsers may not support nth-child selectors (older Firefoxes), RGBa color values (older Operas), or both (any Internet Explorer, including 8).

When placing an image on a web page, it’s usually done by referencing an image on the server:

<img src="/images/smileys/smile.gif" alt="Smile"/>

Which looks like this:

A data URI is the same image encoded and added directly to the code:

<img src="data:image/gif;base64,R0lGODlhEwATAPcAAP/+//7/////+////fvzYvryYvvzZ/fxg/zxWfvxW/zwXPrtW/vxXvfrXv3xYvrvYvntYvnvY/ruZPrwZPfsZPjsZfjtZvfsZvHmY/zxavftaPrvavjuafzxbfnua/jta/ftbP3yb/zzcPvwb/zzcfvxcfzxc/3zdf3zdv70efvwd/rwd/vwefftd/3yfPvxfP70f/zzfvnwffvzf/rxf/rxgPjvgPjvgfnwhPvzhvjvhv71jfz0kPrykvz0mv72nvblTPnnUPjoUPrpUvnnUfnpUvXlUfnpU/npVPnqVPfnU/3uVvvsWPfpVvnqWfrrXPLiW/nrX/vtYv7xavrta/Hlcvnuf/Pphvbsif3zk/zzlPzylfjuk/z0o/LqnvbhSPbhSfjiS/jlS/jjTPfhTfjlTubUU+/iiPPokfrvl/Dll/ftovLWPfHXPvHZP/PbQ/bcRuDJP/PaRvjgSffdSe3ddu7fge7fi+zkuO7NMvPTOt2/Nu7SO+3OO/PWQdnGbOneqeneqvDqyu3JMuvJMu7KNfHNON7GZdnEbejanObXnOW8JOa9KOvCLOnBK9+4Ku3FL9ayKuzEMcenK9e+XODOiePSkODOkOW3ItisI9yxL+a9NtGiHr+VH5h5JsSfNM2bGN6rMJt4JMOYL5h4JZl5Jph3Jpl4J5h5J5h3KJl4KZp5Ks+sUN7Gi96lLL+PKMmbMZt2Jpp3Jpt3KZl4K7qFFdyiKdufKsedRdm7feOpQN2QKMKENrpvJbFfIrNjJL1mLMBpLr9oLrFhK69bJFkpE1kpFYNeTqFEIlsoFbmlnlsmFFwpGFkoF/////7+/v///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAANAALAAAAAATABMAAAj/AKEJHCgokKJKlhThGciQYSIva7r8SHPFzqGGAwPd4bKlh5YsPKy0qFLnT0NAaHTcsIHDho0aKkaAwGCGEkM1NmSkIjWLBosVJT6cOjUrzsBKPl54KmYsACoTMmk1WwaA1CRoeM7siJEqmTIAsjp40ICK2bEApfZcsoQlxwxRzgI8W8XhgoVYA+Kq6sMK0QEYKVCUkoVqQwQJFTwFEAAAFZ9PlFy4OEEiRIYJD55EodDA1ClTbPp0okRFxBQDBRgskAKhiRMlc+Sw4SNpFCIoBBwkUMBkCBIiY8qAgcPG0KBHrBTFQbCEV5EjQYQACfNFjp5CgxpxagVtUhIjwzaJYSHzhQ4cP3ryQHLEqJbASnu+6EIW6o2b2X0ISXK0CFSugazs0YYmwQhziyuE2PLLIv3h0hArkRhiCCzAENOLL7tgAoqDGLXSSSaPMLIIJpmAUst/GA3UCiuv1PIKLtw1FBAAOw==" alt="Smile"/>

Which will display as:

While almost all modern browsers support data URIs (including Firefox, Safari, Opera, Chrome, and Internet Explorer 8) IE 6 and 7 don’t, so that limits their usefulness. Also, data URIs aren’t cached like normal images; an encoded image used twice on a page is downloaded and rendered twice, every time that page is loaded. The encoded data is usually larger in size than the actual image equivalent, so it’s best to keep the encoded images small.

There are several web applications available that will encode images for you. My favorite is here: http://www.scalora.org/projects/uriencoder/. If you use a Mac, there is a stand-alone app available: http://osx.iusethis.com/app/imagetodata

Using data URIs certainly seems like a gimmick, but it can be useful in certain circumstances. If you contribute to a blog but don’t have the ability to upload images, data URIs would be a nice work-around. Also, if you have a need to keep everything contained in a single HTML file (say, for offline viewing), data URIs can come in handy. They also work in CSS, so you can add encoded images through styling.

I would suggest only using data URIs for simple graphics, such as the smiley sample above. Larger images add a LOT of code, and can make your code hard to read. Internet Explorer 8 is limited to 32 KB (even with that limitation, imagine adding 32,000 characters to your HTML). However you use them, have fun!

Reference: http://en.wikipedia.org/wiki/Data:_URI_scheme

On the new skittles.com, the only part of the site that is actually from Skittles is a small navigation menu at the top left that floats above the pages. The navigation is just six items: Home, Products, Media, Chatter, Friends, and Contact.

The Home and Product links load the Wikipedia entry for Skittles. Media loads special Skittles Flickr and YouTube pages. Friends loads the official Skittles Facebook page. Perhaps the most daring page is Chatter, where they load a Twitter page with ‘skittles’ pre-populated in the search. This pulls every post from Twitter that has the word ‘skittles’ in it, good or bad. The Contact page seems to be the only one that isn’t using content from a social site.

There are several thoughts I have about their site. Above all, they are showing strong confidence in their brand. They believe in their product well enough to use content they have no control over. Technically, it’s very simple for them to maintain. All that comes from their servers are pages with their navigation and an iframe to load the content. This also means there’s very little content they need to maintain themselves. Their biggest challenge is to promote and maintain the social and viral awareness of their site.

This approach to web development is definitely not for everyone, but I believe it works for Skittles. While Skittles is technically only candy, it is also an experience that has been built through decades of advertising. Now, that experience is being built by everyone.

Keep the styles separate from the content. Use external stylesheets and link to them from the HTML. Use proper markup for your content. Make sure headlines are within <h1>-<h6> tags, paragraphs are within <p> tags, and so on. If your site is built using the best practices of web standards, it’s already more than halfway there.

Pay attention to the default rendering of elements. Taking away CSS means all headlines will be bold, all paragraphs will have a double-space between them, and all lists will be indented. There are no floats or positioning, so content will be in its source code order. Every block element will start on a new line, and every inline element will flow with text. Choose your markup wisely and always plan ahead.

Don’t be afraid of <hr/> and <br/> (yes, they’re still part of XHTML strict!). Using horizontal rules to divide sections of your site can make it a lot easier to use. They are also easily hidden with CSS, so you don’t need to show them when not needed. Line breaks should be used any time you have text on different lines that is still part of one paragraph (such as a street address).

A naked webpage will have a white background, and so should your logo. In CSS, show the logo for the styled page as a background image. Add the logo with the white background as an <img> tag in the markup and hide it with CSS. That way, the appropriate logo will show according to whether styles are turned on or off. (This technique can also be used with print stylesheets.)

Every web page is different, so they don’t all have to look the same when styles are taken away. Experiment to find unique ways of designing content without CSS. Remember, your website is going to run around naked every once in a while. Be sure its warts aren’t showing.

Where does this anti-tableism come from? In the early days of web design, it became a very popular technique to build web pages using tables to lay out the elements. The ability to slice up Photoshop mockups and arrange them in a grid was the most basic skill a web designer could have. Everybody did it. Since web browsers were in their infancy, it was almost the only way to have a consistent design across browsers. As time went on, pages became more complex. Their designs required more and more tables nested within tables, and page size grew and grew. I remember building pages where just the markup was over 100KB.

But soon, the web grew up, and browsers did too. With using stylesheets, we now have a much better way of designing a page. We keep the HTML dedicated to defining the content, and the CSS to styling it. When this method was new, we called it ‘table-less design’. Tables became associated with the ugly past. So they needed to be replaced…everywhere.

But tables should not be replaced. Tables are meant for tabular data (hence the name). Just think of them as a spreadsheet in HTML. All the HTML elements and parameters associated with tables are there to support a tabular structure. And they are perfect for the job.

Of course, this means tables should NOT be used for laying out a page, since sliced images and transparent spacer .gifs are not tabular data.

As for the calendar? It’s meant to be a grid. Calendars are tabular data. Each row represents a week, and each column represents a day of the week. Once the HTML defines the structure, CSS takes over styling it.

Tables aren’t dead in web design. They’re just finally doing what they’ve been supposed to be doing all along.

It’s because <strong> and <em> are not replacements for <b> and <i>. They are supplements. And there are still plenty of places <b> and <i> should be used instead.

Book or movie titles are usually italicized, but it’s not to give them emphasis. It’s merely to set the text apart, or to give it formality. The <em> tag would not be appropriate in this case. Sure, a <span> with a class attribute of ‘movie-title’ could be used, and then italicized with CSS. But why not use the tag that specifically italicizes text? Using something like <i class=“movie-title”> gives the text meaning and gives it formatting for accessibility and viewing the document without styles. (By the way, the and in the last sentence was marked-up with <em> because I was giving emphasis to it, but was marked up with <i> in this sentence because I am only setting it apart.)

The semantics of <b> and <i> are found between the lines. Just like other non-semantic tags, such as <div> and <span>, they are used to group text together.

<b> and <i> have gotten a raw deal. It’s time to bring them back to their former glory!

The modern personal computer’s user interface is largely designed around the mouse. Almost every operating system is based on objects (such as windows, icons, and buttons) being manipulated by a little arrow (the pointer) on a two-dimensional screen. The mouse was designed to allow a human to easily move the pointer with precision. Moving the pointer from one side of a twenty-four inch monitor only requires moving the mouse a few inches, which is very helpful for ergonomics.

Nintendo designed the Wii controller for games. It’s perfect for mimic-ing swinging a bat or throwing a bowling ball. It’s also useful for navigating the simple menus in the Wii’s interface. And for some computer related tasks, such as browsing the internet, it may work fine. But one of the reasons it won’t replace the mouse is it requires a certain distance and position from the screen. It’s made to be used on a TV across the room, not on a monitor eighteen inches from your face. A lot of people (including myself) make a living by sitting in front of a computer for eight hours or more a day. Imagine holding up and waving a device in front of you all day. Think about all the precise targeting you do to get your work done, such as opening folders, moving icons, clicking on menus, or clicking the ‘bold’ button in Word. We don’t think about how often we do it (which is probably thousands of times a day), because the mouse makes it easy to do.

Touch screen popularity is also on the rise, thanks in part to Apple’s iPhone. And there’s no doubt that for a small mobile device, a touch screen is the perfect way to interact. One of the reasons it works so well on the iPhone is because the interface was designed around the finger. Many of the metaphors that exist in a personal computer, such as hovering over items, click-and-drag to select, or overlapping windows, don’t exist on the iPhone. It’s a different kind of interface. Having a touch screen desktop computer might sound neat at first, but it will quickly turn into a burden.

Try this little exercise: if you’re on a desktop or notebook computer, tap the actual screen (be gentle!). Tap your icons, act like you’re dragging them around, or moving or closing windows, or selecting text. Try to do it as quickly as you can with your mouse. Doing that for a minute or two isn’t bad. But imagine doing that for ten minutes, or eight hours! It would be enough to put an orthopedic surgeon on speed dial.

The mouse is very well suited for the problem it solves: interacting with a personal computer. There will be many more specialized interfaces in the very near future like the Wii and iPhone that don’t require a mouse. Small internet devices, like a sort of simplified tablet PC, would work just fine with a touch screen. But the personal computer is too generalized for the mouse to go away. So five, ten, fifteen, or more years in the future, the mouse will survive and remain in good health.