Winston{yw}

Google Ajax Libraries API which hosts a few of the common open source frameworks like jQuery (and UI), Prototype, MooTools and others was launched earlier this year, and I was excited about the performance boost which it promised.

Basically, the libraries are hosted on the Google infrastructure and common obstacles such as caching and gzipping of these Ajax libraries are handled by the Google engineers. The API is also kept up-to-date with the latest stable release of each Ajax library, and by default, serves the minified version. Of course, there’s also an option to use an uncompressed version for development purposes.

As my WordPress is on shared hosting, I don’t have the luxury of setting up a cache or gzipping my files, and so there’s always been a performance issue with my blog. Therefore, any form of optimization could go a long way in making my blog’s loading experience more pleasant, and so I figured that the Google Ajax Libraries API should be able to help in some way; moreover, Google has a wide CDN and their servers are fast.

To use Google’s Ajax Libraries API is simple, as illustrated on Google’s Ajax Search API blog and Ajaxian, and I made the switch in just 5 minutes for the jQuery framework which I am using on this blog.

Previously, I was including the jQuery packed script which was hosted on my domain, but now I am including the Google’s Ajax Libraries API:

<!-- Previously -->
<!-- <script type="text/javascript" src="js/jquery-1.2.6.pack.js"> -->

<!-- Google's Ajax API -->
<script type="text/javascript" src="http://www.google.com/jsapi"></script>

Why was I using the packed version? Because, I cannot do gzip on my shared hosting and without that, the packed version is smaller in size as compared to the minified version.

In my other external javascript file that contains my jQuery codes, this was how it looked like:

$(function(){
  //Line 1
  //Line 2
  //...
})

Now, I need to first load jQuery using the API which has smart versioning feature, then replace jQuery’s DOM ready function with Google’s on page load function. The internals, or codes, remain the same.

google.load("jquery", "1");
google.setOnLoadCallback(function(){
  //Line 1
  //Line 2
  //...
});

That’s it! I am done! Testing the response time via YSLOW with Firebug:

• jQuery on www.winstonyw.com: Average of 700ms, 31K (No gzip)
• jQuery on Google: Average of 150ms, 16.7K (With gzip)

Are you going to make the switch and improve your users’ experience?

A few days ago, I found a JQuery selector that can be used to select the first visible form input element on a page:

$(':input:visible:enabled:first')

This selector can further be used to focus on the first form input element on page load, as seen in the following code snippet:

$(function () {
  $(window).load(function () {
    $(':input:visible:enabled:first').focus();
  });
})

In the code snippet above, I placed the focus event call inside the load function (bounded to the window element) so that the focus event fires when the browser finishes loading all content within a document, including window, objects and images. Initially though, I had excluded the load function and had placed the focus event call within only the DOM ready function, but it failed to work.

This simple trick is great for usability, as the user can start filling up a form right away without any additional mouse clicks or key strokes, since the cursor would appear in the first form input element once the page has finished loading.

Google and Yahoo, for example, focus the user’s cursor in their search box on page load so that the user can start a search conveniently. In their industry where every search counts towards achieving their business goals, such usability enhancement, though small and subtle, can make a difference.

However, do note that this may only be good for pages that need to focus the user’s attention on a form’s input field, or for pages whose primary content is a form. Else, it becomes more of an annoyance to find the cursor focused on some obscure form input field on every page load.

Lately, I have been reading up on DOCTYPE and (X)HTML as I felt that my knowledge of them was limited. This post is a summary and brain-dump of my readings and is not to be taken as an exhaustive documentation on the subject of DOCTYPE and (X)HTML. Do correct me if I err in any of the stuff mentioned below.

DOCTYPE

A DOCTYPE, or Document Type Declaration, defines the legal structure, elements and attributes of a web page. It is declared at the very top of every web page, and is required for browsers and validators to parse and render the document consistently and correctly.

HTML vs. XHTML

In the process of creating a web page, we have the choice of declaring our markup to be either HTML or XHTML. However, based on my observations, web pages nowadays are mostly declared as XHTML because XHTML, being known as a reformulation of HTML in XML, is an extension and improvement over HTML.

To quote the current XHTML 1.0 Recommendation:

The XHTML family is the next step in the evolution of the Internet. By migrating to XHTML today, content developers can enter the XML world with all of its attendant benefits, while still remaining confident in their content’s backward and future compatibility.

As XHTML conforms to the syntax of XML, XHTML pages are required to be well-formed. By enforcing well-formed rules in our markup, XHTML is more consistent to code and easier to maintain. The following are some of the more important rules of being well-formed:

• elements must be properly nested
• elements and attributes must be written in lowercase
• non-empty elements must be closed
• empty elements are minimized as a single element and closed with a space before the trailing slash
• images must contain alternative text
• markup characters: <, >, & and " are escaped

Being well-formed also means that XHTML is backward-compatible and can be served as HTML, using the media type: text/html. In fact, web servers and server-side scripting environments (PHP, Ruby etc) use this media type for content delivery, and so by default, XHTML pages are served as HTML.

In addition, XHTML inherits a useful feature from XML in XML namespaces. Because of this, XHTML markup can include other markup languages like MathML, SMIL, or SVG, and thus extend the basic functionality of a web document. This is semantic flexibility that isn’t available in HTML.

Deciding between HTML and XHTML is the easy part, but for each declaration, there are also different flavours to choose from, such as the Strict and Transitional DOCTYPE (and Frameset DOCTYPE).

Strict DOCTYPE

A Strict DOCTYPE enforces the separation of structure and presentation, requiring that presentational elements are shifted from markup to CSS. Using a Strict DOCTYPE also ensures that all markup are fully standards-compliant, and would only be processed by browsers in their strictest, standards-compliant mode. Ultimately, this results in the most consistent and forward compatible interpretation of the markup.

Transitional DOCTYPE

A Transitional DOCTYPE is used when transiting from legacy markup to modern standards, permitting the use of some deprecated elements or attributes that were common in legacy markup. This DOCTYPE is not meant to be used permanently and all markup should aim towards implementing the Strict DOCTYPE.

Differences between Strict and Transitional DOCTYPE

In general, most of the differences between a Strict and Transitional DOCTYPE are related to presentational elements. Listed below are some of the differences that are more likely to cause problems when migrating from Transitional to Strict DOCTYPE.

Elements not allowed with Strict DOCTYPEs:

• center
• font
• iframe
• strike
• u

Attributes not allowed with Strict DOCTYPEs:

• align (allowed on table elements: col, colgroup, tbody, td, tfoot, th, thead, and tr)
• language
• background
• bgcolor
• border (allowed on table)
• height (allowed on img and object)
• hspace
• noshade
• nowrap
• target
• text
• link
• vlink
• alink
• vspace
• width (allowed on img, object, table, col, and colgroup)

Conclusion

As most of the readings point out, we should strive to use a Strict DOCTYPE for our web quality’s sake. This is because a Strict DOCTYPE promotes the separation of presentation and structure, and results in code consistency and ease of maintenance of any website. HTML 4.01 Strict or XHTML 1.0 Strict? That would depends on our requirements and application architecture. But from a Web Standardista’s point of view, making sure that a Strict DOCTYPE is in use is more important than anything else.

Note to self: I should start to transit this blog into a Strict DOCTYPE.

Resources:

• Fix Your Site With the Right DOCTYPE!
• Recommended Lists of DTDs
• HTML and XHTML Frequently Answered Questions
• HTML to XHTML
• XHTML Wikipedia
• Serving XHTML As HTML
• HTML or XHTML
• Transitional vs. Strict Markup
• Comparison of Strict and Transitional XHTML
• XHTML1.0 Element Attributes by DTD

After a hiatus of nearly two years, I want to start blogging actively again. This new design is created for that purpose, as a celebration of my return to blogging.

I have it made to be just a plain and simple blog design that’s absent of many colours or other funky design elements, as I hope that the content would eventually be the main draw. But, I also have it optimized in several aspects to make it look aesthetically pleasing (at least to me).

Firstly, the main fonts are 13px at least, and there’s a line height of 1.5em between the lines to make sure that paragraphs are easily readable. Secondly, for every paragraph, the number of words per line is in the range of 12-18 words which is what I understand as the optimum number of words per line. Thirdly, I am using a grid layout that further enhances readability. Last but not least, I am using dark coloured wordings on a white background which is the safest colour combination for any blog design. You may disagree with me on all the aspects I listed above, but well, those are what I believe in.

Anyway, I don’t call myself a designer and this blog is a culmination of inspirations I got from a number of blogs. This list is not exhaustive, but the following are the ones that I felt had the strongest influence in my new blog design:

• Subtraction
• Scribbish Theme
• Woork
• Matt Mellenweg
• Chris Brogan
• ProBlogger
• ReadWriteWeb
• TechCrunch

As of this writing, this blog design is almost complete. But I am still looking to integrate my FriendFeed into the blog. I had a look at the FriendFeed plugin, but am not extremely fond of it. So, for now I would sit on it while I brainstorm for fresh ideas on how to do the integration.

That’s all I have to say about my new blog design. I hope you like it as much as I do, and I welcome feedback or suggestions!