Lilac Creative

Things are looking a little different around here! When ExpressionEngine 2.0 beta was released last December, I started planning for a site redesign to be implemented once EE2 was out of beta (which happened last month with the release of ExpressionEngine 2.1). Initially, there were three things I wanted to “upgrade” in this redesign: the ExpressionEngine templates, my site content, and the visual design itself. ExpressionEngine 2 has some great new templating features (i.e. snippets and global variables) that really help simplify templates, and making use of those, I was able to get rid of a lot of redundant code in my templates and template groups. I used Google Analytics to identify content on my site that wasn’t being used. I ditched anything that wasn’t getting significant hits, and reorganized my navigation to make the site necessities easier to get to. The visual design came together slowly, in between client projects. By the time I was ready to translate the design into HTML and CSS, I started considering a fourth upgrade for my new site design: HTML5.

The Viability of HTML5

There’s been lots of buzz about HTML5 lately, but it’s still currently in the Working Draft stage of its development, which means nothing is finalized and a lot could change in the development process. Just how viable is the HTML5 specification, and should I use it for my site? These were the questions I was asking myself as I approached the coding point of my site redesign.

So I started doing some reading on the subject. I read arguments for and against using HTML5 now. Arguments against using HTML5 right away argued that HTML5 is still in the Working Draft stage of its development, and could therefore change a lot before a stable specification is settled upon. Arguments for adopting HTML5 today pointed out that most browsers already support HTML5 elements (with IE being the exception—big surprise there), and IE is easily accomodated by including a quick and easy javascript shiv to force IE to recognize the new elements.

In the end, I decided I wanted to give HTML5 a shot with this redesign, mostly so I could try out the new specification and get a feel for it.

Calling It What It Is

One of the things I like best about HTML5 is the new elements—they enhance web semantics. Before HTML5, I would wrap my header in a div named “header”, my nav in a div named “nav”, and my footer in a div named “footer”. Now each of those commonly used page sections is its own element. The whole point of web semantics in HTML is to correctly organize and identify the purpose of a site’s content while keeping it separate from the presentation of the content, and the new elements allow HTML authors do just that.

In the same vein, HTML5 forms introduce new input field types such as email, url, color, and tel for telephone numbers.

Useful HTML5 Articles and Resources

Below are some of the articles and resources I checked out when considering HTML5:

• 5 Reasons Why You Can Use HTML5 Today
• Why designers should care about HTML5
• A Preview of HTML 5
• W3C HTML5 Working Draft
• W3C HTML5 Forms Specifications
• HTML5 Gallery - A gallery of sites already using HTML5

Have you tried your hand at HTML5 yet? I’d love to hear why or why not!

I've been building ExpressionEngine sites for two years now, and I still learn fun new things EE will do with each new site I build. It's one of the things I love about EE: it's so robust and full-featured that its implementation possibilities are seemingly limitless. Rebuilding my own site on EE was a chance to explore EE even further, and I learned a handful of things I'd never even thought of before (neccessity is the mother of invention, right?). One of those things lies in EE's global variables, which I admit, I've never really paid much attention to before now.

What I Wanted to Do

I designed the blog section of my site to have a fun little banner graphic that would identify the blog and that I could change out seasonally if I feel so inclined. I'm using a pretty standard structure for the blog area: an index page that displays the most recent entries, with pagination at the bottom that will allow readers to go to the next page with the next 5 entries, etc. I wanted the banner graphic to show up at the top of the posting area on the index page, but during testing I realized that with the way I had things set up, the banner graphic would show up at the top of all the paginated pages that use the index page. I thought that was a bit redundant and unneccessary, so I went looking for a way to have my banner only display on the first page.

URL Segment Variables

I knew the logic needed to be something like: { if thisPage == "index" } Content Here { /if }, but I had no idea what variables EE used to acheive what I was going for. So, I asked in the EE forums (another super awesome thing about EE is the friendly support from both official EE techs and the scores of EE enthusiasts in the EE forums). The answer was URL segment variables.

The URL segment variable lets you change your page content dynamically based on what's in the display page's URL. EE breaks its URLs down into segments, where each section separated by a / is a segment. If you have EE installed in your root directory then your main index page is located here: http://www.yoursite.com/. So let's say you have an about page located at http://www.yoursite.com/info/about (assuming you've removed index.php from your URL using one of the hacks available for that). EE identifies segment_1 as "info", and segment_2 as "about."

Identifying My Index Page

Back to what I was trying to do with my index page and banner graphic. With this newfound knowledge, it was now possible for me to identify my blog's index page in a conditional statement using EE's URL segment variables. To get my banner graphic to display only on the index page of my blog, I used this code (outside my exp:weblog:entries loop, since URL segment variables are global, and therefore don't require a governing loop):

{ if segement_2 == '' }<img src="bannerGraphic.jpg" alt="Design Blog" />{ /if }

This code checks to see if segment_2, which would come after "/blog/" in my URL structure, is empty. If it's empty that means it's the index page, since paginated pages insert P1, P2, etc. into the URL after "/blog/" to denote the number of the paginated page. So, if segment_2 is empty, then display bannerGraphic.jpg. Voila! This particular solution could be useful for displaying featured content on your index page only, or if you decide you want your index page to display the full body of your most recent post, but display only excerpts of all following posts.

But URL segment variables have many other dynamic templating possibilities, some of which are explored on the URL segment variable page in the EE documentation, so be sure to check it out!