Tag Archives: web

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

Einstein and Tagore, Berin, 1930
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.

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

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:

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

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:

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:

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:

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

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:

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:

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.

Relaunch of Yingwen’s website

I finally got around to finishing the upgrades on Yingwen’s piano teaching website last Sunday. Talk about taking one’s time…

Anyway it looks fabulous. Used the Piano Black theme by mono-lab, and hacked it up good at Open Web Camp for the mobile audience. Try it on iPhone or Android.

Yingwen has quite a growing studio. With her better students now winning competitions, she’s building up quite a demand for piano lessons. Most of her piano students come from Danville and San Ramon, particularly from the Blackhawk and Windemere areas, but some drive an hour or more for lessons now. Crazy… Check her out at yingwenlewis.com

An iPhone Story

Last Sunday I purchased an iPhone. This was not my plan, but a couple of things came up to prompt this move. This thing is incredible for the most part, but with only one complaint:

The Purchase

First of all, my expectation was that I’d wait until a second generation release came about. I was quite content with my old Sony Ericsson semaphoring to the bimmer’s Bluetooth interface connection, and the old 3G iPod was the hurdy gurdy churning away at the iPod interface in the glove compartment. And these were good times. It all worked just fine – contacts loaded to the dash, control both from the steering wheel, phone call comes in and the iPod pauses until my conversation completes.

Until last week, when the phone died.

It had been dying a slow but natural death. To be honest, the only thing that was wrong with it was that the battery was able to hold less and less of a charge. The thing on my last business trip would last for maybe one phone conversation after a charge, and certainly wouldn’t make it through a couple of hours away from its power leash. But finally it ceased to work while connected to the charger. It couldn’t even hold enough juice to muster up a single phone call connected to power. Clearly it was time for a change.

And then the urgency occurred when a loved one wound up in the hospital, and my phone wasn’t working to receive the calls for assistance. What timing. Friday night in a hospital I had become all too familiar with recently, to the point where you know half the staff by name. Ugh. I need to do something about this quick.

I had two choices: Get a replacement battery for my Sony Ericsson for around $20 to hold me over until a 2G iPhone appeared, or jump on the technology bandwagon early and get an iPhone for upwards of $700 including tax and AppleCare. Naturally I went for the irrational choice and got the iPhone.

I owned the 1st gen Treo 180 when that first came out, and I loved it despite all its flaws. It was a PDA and a phone, and it was highly functional. But somehow the Treo line got confused and didn’t go quite where I was hoping it would, Palm support for Mac was off and on, and the rumors of an Apple phone began. My next phone would be a cheap-ass one with Bluetooth just to hold me over a cycle until something decent appeared. So with the iPhone finally coming out and the glowing reviews, I was placing myself in line for one of these babies.

The Initial Experience

If I may gush…

The purchase took minutes, the unboxing and activation was effortless, and I didn’t find the keyboard too difficult to operate even with my fat, round thumbs and long guitar-player fingernails. The initial sync was a bit lengthy over the USB connection for about 6 GB of data I had ready to go, and I had to rerun it a couple of times to get my contacts list right and to get the software updated on the unit. But once running, it just worked like a hot knife through warm butter.

Every application on this thing works extremely well, and well together. Syncing with my Mac, browsing through contacts, dialing numbers, watching vids from iPod or YouTube, email, calendar, and the rest of it – all very nice. The browser picks up phone numbers and converts them to hyperlinks to dial. Nice. I am sure that this is the finest mobile device created to date – very elegant.

The Browser

I’m going to get this out of the way. At the risk of being unpopular, I really am not a huge fan of the Safari web browser on the iPhone. Here’s why: I can’t resize fonts beyond tilting the screen – unless the page itself has font resizing baked in to the controls – a rarity. Zooming in on the content is inadequate, because I wind up scrolling horizontally as well as veritcally. The default page width for the iPhone is too wide and makes font scales too small as a result.

Now that I’ve had the iPhone for a couple of days, I want the handheld media type even more. This is an effing handheld device – support the handheld media type and prod developers to use it for your world domination goals instead of having to get people to fork their code. Web page layouts are too big by default for this size screen, and the web developer is confronted with the choice of either writing a version of their website just for the iPhone, or they have to install some greasemonkey-style hack. And I’m seeing plenty of websites offering iPhone-optimized versions of their sites so don’t tell me you’re doing this to offer the big giant World Wide Web in all its splendor. Boo. This would be so much better with an option to load the handheld css as an option somewhere. So much. Heck, even on a per-site basis as a preference in the bookmark or something.

What Safari on iPhone does, it does well – zoom in, hyperlinked phone numbers, and highly usable for a PDA web browser. Give me font resizing and the option to load the handheld stylesheet associated with the given web page and I’ll be happy. Bonus points if you can squeeze in a Flash plugin.

The Money Shot

OK this part I’m about to tell you was entirely unexpected. I went in to the Apple Store with no expectation that this thing would want to have anything to do with my BMW’s iPod and/or Bluetooth interfaces. It was created in 1995. This is emerging 1st generation technology two years later – snowball’s chance in hell of working with my car I thought.

I thought wrong.

This thing is sick. I tried plugging it in to the iPod interface and it just worked. OK cool – I can listen to tunes on this thing in my car if I need to. But surely this won’t pair up with my bimmer, right? No – it works effing perfectly. I pair it up, it connects just fine, it syncs my contacts, and I can place and receive calls in my car. iPhone gets charged up in the meantime – bonus points.

This thing just rocks. I am very impressed with the elegance of this innovative and highly usable design. Well done! Just fix Safari for me and we’ll be good.