San Bei Ji | 三杯雞好吃!

January 2, 2011
by Joe
2 Comments

Maui vacation, gluten-free

I have just returned from a wonderful vacation to Hawaii. We stayed almost the entire time at the Makena Beach and Golf Resort (formerly the Prince Hotel) on the south side of Maui. I had an excellent experience in dealing with this trip on a gluten-free diet, and most of that is thanks to Chef Marc McDowell, who is the new executive chef at Makena. Chef McDowell and the rest of his staff went way out of his way to ensure I had an easy and comfortable trip without worries about gluten issues.

When I was first planning out my trip to Maui, I did a little research on what to expect. I did find a blog post with some useful tidbits of information, especially in the comments section. Encouraged, I sent out an email to the concierge at Makena to see what they could do for me about gluten-free dining. I didn’t want to travel around much – my plan for this vacation was to spend as much time as possible by the beach and the pool, relaxing my ass off. (Mission accomplished, by the way…)

What I got in response a couple of days later was an email from Chef McDowell, saying I’d have nothing to worry about, and that he wanted to give me a call to go over some options. When we talked, Marc let me know he had extensive experience with handling food allergies and intolerances, and he was going to make sure I had whatever I wanted. I muttered something about burgers and pancakes with bacon, and he said we’d be good. Yes, every morning I had gluten-free pancakes with bacon, and on several occasions lunch consisted of a burger on a gluten-free bun with hand-cut and custom-prepared fries, poolside. Just look at this work of art:

In ordering, I found it was easiest for me to let the wait staff to give my name to whomever the chef on duty. Chef McDowell made sure the kitchen staff were well advised of my situation and how to prepare gluten-free meals, and just about anything I wanted to eat they were able to customize to be gluten-free. Here I am with my two new best friends. Chef Lester on the left, Chef Marc McDowell on the right. I am the well-fed one in the middle:

On the second day of our trip, we booked a tour to Hana and around the south side of Maui. This is a very remote part of the island, with a lot of windy dirt road to get through. Marc had asked if we were going on any excursions, and indeed this was just about the only one we had planned ahead of time. He insisted that they pack a lunch for us, and that morning at breakfast I went and picked up a cooler full of sandwich fixin’s, with the gluten-free parts clearly labeled. This was incredibly thoughtful and we had a great picnic in Hana with turkey wraps for my wife and kids, and a nice big gluten-free turkey club sandwich for myself.

Dinners were quite good. The special evening for us was dinner at Roku, which is the Japanese restaurant there at the resort. I brought my own gluten-free soy sauce (actually black bean sauce to be specific—tastes very similar) for the event. We decided to order some sashimi for appetizers and then a nice big pot of sukiyaki for the main course. We handed a small, travel-size bottle of the black bean sauce to the waitress and she said the chef would have no problem making a special batch of sukiyaki sauce for us.

Eventually we decided to rent a car and explore a bit outside the island. With a little Google research, I was able to find a pasta joint in Lahaina called Penne Pasta. They have rice pasta available for $2 extra per plate, and they assured me that the pasta was cooked separately and with all the appropriate precautions in place. I had some great bolognese and was quite full on our way back to the hotel.

That night we booked reservations at Mala Wailea at the Wailea Beach Marriott Resort. Let me just start by saying I generally can’t stand the Marriott chain. There is something kind of corporate and unfriendly that I’ve experienced at every one I’ve stayed at. This place was no different. When asking for directions, the employee I asked looked as if she were thoroughly inconvenienced by my query, and then pointed it out with a rather snotty tone of voice. Once at Mala, things got much better. Very professional staff, and we had our meals served in record time. There was a bit of excitement over the fact that we were seated right near Alice Cooper, who is apparently a part owner of the restaurant – he looks way more friendly in person. Anyway, the menu has gluten-free items indicated right there, but it wasn’t very clear as they only marked appetizers and sides with gluten-free and didn’t mention anything about the entrees. Turns out many of the entrees could be modified or were already gluten free, so it was no big deal, but I couldn’t help but think if you’re going to print a menu like that then at least mark a few entree options. Anyway, the food was decent, although a bit too much on the sweet side overall.

On our last day, we did a road trip up to Wailuku and the Iao Valley. Along the way, we found Maui Tacos, which is a great little chain fast-food joint. On their website they state that everything not made with flour tortillas or enchilada sauce is gluten-free, so that means tacos and the burrito bowls are A-OK. I had a couple of hard tacos and half of my wife’s burrito bowl and they were quite tasty. Maui Taco franchises are found all over Hawaii and in a few locations on the mainland as well! I hope to see one in the Bay Area soon…

My recommendation to anyone traveling to Hawaii is: Stay at a nice place like the Makena resort, and get in touch with the head chef beforehand to make sure they can handle your needs and give them time to prepare. Makena was more than accommodating, and I was really appreciative of everything they did for me. This resort is in a transition under their new management, and I can clearly see these guys are committed to rebuilding this hotel with things like customer service and attention to detail at the forefront of the guest experience. You’d be in very good hands staying at the Makena and letting Chef McDowell and the rest of the great staff there take care of you. And if you do head down to Makena, tell them I said hello!

December 7, 2010
by Joe
2 Comments

SVG and MathML in HTML5

The next article in the Developing with HTML5 series.

Pick a flower on Earth and you move the farthest star.

—Paul Dirac

Scalable Vector Graphics (SVG) and MathML are XML applications that are widely used in scientific contexts. SVG is used to draw vector graphics, and is frequently found in visualization libraries such as ProtoVis. MathML is used to describe the presentation and meaning of mathematical formulæ. They are very easy to work with in a programmatic sense, because they are XML-based and therefore just text, and yet they are capable of rendering beautiful information in supporting web browsers.

Paul Dirac, who loved the maths.

The idea behind XHTML was to move the web toward extensibility (the X in XHTML), where a web browser markup language could be seeded with bits of other XML applications by declaring a namespace and letting things coexist. The problem with that plan was that XML parsers were required to be extremely fussy, to the point that if a problem was detected the browser should render an error message. Browsers don’t work that way. Instead, they forgive your human or computer errors and render the page as best as their little hearts can.

In the beginning of the process, HTML5 was not extensible, and to this day it remains opposed to the whole namespace idea. But SVG and MathML are highly popular and useful XML applications that deserve a place within the HTML5 spec. And so shall it be: <svg> and <math> are the opening volleys in inserting SVG and MathML into your HTML5 document tree. Any elements that are children of the SVG and MathML specs are valid and functional child elements of the <svg> and <math> elements respectively. No need to declare a namespace. You’re done. Thank you.

Now this is not to say that the idea of inserting these XML applications within the HTML5 spec is not without some controversy. What about other XML applications and XHTML extensions such as RDFa, CML, and MML? CML (Chemical Markup Language) and MML (Music Markup Language) are indeed common, but within specific application contexts. They are not supported yet by any web browser (whereas MathML and SVG are well supported.) RDFa on the other hand is a more political issue: More on that whole mess in a later post…

So in short, SVG and MathML are supported objects within HTML5 because they are widely deployed in existing web browsers, and they are very useful – particularly to those of us in the science industry charged with representing scientific information on the web. Let’s look at how to get started. First, an SVG example – simply start your SVG block using the <svg> element and drop your SVG markup within:

<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>The Sun in SVG</title> </head> <body> <h1>The Sun in SVG</h1> <svg style="width:300px; height:300px;"> <radialGradient cx="0.5" cy="0.5" r="0.5" id="g"> <stop stop-color="rgb(255, 255, 0)" offset="0"/> <stop stop-color="rgb(255, 221, 51)" offset="0.6917"/> <stop stop-color="rgb(254, 140, 25)" offset="0.7083"/> <stop stop-color="rgb(0, 0, 0)" offset="1"/> </radialGradient> <rect width="100%" height="100%" fill="url(#g)"/> </svg> </body> </html>

Here’s a live example that will work in browsers that support SVG and MathML in HTML5. (Try it in the Firefox 4 beta.) Or if you aren’t one of those early-adopting browser users that are used to living dangerously, then please refer to the perfectly safe reference image below:

Reference rendering of the sun in SVG.

To learn more about SVG, check out the w3schools SVG tutorial for starters. While SVG is supported in basic forms in Chrome, Safari, and Firefox, only Firefox 4 (currently in beta) supports embedding SVG natively in HTML5. But Chrome will follow soon, followed by IE9, Safari, and eventually (hopefully) Opera.

MathML is equally straightforward, using the <math> element as the opener:

<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>The Dirac δ-function</title> </head> <body> <h1>The Dirac δ-function</h1> <math style="font-size:200%"> <mrow> <msubsup> <mo>∫</mo> <mrow> <mrow> <mo>-</mo> <mi>∞</mi> </mrow> </mrow> <mi>∞</mi> </msubsup> <mrow> <mi>f</mi> <mi>δ</mi> </mrow> </mrow> <mo>=</mo> <mrow> <mo>f</mo> <mfenced> <mrow> <mn>0</mn> </mrow> </mfenced> </mrow> </math> </body> </html>

Compare to the reference rendering below, or check out the live example.

The Dirac delta function rendered from MathML in Firefox 4 beta

Again, currently Firefox 4 beta is the only close-to-shipping browser that supports this. But it is expected to come to all major modern browsers in 2010/2011, including IE9, Safari, Opera, and Google Chrome. To learn more about how to construct MathML, check out Mathematica’s MathML tutorial.

In short, it’s an easy trip to embed SVG and MathML in HTML5. No namespaces are required. The trade-off is less extensibility, but if you need extensibility back there’s an XML flavor of HTML5, appropriately titled XHTML5. In the meantime, start looking for ways to leverage SVG and MathML in the coming months as capable browsers start coming online! While this is indeed a bit on the bleeding-edge side of things, web browsers are beginning to implement these features and I expect over the next year or two the practice of embedding SVG and MathML markup in HTML5 web pages will become entirely commonplace within the scientific community.

December 3, 2010
by Joe
0 comments

Exploring New HTML5 Elements

The next article in the Developing with HTML5 series.

Nothing endures but change.

—Heraclitus

The HTML5 draft specification includes many new elements and attributes for enhanced structural and semantic clarity. Most of the old elements still exist too, and you can still use them if you like. But the new elements will serve to make your markup clearer, more compact, and more functional in modern web browsers. Let’s take a look at some of these elements and what they mean for web developers in scientific contexts. For starters, here’s a list of the new elements, along with links to the relevant points in the specification:

Heraclitus by cote on Flickr

A first glance at HTML5 structure

The first elements we should look at are the structural ones:

article, aside, figcaption, figure, footer, header, hgroup, nav, and section. Take a look at those names for a moment. Think how many times you’ve formed your markup in a fashion resembling something like the following code:

<div id="header"> <h1>Tales of Woe</h1> <p class="tagline">The neverending saga continues...</p> <div id="nav"> <h2>Navigation</h2> <ul> <li><a href="one.html">Page One</a></li> <li><a href="two.html">Page Two</a></li> <li><a href="three.html">Page the Third</a></li> </ul> </div> </div> <div class="article"> <h2>The Stagnant Staircase</h2> <p>It was a dark and stormy night. She didn't notice the vase by the banister as she walked past it, holding the wilted flowers in stale and murky water. The only thing she knew was that the nightmares had to end, and that they would end tonight...</p> </div> <div id="footer"> <p>©2010 In Your Nightmares Productions.</p> </div>

In particular, I’d like to direct your attention to the ID and class attributes for header, article, and footer. These are major structural components that are common in everyday markup. Use of these semantic structures is so common, that it made sense to construct elements around them. Here is the same code as the above, refactored in HTML5:

<header> <h1>Tales of Woe</h1> <p class="tagline">The neverending saga continues...</p> <nav> <h2>Navigation</h2> <ul> <li><a href="one.html">Page One</a></li> <li><a href="two.html">Page Two</a></li> <li><a href="three.html">Page the Third</a></li> </ul> </nav> </header> <article> <h2>The Stagnant Staircase</h2> <p>It was a dark and stormy night. She didn't notice the vase by the banister as she walked past it, holding the wilted flowers in stale and murky water. The only thing she knew was that the nightmares had to end, and that they would end tonight...</p> </article> <footer> <p>©2010 In Your Nightmares Productions.</p> </footer>

In the revised HTML5 version, things are much clearer to read. Your eye can readily follow where the beginning and end of the structural blocks are, because they have structural names such as article and footer instead of just generic div elements with nondescript element closings.

The specification defines header as “a group of introductory or navigational aids.” This could mean navigation, tag lines, section headings, logos, etc. In this example, we use this element to define the masthead of a page, but it could just as easily be a child of a navigation element or an article too – if that’s what the content semantically would require.

The article element represents a defined, distributable piece of content. This might be a press release, a journal article, a blog post, or even a status message such as we’d see on Twitter. We used it here to begin our piece of pulp fiction. (I’m sure there’s more to the story – perhaps at the next NaNoWriMo I’ll use that as a germ for an actual story…)

Heading groups

Oh, one more thing about this section that we should address, and here’s where things get interesting: the tagline. Right now we have a paragraph tag with a class of tagline. And if we’d like to keep that formatting in place, that’s fine. However there’s a new construct in HTML5 that we can leverage, so let’s take a look at the hgroup element:

<hgroup> <h1>Tales of Woe</h1> <h2>The neverending saga continues...</h2> </hgroup>

Here what we’ve done is to change the tagline paragraph into an h2 element, and wrap the h1 and h2 elements inside of an hgroup. The hgroup element is a heading, and can only contain two or more of h1 through h6.

Sectioning off headings

Furthermore, you can use the section element to help structure your document. In a nutshell, consider that any heading within a section is one level lower than headings of the same face value outside of it. Consider the following markup:

<section> <h1>Homininae</h1> <section> <h1>Gorillini</h1> <section> <h1>Gorilla gorilla</h1> <section> <h1>Gorilla gorilla gorilla</h1> <h1>Gorilla gorilla diehli</h1> </section> <h1>Gorilla beringei</h1> <section> <h1>Gorilla beringei beringei</h1> <h1>Gorilla beringei graueri</h1> </section> </section> </section> <section> <h1>Hominini</h1> <section> <h1>Pan</h1> <section> <h1>Pan traglodytes</h1> <section> <h1>Pan troglodytes troglodytes</h1> <h1>Pan troglodytes verus</h1> <h1>Pan troglodytes vellerosus</h1> <h1>Pan troglodytes schweinfurthii</h1> </section> <h1>Pan paniscus</h1> </section> </section> </section> <section> <h1>Homo</h1> <section> <h1>Homo sapiens</h1> <section> <h1>Homo sapiens sapiens</h1> </section> </section> </section> </section>

These are all h1 elements, but structurally the hierarchy is represented as so, due to the nestings of the section elements:

Homininae
- Gorillini
  - Gorilla gorilla
    - Gorilla gorilla gorilla
    - Gorilla gorilla diehli
  - Gorilla beringei
    - Gorilla beringei beringei
    - Gorilla beringei graueri
- Hominini
  - Pan
    - Pan traglodytes
      - Pan troglodytes troglodytes
      - Pan troglodytes verus
      - Pan troglodytes vellerosus
      - Pan troglodytes schweinfurthii
    - Pan paniscus
- Homo
  - Homo sapiens
    - Homo sapiens sapiens

It’s turtle headings, all the way down

In the code, we had all h1s, but the spec requires that the hierarchy is interpreted as shown in this list, and we can clearly see that say homo sapiens sapiens is a subheading of homo sapiens, which is in turn a subheading of homo, then finally homininae. But why does this matter? Well, consider for a moment that the HTML5 specification only allows specific headings of h1 through h6. Then consider if we were to extend our taxonomic classification to encompass all mammals. We’d run out of headings before we got to homininae! In this manner, we can use the h1 element ad infinitum within it’s own section elements, and if we needed we can throw in a little h2 through h6 if needed. If we run out, just add more sections.

A small caveat, however: Having an endless stream of h1s means today’s screen readers used by disabled users might have trouble dealing with the hierarchical order of your content, and there is no functional CSS or other construct currently available to work around this problem. If you have accessibility issues to contend with, stick with the traditional usage of h1 through h6 for now, even if you use heading within.

Go figure

The figure and figcaption elements are for inserting and captioning figures in text documents. Before, we didn’t have an effective way to mark up figure images, and certainly had to come up with creative ways to mark up captions. These elements wrap this problem up nicely.

<figure> <img src="Viola.jpg"></video> <figcaption>This is a lovely Amati 1710 viola.</figcaption> </figure>

As a side note…

The only structural elements I haven’t mentioned yet is the aside element. The aside element indicates related information. It could be used for what we consider typical “sidebar” content in a web page layout, or it could be an aside in a story – such as a text box titled “learn more” in a feature news story or textbook-style article of content. This element may have it’s own headings, nav, content, and whatnot, and if it is found occurring within an article then it is considered related to that given article of content.

And that just about wraps up an introduction to HTML5 with a brief overview of the core structural and hierarchical elements. As we move forward with this series, we’ll take a look at the other new elements mentioned above, as well as look at some of the ways HTML5 has refactored existing markup to have new meaning.

November 7, 2010
by Joe
0 comments

First steps with HTML5

As I mentioned in my earlier post, HTML5 means quite a lot more than what we all understood markup to be in the HTML 4/XHTML days. At the core of the HTML5 specification however, markup is still the foundation. Let’s take a quick look at some of the differences between HTML5 and it’s predecessors. But before we get too into this HTML5 series, I should mention that the principal reason I’m posting my thoughts here on the subject is to learn for myself, and secondly to document a nugget of information or two that might be useful to you all out there. Excellent stuff has been written on this subject. Go read Bruce Lawson and Remy Sharp’s book Introducing HTML5, Mark Pilgrim’s HTML5 Up and Running, and Tantek Çelic’s HTML5 Now. Go read every one of these books cover to cover — I highly recommend them.

It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.

—Albert Einstein

Physicists with mad hair who most assuredly would have been totally down with HTML5.

I will now go through some of the reasoning akin to the way Pilgrim and Lawson follow in constructing the optimal basic HTML5 markup template, with my own commentary, flavor, and style thrown in just so I can acquire it in my head and hopefully help you all along with the reasoning:

The first line of code we see in HTML documents is the doctype. The reason why it is standard practice to use doctypes in markup, as all good web developers already know, is to trigger standards mode in web browsers. All major modern web browsers support this function, and it makes the role of a web developer much simpler to develop a consistent user experience across all platforms. If you’re familiar with the doctypes of HTML 4 and XHTML 1, you are familiar with how complex they appear.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Not the type of thing one would readily commit to memory at first glance. The HTML5 doctype is significantly shorter:

<!DOCTYPE html>

There – fixed it.

With just a little experimentation, it was found that all browsers triggered standards mode with just the above minimal amount of code. So the HTML5 spec was written to codify what was already in existence, in the most compact and simplistic way that works. No long URL. No unmemorable string of voodoo or versioning cluster nonsense. Just the standards mode, please. That’s all we need – something simple and to the point.

The next thing you should know about is defining a character set for your document. This is a departure from the straightforwardness of our journey into HTML5 markup, but it is important for addressing a security concern where browsers attempt to guess character encodings that could conceal malicious scripts, so let’s get off on the right foot shall we? First, the old way:

<meta http-equiv= "Content-Type" content="text/html; charset=UTF-8">

Again, not the most memorable code. But then, that’s why I like HTML5: It fixes things. This is much better:

<meta charset="utf-8">

I should also point out something important here. In HTML5, you don’t need to place quotation marks around attribute values if there are no spaces. Spaces separate multiple values, and you need those quotes to herd them together and distinguish them from standalone attributes (which we’ll get into later). So, this would also be perfectly valid:

<meta charset=utf-8>

If you’re compressing a document for speedy delivery over slow networks, such as mobile contexts, then here’s a place to save a few bytes. But in general, it’s my personal preference to quote my attribute values for legibility’s sake.

Another thing you might notice is that this standalone element is not self-closing in the XML sense. You could write it that way, as in:

<meta charset="utf-8" />

That’s with the trailing slash before the end closing angle bracket, in case you missed it. This would be the way it would be done were our document conforming to XHTML rules. XHTML5 is the XML-conformant variant of HTML5 and is developed as an option to the HTML5 specification. But it is not necessary, unless you really need XML parsing to be enabled. And the good news is, HTML5 allows for SVG and MathML embedding without having to switch to XHTML mode, so for most contexts even at the scientific level, we won’t need the X tacked on to the front of our HTML5. But please, don’t let that stop you from self-closing those tags. I myself only recently got out of the habit, after writing HTML5 for the past 10 months or so. It’s perfectly valid either way.

The rest of your basic HTML5 document at this point will look very familiar, with just a few things to point out. The most notable difference will be the opening HTML tag. Usually we’d just open up our markup tree with this:

<html>

However, if we were pulling out all the XML stops and such, we would be defining a namespace and a language, as so:

<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">

In HTML5, it is certainly not necessary to define a namespace (the xmlns part) because that much is assumed. That leaves us with the language declaration, in the form of the lang attribute. Lang attributes are specified according to IETF BCP47, and there’s a practical list of these codes that may be used on MSDN. A lang attribute is used by search engines to understand the content meaning better and categorize the results. It is used by speech synthesizers to produce the correct pronunciation of words with similar spellings across languages. It is used by browsers for producing the correct hyphenation, spelling correction, and so on, even across regional dialects. A lang attribute specifies the language of the contents of the given element, which means you may specify several languages on a given document.

Do use the lang attribute. Even better – use it regionally. I would specify lang=”en-us” (English – U.S.) for most of my web work, but on occasion I’ll dip into Traditional Chinese for my language studies, with specific vocabulary rules for Taiwan, in which case I’d use lang=”zh-tw” (Chinese, or “zhongwen” – Taiwan).

I’m fascinated by language processing and character sets in computing, so forgive my overly-thorough description of the situation back there. The point is, in HTML5, we can shorten this information on the opening HTML element to this by removing the namespace and the xml:lang attributes, and including the addition of my regional preference:

<html lang="en-us">

There, that’s a gooood HTML element. For other elements in your document, such as perhaps LI or P, you might specify additional languages as needed.

Bruce Lawson has a nice, clear writeup of what he considers to be the minimal HTML5 document framework. I agree with this markup template, with my own minor stylistic modifications presented below:

<!DOCTYPE html> <html lang="en-us"> <head> <meta charset="utf-8"> <title>My Page Title</title> </head> <body> <p>My awesome web page.</p> </body> </html>

The rest is pretty straightforward, right? We have the overall wrapping HTML element, a HEAD, a BODY, our charset definition, our lang attribute set to Amurikun, well-formed tag organization, a title attribute, and some content. That’s it – not too different from our past experiences with HTML4 and XHTML, but arguably much simpler. You now can fill in the rest of your markup as needed as if it were HTML 4.01, and it’ll work in all modern browsers. That’s right, it’s OK to get started with this much right away. But if we stopped there, that would be missing the point of the new semantic conveniences of HTML5! So in the next post we will explore those constructs in a little more detail and talk about how these new constructs will save you time and make more sense for web development in the long run.

October 19, 2010
by Joe
1 Comment

Moving Towards HTML5

HTML is arguably the foundation of everything that makes the World Wide Web what it is today. It is simple enough to write that just about anyone can pick it up – not too much unlike learning to play the guitar: If you have the ability to learn three chords and grimace musically, you might be able to join a rock band. Same with HTML: Learn a few tags, and you too can be an Internet sensation.

When the curators of web technologies–the W3C—decided we’d all be better off moving towards XML via the XHTML specifications, I was all for it. I dutifully embraced the rigors of XML nesting rules and self-closing tags, and learned how to properly attach semantic markup to content and style it using cascading style sheets. And that was fine, until…

Well, the fact is that XHTML broke one of the foundations of what made HTML itself so great; it broke the simplicity. XHTML was supposed to act like XML, meaning XHTML was supposed to be interpreted strictly, and invalid markup should cause the interpreter to fail.

There were other problems too. Web servers and web browsers never fully caught on to the potential, let some things slide here and there, and the XHTML 2.0 working group was looking to be one of the most dysfunctional standards bodies the web had ever seen. XHTML wasn’t working out for the long term.

Then HTML5 came along.

It’s a shame to throw the baby out with the bathwater, right? HTML got us along this far with the World Wide Web, so why discard it now? One guiding principle of HTML5 is this: “Let’s hang on to HTML and promote what makes HTML so successful.” Simplicity is what made HTML successful in the first place. So let’s make things simple again in HTML5, and find out what would make it work even better.

It took me quite a while to reconcile my biases against HTML5. After years of evangelizing XML-style rules of XHTML, giving users the option to do unholy HTML practices such as not adding the slash-anglebracket closing of standalone tags—or even worse—uppercase HTML elements, was perceived by web standardistas for years as crimes against humanity. But after combing through the latest state of the spec, researching the benefits, and observing the consensus that has formed around it in the web community at large, not to mention seeing a few well written books out there composed by some highly regarded experts, I am finally at peace with the HTML5 movement and ready to endorse its use across the board.

Now I know what some of you are thinking: “But isn’t this is just a specification under development? Won’t this take years before it’s ready for me to use in my daily work?”

The answer to this is mostly no, you don’t have to wait—you can start using aspects of HTML5 today. While there are some dreamy parts of the spec that we’d like to see someday, for the most part things will work in modern browsers or can be modified to work with slightly older browsers like IE7. But much of this stuff works today. More importantly, this stuff will work across the majority of modern shipping browsers in the very near future—specifically when IE9 ships. And it does work today in the majority of mobile devices out there with usable web browsers, including iPhone and iPad, Android devices, and new BlackBerry platform.

And you might as well start learning now. XHTML is officially a dead-end branch by itself, though parts of it live on through the activities of the HTML5 specification (and in particular, the XHTML5 portion of the HTML5 effort.) While the HTML 4 and XHTML specifications are still quite valid and will continue to work in new browsers, the future of the web is HTML5.

OH: HTML5 is the new Web 2.0

Sigh. This is the new buzzword, folks. At least, that’s how it is getting used lately. This became painfully apparent when today I noticed a Wired article that discussed how a lawsuit is being filed against an advertising company because they are circumventing privacy law by bypassing using cookies to track users and are instead using the HTML5 offline database API. Brilliant idea—terrible consequences. You can flush cookies from your browser, but there’s no way to flush your offline databases in the API unless the app you’re using specifically allows for it. Ha! Case law for HTML5 means it’s time has come.

But more to the point, HTML5 is being used as a blanket term for all those shiny, trendy new web techniques we see people using today in modern web development. Instead of asking “how Web 2.0-ey is that thing,” people now evaluate new web trendiness based on how HTML5-ish their widgets are. Nowhere is this more apparent than in the current web browser landscape, where browser vendors tout their support of HTML5 instead of touting whatever proprietary extensions they may have packed on. Despite the shameful abuse of terminology, overall this trend towards better standards support is a Good Thing™ – web standards have caught on and have gone mainstream.

HTML5 is here to stay

As I mentioned earlier, HTML5 is the successor to all other flavors of markup – HTML 4, XHTML1, and the rest of it. All branches have now merged into one specification. If you like XHTML, you can continue to use XML-style syntax rules in HTML5. But it’s not necessary, and is arguably a waste of bytes – The HTML5 DOM allows for HTML4-style unquoted attributes and standalone tags that aren’t self-closing. All modern browsers will parse your code just fine. Unless you need the extensibility of real XHTML, use the regular HTML variant.

All modern browsers will support HTML5. This includes the last holdout, Internet Explorer, which as of version 9 (currently in beta as of this writing) will have the very solid beginnings of HTML5 implementation. At some point in the near future, all browsers in the hands of your web users will be capable of handling most or all of what is currently in the HTML5 specification. We will probably be in the 50% mark for HTML5-positive public web users somewhere in the first quarter of 2011, and if mobile web trends continue down the current path then I’d expect that to be close to 75% by the beginning of 2012. Wild ass guess, but what the heck.

The HTML5 spec will be the last version of HTML to be published. But it will not be a static fixture set in marble for us all to behold ad nauseum. No, instead of the past models where things were published and left for dead by the W3C, HTML5 intends to be a living document – an expression of the working capabilities of the modern web landscape, rather than some ivory tower ideal that we should all strive to achieve. At least, that’s what we hear (and what some of us hope…)

With all that said, let’s put to rest the question of whether or not we should be pursuing HTML5 as a skill or a development strategy at this time. The answer is yes – you should start doing this right now.

The HTML5 philosophy

For a moment now, let me attempt to define the philosophy of what HTML5 is:

HTML5 specifies what is practical in modern web browsers. It covers semantic structure, the document object model, and certain features that really do blur the lines between markup and functionality. It is more a web application framework than just a simple markup language, and in fact I think of the markup portion of HTML5 now as a sort of subset of the greater HTML5 umbrella.

Much of the HTML5 specification is defining in semantic or in operational terms what is already possible in web browsers and in wide enough use to justify itself.

It will have you scratching your head at times if you’re well versed in HTML 4 or XHTML 1.0, because some things will appear completely foreign to you. Just remember this: HTML5 is not just a markup language. It is an application framework. It is a document object model. It is a set of APIs. It is the new Web 2.0.

What specifically is HTML5 then?

OK, ok… I’ll be specific. Here are some of the primary features of HTML5-the-specification:

A new markup specification: Most of the markup from HTML4 exists, with only a few elements deprecated. Some elements which were deprecated in XHTML are now redefined in HTML5 as being perfectly valid, including <b> and <i>. Other elements have been created to simplify semantic patterns that have been observed in modern web development, such as <article> and <footer>. Yet more new elements appear to extend the functionality of web interfaces, such as <canvas> and <video>. HTML5 replaces all prior versions of HTML and XHTML from the W3C’s perspective.
New APIs: Some of these new APIs include the aforementioned <canvas> element, offline data storage, editable content, and semantic structures such as microdata. This alone is a big stretch over what prior HTML specifications included, but it is important to consider these as part of how the browser, markup, and DOM should interact.
New rules: Markup doesn’t need to be strictly upper- or lower-cased. It can even be mixed case. (But please, stick with lower case – I urge you.) Markup may be served as text/html. You can go ahead and insert SVG and MathML in your markup served as text/html – it’s OK!

The working draft of the HTML5 spec is available on the W3C site, and I do think it is valuable to reference it whenever you have a question about the intent of a certain element or API. I’ll try to link to those points as we get deeper into these features in upcoming posts, so stay tuned!
What is HTML5 not?

HTML5 is not CSS3, so don’t go there. CSS3 does work very well with the modern and emerging browsers and with HTML5, but it’s a different spec. Every time CSS3 gets lumped together with HTML5 as a blanket term, an angel cries.
HTML5 is not JavaScript. However… there is a boatload of JavaScript that is specifically indicated to work within HTML5. Soooooo think of those parts of JavaScript as a subset of HTML5 where appropriate. There are some very script-y things about HTML5, but it’s important to remember that JavaScript is working within HTML5’s framework. (This is one of those head-scratcher areas I mentioned earlier. Just go with it – it’ll start to make sense later.)
HTML5 is not the answer to all your problems. It is pretty cool – don’t get me wrong – and it corrects the vast majority of mistakes created by HTML 4 and XHTML. But it’s still a work in progress and has it’s own quirks and areas where we may need to tread carefully. We’ll look at some of these issues as we go along.

What do we do now, Ren?

In my next post, we will look at the new semantic structures of HTML5 and how to start using HTML5’s new markup rules today. Thank you and happy HTML5-ing!