Recent W3C HTML5 Updates

I've been a member of the W3C HTML Working Group for a month now and appear to have joined at a point when there is a push to get HTML5 wrapped up as quickly as possible. While we all (should) know that HTML5 as it is referenced in the media is really a combination of related specifications, this push is about the core HTML5 specification itself.

Be warned, this is a dry read.

The W3C HTML Working Group has been taking steps to speed the HTML5 specification to completion. A couple weeks back the chairs proposed a new plan to get HTML5 to Recommendation status in 2014 and opened it up for discussion within the group, updating a draft plan as they receive feedback. This plan gives HTML 5.0 a target date of the fourth quarter of 2014, which we can realistically assume means "by January 1, 2015." This plan also outlines a timeline for HTML 5.1, putting its release date in the fourth quarter of 2016 (by January 1, 2017).

In order to meet these timelines, HTML5 needs to make it to Candidate Recommendation by the end of this year (2012). To successfully make that goal and move on to a Proposed Recommendation, the chairs have defined "exit criteria" that must be met. To do this, from the W3C document:

[T]here must be at least two independent, interoperable implementations of each feature. Each feature may be implemented by a different set of products, there is no requirement that all features be implemented by a single product.

The exit criteria document defines independent, interoperable, and implementation, as well as the judgment level.

There are still ten open issues to be resolved to move this along. Two of the issues are to be decided by the editor, seven by the chairs and the final issue by the working group. The final issue (the first on the list) is also the only one with a due date (which has passed). The plan calls for creating extension specifications for each open issue that can potentially get folded back into the main HTML5 specification if they are put together in time (December of this year) and approved.

In addition there are still about 300 open issues and eleven Formal Objections that need to be sorted. Right now the plan pushes bugs about interoperability issues or that don't require major changes to the specification into their own group to be worked for the Candidate Recommendation phase. Remaining bugs are assigned to HTML 5.1. The 11 Formal Objections, if still supported by their authors, will be passed to the Director (Tim Berners-Lee) for "consideration."

There are a few HTML5 features at risk, meaning they might not make it into HTML5. Right now the list is short and consists of hgroup, command (and the commands API), menu, dialog, and the outline algorithm. It also includes the path object in the HTML Canvas 2D Context.

As HTML5 makes it to Last Call, the HTML Working Group Decision Policy will be updated to reflect the need to quickly resolve any open issues with a clear process to get to decisions.

For a more simplified and immediate timeline I quote the 2014 plan directly:

For CR, we begin in October 2012 by creating a draft HTML5.0
implementation report, which eliminates controversial or unstable
features, and contains a listing of all the features in the current
HTML5 specification, with information about:

• which of the features have been implemented in browsers, and in
  which browsers


• how stable each feature is


• what the level of interoperability for each feature is


• a list of at risk features

We also begin work on a systematic HTML5.0 Testing Plan, with the goals
being:

• identifying areas that are known to be inter-operable and don't need
  further tests.


• identify areas that are known not to be interoperable, and to be
  removed without the need for investing time in the creation of tests.


• 
  for the remaining areas:
  
  
  
  • systematically determine which features we currently have test
    cases for
  
  
  • systematically determine which features we still need test cases
    for
  
  
  
  

Again, as I am new to the group I am still working to understand the dynamic, the policies, the processes, and the players. I am confident, however, that we won't see HTML5 as a final specification until the start of 2015.

Part of my opinion is based on my own experience with the Working Group so far coupled with plenty of experience participating and managing mailing lists, working with clients, being involved in my community and so on.

Because I have my own assumptions on how this will all play out, I am leaving any particular opinion about any of the open items out of this post. I also suspect that, even after my short time with the W3C to date, I might be gaining a reputation (at least on Issue 30, the longdesc item) as evidenced by a random tweet:

And @aardrian takes up the good fight in the HTML5 WG lists.w3.org/Archives/Publi…

— Shelley Powers (@shelleypowers) September 21, 2012

So. There's that.

Read More

Reviewing Twitter's New Profile Header

Today Twitter announced that it has added header images to profiles, similar to what Facebook and Google+ have done. In addition, Twitter has updated its apps for iOS and Android devices to use those header images. Twitter explains why it has added this feature:

Starting today you can make your presence on Twitter more meaningful with new Twitter profiles. […] You can upload your header photo, which appears above your Tweets, to express yourself instantly, anywhere.

By adding a header image, I am both making Twitter more meaningful and expressing myself. Even though I have used Twitter for 15,000+ of my own tweets so far to express myself, and follow a group of folks that bring meaning to my Twitter stream. In case it's not obvious, I am suspect of the reasoning. It feels to me more like Twitter trying to make itself more like Facebook (and Google+ and App.net), especially with the promotion of any photos from my timeline into their own prominent photo bar on mobile displays.

Twitter offers only two parameters for providing the header image — it should not be over 5MB and it should be 1,252 × 626 pixels. I can only assume this over-sized behemoth is Twitter's way of accounting for high resolution displays. And so I dutifully made and uploaded my header image.

Desktop Browser

Screen capture of new Twitter header on desktop browser.

I am wholly unimpressed with the desktop browser experience. Not only has the image been scaled down (which I expected), it was scaled down to 542 pixels in width, or by a factor of 2.31. That's not a nice even number and it relies on browser image scaling (which isn't even bicubic in older browsers) to present the image.

In addition, my name and description are lost in the image, which means I'd have to build a space into my file just to account for the text. On top of all this, the link to my web site doesn't stand out in any way as a hyperlink. It is not obvious that it is clickable, and that's ultimately the thing I want people to click if they visit my profile page.

Forgetting how the image disrupts copy laid on top of it, the size of the image header leaves (at the window size I was using) only 3 tweets visible in my timeline. While at this same window size I only had 5 tweets visible with the old header, I'd rather have those two tweets back given the issues I have with the new header.

Compare this with my profile page before the header:

Screen capture of old Twitter header on desktop browser.

Mobile Browser

Screen capture of new Twitter header on mobile browser (Chrome on Nexus 7).

The mobile browser experience isn't much better. The text is nearly illegible, but at least the hyperlink to my site appears to be bold, if smaller. Only three tweets are visible and then there is a bar with images I have posted. The worst part is that only one of those is mine (the other five are retweets), they are from July, and the thumbnail, when tapped, loads the wrong image. I don't like my tweets being truncated for this low-value content.

Without the header image, however, the experience is almost no better. I still lose the same amount of space to a header image I have not defined. The only plus is that the text is now legible. See the before photo:

Screen capture of old Twitter header on mobile browser (Chrome on Nexus 7).

Mobile App

Screen capture of updated Twitter app with new header (Nexus 7).

Everything I said about the mobile browser experience with and without the new Twitter header applies.

Except this is even worse.

You can't see my description, location or web site address in my profile without swiping to a second panel. Perhaps in some misguided attempt to make the text more legible by laying down a black overlay on the background header image, Twitter has now made my biographical information and link to my site totally invisible without some user interaction.

Not providing a header image does not save me from this mistake. As you can see below, custom image or not, my information is still a screen away.

Screen capture of updated Twitter app without new header (Nexus 7).

Conclusion

I removed the header image. I see no reason to push all those kilobytes to users to lessen their experience should they stumble across my profile page. On top of that, I don't want to hide any more tweets than necessary nor obfuscate the link to my site (though I have no control over that in the mobile app). Perhaps in the future I'll take time to craft an image to better fit the layout, but I have more important things to do than try to shoehorn something into Twitter's mistake. Not to mention they can just change the rules again at any time.

Frankly, I'd rather Twitter enable Twitter cards for all sites. There is far more value to me as a content creator and as a user in that feature. And that feature leans on the existing Twitter experience, not some vapid attempt to copy other social media platforms.

Update: 2:19PM

I just discovered .net Magazine did a brief piece on the Twitter header image this morning, and the sources they cite say pretty much the same thing as I do.

Read More

Facebook, HTML5, and Mis-Reporting

My Twitter stream and the headlines of sites across the web yesterday lit up with Facebook's CEO blaming its stock price (failure to meet hyped expectation) on HTML5 (and its failure to make the Facebook mobile experience suck less).

Even ZDNet jumped on that bandwagon with a post titled Facebook's Mark Zuckerberg knocks HTML5 in favor of native apps, using the summary, Mark Zuckerberg didn't hold back in acknowledging Facebook's mistakes, citing a focus on HTML5 as the biggest one. Bolstering its point, ZDNet included this quote from Zuckerberg:

The biggest mistake we made as a company was betting too much on HTML5 rather than native.

That's it. No additional context, no more justification. An article clearly buying into the notion that Facebook is doing poorly because it built its mobile experience using HTML5.

Blaming a technology is easy. It takes the burden off the organization using it. No longer do you need to justify that your business model is broken, or the user experience is impenetrable, or that you didn't factor all the use cases. You can just blame the "savior" technology for letting you down.

That would be as silly as blaming responsive web design for Facebook's poor IPO performance.

The W3C, one of the organizations developing HTML5, today tweeted a link to a message from one of its mailing lists that includes the full Zuckerberg quote:

When I'm introspective about the last few years I think the biggest
mistake that we made, as a company, is betting too much on HTML5 as
opposed to native... because it just wasn't there. And it's not that HTML5
is bad. I'm actually, on long-term, really excited about it. One of the
things that's interesting is we actually have more people on a daily basis
using mobile Web Facebook than we have using our iOS or Android apps
combined. So mobile Web is a big thing for us.

That statement better summarizes the situation. HTML5 is not done yet. It's not fully formed. Browsers haven't implemented everything and the rules are changing as (parts of the group of specifications that make up the marketing term) HTML5 gets into the wild. It also demonstrates that Facebook made a poor strategic decision by expecting too much.

In Facebook's case, relying on HTML5 to mimic an app just won't cut it for some of its features. While it has worked in other cases, that doesn't mean it will work in all cases. Facebook has consistently had a poor user experience on mobile. That's not the technology, that's strategy and implementation.

You can watch the full interview in the embedded video below. Make your own judgments about Zuckerberg's comments and compare it to how it's being reported across the web.

Head to ~11 minutes for the conversation about mobile.

Related

• Facebook: bet on HTML5 a 'big mistake' from .net Magazine.


• Mark Zuckerberg: Our Biggest Mistake Was Betting Too Much On HTML5 from TechCrunch.


• Zuckerberg’s Biggest Mistake? ‘Betting on HTML5′ from Mashable.


• HTML5 is dead. Long live HTML5! from CNET.


• Failure of Responsive Design is Why Facebook's IPO Tanked, on this blog, May 23, 2012.


• Don't Choose Between Mobile Web and Mobile Apps, on this blog, February 26, 2011.


• Apps Are Not Killing the Web, on this blog, February 5, 2011.

Update, September 18, 2012

Yesterday .net Magazine had a piece about Facebook's W3C representative posting to a W3C mailing list his troubles with the HTML5 approach. I read it not as a complaint but as someone raising issues and asking for help. I also saw some interaction on Twitter this past weekend, spawned by a tweet of mine pointing to the W3C email, between Tobie Langel (Facebook), John Dowdell and Brian Leroux (Adobe), and Steve Souders (Google). Following the link embedded in the tweet below demonstrates that there is discussion among the industry players and perhaps this entire media storm could help move standards further along.

@souders would love your feedback on etherpad.mozilla.org/appcache /cc @brianleroux @jdowdell @aardrian

— Tobie Langel (@tobie) September 17, 2012

More Update, September 18, 2012

Quora answers questions about rebuilding its app, a la Facebook, providing context from a different perspective.

Read More

Page-Level Container Discussion for HTML5

As I started down the path of my first HTML5 web page I spent a good deal of time trying to understand the sectioning elements of HTML5 — nav, article, aside, and section — as well as the major structural elements such as header and footer.

Trying to find the container to wrap the content of my page turned out to be the hardest part of the process.

Are We Talking about a Content Element?

Some elements more obvious in their intended use than others, but I felt that there was no specific element to denote the main content of the page. I struggled with trying to figure out whether my content should be in an article, a section, or even just a div.

Apparently I am not alone. Even folks on the WHATWG mailing list were asking the same question. And then I saw this feedback from Hixie:

The element that contains "a website or a blog entry's main content" is
body, as far as I can tell.

It seemed like that was the end of that. Clearly he had considered it and felt that there was no issue.

But in the past week on both the WHATWG mailing list and the W3C HTML Working Group list this topic has resurfaced. And there are some good arguments in its favor.

Why Should We Get a Content Element?

One argument is that developers are already coding a solution to this, often by specifying a div with an ID of "main" or "content." In this scenario, the concept of paving the cowpath, where HTML5 is intended to reflect how developers actually code web pages, comes into play. If it's already appearing in code, perhaps formalizing it can allow for consistency in structure and semantics. This is, after all, how we got nav, aside, and others.

Another argument centers around ARIA use for accessibility. Since elements like header and footer have built in ARIA roles, developers who care about accessibility want an element with a similar built in role for the main content. Currently, these developers put role="main" into the div or other element that wraps their page.

The argument in favor of a content / main / maincontent element is then a matter of demonstrating an existing pattern and an end-user benefit, in this case in the form of accessibility.

Why Shouldn't We Get a Content Element?

The flip side of this argument is that we're just creating another element to add to the tag-soup that developers are already contending with in HTML5. Evidence today shows us that 95% of the pages that use ARIA ultimately use role="main" properly. Those pages that use ARIA at all only make up 1.3% of a 10,000 page poll, however.

Those users who understand and want to provide accessibility are already doing it with ARIA. Adding a new element may help get more developers to accidentally support accessibility, or it may confuse the issue if its use isn't restricted to one instance per page.

What Might This Content Element Look Like?

Steve Faulkner proposed a new element, maincontent, on the W3C HTML Working Group list yesterday, pointing to his own draft to start discussions. Ostensibly he concatenated the commonly used IDs of "main" and "content" that already exist in the wild when naming this element.

Where it goes from here is anybody's guess. Discussion is happening on both lists, but with all the other activity and the push to start to wrap up the specification it may get pushed out. Perhaps this time next year there will be a solid proposal with well-formed arguments on both sides, but I wouldn't expect to see a new element by then.

Related

• Scooby Doo and the proposed HTML5 content element by Bruce Lawson.


• The discussion on the W3C HTML WG mailing list, September 2012.


• The discussion on the WHATWG mailing list, September 2012.


• HTML5 Accessibility Chops: ‘real world’ ARIA landmark use from The Paciello Group.


• New structural elements in HTML5 at Opera


• maincontent element, Unofficial Draft 9 September 2012 (not a W3C draft).

Update, November 28, 2012

The main element was approved by the W3C as a First Public Working Draft, but within the first 48 hours of life has run into significant blocks. Read my write up: New main Element Approved then Blocked.

Read More

Use Twitter's New Embedded Timeline without Slowing Your Page

Update: September 7, 2012

I misunderstood how browser load external JavaScript files when that load itself comes from embedded script. Ben Ward explained it to me and referenced this handy article, Thinking Async.

The gist of the article is that using JavaScript to write in a call to a JavaScript file causes the browser to load the external script asynchronously.

While it may be like wearing suspenders with a belt, I'm still going to leave my async edits in my Twitter embedded timeline calls.

Original Entry

Yesterday Twitter announced its new embedded timeline feature for web sites. The gist is that you drop a block of code on your site and users will see the timeline for the selected account as if they were viewing it on Twitter.com — embedded media, expanded links, etc.

This is a new feature and is likely to change, even if the how-to Twitter post isn't too clear on that. I say that it will change because of language in the developer documentation like No other customization options are available at this time, as well as the slew of requests for more type styling options (among other customization requests) on the Twitter Embedded Timelines Questions page(s).

There are also known bugs. If your domain has a hyphen in it, then this won't work. If you are using Opera Mobile, Android 2 or 3 default browser, or an iPad, then the swipe-to-scroll gesture doesn't work (I already reported that one).

Another issue that Twitter may not consider a bug is how the script to embed the timeline is loaded. Currently if you have an embedded tweet or the old embedded timeline on your page and Twitter is down (fail-whale down), then your web page will take quite a while to render. This is a function of how browsers load JavaScript. The browser won't finish rendering the page until it has loaded all the JavaScript or given up (a timeout, which can take minutes).

While there are JavaScript functions that can mitigate this, those don't come into play until the script has downloaded. Instead, HTML5 has a couple attributes for the script element that apply here — async and defer. Essentially these tell the browser it can render the page before the script is downloaded. Since Twitter content is often just add-on content for your existing page, this is the right approach.

Instead of spending a thousand words explaining how this attribute works, I refer you to the WHATWG specification using an embedded tweet where I manually insert the async attribute:

If you use JavaScript and don't know about async/defer HTML5 attributes, you should read up and use: whatwg.org/specs/web-apps…

— Adrian Roselli (@aardrian) September 6, 2012

The new embedded timeline feature doesn't make it quite that easy. Twitter gives you code to drop on your page that has no script element into which you can casually paste async. The script element is generated by JavaScript, which looks like this:

<a class="twitter-timeline" href="https://twitter.com/aardrian" data-widget-id="243755160277487616">Tweets by @aardrian</a>

<script>!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src="//platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");</script>


Many of the people who may drop Twitter timelines into their web site are not JavaScript coders. So I whipped up a quick modification you can make to that pre-generated script that will drop the async attribute where it needs to go:

<a class="twitter-timeline" href="https://twitter.com/aardrian" data-widget-id="243755160277487616">Tweets by @aardrian</a>

<script>!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.async=true;js.src="//platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");</script>


The js.async=true; tells the Twitter function to drop an async into its script reference when it gets created. The generated chunk of code will look like this:


<script src="//platform.twitter.com/widgets.js" async="" id="twitter-wjs">


Now if Twitter goes down again (which it will) your page won't hang as a result.
I have also asked Twitter to consider including async in its standard copy-and-paste code.

I have eight (8!) examples of this in play on my Buffalo food truck page, where I have embedded the timelines of the current crop of food trucks in the area so I can check them all at once while aimlessly wandering the streets in a hunger stupor.

If you have a better solution, I am all ears. Please drop it in the comments with any other feedback.

Read More