Google+

HTML 5: A Little History

HTML 5 is being proposed as a magic potion for all that ails the world of developers. It slices, it dices, it chops and even calls your mom on her birthday when you forget. Let's jump on the bandwagon!

To understand HTML 5, first you'll need a bit of history... HTML is a standard, standards are created by standards bodies, and they can take a while. The HTML standard is created by the World Wide Web Consortium (W3C), with the last HTML standard being HTML 4, which was published in December of 1997. At that point, the W3C essentially said HTML is dead, long live HTML, but in the form of XHTML, a break from the previous version of HTML with HTML being recreated as strongly formed XML.

The introduction of XHTML had one problem though; XHTML "broke" the internet. It didn't literally break it in the sense that you couldn't get your White Sox scores from ESPN, but without massive rewrites, it would have. HTML has always been a "forgiving" standard. If I develop an HTML page and have an opening xml <P> tag but not a corresponding closing xml </P> tag, my page will (most likely) work. XHTML would have resulted in a fatal error. People have estimated that fully implementing the XHMTL specification would have resulted in 99% of HTML pages at the time not rendering properly.

So, our journey to the way back machine brings us to 2004, HTML 4 is the last W3C standard and their work has been focused on XHTML since 1997. During this time, XHTML has NOT taken off in the marketplace. People still want their White Sox scores from ESPN. As a result, browser developers, some web development companies, and some W3C members got together and proposed evolving HTML 4 with new features for modern browsers since a lot had changed in the years since the last standard (2004 -1997 = 73 Internet years). The W3C said they were not interested but the folks who proposed extending HTML WERE interested and went off and created the Web Hypertext Application Technology (WHAT) working group. So here is the state of the world: the people responsible for the HTML standard are not evolving the HTML standard any more, the folks who implement the HTML standard (the web browser creators, the app tool creators, etc.) want to evolve HTML.

So the WHAT group went on doing its thing. Their main goal was backward compatibility. They wanted to be able to evolve HTML without breaking the 10 years of web development that came before. One of the more interesting things they did was explicitly identifying HOW to parse HTML so that it would be compatible across all browsers. In some ways, that became a new standard that indicated how all browsers should work.

They also went on and introduced new features into HTML (without breaking HTML) including new form elements for things like dates. They thought, "Wouldn't it be swell if browsers natively supported video and audio so we could get rid of things like Flash for streaming video?", so they added it. They also thought, "Wouldn't it be awesome if you could animate things directly in the browser?", so they added a drawing canvas to HTML.

The industry responded positively to these new ideas and the WHAT group started gaining momentum. During this time the W3C was working on XHTML 2, which none of the browser vendors implemented. I'm not sure what you call a standard that nobody implements, but whatever you call it, it's pretty useless. It got to the point where in October of 2006, the W3C and the WHAT working group decided to join forces and evolve HTML and create HTML 5.

Today we are at a point where these two groups are working together to create the HTML 5 standard. The next question is WHEN will there be an HTML 5 standard? It's going to be a while, maybe as far out as 2022 or later. So is that a problem? The answer is, hopefully not.

Part of the reason for the long time is that the HTML 4 specification is very vague or even undefined on how things work. If you forget to include your closing paragraph tag, it was up to the browser vendor to figure it out. This leads to different implementations across vendors so things don't work as expected across all the browsers, something you are no doubt very familiar with. As a first step, sometime in 2012, a candidate recommendation for the HTML 5 standard will be released. At that point, the feature set, already very close to being final, will be official. A good part of the remaining 10 years will be spent on officially documenting how the standard should parse HTML.

Another, even more important thing, is that the HTML 5 team is working on test suites. The idea is that browser vendors will have to run their browsers against the test suite and not until they hit 100% in a test suite will they be considered to have passed. In a lot of ways, the test suite becomes the standard. In fact, not until two major browser vendors pass the test suite with 100%, will the standard be considered completed. This is part of the reason for the very long elapsed time.

The other player in this is how HTML 5 works other devices. HTML 5 is or will be supported by all major smart phone vendors as well as tablet vendors, e-readers and most likely a plethora of things not even imagined yet. In fact, some sites, such as the ubiquitous Facebook, are rumored to be developing HTML 5 applications rather than native applications for mobile or tablet vendors. Part of the reason for this is that some of the hardware vendors are requiring essentially a commission on any purchases within a native application. As a result, a lot of sites may be looking to bypass the App Store approach and create native HTML 5 so they don't need to worry about giving hardware vendors a percentage of their revenue.

HTML 5 is a lot of hope and promise. In the past I have called it Java-esque, in the promise of the write once, run everywhere. What is different this time? A couple of things, one is the test suite that browser vendors will need to pass. The other is that there really seems to be a good cross section of the industry that REALLY wants this to work. It's not often that Apple, Google, Microsoft and other big companies are working towards the same thing. Do they always agree? Of course not! Will it cause problems? It already is. However, the industry is working hard to make this a reality.

It will be interesting to see how it all plays out. Browsers like Google Chrome are working hard on supporting HTML 5 across many platforms. IE is working towards supporting HTML 5 on the Windows platform using hardware acceleration. You will see differences where HTML 5 rendered using IE which will run much faster and can do more, so that performance issues of other browsers may be a concern. Vice-versa you can have issues where IE is not rendering something the same way Chrome is.

It's a long article just discussing the history of HTML 5 with none of the introduction of what HTML 5 is. However, it's important to understand the history of how we got here, and why the industry thinks this will be important. Next time I'll actually discuss some of what's new in HTML 5!

Why Use it? HTML 5 is going to (soon) be the industry standard for web applications

I want to learn more! Interview with Ian Hickson discussing HTML 5 adoption rates

This blog post originally appeared at [Skyline Technologies] (http://www.skylinetechnologies.com/Insights/Skyline-Blog/June-2011/HTML-5-A-Little-History)


 

An Introduction to the Microsoft Razor View Engine

In past blog posts on MVC and WebMatrix. I've mentioned Razor. Today, I'm going to get a bit more in depth on Razor and what it can do.

ASP.NET MVC supports view engines. All web programming consists of providing developers a way to insert data dynamically into their HTML output. In ASP.NET Web forms, this was done using <%= =%> syntax to let the runtime know that code was coming. In previous versions of ASP.NET MVC, this same approach was used and was called the Web Forms view engine.

ASP.NET MVC, however, had the ability to use other view engines. Ever since the introduction of MVC, people have not liked using the Web Forms View engine. During that time, several other view engines became popular for MVC development including Spark, StringTemplate and NHAML.

With the release of ASP.NET MVC 3, Microsoft is now using the Razor view engine. You can still use the previous Web Forms view engine if you would like. The team at Microsoft outlined several design goals for Razor when they introduced it. The most important ones are that Razor be compact, expressive and fluid as well as easy to learn.

One of the main complaints with the Web Forms View engine is how verbose the syntax was. Razor explicitly address this by using the @ keyword to enable script escaping.

So what does this code look like? First, Razor files have the extension csHtml (C# Syntax) or vbHtml (VB syntax). Razor files then get processed by the runtime. If we have a variable defined message and have an HTML stream going, you can see the razor terseness in the following syntax:

<p>Message for the user @message</p>

In ASP.NET Web Forms, this same line would have been

<p> Message for the user <%= message %></p><

Similarly, for example, if we have a list of sports teams showing their name and what place they are in and we want to iterate through to display the standings the syntax is:

<h3>Teams</h3>
<ul>
@foreach (var t in teams) {
<li>@t.Place - @t.Name </li>
}
</ul>

On the screen this would print as follows:

<h3>Teams</h3>
    <ul>
        <li>1 - Green Bay Packers</li>
        <li>2 - Chicago Bears</li>
        <li>3 - Detroit Lions</li>
        <li>4 - Minnesota Vikings</li>
    </ul>

Similar syntax with Web Forms:

<h3>Teams</h3>
<ul>
    <% foreach (var t in teams) { %>
        <li><%= t.Place%> - <%=t.Name%> <li>
    <%}%>
</ul>

Razor also supports HTML Helpers, which are a way for users to create HTML snippets across their code. So in the example above, we could create an HTML Helper to create the football standings and use it multiple times in our view or across multiple views. The syntax is as such:

@helper TeamStandings(FootballTeam team) {
    <li>@team.Place - @team.Name </li>
}

We could then update the page to call the helper:

<h3>Teams</h3>
<ul>
    @foreach (var t in teams) {
        @TeamStandings(t)
    }
</ul>

You can see how less verbose the syntax is to use. It is also, in a lot of ways easier to use. You never need to remember if you should escape out using <% or <%= either. The Razor syntax also introduces new syntax for laying out pages, superseding the ASP.NET concept of master pages. In truth, the ideas are both the same, but the concept is now called LayoutPages. Instead of having ContentPlaceholder sprinkled throughout a master page, helper methods in the template are used to fill in specific content. For example, let's call this page _groovySiteLayout.cshtml:

<html>
<head>
    <title>Groovy Page</title>
</head>
<body>
    <div id="groovyMenu"><a href="/">Home</a></div>
    <div id="groovyPageBody">
        @RenderBody()
    </div>
</html>

Then, within the view, we create our site content which includes a setting for the layout page. When the layout page hits the @RenderBoy helper method it injects the view content into the layout page and sends back to the browser. So for a simple view:

{
    @LayoutPage = "_groovySiteLayout.cshtml";
}
<h1>Welcome to Groovy</h1>
<p>Hello world</p>

Would render the following HTML:

<html>
<head>
    <title>Groovy Page</title>
</head>
<body>
    <div id="groovyMenu"><a href="/">Home</a></div>
    <div id="groovyPageBody">
        <h1>Welcome to Groovy</h1>
        <p>Hello world</p>
    </div>
</html>

There is a lot more to the Razor view engine, this is just a quick introduction, I will be talking about it a lot more in the future.

Why Use it? Razor is a new Microsoft view engine that is lightweight and easy to use. It is currently part of WebMatrix and ASP.NET MVC. There are even indications it will be an integral part of a future version of ASP.NET WebForms.

I want to learn more! Microsoft Introduction - This post on Scott Guthrie's blog is an excellent introduction! • Microsoft ASP.NET MVC site - Check out the pluralsight videos on the page


 

Comparing ASP.NET MVC and Web Forms

Before we get into MVC proper, let's discuss why you should consider MVC at all. It's my personal feeling that MVC 3 is going to be a horrifically important technology for all of us. If you're moving into more mobile development, MVC is going to be a much better choice. Secondly, in a HTML 5 world, MVC is going to be a better choice due to its ability to control HTML markup and reference client IDs via JavaScript. It's not to say ASP.NET Web Forms will not allow for this kind of development, but as the current Web Forms platform exists, it will be more difficult. An example of this..., having the ViewState be part of HTML pages on mobile browsers can have significant impact on load times. Okay, time to jump off the soapbox.

MVC stands for Model-View-Controller. In my mind, I think of it this way ... model is really our data or more correctly, business object. The model contains the data we want to render. The view is the page that we use to render the data. The controller is essentially the traffic cop that tells the data, what view it needs to go to. Most of this is handled automatically by MVC's concept of convention over configuration.

It all works something like this ... a user hits a URL and the controller gets called, based on routing rules it knows which controller to go to. The controller then loads the model from the database. Once the model is populated it then determines what view to load and passes the model to the view for rendering. One of the benefits of an approach like this is that the view is very lightweight with little code in the view proper. The code there is just for helping to render the data. This naturally leads to separation of concerns, which is always a good development practice that is hard to follow in Web Forms.

One of the reasons for converting a site to MVC is to create both an HTML 5 version of the site and a mobile HTML version. In this scenario the controller would load one version of the data (aka the model), but based on the type of browser accessing the site, pass the model to a different view, for example the HTML 5 view. You can get a glimpse of the power. No matter the type of site we have, we are always accessing our data in the same way and passing the view.

So, is ASP.NET Web Forms dead? Of course not! The real genesis of ASP.NET Web Forms was to provide an easier migration path for VB/Winform developers, who were familiar with event driven programming, into the stateless world of the web and web programming. Essentially, Web Forms abstract away the stateless nature of the web. As our paychecks prove, it's a great programming platform running millions of sites. Microsoft will continue to support Web Forms.

There are times when Web Forms will make sense, and times where MVC will make sense. At a high level:

Advantages of Web Forms:

  • Developer Familiarity
  • VERY rich eco system of server controls
  • Provides a RAD development environment
  • Event driven system
  • Much easier development for data heavy LOB system

Advantages of MVC:

  • Full control over HTML
  • Easy integration with JavaScript frameworks
  • Embraces the stateless nature of the web
  • Easier Search Engine Optimization
  • Allows for better testing

At the end of the day, both MVC and Web forms are platforms built on ASP.NET and use the same runtime. HTML and HTML 5, while always an important part of what we do, are becoming more and more important. If you ever needed verification of this, Microsoft's recent announcement that Windows 8 would allow for the distribution of HTML 5 apps to Windows reinforces that. MVC and Web Forms are both platforms we need to make our customer successful in this kind of environment. While I feel MVC is going to be a preferred platform for HTML development, the truth is both platforms are suited for the creation of HTML sites.

Why Use it? ASP.NET MVC is a platform for developing HTML applications that provides the user much greater control over the HTML markup that is rendered. There are added benefits such as supporting testing and better code design too!

I Want To Learn More!

Professional ASP.NET MVC 2(book)

ASP.NET MVC 2 in Action (book)

Pro ASP.NET MVC V2 Framework (book)

Microsoft ASP.NET MVC site- Check out the pluralsight videos on the page!

StackOverflow question on Web Forms vs MVC

Along this same line there is great NuGet package that you can use with MVC3 and EF 4.1 that will generate your views, controllers and Repositories. Yes, a code-gen tool that adheres to real world architecture practices, from your true POCO model classes. Check it out.


 

John Ptacek I'm John Ptacek, a software developer for Skyline Technologies. This blog is my contains my content and opinionss, which are not those of my employer.

Currently, I am reading Norse Mythology by Neil Gaiman

@jptacekGitHubLinkedInStack OverflowGoogle+