Category Archives: Web Development

When Can I Use posts a usage table

When Can I Use has posted a nice browser usage table, which includes mobile browsers and a breakdown by browser version. Compared with the browser market share analysis at Wikipedia, the numbers do line up quite well for the major categories, although there are some interesting discrepancies when you get down into the weeds.

I love looking at statistics and seeing what jumps out at you. What I see from these numbers today, here in September of 2011, is this:

  • IE is only 39% of browser market share now. Remember ten years ago? Yeah, times have changed.
  • Chrome is doing quite well. It’s going to overtake Firefox at this rate. 21% – that’s amazing.
  • Going by the When Can I Use analysis, if you combine Chrome, Safari, iOS, and Android, you have about 29% market share for WebKit browsers.
  • If these trends continue, and I see every indication that they will, Google Chrome will become the dominant browser platform sometime in the first half of 2012.

Fascinating. I’m going to need to make more popcorn.

Some Google+ thoughts

No question, Google+ is Google’s most successful foray into the whole social media arena. I am sure this one will succeed where other initiatives have failed. I’m glad to see it taking off. But a few things need to be worked out for it to achieve it’s full potential. Here’s my unsolicited feedback:

I think the first thing I’d like to see is for all my Buzz content to go directly into my stream. I don’t want two streams, nor do I want to go look at a separate place for all the people I follow on Buzz vs. Google+. It is an extra step that I don’t have time to take.

Another thing I’d like to see is that my activity stream selection should remain persistent. Currently the default stream is for everybody in my circles, but I would much rather have that be filtered to whatever circle I choose or was last viewing.

In fact, get rid of Buzz. And figure out how Google Reader and Google Bookmarks play in with this. Integrate them, or get rid of any overlap or confusion. Do it now before the problems become worse. Don’t wait.

I would really like a way to have my Twitter posts show up in my Google+ stream. This again is a time issue – I don’t want to spend a lot of time tending my content on both networks. It’s largely the same crowd for me anyway. If I have a choice between one or the other, I’m going to spend the time on Twitter because that’s where most of my contacts are. On the other hand if my content is posted in both places, then I can see if there are responses and alerts in the Google nav bar whenever I’m using Gmail or Calendar, which would be fine.

The toolbar changes lists links for Web, Images, Videos, Maps, and News if I’m looking at one of those properties, and Calendar, Documents, Photos, and Reader if I’m in one of those areas. Gmail and Web are listed in both, although the Gmail toolbar uses the docs/photos/reader listing (inexplicably in gray instead of black I might add) and Web lists the web/images/videos set. Sometimes links open in new windows. Sometimes they don’t. Who knows or cares what will happen next? I’m feeling lucky! Sigh.

The mobile version of the site doesn’t let me +1 comments. Overall I’d like to see more functionality built in to the mobile version of the site.

The mobile app on iOS seems like an early beta. I opted out of using geolocation when I first launched it and now there’s no way to get it back.

There it is – my loving feedback. Fix all that and I will be back. xoxox -J.

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.
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:

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.
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:

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

The Dirac delta function rendered from MathML in Firefox 4 beta
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.

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
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:

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:

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:

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:

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.

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.

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.