If you haven’t had a chance yet, take a few minutes to look at the Valve New Employee Handbook at http://www.valvesoftware.com/company/Valve_Handbook_LowRes.pdf 

Valve is best known for their Half-Life, Team Fortress, Left 4 Dead and Portal games, along with the Steam gaming platform. They put out a great product, and the Handbook shines a light into the process of developing great commercial software.  Some of the main points:

• There are no management positions.

That’s why Valve is flat. It’s our shorthand way of saying that we don’t have any management, and nobody “reports to” anybody else. We do have a founder/president, but even he isn’t your manager. This company is yours to steer—toward opportunities and away from risks. You have the power to green-light projects. You have the power to ship products.

• As a company with no managers, employees are expected to find the best ways that they can contribute to the company.

We've heard that other companies have people allocate a percentage of their time to self-directed projects. At Valve, that percentage is 100.  Since Valve is flat, people don’t join projects because they’re told to. Instead, you’ll decide what to work on after asking yourself the right questions

• Mistakes are expected as part of the creative, competitive process.

Screwing up is a great way to find out that your assumptions were wrong or that your model of the world was a little bit off. As long as you update your model and move forward with a better picture, you’re doing it right.

• Employees are the seen as important long term corporate asset

If you’re looking around wondering why people aren’t in “crunch mode,” the answer’s pretty simple. The thing we work hardest at is hiring good people, so we want them to stick around and have a good balance between work and family and the rest of the important stuff in life.

In summary – hire great employees, then expect and empower them to make the company great.  Scrum has self-organizing teams; but Valve has created a self-organizing company and turned a nice profit doing it. 

Whether you believe the StatCounter hype from last month or not, everyone can agree that Internet Explorer market share is down from previous years.  Chrome usage is creeping up, and changes in the market (such as tablet proliferation) are likely to continue the IE downward trend for the near future.

As a Visual Studio developer I see an equally disturbing trend for Microsoft – the loss of browser mindshare within the Microsoft developer community.  My statistics are limited and subjective, but evidence suggests Chrome is staking out a major position on the MS developer desktop.  For instance this blog (which is admittedly more focused on HTML than .NET recently) has a 10.5% Internet Explorer market share!

While IE may be down, I think there are things Microsoft can do to reverse their IE market share slide:

1.  Make Friends

Apple.  Google.  Mozilla.  Which of these pose an existential threat to Microsoft? 

Microsoft should partner with Mozilla on basic web standards support and rendering technology. The loss of Mozilla would leave IE as the only major non-WebKit browser.  By working with Mozilla Microsoft could position themselves as champions of an open web, save money by sharing development resources for non-competitive features, and help avoid a WebKit duopoly that works directly against their bottom line.

Look at the Google-WebKit relationship as a potential model for coopetition with Firefox.

2. IE6 was just a warning

Include the full range of HTML/CSS/JavaScript standards in Internet Explorer, and make it available for customers without requiring a new OS or computer. 

You know how hard it was to get customers to stop using IE6?  IE 7 only required a simple download.  For many customers the move to IE9 or IE10 means a new operating system, which in the Microsoft world often means a new computer.  The potential ill will for Microsoft caused by this segmentation of the IE space is unprecedented.  MS should kill this debacle before it materializes.

Also include support for standards-based tech like WebGL. If Chrome, Safari, and Firefox can run WebGL on a Microsoft operating system, Internet Explorer should too. 

3.  Go Faster and Slower

Reestablish a technical leadership position that makes developers want to develop for Internet Explorer.  This will involve a move to implement web standards faster, requiring more frequent IE releases.  Chrome and Firefox have shown that consumers and developers appreciate new features as long as they are easy/automatic upgrades to the browser.

But it is equally important for Microsoft to provide corporate customers a stable platform with established release timelines & patches.  Avoid the Firefox debacle from last year.  Don’t hit companies with the one thing they hate most- surprises. Stick with the MS patching schedule, and look at the Firefox Extended Release plan as a model for major releases– it balances the differences between corporate & consumer expectations.

4.  Keep doing things right.

Microsoft gets their fair share of flack for Internet Explorer, but the company has provided a tremendous amount of value to web customers and developers .  Internet Explorer 4 helped set us on the path to the modern web standard.  MS & IE were early XML supporters.  They have recently open sourced much of their web-based technology stack as well.  Microsoft has also worked hard to provide developer tools that take advantage of open web standards.  Recent WinRt/Silverlight issues aside, Microsoft also has a record of open communication with their development community, and the best evangelist/outreach program you will find.  So change to adapt, but don’t lose the things that have made Microsoft a formidable competitor in the browser & developer space.

HTML5 supports a standard, native <video> tag which is already well supported in browsers and has great backwards-compatibility options. 

Before you spend too much time on the HTML5 video element, you should spend some time getting comfortable with video codecs and debate going on regarding video codec support between the different browsers.  Dive Into HTML5 has a great introduction to the topic, and these Information Week and Register articles can help catch you up on the current state of video as part of the future open web standard.

This example shows how the video tag takes advantage of a standard HTML behavior to provide compatibility to older browsers and new browsers that require different video file types:

• A browser will ignore tags it does not recognize.  So older browsers will bypass the <video> and <source> tags.  If the browser can support a Flash plugin (in the <object> tag) it will pull the youtube video.  If that isn’t supported, it falls through to the “downloadMovie” div that shows a message, static image and a download link.
• For new browsers, the system will fall through inner <source> tags until it finds a value it supports.  This means it will stop at the mp4 for IE 9 and Chrome browsers, webm for new Firefox browsers and ogv for Firefox 3.6.  For more information on these codecs search on “ogv”, “webm” and “h.264” on www.caniuse.com. 

<video id="animalVideo" width=600 height=600 controls>
	<source src="/video/MVI3.mp4"  />
	<source src="/video/MVI5.webm"   />
	<source src="/video/MVI4.ogv"   />
	<object width="600" height="600" type="application/x-shockwave-flash"
		data="http://www.youtube.com/v/OUcvO4MiWek">
		<param name="movie" value="http://www.youtube.com/v/OUcvO4MiWek />
	<div id="downloadMovie"><img src="/video/Manatees.jpg" alt="Manatees"/>
	<br>
	<a href="/video/MVI3.mp4" alt="Download video">Download the video as \MP4</a>
	</div>
	</object>
</video>

The ASP.NET MVC template drops a copy of Modernizr 1.7 in your project automatically, and if you check for NuGet updates the library is brought up to the current version - 2.5.3.

The NuGet package is a a great way to introduce developers to Modernizr and makes checks for updates easy.  But when adding Modernizr to your projects consider two alternatives:

Alternative One – Content Delivery Network:

Microsoft CDN currently hosts two Modernizr versions – 1.7 and 2.0.6.  By using a CDN copy you increase the chance that your customers will already have a browser-cached version of the library. 

There are some negatives to this approach though.  MS is not hosting the newest version of the library (2.5.3), and despite the fact that Microsoft has a highly reliable CDN the potential for outage will always be higher when your site relies on multiple web sites. 

You can help resolve this last issue by using the pattern that HTML5Boilerplate employs to load jQuery: start by loading the CDN version, but use a local copy if the CDN load failed:

<script src="//ajax.aspnetcdn.com/ajax/modernizr/modernizr-1.7-development-only.js"></script>
<script>window.Modernizr || document.write('<script src="Scripts/modernizr-1.7.js"><\/script>')</script>

Alternative Two:

The recommended approach, particularly for production sites, is to use the Modernizr Download Page (http://www.modernizr.com/download/).  This page lets you create a custom Modernizr JS file that only includes those tests that you require for your site.  It also lets you add YepNope calls for dynamic loading of JavaScript libraries – an option that isn’t available in your default NuGet MVC package.  You get all of this and a smaller file that reduces load and JS prep time.

There are potential caching benefits with the CDN route, but the Modernizr team has gone out of their way to endorse the customized download option (http://www.modernizr.com/news/modernizr-and-cdns).

For instance if you create a custom download of Modernizr including the first 5 HTML checks with HTML5shiv and the “add CSS” function the file is 4144 characters.  By comparison the default Modernizr 2.5.3 NuGet file is 49,397 characters.

This is the fourth entry in a series of descriptions & demos from the “Using HTML5 Today” user group presentation.

For practical purposes, the original XHTML standard is a historical footnote, although XHTML transitional will probably live on forever in the default web page templates of old web page editors.

The original XHTML spec was released in 2000, on the heels of the HTML 4.01 spec.  The plan was to move web development away from HTML to the more formal, rigorous approach that XHTML offered, but it was built on a principle that conflicts with the history and culture of the Internet: XHTML introduced the idea of Draconian Error Handling, which essentially means that invalid XML markup on a page will cause a page to stop rendering.

There is a transitional mode offered in the original XHTML spec, but the goal was to move to required Draconian handling.  You can see the result by changing the doc type for a document to “application/xhtml+xml” - for my class example we change this setting in the web.config file:

<staticContent>
<remove fileExtension=".html" />
<mimeMap fileExtension=".html" mimeType="application/xhtml+xml" />
</staticContent>

With the new strict syntax a simple error, in this case a duplicate </td> tag, can cause a critical page error:

While XHTML became very popular in the ensuing decade, the Strict form of XHTML never achieved widespread use.

Draconian Error Handling was one of the factors that led in time to the creation of the WHATWG, or Web Hypertext Application Technology Group.  WHATWG contributed to the eventually disbanding of the XHTML 2.0 working group and the W3C’s move to embrace the HTML5 standard.

For developers who long for XML markup the W3C HTML5 standard includes an XHTML5 syntax.

For the longer, more definitive look at what happened to XHTML and how HTML5 came to be check out the Dive Into HTML mirror site or Bruce Lawson’s “HTML5: Who, What, When Why” talk.

Shims help when adding semantic tags to older IE browsers, but there is a huge range of other new HTML5 features that having varying support on browsers. Polyfills are the tool to work with many of these new features.

Polyfills are JavaScript code and/or browser plug-ins that can provide older or less featured browsers with API support for recent browser advances.  The best polyfills will detect the whether the current browser has native support for a given feature, and only adds the functionality if necessary.  The Douglas Crockford JSON2.js library is an example of this approach: if the browser already supports the JSON object, nothing changes.  If JSON is not available, the library adds a JSON property in the global object.

This approach provides some big benefits:

• It lets you add great new HTML5 features to your web sites sooner.
• It lets the developer focus on writing to the up-and-coming standard rather than proprietary APIs.
• Where most one-off legacy code fixes tends to break down over time, well done polyfills will stop executing over time (as customer browsers natively support the feature) meaning polyfill code may not need to be tested against new browsers since they will execute the native methods instead.

Your should also remember that Polyfills represent an entirely separate code path (and sometimes plug-in) that requires testing for support.  Also Polyfills tend to run on older browsers, which often have slower JavaScript performance.  As a result you might find that performance on older browsers is not comparable.

When looking for Polyfills you can start by checking the Modernizr GitHub wiki or the HTML5 Please site.

For an example of a polyfill consider a page that writes a few geometric shapes on a <canvas>

<script src="jquery-1.7.1.min.js"><script>
<script>
       $(document).ready(function () {
           drawCanvas();
       });

       function drawCanvas() {
          var context = $("canvas")[0].getContext('2d');

	  //background
          context.fillStyle = "#8B0000";
          context.fillRect(5, 5, 300, 100);

          // emptybox
          context.strokeStyle = "#B0C4DE";
          context.lineWidth = 4;
          context.strokeRect(20, 15, 80, 80);

	  // circle
          context.arc(160, 55, 40, 0, Math.PI * 2, false);
          context.fillStyle = "#4B0082";
          context.fill();
</script>

The result is a simple static canvas with a box & a circle:

…to enable this functionality on a pre-canvas browser we can find a polyfill.  A check on html5please.com references  FlashCanvas.  Pull down the zip and extract the files (flashcanvas.js, flash10canvas.swf, etc) to a directory on your site.  Then based on the documentation you need to add a single line to your original HTML file:

<!--[if lt IE 9]><script src="flashcanvas.js"></script><![endif]—>

…and you have canvas functionality!  The IE conditional comments ensure that the library is only loaded in browsers where it is useful, improving page load & processing time.

Like all Polyfills, you should test to verify the functionality matches your expectations across browsers you need to support.  For instance the Flash Canvas home page advertises 70% support of HTML5 Canvas spec tests.

The default NuGet template for MVC3 pushes down jQuery 1.5.1.  You can upgrade to a new version (1.7.1 is current when this was written) to avoid a problem with the creation of “unknown” HTML5 tags in IE6-8:

Take this sample HTML page using HTML5Shiv to provide support for new HTML5 tags in IE6 – IE8.  The page has a number of <article> tags that are backwards compatible in Internet Explorer 6-8 thanks to the HTML5Shiv.

After the article elements there is a jQuery 1.5.1 script tag, and a ready() event handler that appends a footer element with a copyright to each of the article tags. 

This appears correctly in IE9, but in older IE browsers the unknown tag problem reappears for the dynamic <footer> elements, even though we have the HTML5Shiv at the top of the page.  The copyright text sits outside of the two separate footer tags.

To solve the issue upgrade your jQuery files to an up-to-date version.  For instance in Visual Studio 2010:

• In the Solution Explorer right click on References and choose Manage NuGet Packages.
• In the Manage NuGet Packages window select the jQuery item on the middle of the page and click the “Upgrade” button.
• You may need to upgrade your script src references to point at the new version.

Using the updated jQuery library the incorrect tags should disappear and styles should work properly:

You can find more information about the issue on the jQuery Bug Tracker site.

Semantic elements and the Shiv!

This is the second entry in the series of demos from the “Using HTML5 Today” talk.

For the definitive discussion on unknown elements and the HTML5 Shiv check out Mark Pilgrim’s Dive Into HTML5 online book at http://diveintohtml5.info/semantics.html#unknown-elements

Semantic tags increase the meaning and maintainability of your markup, help make your page more computer-readable, and can even provide opportunities for libraries that are written to automagically enhance content using standard tags like <nav>, <header>,  or <footer>.

Legacy IE issues

However, new HTML5 tags get mangled in IE browsers prior to version 9.  To see this in action, consider this bit of HTML code which includes the new <article> and <header> elements:

Viewing this page using the IE9 developer tools (F12) we see that the browser correctly models the hierarchy of tags listed above:

But if we switch to IE8 Browser Mode in developer tools things go bad:

Did you know that a closing tag could close itself?? The browser loses the hierarchy & closes all of the new tags.  The new tags become unusable and the page structure falls apart.

Additionally block-level elements lose their block status, appearing as inline. 

The Fix (good)

The block-level issue can be resolved by using CSS styling.  Below we set the article, header, and footer tags as block tags.

article, header, footer {display:block;}

You can avoid the unknown element issue by creating a version of the element in JavaScript before the actual HTML5 tag appears on the page:

   <script>
        document.createElement("article");
        document.createElement("header");
        document.createElement("footer");
    </script>

By default the Modernizr library includes HTML5 Shiv, so you don’t need to include the shiv code separately if you are using Modernizr.

Simplify your HTML Syntax

This is the first in the series of demos from the “Using HTML5 Today” talk.

One of the great features HTML5 offers is the chance to minimize some of the longer tags in your template, reducing the size of the document and increasing readability and maintainability.  Below we cover a few of the easy, cross-browser, backwards-compatible changes.

Why are these changes backwards compatible?

Because we, the authors of the content on the Internet, are pretty bad at writing proper HTML.  The browser manufacturers have accommodated our poor syntax browser parsing engines for a long time now.  These fixes simply take the best of these and elevate them to the standard.

Why bother?

None of these changes are necessary, but the updated syntax is shorter and cleaner.  In the example case these changes drop the length of a short page by about 12%.

Drop the long doctype

The typical XHTML transitional doctype inserted by Visual Studio (or many other IDEs) looks something like this:

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

The HTML5 spec changes this to

<!DOCTYPE html>

Get rid of the html namespace

The xml namespace for the html tag is not necessary.  You can change

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

to simply read

<html>

…or if you would prefer to include the primary language for the document you can add the lang attribute:

<html lang=”en”>

Shorten your <meta> tag

You should include the charset with your pages to avoid a UTF-7 encoding XSS attack.  Rather than using the older legacy version:

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

you can switch to the shorter HTML5-standard version

<meta charset="UTF-8" />

No more ‘type’ attribute for <script> and CSS

The type attribute is now optional for <script> and <link> tags.  The HTML5 spec notes that “The default, which is used if the attribute is absent, is ‘text/javascript’”  The same document notes that the type attribute is “purely advisory” for the link element.

So you can take your typical JavaScript tag

<script src="/scripts/jquery-1.7.1.min.js" type="text/javascript"></script>

and cut it back to

<script src="/scripts/jquery-1.7.1.min.js" ></script>

In the same fashion a CSS declaration such as this:

<link href="/Styles/Site.css" rel="stylesheet" type="text/css" />

can be shortened to

<link href="/Styles/Site.css" rel="stylesheet" />

For more information, check out the classic Dive Into HTML site or the developer edition of the WHATWG HTML5 spec.

Other links:

http://dev.w3.org/html5/spec/Overview.html#a-quick-introduction-to-html

http://dev.w3.org/html5/spec/Overview.html#the-doctype

http://dev.w3.org/html5/spec/Overview.html#attr-link-type

http://dev.w3.org/html5/spec/Overview.html#the-head-element

The new HTML standard is part of a proliferation of challenges and opportunities that developers face today:

Browser Wars v2.0

Going back 10 years ago, Internet Explorer could claim 95% of the browser market (http://en.wikipedia.org/wiki/Browser_wars).  Today you have to include IE, Firefox, Chrome and Safari to get past the 95% support mark (http://marketshare.hitslink.com/). And this only includes desktop browsers!  Safari, the Android browser and Opera all have strong market shares in the mobile/tablet space.

New Form Factors

The proliferation of mobile and tablet computing doesn’t just add to the number of browsers.  Developers now have to consider a wider range of screens (and viewer perspectives), keyboard alternatives, and touch interfaces.  Power consumption provides a challenge as well.  While we often think of the future web in terms of smaller mobile devices, we also have multi-monitor systems, large monitor systems and web-enabled TV devices to look at with varying sizes & pixel densities.

Consumerization

While corporate IT organizations used to rule the rate & range of adoption for new technologies, the technology market is being firmly pulled along by the consumer.  This greatly increases the speed of technology adoption, and in turn has helped shift the technical expectations of societies – our customers are becoming more sophisticated. 

Uncertainty in the Browser Plug-In market.

Adobe Flash has dropped direct mobile support, and it seems like Silverlight has seen it’s last major release (although it will be supported through 2021).  Windows Mobile will be headed to a new (WinRT) platform as well.

Browser Version proliferation

Windows XP still has a huge market share, and it won’t run IE 9.  In fact IE10 won’t run on Vista either.  If you thought you had problems getting customers to hit the “upgrade” button to get off IE6, imagine the work it will take to get them to buy a new OS, or more likely a new computer, to move up to IE 9.  Paul Irish has a great article discussing the implications.

The Rate of Change

The idea of Internet Time definitely applies to the browser market…or at least two of the major browsers.  In the last year Firefox has moved from version 4 to 11, and Chrome has moved from up from version 9 to version 17.  We have a new set of Internet Explorer experiences coming up with IE 10 as well. 

Windows 8

Windows 8 promises to be a disruptive change.  There is a new browser version, a new Metro interface experience for desktop/laptop users, and an updated development stack (WinRT/XAML) for Windows Mobile 7 users.  Then there is the introduction of HTML, JavaScript and CSS as a first class development environment environment, with WPF, Silverlight & WinForms relegated to “legacy” status.

New Markets

The changes brought on by mobile & wireless communications going beyond the hardware and browser: new customers are being engaged, frequently in parts of the world that did not have a heavy usage in the wired Internet world.  Browsers are being considered as a serious platform for an increasing set of applications.  Google Maps was an early example of the amazing power browser-based apps provide, with questions being asked about the use of the browser as a commercial gaming platform, education medium, and all around “Internet of Things” beyond our current conventional browser-based expectation. 

So what is a developer to do?

Next blog we will talk about some of the benefits of web-standards based development and how it can help you capitalize on these opportunities.