The W3C recently published the “complete definition of HTML5 and Canvas 2D applications.” These are not W3C standards just yet, but it represents a major step forward for the Web technology. Those who were on the fence can now start developing for HTML5 in earnest as a stable version is now available.

HTML5 may be stable and feature complete, but the W3C is not yet done with the Web standard. The group says that browser fragmentation still remains a problem with some browsers lagging behind others in terms of HTML5 adoption. The group’s new goal is to make sure HTML5 is interoperable across every browser. They hope to have this completed by the middle of 2014 and then it will publish its final HTML5 recommendation.

A number of W3C members spoke out on this tremendous milestone. All express excitement that HTML5 is ready for its biggest debut yet. Here’s some of the more interesting testimonials with promises of a better future for all on the Web.

Danny Winokur, Vice President and General Manager of Adobe Interactive Development, spoke on HTML5′s impact on the company’s recent introduction of its Edge Web tools:

The completion of the HTML5 and Canvas specifications is an important milestone for developers and designers as it provides a common foundation for browsers and other implementations. Web standards are central to Adobe’s Edge Tools & Services for authoring rich interactive web media and animations, helping us deliver a more predictable and reliable user experience for anyone creating content and applications for the modern web. We congratulate the working group for their efforts in advancing both specifications.

Tobie Langel, W3C Advisory Committee Representative for Facebook, spoke on the social network’s tight relationship with the Web technology:

HTML5 plays a fundamental role in making Facebook accessible to the more than one billion people who use our products. Building with the latest web technologies is how we are able to make our experience available across more than 7,000 devices. Today’s announcement is an important milestone for the Open Web Platform. Facebook is proud to contribute to this effort through involvement in initiatives like the Coremob Community Group.

Jean Paoli, President of Microsoft Open Technologies, spoke on Microsoft’s commitment to implementing HTML5 technologies in its products:

Microsoft is proud to have participated in the hard work that has made HTML5 and Canvas 2D Candidate Recommendations, and congratulates W3C on reaching this important milestone. We look forward to working with the Web community to finalize these as W3C Recommendations. Several Microsoft products have implemented these emerging open Web standards to bring interoperability and maximum reach across multiple devices. We’re confident that HTML5 and Canvas 2D are ready for wide adoption, and glad that the industry shares our enthusiasm for HTML5.1 that will soon support better graphics and streaming media in an open way.

It will be interesting to see how other players in the Web ecosystem approach HTML5 now that it’s “feature complete.” I know a few developers who have stuck to Flash and other plugin-based Web technologies because HTML5 just wasn’t good enough for them yet. It’s unknown if this will increase HTML5 adoption across the Web.

“Verifying ownership of your site in Webmaster Tools provides you and Google a secure channel for giving and receiving information,” she says. “Including a specific HTML tag is only one of several ways you can verify ownership of your site. It’s a great option if you’re familiar with HTML code like head, title and body tags, and you know where and how to edit this content or if you’re using a content management system or CMS like Google Sites, be sure to follow any specific instructions from your provider.”

“If HTML tags look and sound like gibberish, then perhaps give another one of the verification methods a try,” she suggests.

As much as we love Cutts’ videos, it’s nice to see some of the rest of the team take on subjects from time to time.

Augmented reality company metaio doesn’t like that so they set off to do something about it. The company’s tools contained in the metaio Mobile SDK have been a huge hit for developers wanting to create AR experiences on mobile devices. It has seen over 10,000 downloads with 1,000 active developers. There are almost 200 applications out there now built on their Mobile SDK with 900 currently in development.

“The response from the developer community was phenomenal,” said metaio’s CTO Peter Meier. “It however inspired us to offer software that would put this technology in the hands of designers, content providers, publishers, and the average users who might not have extensive programming knowledge.”

That’s why the company is now introducing the metaio Creator. It’s aimed squarely at “non-developers, designers and people who have the desire to create amazing AR experiences but with to do so without using a hard-coding environment.” The Creator is compatible with junaio, a mobile AR browser, and can be used to quickly create cloud-based AR content for Android and iOS devices.

In an even more exciting news, the next update for junaio will introduce HTML and JavaScript support, so developers will be able to expand their AR applications to do even more. Looking even further ahead, the metaio Creator will allow users to upload their creations to all of metaio’s software including the Mobile SDK.

“The most important thing for metaio is to cultivate development and content creation for the entire community,” said Head of US Marketing Trak Lord. “Programmers, users, designers, artists – everyone should be able to live in the Augmented City.”

From May 8 through 21, the metaio Creator will be 30 percent off. The price is still a pretty hefty $227, but it may be worth it if it delivers on its promise of advanced AR creation without the need for expansive programming knowledge. There is also a demo available for you to try out.

To combat this and maybe even help sites optimize their code and content, the company has published an HTML and CSS style guide. It contains the standards that their own developers and programmers adhere to. While your company of choice may use a different style guide, Google offers up their own for those who may not have one yet.

Most of the style guide deals with formatting and its implications on the code you write. The style guide, however, also contains best practices to encourage better coding etiquette. Google also says that they find style guide authors arguing over whether code should be descriptive or prescriptive. Google takes an approach that includes both so that the code can retain some stability, but allow developers to express themselves more openly through their code.

The HTML and CSS style guide is just another in a long line of style guides published by Google. They have previously released style guides for C++, Objective-C, Python, JavaScript and an XML document format style guide.

The wealth of information contained in the style guide might not be surprising to code masters, but it should be incredibly helpful to those just starting to learn code or amateurs who might need some guidance on standards. It’s also just interesting to see what Google views as good style when it comes to HTML.

You can check out the HTML and CSS style guide here. You should definitely check it out. You won’t be disappointed and you might even learn something. You might even rise to the rank of a mighty street coder one day.

It looks like it’s a five step program, so get ready to be rehabilitated folks. If you’re tech savvy it should be a no-brained, but if you’re are somewhat impaired you may need to buy the study guide. Either way, take a look at this thing, it may actually come in handy and help you solve a couple issues in the future.

Enjoy:

The sad truth is, after three or four seconds, nearly half of your website’s visitors may be gone, having bounced away in frustration.  And for those users who do suffer through a slow page load, the slowness will negatively impact their satisfaction and their engagement with your site. Delays as small as a hundred milliseconds have been shown to decrease the amount of time users spend on a site, reduce conversion rates and reduce average order size. Slow pages also rank lower in searches, are less likely to get indexed, and are less likely to be recommended via word of mouth. In every conceivable way, when it comes to your goals for your website, slowness is the enemy.

Where does the slowness come from? Perhaps surprisingly, over 90% of the time users spend waiting for a given page to load typically occurs after the main HTML page has been retrieved from the server! So for a huge number of slow sites, the single biggest culprit is bloat and inefficiency in the page. Specifically, the main offender is often too many HTTP requests triggered by the page. Each stylesheet, script and image found in a typical HTML page requires a separate round trip from the browser, to request and receive the resource from a web server.  The latency inherent in these HTTP requests delays the display of the page and users’ ability to interact with it. The overhead of these round trips can be massive, dwarfing the time it took to obtain the HTML document itself. So one effective rule of thumb for making your pages faster is to find ways to reduce the number of HTTP requests it requires.  This principle is the basis for many of the front-end optimization techniques recommended by web performance experts. Below are a few such techniques for reducing HTTP requests.

A quick disclaimer about the following recommendations: web performance optimization is a complex and evolving discipline, and brief articles like this one require glossing over some subtleties, details and trade-offs. So, please consider these points as an introduction and a starting point, rather than a definitive or prescriptive solution.

1. Stylesheets

Combine them:

Simply “concatenate,” or combine, multiple stylesheet files into one. If you have four .css files, for instance, instead of referencing them individually:

<link rel=”stylesheet” type=”text/css” media=”all” href=”/css/one.css”>
/** contains: css rules in one.css **/
<link rel=”stylesheet” type=”text/css” media=”all” href=”/css/two.css”>
/** contains: css rules in two.css **/
<link rel=”stylesheet” type=”text/css” media=”all” href=”/css/three.css”>
/** contains: css rules in three.css **/
<link rel=”stylesheet” type=”text/css” media=”all” href=”/css/four.css”>
/** contains: css rules in four.css **/

combine their contents into a single .css file like this:

<link rel=”stylesheet” type=”text/css” media=”all” href=”/css/concat-v2.css”>
/** css rules in one.css **/
/** css rules in two.css **/
/** css rules in three.css **/
/** css rules in four.css **/

… so the content of each of these four files is included in the same order in the combined file. The same styling will apply to your page, but it cost a fraction of the HTTP requests to fetch it.

Put CSS in the head:

Also, be sure to put CSS in the HTML document’s <head> where it belongs, to speed up rendering. Inline <style> tags can delay rendering and force the browser to re-paint the whole page, which is costly from a performance perspective. Minification and compression are highly recommended, to reduce file size. Making your stylesheets cacheable will also greatly speed up subsequent page. (I’ll discuss caching and related topics in a future article in this series.)

2. Scripts

Combine them:

Just like with stylesheets, concatenating JavaScript files is a good way to reduce the number of HTTP requests in your page. If you have multiple scripts, combining them into a single script that is minified, compressed and is recommended.

Note there are tradeoffs with concatenation, for both CSS and JS. For example, you may want to discriminate between styles and scripts needed in every page of your site versus those unique to a given page or section of your site. You may also want to prioritize early loading for certain scripts, while others are fine to delay until everything else is done. And you may choose to reference certain popular libraries like jQuery on a commonly used public CDN URL in an attempt to leverage the browser’s cache from other sites the user has visited. So there are valid reasons not to combine every single .css or .js file in every page. But in general, given a choice between loading a bunch of smaller files separately and loading a single larger combined file, the latter is usually the better choice for performance.

Put scripts at the bottom:

Scripts should be loaded at the very bottom of your HTML document before the closing </body> tag. The old-school practice of putting them in the <head> introduces severe performance problems, in part because scripts are “blocking” resources. In other words, when the browser encounters a script tag, it generally stops doing much of anything else at all until it has fetched and executed the script. So putting scripts at the end of the document and/or fetching them asynchronously is important for performance. There are different ways to account for dependencies of the page on external scripts or interdependencies among scripts, and to preserve their order of execution in a cross-browser compatible way. For complex scripting and client-heavy web applications, using an open source script loader can be a good solution. But the simplest approach is usually just to put them at the bottom, in the desired execution order. [To learn more about blocking scenarios and script loading approaches, I highly recommend the excellent Steve Souders book “Even Faster Web Sites”.]

3. Images

Having too many images on a webpage is a very common performance problem that’s nearly as old as the <img> tag. Fortunately, there are optimization techniques which allow you to implement your chosen design with fewer HTTP requests. This can be achieved by combining image files with CSS sprites, by in-lining them with Data URIs, or by using pure CSS to eliminate the use of an image file altogether. Read on for details.

Combining with Sprites:

Combining images with “CSS spriting” has become a mainstream optimization technique. The idea is to combine a number of common images into a single, larger image file—and thus a single request.  This typically includes images like navigation elements, buttons, logos, icons or any other static images which are central to a design and which rarely change. When the big master image containing the smaller ones in it is fetched, CSS is then used to precisely position specific parts of the same image in the right places in the page while hiding the other parts from view. The result is a page that looks the same as if it had loaded each image separately, but which only required one HTTP request instead of dozens.

Note this technique is fairly invasive, and can introduce a considerable maintenance burden. Since the images are no longer in separate files, editing even one of them can require generating a new master sprite image and sometimes editing the HTML and CSS using the sprite. Tools for automating CSS sprite generation do exist to help ease their maintenance costs [e.g. http://spriteme.org and http://compass-style.org/help/tutorials/spriting/]. However, it’s worth comparing alternative solutions for reducing HTTP requests associated with images.

Inlining with Data URIs:

It is possible to directly embed the contents of an image file in HTML or CSS, instead of referencing it as a separate file. For example, you can replace this:

<img src=”tiny_image1.png” …>

with this:

<img src=”data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO 9TXL0Y4OHwAAAABJRU5ErkJggg==” …>

This technique has some advantages over spriting. It involves zero extra HTTP requests, and it also makes the in-lined image immediately available for rendering as soon as the browser discovers it. It does increase the file size of the HTML page or the CSS file that includes it, so it’s definitely not appropriate for large images, but this tradeoff is often worth making for smaller files (e.g. < 4KB). For sites with a bunch of small images, this can be extremely effective for reducing extra requests. As for caching, if the DataURI reference is in a CSS file or HTML page that can be cached, the image is effectively cached as well.

Data URIs have maintenance overhead too. Changing an image requires changing every HTML or CSS file that references it. Also, some older and less capable but still-popular browsers don’t support Data URIs, so some conditional processing is required. This is a primary reason why Data URIs are not as popular as CSS sprites in the web performance world. But with the advent of automated performance optimization services (like Yottaa Site Speed Optimizer), the feature detection and maintenance burden can be removed altogether.

Replacing Images with Pure CSS:

One smart approach to reducing HTTP requests is to forego image files, in favor of styling HTML elements with CSS. CSS can be used to great effect in implementing background colors, borders, buttons, hover effects, styled text, and even vector-scalable icons (via “icon fonts”). Using pure CSS is virtually always better for performance than using image files, and it can help make your site more maintainable too. Of course, cross-browser compatibility issues and “graceful degradation” of a complex design [or better, proper “progressive enhancement” of a simple basic design] are a challenge for every web developer and designer… but there are some fantastic open-source projects and communities that can really help. For example, HTML5Boilerplate and Twitter-Bootstrap provide great starting points for excellent, highly tested templates and user interfaces, and are essentially reference implementations for modern web development best practices. They are a great way to leverage the accumulated knowledge of experts and to learn about best practices for your markup.

Splitting up the page:

Finally, for cases where the number of images can’t easily be reduced with one of these techniques, it’s worth considering breaking up the page itself into smaller pieces. Pagination, with use of Ajax to fetch additional content when the user requests it, is a way to support a smaller initial page with fewer HTTP requests. That is, instead of a massive page triggering large numbers of image requests, have the initial page require just a few such images. Then use pagination to incorporate the additional content and images in the user experience. This isn’t a casual decision — if not implemented carefully, splitting up a page can cause problems for SEO, accessibility, bookmarking and user-friendliness. But by following best practices, these issues can be surmounted, with the desired result of faster pages delivered to your site’s visitors.

To recap:

* Slow web pages impede your website’s goals;
* 90% of a typical web page’s slowness happens after the HTML has been downloaded;
* Reducing the number of HTTP requests triggered by your page is usually the best first step to making your pages faster;
* We reviewed some specific techniques for reducing the number of HTTP requests in a given page
* We noted that automation can ease or remove the maintenance burden for more invasive optimization techniques

Next time I’ll dive into another area of web performance optimization: doing more to leverage the browser’s capabilities, moving toward the client side of the client-server relationship. In the meantime I’m always interested in feedback and others’ thoughts on web performance. Please reply in the comments.

A fun thing with the Chromium project is that you can type in chrome://inspect to get a list of all pages. shared workers, extensions, applications and background pages that are running in the browser. It makes the inspection of the various components of Web sites easy to access and view. Now you can inspect all of the pages and extensions with the click of a mouse button.

Let’s dig in, shall we? Here’s what you can expect to see when you go to chrome://inspect. As you can see, it lists all the Web sites that I have currently open. I can then click on the inspect button next to each Web site and it will direct me to that tab and open the console to view the HTML and JavaScript that’s currently powering the Web site. It’s a great educational tool for developers wanting to see how other Web sites are built.

Let’s take Google.com as an example. Here’s what you can expect with the inspection tools. The elements tool is the most basic allowing you access to the code that’s running in the background. You can mouse over specific code and it will highlight what that code powers on the Web page in real time.

The other important tab for developers to check out is the scripts tab. This will lay out in detail all the separate scripts running in the background. Once again, it’s a great educational tool to see how other Web sites are built.

You can see all this and more for yourself with the latest Chromium build available here. You can also view code review page for the new inspection tools here.

[Source: Google Developers Google+]

Along with these design changes, Twitter is also unveiling the ability for developers and bloggers to easily embed tweets, simply by clicking a link on the particular tweet’s permalink page.

“Every Tweet has a story that’s more than just 140 characters. It has an author, mentions @people and #topics, contains media, and has actions you can use to share or join the conversation. It’s a dynamic piece of media, and we believe that everyone should be able to view and interact with Tweets on the Web in the same ways you would from any Twitter client,” said Twitter’s Brian Ellin in a blog post.

Here’s what the new option will look like on the individual tweets:

And here’s the lightbox that will pop up. It allows for a little bit of customization and provides the full HTML code for the tweet as well as the shortcode (for applicable platforms) and the simple URL:

Finally, here’s how the embedded tweet will look on your site:

The embedded tweets will allow you to reply, retweet and favorite them as well as follow the tweeter directly from the third-party site.

Much like the “nofollow” tag, the “standout” tag belongs to the HTML rel category, and much like it suggests, it’s intended for the most pop-worthy content, although, there’s nothing to stop people from putting the rel=”standout” tag on all of their content. One would guess Google is prepared for standout tag spam, and the inclusion of the tag doesn’t guarantee first page status on Google News. According to the Google News blog, the tag exists as a suggestion:

If you put the tag in the HTML header of one of your articles, Google News may show [emphasis added] the article with a ‘Featured’ label on the Google News homepage and News Search results.

The blog entry also suggests using the standout tag — which looks like this: — while linking to content being referenced as well as on your own:

Standout Content tags work best when news publishers recognize not just their own quality content, but also the original journalistic contributions of others when your stories draw from the standout efforts of other publications. Linking out to other sites is well recognized as a best practice on the web, and we believe that citing others’ standout content is important for earning trust as you also promote your own standout work.

While that stanza contains a “we believe” in reference to trust-earning, it’s clear Google is relying on this trust when it comes to picking which content is actually standout worthy. If you run a content spam site, one that survived the Panda purge, and you’re making liberal use of the standout tag, it’s doubtful it will make much of a difference in how the content is perceived, especially as Google refines the weight it gives links containing the tag in question.

In what looks like an effort to proactively address standout tag spam, Google suggests news organization only use the tag once per day:

At this point, we ask news organizations to use the Standout tag to cite their own content at most seven times in each calendar week. If a site exceeds that limit, it may find that its tags are less recognized, or ignored altogether. A news organization may cite standout stories from other news sources any number of times each week.

In other words, don’t spam with the standout tag, otherwise, we’ll ignore you; but please, use it when you’re linking to quality content.

Pretty simple, right?

With that in mind, how long will it be before we see the first “Standout Tag Spam on Google News” article? Before the end of the coming week? Once again, for those who may have missed it, the syntax for the standout tag is as follows:

link rel=”standout” href=”http://www.example.com/scoop_article_2.html”

Thoughts on the standout tag? Let us know in the comments.

“Fresh from the work that we’ve been doing with the HTML Speech Incubator Group, we’ve added support for the HTML5 speech input API,” explained Google software engineer Satish Sampath. “With this API, developers can give web apps the ability to transcribe your voice to text. When a web page uses this feature, you simply click on an icon and then speak into your computer’s microphone. The recorded audio is sent to speech servers for transcription, after which the text is typed out for you.”

You can talk to search, just like you can on your phone. I’m not sure how often this will be preferable from the desktop, but it’s a cool feature nevertheless.

With the new announcement, Google uses translation through Google Translate as an applicable example.

“Speech input through HTML is one of many new web technologies in the browser that help make innovative and useful web applications like Google Translate’s speech feature possible,” says software engineer Josh Estelle.

In other Chrome-related news, Google has been working with Adobe (and others) on transparency and controls for Flash Player’s local storage.