scriptNode

The ability to write multiline strings is a common feature in many languages. It promotes readability and is often much cleaner than the alternatives. Here's a typically ugly example of string concatenation in PHP:

Thankfully, PHP has the benefit of heredoc syntax, which makes code like this much easier to read, write and maintain:

E4X

But what about JavaScript? There is no native heredoc support, but there are some other workarounds that can be used. The first I'll offer up is ECMAScript for XML (E4X).

The first line in the above example is a bit confusing. The XML will return an xml object by default, but what we want is a String. We can type the return as a String by concatenating to an empty string ('').

Next, an element must be wrapped around the CDATA to trigger the XML parser. This step is similar to PHP's heredoc syntax in that it requires an identical beginning and ending identifier.

You can test this yourself in the lab. Currently, it looks like only Gecko browsers (such as Firefox and Camino) support E4X. This obviously doesn't include Internet Explorer, which is (unfortunately) often a large portion of most websites' user bases. While this workaround is interesting, it's definitely not realistic to assume all of your users are using Firefox, despite its rising popularity (also, it will fail to validate).

Hidden Element Hack

Another workaround I've seen is to place the string inside of an element (often hidden from view) and to read it in via JavaScript. Here's an example:

This solution is clever, but definitely a hack job: not very clean, and with a bad accessibility case. The primary issue though is that it doesn't completely solve the problem. Markup is needed to interact with the JavaScript code, so to use this solution one couldn't maintain a completely independent .js file.

Escaping linebreaks

Another solution is very simply just to escape line breaks:

By escaping the linebreak, you're free to continue the string on the next line (note: this doesn't include spaces, so if you want to separate words, you'll need to begin each new line with a space). This solution is not as attractive as the E4X workaround, but has the benefit of being perfectly cross-browser compatible. Therefore, it looks like it's currently the best method available.

Do you know of any other workarounds? If so, please let me know in the comments section.

I often chat with a lot of new JavaScript developers. Many of their questions are really easy and can be answered with single-line responses, such as, "How do you append to an array?"

Easy stuff. What's unfortunate, though, is when the questions are a bit more involved, and these developers have already searched around a bit and found lousy code to read and learn from. The problem is that there's much ancient, awful JavaScript code out there, and when performing simple search queries, these sites come up. My goal is to improve this process.

One common topic is that of cookies. Dealing with cookies is really basic stuff, but hey, that's what the novice category is for. So here's a simple script to assist with managing cookies:

You can download this script below:

• [Download cookies.js] (2,160 bytes)
• [Download cookies-min.js] (634 bytes; compressed)

Also, PPK has an in-depth article about cookies. His code examples get the job done, but unfortunately create too many functions in the global scope (which, as we all know, should be avoided).

Web developers don't usually browse the net like your average surfers. We will often view pages with a critical eye, tear them apart and see how they tick. I know I do. Sure, I've got periods when I'm lazy and just feel like surfing around or watching videos. But usually the engineer in me will take over and criticize a page when I first see it. Here's what us webdevs do when we first see a webpage.

1. Disable Styles
2. View Source
3. Check the favicon
4. Validate
5. Check Firebug
6. Disable JavaScript
7. Run YSlow

Note: This article focuses on browsing with Firefox, the browser "real" web developers use!

1. Disable Styles

   The first thing I do when viewing a new webpage is hit ctrl+shift+s to disable styles and see a page in its design-free, naked state. What you should see after doing this is a really basic page with headers, text, and maybe some images. The Internet in its easiest-to-consume form, really. If nothing or very little changes, you know the page was developed incorrectly.

   Firefox added a keyboard shortcut (I believe in version 3) to map ctrl+shift+s to toggle the sidebar. I'm used to this shortcut disabling styles instead because I've been using the Web Developer Toolbar for a few years now. Thankfully, there's the keyconfig add-on to allow users to alter keyboard shortcuts to their liking.

2. View Source

   This one's a given and can be very revealing. Hit ctrl+u to view source and open up a world of shame or glory.

   Viewing a page's source reveals many things about the developer(s) responsible. It's one thing to disable styles to see how well separation of design and content was practiced, and quite another to see how semantic the page's markup is (typical things to look for include headers in <h*> tags, paragraphs in <p> tags, and lists in their proper ordered or unordered tags).

   It's also pretty revealing when a developer tries his or her damnedest to get spacing and/or tabbing consistent in the markup. It takes a lot of effort and shows a real discipline for cleanliness and organization.

3. Check the favicon

   Having a favicon can be a pretty good indication of whether a site is serious business or not. Web developers that are devoted to high performance would shudder at the thought of pushing a site live without a favicon.

   Other than the technical reasons, favicons have high visibility by showing up in your browser's tabs, can have considerable branding benefits (or consequences), are easy to make and can be really fun or just adorable. Why the hell not have one?

   ... Then again, even web standards evangelists like Yahoo! have some properties lacking favicons (Yahoo! Profiles is guilty as of this writing; I have filed a bug), so not having one only says so much.

4. Validate

   This is one of my favorites. The W3C Validator is one of the most useful development tools I've ever had access to. Now, there has been much debate about whether making a page 100% valid has any value at all. The usual consensus is to remove obvious or easily fixed errors (like malformed tags), but not to put too many resources into validation just to be valid.

   But it's a pretty good indication of careless development when a page has hundreds of errors, especially when most of them are easily fixed. Honestly, I'd say a large majority of pages have errors, and that's fine, but when a page is 100% valid, it shows that the developer(s) went that extra mile.

5. Check Firebug

   Oh, Firebug, where were we without you? Typically I will glance at Firebug to see if there are any JavaScript errors and to see what XHR calls are getting sent off (mostly just out of curiosity). The JS errors can be pretty revealing, but overall Firebug is just a great development tool that really lets you look inside of a page.

   As of Firebug 1.2, you now have to add a site to its whitelist to enable it, so I do this much less often than I used to. Oh well.

6. Disable JavaScript

   I only do this when I'm feeling overly critical or just hardcore. Maybe I simply love JavaScript too much, who knows? I don't have a quick shortcut for this; instead, up in my toolbar I click Disable > Disable JavaScript > All JavaScript, and then releod the page. Often, this tells me nothing. But sometimes it tells me that the page isn't as accessible as it should be.

   A good example is the current Yahoo! Developer Network homepage, which as of this writing doesn't properly display its footer when JS disabled (see it with JS and with JS disabled). For shame!

7. Run YSlow

   YSlow is a fantastic tool that gives a letter grade to a page based on how well it follows Yahoo!'s high performance recommendations. Again, this is only if I'm particularly bored or curious, and Firebug must be enabled so I very rarely do this. Getting a B or higher can be challenging, so it's a terrific indicator of developers that really care about a snappy user experience.

These habits are pretty common among webdevs. Hopefully they come across as endearing instead of obsessive compulsive. Either way, they come in especially handy when looking for a reason to praise a site, or when wanting to scrutinize an applicant's resume sites.