Neatly Sliced

I love solar-power! The Voltaic Backpack is an amazing piece of work. Not only is it solar-powered, but the bag itself is manufactured from 100% recycled PET products (like plastic bottles). I had been hankering to purchase one for quite the while, but the $200 pricetag always dissuaded me.

Fortunately, right now Rad-Tech has a 20% off promo code. This can chop off upwards of $60 from the price of your Voltaic backpack.

I decided to bite the bullet and purchase the 15.5 inch DayPack. Even with the discount, the pricetag is $159.96. This is quite the chunk of change, so what moved me to take the plunge? Mainly, I read several reviews. The most notable and convincing review was Gizmodo’s review from three years past. The writer’s detail of the daily functional use that I too would implement, coupled with my desire to be friendly with the earth, contributed to my decision to purchase.

Treehugger’s review was also quite affecting, bringing out possible comfort problems for women. All things considered, the benefits of the gorgeous bag appeared to outweigh the flaws, and I’m willing to forgo 100% comfort for power conservation and aiding in the reduction of air pollutants.

Redeem your Rad-Tech promo code soon, as the sale supposedly ends shortly.

I’m always eager for debug tools in different browsers so that I can troubleshoot browser-unique rendering CSS and JavaScript issues.

I am yet to uncover a decent Safari Web Dev toolbar. A simple option, however, is the Debug menu. The Debug menu features User Agent spoofing, JavaScript console (not quite as good as Firefox’s), and a view of the DOM tree, among other things.

To enable the Debug menu, first launch OS X’s Terminal. Then type the following:
defaults write com.apple.Safari IncludeDebugMenu 1

To disable the Debug menu, simply replace the 1 with a zero:
defaults write com.apple.Safari IncludeDebugMenu 0

Relaunch Safari and view your new Debug menu, next to the Help menu. Read a short bit of the JavaScript Console at Apple’s Safari Dev page.

Have you found useful Safari development tools? Leave a comment and let me know.

If you’ve been under a rock and haven’t heard, Ratatouille is Pixar’s newest flick. The past few films from Pixar (The Incredibles, Cars) appeared positively banal and to this day I have not viewed them. Ratatouille features an innovative storyline - a rodent chef working on the sly in a Parisian restaurant, only in cahoots with the kitchen boy. I am anxious for its release date on June 29.

Download the (free!) 9 minute preview (iTMS link) and subscribe to the video podcast.

An Event Apart is coming to a town near you! It’s two days of web standards and best practices.

Jeremy Keith is speaking at Chicago’s event. Jeremy Keith rocks - I have learned more about JavaScript and AJAX from Jeremy Keith’s books than I have in all my time coding sites.

Dan Cederholm is also speaking, as well as the event’s co-founders Eric Meyer and Jeffrey Zeldman.

This is a must-see event for fans of A List Apart. Buy your seat soon, early registrants receive a $100 discount!

Congratulations to Dawid Lizak for winning the CSS Off competition of June. View his winning entry.

Gripes

Note: A lot of these gripes are directed to my own misunderstanding of the rules of this fairly new competition. If you disagree with any of my gripes, please, leave a comment.

Non-Semantic HTML

There are divs named “top”, “topleft”, etc. About half of the classes/ids are named semantically, and the others are describing style. The naming convention implemented is far from CSS best practices.

Copy Alterations

In the “Upcoming Events” section, Dawid has changed “August”, “June”, et cetera, to their three character abbreviation. The copy that we received in the Jabroni packet (included with the PSDs were text files of the copy) distinctly bore the month name fully spelled. Changing the month in the HTML is a cop-out. If the system feeds the page “August”, and the design calls for “AUG”, some sort of server-side or client-side processing must be taken. This ought to be clarified in future contests. If I can assume that “January” has been handled on the server-side, I would love to hard-code “JAN” into my page rather than write JavaScript to handle the text transform.

In like manner, there are various places where the HTML has uppercase lettering hard-coded rather than handled with CSS. The text document bore sentence capitalization. It’s not fair to change this in the HTML unless we have specified that certain server-side text manipulation may be assumed. Conversely, it’s simple to perform an uppercase text-transform with CSS, and I’m upset to see the lack of such a simple CSS implementation on the winning entry.

Missing Headings

Some of the heading tags are in improper order. An h5 tag is used underneath an h2 tag - tsk, tsk. This is a bear on the document outline and generally poor HTML practice. Some can be chalked up to semantics, but you should never jump multiple heading levels like that. You can find errors in your document outline by using the Web Developer’s toolbar in Firefox: Miscellaneous > View Document Outline. If you are missing heading elements (as Lizak’s entry is), this tool will reveal them to you.

Usage of b, small tags

I know they are technically valid, but really, are we ignoring best practices? And the “small” tag? Could we be any less semantic? Why don’t we just write < font size="-1"> while we’re at it?

Diversion from Original Design

I understand that some diversion is good if it improves upon the original design. This gripe is just a personal “Arg” because I was going to force my header to span the width of the browser window, like Dawid, but I looked again at the design and said, “No, that is not in the design,” and refrained. Now I am wiser for future competitions.

Self-Critique

My entry did not validate. Why? Because I forgot to close my img tags a couple of times, and I forgot an alt attribute on one or two images. Arg! My CSS was valid, but not my HTML. I remember thinking immediately after I submitted the entry, “Doh! I forgot to validate my HTML!”; it must have been an oversight/tiredness from the short amount of time (only a few hours) that I had to build this.

I had not noticed my massive file size: 111kb. I wholly attribute this to my lack of proper image editing software.

Had my code validated, I am confident that I would have been one of the 6 semi-finalists. I should have abstracted my JavaScript. I’m relatively new to proper implementations of JavaScript and I see now the flaws in my JavaScript for cross-browser compatibility - namely, using getAttribute(”class”) rather than the .className property for IE compatibility. I also wonder if my lack of attention to fonts played a part in the disqualification. That’s part of the frustration: when I’m coding a design in the workplace, I can ask the designer what typeface, what font size, what exact hex color.

So it goes.

Fortunately, I was one of 15 finalists (out of the 48 timely entries). View the finalists (I’m #10 in the list of chronologically ordered entries). Regardless of my place, I learned quite a few lessons in speed-coding.

Final Thoughts

I shouldn’t gripe so much, as I neglected to close a few “img” tags, and had a minor cross-browser JavaScript quirk to learn about. I have also learned to spend more time in optimizing images for the web.

Sadly, I didn’t really learn much from the winning entry except the interesting method of employing a two-toned header spanning the width of the browser window. It utilizes non-semantic divs, but we live in the real world, not an ideal one, which makes sparing use of non-semantic divs “acceptable”.

It is a fabulous competition. With my learned lessons (from my stupid mistakes), perhaps I have a better chance of winning the next competition. Thanks to Tony and JD for their long hours judging despite loads of entrants’ griping.

I installed Safari 3 Beta on my work Windows machine to test some sites. It was running fairly well, but one site that I hit crashed every time I hit a menu option. I did some googling, and the error code I received matched that of an application hitting a bad batch of memory. In other words, this is due to a memory corruption error; Aviv Raff lamented the same issue. In addition to the memory problem, MacRumors.com reports additional security breaches.

In any vein, I’m definitely holding off on installing Safari 3 Beta on my MacBook until a more stable release. Not only do I wish to avoid the problems, but the Beta overwrites Safari 2, much to an over-eager web developer’s chagrin.

Only install Safari 3 Beta if you are using Windows and if you need to quickly see how a page is rendered in Safari. Otherwise, hold your horses.

XML is the bread and butter of the so-called Web 2.0 development movement. While writing a web service to export some data to an XML file, through a few trials I learned some best practices with XML naming conventions.

Basic Naming Rules

These are nothing new for most programming languages, but sometimes slight variances apply (e.g., is punctuation allowed for the first character, as an underscore?). The rules according to the W3C schools guidelines:

• Names can contain letters, numbers, and other characters
• Names must not start with a number or punctuation character
• Names must not start with the letters xml (or XML, or Xml, etc)
• Names cannot contain spaces

Thus, "_" and "-" are acceptable characters.

Allowed Characters - Best Practices

The "-" character may be allowed, but it may lead to problems later with server-side code trying to subtract your XML element values. I used "-" in my CSS, since it is of no consequence in that language, and spread the habit to XML believing the same to be true. Use the underscore (_) and save yourself a headache.

In like manner, strive for all lower-case characters. XML is case-sensitive, just like CSS. Using camel-case will only lead to heartache when you typo that one character and your whole world explodes into hate.

Element Name Consistency

Ensure you have a solid schema. Often times to display your stored XML data, you will use an XSLT. XSLTs will often work by cycling through elements of a consistent naming convention and outputting your values depending on logic or required HTML.

Just last week I absentmindedly generated an XML file with a minor schema failing. The resulting XML, with that failing exaggerated, could have resembled the following:

This would be impossible to transform with an XSLT, as "rock" and "folk", in the structure of the XML, have no correlation. In a similar vein, the artist inside the genre could be anything - there is no way to know that "radiohead" and "matt-costa" are both artists.

Follow a schema with generic, semantic names, and either use elemental content or attributes to display your pertinent values. A refined XML file follows:

Ah, how much easier this is to transform with an XSLT. Rather than analyzing element depth - which is vicious as it is inconsistent with larger XML files - one could process based on each genre, each artist, et cetera.

Get a naming convention down before you start processing your data; sometimes one of the tougher parts of programming is coming up with appropriate names. Be universal, be sustainable.