I learned HTML in 1998, by viewing source code and trying to replicate what I’ve seen. I built on that knowledge by making my own websites: about myself, about books and series that I loved, communities like the long-forgotten web rings and those cute little adoptable graphics. (Which brings me to another point: I learned to make graphics and some pixel art from those days, too.)

I learned CSS shortly after, as I made websites, starting from the shiny that is absolute positioning and continuing on to learn about fluid layouts, floating, the box model, etc. as I went along. My shrines and cutesy sites made way to personal journals and blogs.

I learned PHP on my own in 2002 or 2003, after I started liking Python for web apps but found it difficult to find an affordable web host with Python–PHP was much more available. I used it for small websites–directories, cliques, and making my own little script to manage fanlistings, which were becoming a big part of what I did online. (I wish I could say I learned SQL on my own, but not really–I took up database courses in college.)

JavaScript, ah JavaScript. I learned bits and pieces, but generally disliked it, until I needed to learn for work; I think a framework certainly makes it easier to wrap your head around, and while JavaScript won’t be in my list of top languages, I do find that I enjoy working with it nowadays–it’s an ongoing process, and I learn more and more as I continue to use it in what I build.

I think it speaks a lot of how learning for yourself, and using it as you learn, is one of the best ways to learn. And this year, I think it’s high time I learn something new again, and use it in something I build while I learn.

I haven’t decided what the new tool will be–a new framework? a new language?–nor the product, for that matter. But I do know that making time for pet projects opened me up to much more than just the enjoyment of creating and building for myself, that it’s something I want to do for myself this year.

So in 2011, I’ll learn and create something new.

One of the best ways to speed up website performance is by reducing the number of HTTP requests the website makes — it’s the first rule in YDN’s Best Practices for Speeding up your Web Site and YSlow, which is arranged according to what technique would have the most impact on your page’s performance. This rule can be quite tedious to do when optimizing a current website/layout, so the best case, really, is to start a project with this in mind.

The article explains it well, so I’ll just quote them (italics mine):

80% of the end-user response time is spent on the front-end. Most of this time is tied up in downloading all the components in the page: images, stylesheets, scripts, Flash, etc. Reducing the number of components in turn reduces the number of HTTP requests required to render the page. This is the key to faster pages.

The use of CSS sprites has been around for quite a while now, and is the best way to reduce the number of HTTP requests to your server. A CSS sprite is basically multiple images combined into one single, larger image, which is then positioned into your HTML elements via CSS.

Can you imagine the conversation between the browser and the server for either case?

Browser: Give me the background for the Index menu item.
Server: Here you go, it will take around 1 second.
Browser: While I’m getting that, can you also get me the background for the Blog menu item?
Server: Here it is, another second for that.
Browser: And let’s not forget the background for the About menu item, too.
Server: Of course, here you go, you’ll get it in a second.
…

As opposed to when you use a CSS sprite for your menu items:

Browser: Give me the background image for the navigation menu items.
Server: Here you go, it will take a bit less than 2 seconds.

Short and sweet.

Note, however, that if your visitors are predominantly dialup users, this might not be a good rule for you to follow — mostly because you really can’t stuff any more data into that pipe than that pipe can handle. It will take longer for them to download the image, which will affect their perception of the website, as opposed to an image that gets downloaded faster and shows up on their browser faster. Remember those old-school rules about slicing header images? That’s basically rooted in that scenario: dialup can only download so much, so give them a couple parts of the header to download and see immediately. What’s best for your website depends on your target visitors.

There are a couple of CSS sprite tutorials and generators around:

• CSS Sprites Generator – a simple generator, giving the sprites in PNG and GIF and giving background positions for each image
• Website Performance’s CSS Sprite Generator – contains a lot more extra configuration options for sprite generation if you want finer control, allows you to choose what image format to generate
• A List Apart’s CSS Sprites: Image Slicing’s Kiss of Death article
• CSS Sprites: What They Are, Why They’re Cool, and How To Use Them
• Image Sprite Navigation With CSS

…to name a few. If you’re just getting started with spriting, I’d suggest you create your sprite manually in your preferred image editing application before trying one of the generators and work on something simple like navigation or lists with icons for the first few times. This should give you a better grasp of what happens with a sprite.

Something to keep in mind: sprites will add complexity to maintaining your design. Adding another image to an existing sprite, updating your CSS code to reflect that (and possibly impacting current CSS rules on other images using that same sprite) is slightly more time-consuming than just uploading a new image and a new CSS rule to use that single image. And of course, the more images on a single sprite, the more difficult it is to keep that image and the accompanying CSS rules maintainable. One of the ways to combat this is to organize sprites according to use. As opposed to one über-sprite containing everything and the dust on the coffee table, a sprite for navigation and a sprite for list items separately is easier to maintain and organize.

Good luck with minimizing your HTTP requests!

The result was code bloat, and once I started weaning away from this practice, I had hundreds of files to update, as they all looked like:

<div class="content">
<div class="title">Some heading!</div>
<div class="date">July 4, 2008</div>
<p>This is some of the content of the page. Yay!</p>
<div class="subtitle">Some subheading</div>
</div>

(I’m sure if you look hard enough you’ll find a couple of my older sites still sporting this sort of markup.)

Movements and events like the annual CSS Naked Day woke me (and hopefully a few others) to the sad truth that as web developers and designers, we can be so obsessive about needing every single pixel in place, but completely forget about keeping the house clean. The impact may be minimal at the onset (i.e., “hey, everyone sees the pretty decors after all!”) but just like your house after a rush cleaning because people are coming over tonight, you have to deal with guests stumbling into hidden mess, things not in the right place, and a painful cleanup job afterward.

(Of course, there’s the other end of the spectrum where holy wars are raged between the use of a <ul> and a <table> tag, which is just as bad, IMO.)

There are three things I do when working on a website to help me keep as close to “clean” as possible:

1. Keep markup in the back of your mind when creating your design. The best example of this is creating a navigation menu. Can it be done in lists? What sort of arcane CSS-fu is needed to make it work like so?
2. Start with a bare HTML page. I’m doing this right now for a couple of projects. I have wireframes (structures) where I’ve laid out roughly where things are going, but nothing else. No colors, no images, no JavaScript, just plain ol’ markup-py goodness.
3. Once done, remove stylesheets and take a look. It’s easy for me to lose track of things when I’m on a roll, so this one personally has made me cringe a lot of times. Temporarily removing all styles from my work is a good way to see if it’s still readable and navigable even without all my pretty styles, and that it’s as close to how I designed it as possible. (This pretty much destroys all unordered lists masquerading as tables… so beware.)

Remember: there are 91 HTML tags available, one of which might serve the need and communicate your intent better. But don’t force it: sometimes saying nothing at all is better than being misunderstood.

According to HTML specifications, there are three elements which are supposed to semantically mark up quotations, namely <blockquote>, <q> and <cite>. Although all intended to markup quotes, they should be used in different contexts. So when should you use what?

I’ve only seen <cite> used fairly recently, while at work in Y!, which sadly doesn’t say a lot about myself and my friendship with various markup tags available. I’ve been using it a bit more since. The best thing I’ve learned from the article, however, is this:

Although <q> is almost never used, it has some useful properties. For instance, you can specify the appearance of quotes within the <q>-element via CSS. That’s reasonable as different languages use different quotation marks for the same purpose. For instance, these ones:

Q {}
Q { quotes: '»' '«'   }
Q { quotes: '„' '“' }

Modern browsers support this way of styling. Of course, Internet Explorer (even in its 8th version) doesn’t support it although it knows <q> pretty well…

The article also shows a few bad and good practices for usage of block and pull quotes. I’ll admit I’ve fallen victim to a few of those questionable practices, but it’s never too late to improve things. ;)

For the first Frontend Friday post, I’ve decided to write about a topic that’s rather central for all web developers: the tools that we use. We all use different programs and extensions and scripts to help us code up a nice layout for our websites. I wanted to share some of mine, and I hope you find them useful.

My top 7 tools:

1. Aptana Studio

   I’ve been using Aptana well over a year now, and in fact I wrote a review about the web IDE before. Because it stems from Eclipse, and Java, it suffers a bit of lag especially when working with large files; I wouldn’t recommend using it for that quick 30-second style fix on your website.

   But working on websites that contains quite a few bells and whistles, I find Aptana to be quite helpful. The Project pane stores all ongoing projects, the Validation tab is quick to look up typos which result in syntax errors, the Outline pane makes jumping between functions and HTML nodes a breeze, and Code Suggest is always great to have around. (You should take a look at my review if you want to know more; while that was for the beta version, it’s still relevant.)

2. Firefox

   Yes, Firefox just had to be there. I will admit that as of late I’d been very frustrated with Firefox’s memory-hogging practices and annoying lag, and if it weren’t for Firefox being insanely great for web development, I might have dropped it for the faster Safari. Firefox is a great standards-compliant browser, plus it provides an avenue for a plethora of web-developer-friendly tools, some of which are…

3. Web Developer Toolbar

   Chris Pederick’s Web Developer Toolbar is impossible to live without. It’s lightweight and contains a lot of helpful tools: disabling cache to make sure you see your CSS updates, cookie manipulation, CSS lookups, markup and style tools for debugging, browser resizer, viewing generated source (for all those whizzy JS things), and more. If you’re a developer and you don’t have this on Firefox yet… what cave have you been living in?!

4. Firebug

   Actually, Firebug vied with the Web Developer Toolbar for the “must have” spot, with the toolbar winning simply because it’s lighter and more mainstream: even if you’re a hobbyist making personal websites during your free time, the toolbar is useful. Firebug is also a must-have, but mainly for more heavy duty stuff, and especially for debugging purposes: completely clueless what styles are messing things up on a certain element? Lost as to what is happening to your variables when running JS? Firebug makes digging into code easy. I can’t count the number of times Firebug has saved me hours of trawling through CSS or numerous alert() calls.

5. Multiple Internet Explorer installations

   There are numerous multiple IE tools out there, but the one I personally use on my Windows test machine is TredoSoft’s Multiple IE. I really only test for IE6 and IE7, though (I should install IE8 soon, too…). It’s a bit of a pain, but that’s the way life rolls. The IE Developer Toolbar is also a must-have for IE-proofing your website. I hope they update the toolbar to include a debugger soon.

   Naturally, you will also need other browsers installed, according to what you wish to test with. I test according to Yahoo!’s list of A-grade browsers, even for my personal work (well, in varying degrees, as I don’t have multiple images of Windows sitting in my personal machine, for instance).

6. YSlow

   YSlow analyzes my pages’ load times. I typically only use this nearer to the end of development, to check if I need to combine more images into sprites, chunk together CSS and JS, etc. It’s definitely a good guideline checker for webdev best practices, which may or may not be critical for you, depending on what you are working on.

   YSlow takes into consideration Yahoo!’s rules for high performance websites, which every web geek into making websites should read through at least once.

7. Fiddler and/or Tamper Data

   These two are mostly useful for deeper digging into the communication between your website and the server, and may or may not be applicable for the type of work you do. I find it highly useful for verifying form submissions’ raw data and AJAX requests — you can stop the data transmission, fudge up the content, and release it, which helps you trap bugs and issues.

   Tamper Data is a nifty Firefox extension for this purpose, and Fiddler is an HTTP debugger tool, much more robust than Tamper Data. Unfortunately, Fiddler is not available on Mac OSX — I’ve been looking for a good alternative for a while now (Paros looks like an interesting alternative, but for some reason I can’t get it to start monitoring traffic).

So those are the top 7 tools I use for working with code. What are yours?

Recently I’ve come across a number of discussions about what constitutes a table-less layout, and most developers’ definitions can be pooled into two differing definitions of this term:

1. A table-less layout used on a website means that no tables are used on the website, none at all, none whatsoever. For all content, use paragraphs, divs, ordered/unordered lists, spans, and the like. Tables are for newbiez.
2. A table-less layout used on a website means that tables are not used to lay out graphical elements and content on the webpage, i.e., the header, footer, content, sidebar, etc., but uses tables for tabular data when it’s appropriate.

Personally, I believe in the second definition of a table-less layout, and I was actually amazed to learn how many people actually believe in the first definition. At the risk of a semantics war, I feel like I have to post about this. It’s probably due to all the HTML/CSS/JS/etc talk I’m exposed to for most of the day while at work; I’m exposed to debates about semantics, accessibility, etc. with some regularity.

HTML is a markup language: Hypertext Markup Language. Any markup language (HTML, XHTML, XML, YAML, etc) is only as good as the structures and tags one uses to markup their data. Using appropriate markup in order to provide inherent meaning to data is important. See for example:

<h1>This is a page heading</h1>
<p>This is some paragraph text. If I am a computer, I wouldn't understand the meaning of these words, but the P tag I, as the developer, used to encapsulate this text tells the computer that this is a paragraph. Now I want to quote someone.</p>
<blockquote><p>Now I am quoting someone, and the computer knows it's a quote because this is inside appropriate tags. This is me trying to emphasize something.. And now my quote is done so I need to cite my source.</p><cite>This is the author of my quote</cite></blockquote>
<p>This is another paragraph, and this time I need to outline a step-by-step process, like so:</p>
<ol>
<li> Step one: do this. </li>
<li> Step two: do that. </li>
<li> Step three: do more things. <?li>
</ol>
<h2>This is another heading, but of lesser importance than h1</h2>
<p>And more paragraphs, but for now this is a strongly-emphasized chunk of text.</p>

Using appropriate, semantic markup is important for us as developers, because we are the ones who develop the web. We are the ones who program the content that is the meat of the web. If we use meaningful markup, it will be easier and easier for computers to index and determine our content, and to provide it to others who need that content.

That said, semantics is hazy, and data can be different in meaning for each developer, for each programmer. Sometimes it does make sense to use lists over tables, when it’s more appropriate. But when you’re talking about correlated data, data you see on charts, feature and price matrices, and the like, it’s usually more appropriate to use a table, because by definition, it is tabular data we are representing.

For example, a price list. It’s a list, right? So here we’re using a list:

<h1>Price list</h1>
<ul>
   <li>
      <ul class="header">
         <li> Product name </li>
         <li> Colors available </li>
         <li> Stock availability </li>
         <li> Price </li>
      </ul>
   </li>
   <li>
      <ul>
         <li class="header"> Product one </li>
         <li> Blue and green </li>
         <li> In stock </li>
         <li> $10.00 </li>
      </ul>
   </li>
   <li>
      <ul>
         <li class="header"> Product two </li>
         <li> Blue and green </li>
         <li> In stock </li>
         <li> $15.00 </li>
      </ul>
   </li>
   <li>
      <ul>
         <li class="header"> Product three </li>
         <li> Blue and green </li>
         <li> Out of stock </li>
         <li> $20.00 </li>
      </ul>
   </li>
</ul>

And here is the same data marked up in a table:

<h1>Price list</h1>
<table>
   <tr>
      <th> Product name </th>
      <th> Colors available </th>
      <th> Stock availability </th>
      <th> Price </th>
   </tr>
   <tr>
      <th> Product one </th>
      <td> Blue and green </td>
      <td> In stock </td>
      <td> $10 </td>
   </tr>
   <tr>
      <th> Product two </th>
      <td> Blue and green </td>
      <td> In stock </td>
      <td> $15 </td>
   </tr>
   <tr>
      <th> Product three </th>
      <td> Blue and green </td>
      <td> In stock </td>
      <td> $20 </td>
   </tr>
</table>

Example #2 has lesser code (better in terms of page size and load time), needs lesser CSS since you don’t have to muck with floats (better, again, in terms of css stylesheet size and load time), and makes sense because we are looking at tabular data: we have specific information connected to a certain product (as defined by the headings).

(Also, shameless pimping: YUI can parse tables and show dynamically-generated charts (from your table’s data) using DataTable–currently in beta.)

If makes more meaningful sense (in terms of markup) to use a list over tables, sure, I’d use lists, and would promote the use of lists as well. But what I’m against is the use of lists for tabular data “just because” — just because I want to make a “table-less” website, just because it’s kewl to sweat it out using lists in lieu of tables and I wanna show I’ve got the HTML/CSS chops to do so, just because I feel that I have to prove myself to others.

I feel a lot of newer web developers end up doing this because of those reasons; I’m a victim of this myself. I was this way when I started not using tables in layouts way back in 2000, I was this way when I started using XHTML to markup my pages a few years back (three or so?). I jumped in on the bandwagon because it was the cool thing to do, because I can say, hey, I can do this. Now I have a lot of websites I need to update because my understanding of the semantic web has changed.

That said–I know there are other ways to mark up that chunk of dummy data I put up. Are there other ways of doing it that is meaningful to you as a developer? What criteria do you use when creating table-less layouts?

Gasp! I can hear it now. I’ve been an avid XHTML supporter for quite some time, making sure my scripts chug out valid XHTML markup. A lot of my online friends feel the same about XHTML. But I’ve been hearing more and more about the arguments for and against XHTML, that I’ve decided to sit down and really think about it.

Here are my reasons for choosing XHTML waaaay back when, and what makes these reasons invalid:

1. False: HTML is parsed as tag soup, but since XHTML should be valid when parsed, it should be parsed faster and better, not in “quirks mode”.

   Unfortunately, almost all usage today of XHTML is as HTML, and not as XML. This means that they are parsed as “tag soup”:

   “XHTML is an XML format; this means that strictly speaking it should be sent with an XML-related media type (application/xhtml+xml, application/xml, or text/xml). However XHTML 1.0 was carefully designed so that with care it would also work on legacy HTML user agents as well. If you follow some simple guidelines, you can get many XHTML 1.0 documents to work in legacy browsers. However, legacy browsers only understand the media type text/html, so you have to use that media type if you send XHTML 1.0 documents to them. But be well aware, sending XHTML documents to browsers as text/html means that those browsers see the documents as HTML documents, not XHTML documents.” XHTML Frequently Asked Questions

   If you want your XHTML to be parsed as XML (and take advantage of the marginally-faster parser… and when they say “marginally”, apparently it is “marginally”!), you have to send it as XML. Unfortunately IE doesn’t support that — you will get a document tree instead of your website layout, unless you give it extra instructions to do so. (See here.) And since IE is still the dominating browser around (yes, I know you’re annoyed), one just can’t ignore it.

   If XHTML is parsed the way it should be parsed (as XML), once your document is found to be not well-formed, the browser is supposed to choke and stop parsing. Period.

   “To minimize the occurrence of nasty surprises when parsing the document, XML user agents are told to not be flexible with error handling: if a user agent comes upon a problem in the XML document, it will simply give up trying to read it. Instead, the user will be presented with a simple parse error message instead of the webpage. This eliminates the compatibility issues with incorrectly-written markup and browser-specific error handling methods by requiring documents to be “well-formed”, while giving webpage authors immediate indication of the problem. This does, however, mean that a single minor issue like an unescaped ampersand (&) in a URL would cause the entire page to fail, and so most of today’s public web applications can’t safely be incorporated in a true XHTML page.” Beware of XHTML

2. False: HTML is so old-school, it’s getting deprecated.

   Apparently not. I’ve heard of HTML 5 for a while now, but only fully realized recently what this means. The W3C renewed the HTML working group, and apparently, web browsers have leaned more towards HTML5 than XHTML2.

   Even more shocking, XHTML2 is not backwards-compatible!

   “XHTML 1.x is not “future-compatible”. XHTML 2, currently in the drafting stages, is not backwards-compatible with XHTML 1.x. XHTML 2 will have lots of major changes to the way documents are written and structured, and even if you already have your site written in XHTML 1.1, a complete site rewrite will usually be necessary in order to convert it to proper XHTML 2. A simple XSL transformation will not be sufficient in most cases, because some semantics won’t translate properly.

   “HTML 4.01 is actually more future-compatible. An HTML 4.01 document written to modern support levels will be valid HTML 5, and HTML 5 is where the majority of attention is from browser developers and the W3C.”

   Beware of XHTML

These are the most important arguments, arguments that I can’t ignore as a web developer. Obviously, the Beware of XHTML document is a good read, gives both the myths and benefits of using XHTML. What’s even more important is that the way XHTML is used, it’s just like “the new HTML”, when it shouldn’t be that way. XHTML is XML, and should be treated as XML. The extension shouldn’t be .html. Browsers should “give up” when there’s an error, and not try to repair the document — after all, that’s what browsers do with ill-formed XML documents, right?

What doctype declaration do you use? And why?

<div class="content">
<div class="divTitle">Some title</div>
<div class="divSubTitle">Some sub heading</div>
<p>My content went here, in ordinary P tags.</p>
</div>

It worked for me. But starting from around two years back, I finally weaned myself off of using the semantically-blank DIV tags (where appropriate) and use proper HTML markup. My biggest reason for this is lesser code, and my page is “prettier” when the CSS is turned off. Observe:

<div id="content">
<h1>Some title</h1>
<h2>Some sub heading</h2>
<p>My content went here, in still ordinary P tags.</p>
</div>

In terms of style control, it was easily done via CSS anyway; and if I wanted a completely blank stylesheet anyway, a nice CSS reset will do that for me. (A word of note though: CSS reset does have its pros and cons. Personally I’m still a bit on the fence as to whether I’d go for using one that reset all the native styles or not, above the paddings and margins.)

An interesting post on heading tags, including a possible system/technique on using them, was posted by Matt Snider: When to Use Heading Tags. It’s a good, interesting read.