New ASP.NET Training Course at Learning Tree

I was back in Learning Tree’s Reston offices last week, presenting the beta of my new ASP.NET course – Building ASP.NET Web Applications: Hands-On.  (The beta is part of our course development process where we try out the course in front of students for the first time.  Their feedback is an important part of refining exercises and slides to make sure that everything is clear, that all the exercises work as written and that we have the right balance of material).

I’ve been busy writing the course over the past few months, which is why this blog went very quiet for a while. The new course takes you all the way from explaining What is ASP.NET? through to building a multi-layer application using Code-First Entity Framework, the Web API and the HTML5 Geolocation API. (I put the course example online, so if you want to see what we build during the week, check out www.learningtreatz.com).

What’s so exciting about the new course? (Apart from the fact that I wrote it, of course…)

Well… there’s Visual Studio 2012….

A lot of people aren’t keen on the new monochrome look and – horrors – capitalized MENU items – but there are some really nice new features like Page Inspector and the new improved Add Reference dialog. Beyond that, it remains a very powerful development environment that makes web development a pleasure. And it means, of course, that we can develop with .NET 4.5 – and that means access to a host of cool new features. There’s the Web API:

And bundling & minimizing – which both reduces the size of your .css and .js files for production and makes sure that all your small files are combined into a single  large file, which is a big help in reducing download times for the client:

And there’s also out-of-the-box support for HTML5…

The class covers all these and more, and takes attendees from creating a simple Web Form at the beginning of the class right through to building a layered application with a Code-First Entity Framework data access layer, a business layer calling IQueryables in the data access layer and a UI that uses everything from combining Model Binding with the ListView through to providing an alternative jQuery Mobile view of the entire web site. So if you’re new to ASP.NET Web Forms or just want to refresh your skillset, why not give it a try!

This is me in full flow at the front of the class…

And helping an attendee with one of the exercises…

Kevin Rattan

For other related information, check out this course from Learning Tree:

Building ASP.NET Web Applications: Hands-On

Google Coding Style Guides

Google have made their internal coding style guides publicly available. I’ve been checking out the HTML and CSS and JavaScript guides over the past couple of days, and would strongly recommend that anyone working on the client-side take a look at both.

Guides like these are full of little tips and tricks. They give you confidence that you’re doing something the right way – Hey look! Google agrees with me! – and you’ll always find some little optimization you haven’t come across before. In this case, I had a definite case of old-dog-taught-new-trick, and also an incredible sense of déjà vu: at least one of the techniques suggested in the HTML guide is a naughty little cheat from years ago (actually, last century) turned into an ultra-modern performance optimization.

Teaching an old dog new tricks

Little more than a week ago I wrote an article for this blog about the SSL features in IIS Express/Visual Studio 2012. Part of that article suggested a way to switch between http and https for images stored on a third party site using an action filter. The HTML style guide suggests a much simpler solution – a form of relative pathing I’d never come across before: simply omit the protocol from the url. Instead of a path like src=https://localhost:44301/Content/Images/1.jpg you use src=“//localhost:44301/Content/Images/1.jpg“. This makes the path relative and substitutes the appropriate protocol automatically. It relies on the images being available in both formats – but it is massively simpler than my original solution. Time to go back and refactor.

Teaching a new dog old tricks

Way back when the internet was a lot smaller and slower than it is nowadays and everything was in black and white (okay, I made that bit up), we sometimes used to cheat to reduce bandwidth. I remember building an online shop for a small web development company in the 1990s where we had one page with a long table listing all products. We saved more than 100kb (a massive amount of bandwidth back then) simply by omitting the closing </td> and </tr> tags. That was naughty even then, but worth it. Since then, of course, it has been completely verboten because it’s such a horrible breach of the rules. Well guess what – that’s exactly what Google recommends!

Here, for example is what they don’t recommend:

<!DOCTYPE html>

<html>

<head>

<title>Spending money, spending bytes</title>

</head>

<body>

<p>Sic.</p>

</body>

</html>

And here is what they do:

<!DOCTYPE html>

<title>Saving money, saving bytes</title>

<p>Qed.

To be fair, they do suggest being cautious on that one – but still: wow! That’s such a sea-change in approach I find it hard believe it’s going to be accepted any time soon, if ever.

Whether you agree with everything in there or not, the guidelines are definitely worth a look. There’s plenty of food for thought in there and you never know, you might pick up a new trick or two like I did.

Kevin Rattan

For other related information, check out these courses from Learning Tree:

Building Web Applications with ASP.NET MVC

Building Web Applications with ASP.NET and Ajax

HTML5 Training Course At Learning Tree

I’m in Reston this week, attending our new HTML5 class. The author, Andrew Andrews III is also teaching it this week, and it’s a lot of fun. Andrew’s the Technical Editor on my jQuery course so I know him pretty well – and I’ve been looking forward to the class for a while.

What is HTML5?

It depends on who you ask. The W3C has one view. The WHATWG has another. Essentially, W3C likes to nail down a version of a specification and then move on tidily to the next one. WHATWG takes the view that HTML is continually evolving. Either way,  HTML5 is a mix of new HTML elements (e.g. article, header, footer), lots of new  functionality (e.g. geolocation, native graphics and audio/video) and a JavaScript API.

Why should you care?

Because if you’re waiting for HTML5 to be finished before you start using it, you’re going to find yourself waaaaay behind the curve. ASP.NET MVC already supports HTML5. ASP.NET Web Forms will be supporting it next release. And you can  download an update to Visual Studio 2010 to allow it to validate HTML5 as well as earlier versions.

Andrew Andrews III teaching in Reston

Andrew is very keen to stress that you can use HTML5 right now. HTML isn’t, and never will be, a finished specification. Browsers are continually being updated to add support for new features. The trick is to do use the new features in a way that is backwards compatible.

Here, for example, is what my HTML5 Web site cocktailsrus.com should look like in a modern browser:

And here is what it looks like in Internet Explorer 8, if I don’t do anything to make the site backwards compatible:

And here is what it can look like if I follow Andrew’s approach. It’s not identical to the look in an up-to-date browser, but it’s a much more graceful degradation:

The change was accomplished with just a few lines of HTML and CSS – and it means you can take advantage of the latest features of HTML without having to sacrifice support for legacy browsers.

So there’s no excuse for avoiding HTML5 any longer. You can use a lot of it right now on all the main browsers, providing better-looking, more functional sites for your users. And if you want to know how to do it without giving up on older browsers… then go along to Andrew’s class!

Andrew helping students with an exercise

Kevin Rattan

For other related information, check out these courses from Learning Tree:

HTML5: Next Generation Web Development

jQuery: A Comprehensive Hands-On Introduction

More tips for ASP.NET MVC jQuery Mobile sites

I’ve had a very enjoyable week finalizing the alpha of my new ASP.NET MVC/jQuery Mobile site and putting it online at cocktails-r-us. I’m now testing and refining it (as well as dutifully drinking lots of cocktails so I can take photos and upload them to the site: all for the good of the application, you understand. Now, if I can just work out a way to claim them on expenses….). Along the way, I’ve come across a few problems (and solutions) that come from combining ASP.NET MVC with jQuery mobile and thought I’d share them with you.

One nice feature of jQuery mobile RC2 is that you can easily hide labels in a way that works with assistive technologies. This is achieved using a css class (“ui-hidden-accessible”). You can then use the HTML5 placeholder attribute to supply helpful text to your users. This allows you to make excellent use of the highly restricted space available in mobile devices.

This:

Becomes this:

This is great…. Except for the fact that the ASP.NET MVC LabelFor() helper, unlike other helpers, has no overload allowing you to add HTML attributes – so there’s no out-of-the-box way to add the class attribute without having to go back to hard-coded HTML. And so you end up with this…

The result is that you end up hard-coding the HTML, when what you really want to do is something like this:

Fortunately, the solution lies in something I’ve already blogged about. In earlier posts, I detailed how the MVC3 ActionLink helper allows you to add the hyphenated data-* HTML5 attributes using an underscore, and how you can create your own helper to do so in MVC2. Well, it turned out I also needed that code in MVC3 after all. The UrlHelper class does not apply the substitution – so when I used the UrlHelper in an ImageLink helper, I had to use the ‘MVC2’ approach. That turned out to be fortunate, as I was able to reuse that code in a helper that extended LabelFor() to accept an anonymous object for HTML attributes – and at the same time future proof it against the need to add any data-* attributes in the future. (I won’t post the code, as it’s too similar to a previous blog post, but I’ve put it online here for anyone who wants it.)

So then I ran the code and… didn’t get what I was hoping for. The LabelFor() helper worked as I’d intended… but EditorFor() was ignoring the placeholder attribute, leaving me with this:

Not very helpful, is it? The code does not throw an error, but the attribute doesn’t get added and there’s nothing in the UI to guide the user. There are a couple of complex fixes for this. You can create a template for EditorFor(), or you can create your own custom attributes. I chose to go down the easy route, and switch from the EditorFor() helper provided by the Visual Studio Entity Framework scaffolding, and use TextBoxFor() instead – which did respect the attributes and gave me the result I was looking for.

Here’s the code:

And here’s the output.

So I suppose the message is – ASP.NET MVC and jQuery Mobile can play nicely together, but it’s early days yet and expect to do a lot of fiddling around to get the exact behavior you’re looking for.

Kevin Rattan

For other related information, check out these courses from Learning Tree:

Building Web Applications with ASP.NET MVC

jQuery: A Comprehensive Hands-On Introduction

HTML5, .NET, and Silverlight: Why So Serious?

Why all the anxiety about Microsoft’s support for JavaScript+HTML5?

In a perfect world, there shouldn’t be any fuss. HTML5 is the latest iteration of the HTML specification and builds into HTML a ton of goodies that developers have had to either shoehorn in with other tools (e.g. Flash), implement by misusing other tools (using CSS classes to tag similar items), or just give up on doing (everything else). Obviously, Microsoft is obliged to implement the standard in Internet Explorer just to stay competitive with the other browsers. And, as the HTML5 spec gets implemented in various browsers, it seems reasonable that ASP.NET/MVC developers are going to want to use those features that turn out to be genuinely useful. So Microsoft is also obliged to support those features in Visual Studio and ASP.NET/MVC.

The issue is Windows 8. Windows 8 gives HTML+JavaScript developers the ability to create applications that have equal standing in Windows 8 with applications built using other development tools (e.g. with Silverlight and XAML based technologies). To provide further integration with .NET, Microsoft also offers the ability to compile .NET libraries into a new file format that allows the objects in those libraries to be called from JavaScript code. On the face of it, this doesn’t seem like major a step (and was probably easier to do  than getting C++ and Visual Basic applications to interoperate in Windows 3.x and COM).

Of course, this support may be a waste of Microsoft’s time—nobody may want to build Windows 8 applications with HTML5+JavaScript (remember Active Desktop? How about Microsoft Bob?). But the company has money in the bank and, who knows?  This initiative could be as important as Microsoft Binder Windows Media Player.

It’s Silverlight developers that are really concerned. In Silverlight, you can do much more, in much less time than you ever could in any version of HTML+ JavaScript—and do it more reliably, to boot. And, like an HTML app, you can deliver Silverlight applications over the Internet to (almost) anyone who has a browser. Unfortunately, Microsoft has announced that Silverlight won’t run on every platform in the known universe (and, we assume, HTML5+JavaScript applications will). That wouldn’t be an astounding announcement…except that the platforms that Microsoft won’t try to get Silverlight to run on are both the hot thing right now and the presumptive future of computing: Smartphones and tablets.

It’s hard to imagine that Microsoft could get Silverlight to run on either Android or iOS (heck, iOS won’t even run Flash). What bothers Silverlight developers is that Microsoft isn’t even going to try. The only potential good news is that Windows Phone on Nokia could become a real player and Windows 8 could show up on some tablet. It says something about the faith that Silverlight developers have in those platforms that they don’t find much consolation in that.

But their real worry is that, answering the siren call of HTML5, Microsoft is actually planning to give up on Silverlight altogether in favour of HTML5+JavaScript. That would leave Silverlight developers in the backwaters of the brave new world (i.e. stuck on desktops and laptops) where they’ll gradually drift into the Swamp of Obsolescent Technologies (right next to the Island of Misfit Toys)**. Some Silverlight developers have gone so far as to suggest that Microsoft should abandon all of ASP.NET and make Silverlight the sole .NET tool for delivering applications through a browser.

Personally, I don’t think any of those things are going to happen. I don’t see Silverlight going away. Developers are so much more productive with Silverlight than they are in HTML+JavaScript that Silverlight will remain a popular choice for both desktop and intranet development…or any development not targeted at smartphones and tablets. And HTML+JavaScript will remain the most popular choice for developers who are interested in reaching everyone but don’t want to rebuild the same application in four different proprietary development tools. It’s worthwhile to note that I think almost as many developers attend Learning Tree’s WPF and Silverlight course as come to the ASP.NET WebForms course that I wrote for Learning Tree.

But, on the other hand, I am going to learn HTML5 (and be keenly interested in seeing if Learning Tree’s HTML5 course attracts lots of developers). I’ll also be brush uping my JavaScript skills. I’d like to see one of my apps running on an iOS, Android or BlackBerry phone. That would be cool.

Peter Vogel

**over-extended, gratuitous metaphor

Understanding Windows 8 Metro-Style Apps and WinRT

I’ve heard some misconceptions surrounding Windows 8 development. The first one is Microsoft is killing Silverlight. The second is Microsoft is favoring HTML 5 and JavaScript for developing Windows 8 applications over XAML and C#. The third is Microsoft is replacing the .NET Framework with a new framework called WinRT.

Understanding Windows 8 Metro Apps

Windows 8 will include a new Start screen similar to Windows Phones. The Start screen will have tiles that represent programs. Clicking on a tile will start the program. The thing that makes a tile different from an icon is a tile can contain live information. For example, the tile for an e-mail program might include the number of messages in the in-box. Tiles are also big. This allows them to not only contain live information, but also makes them optimized for touch screens.

When a tile is selected, a traditional Windows application or a Metro-style application might start. Traditional Windows applications will run on the Windows desktop. Metro-style apps will run in full screen, like an application on a phone or tablet. Metro-style apps will also have their own controls and idioms optimized for touch. Microsoft has claimed that in a couple years nearly all computers will have touch-enabled screens.

Understanding WinRT

WinRT is the framework used to build Windows 8 Metro-style apps. It is a native Windows API that is optimized for Windows 8 Metro-style UIs, and not a part of the .NET Framework. Metro-style apps can be created using WinRT three ways: with XAML and unmanaged C++, with XAML and C# (or VB), or with HTML and JavaScript. For the third option, Microsoft has created a JavaScript API that allows access to WinRT and some custom HTML tags that understand the WinRT controls.

So, let’s clear up the misconceptions

First, Microsoft is not “killing” Silverlight. Silverlight will be used where appropriate. For example, when a program needs to run on both a PC and a Mac.

Second, by allowing Web developers to use languages they are comfortable in (namely HTML and JavaScript), it doesn’t mean Microsoft intends that to be the development platform of choice. The strength of HTML and JavaScript is support for any platform. Once an application uses the WinRT JavaScript library, it’s a Windows app, not a Web app. I suspect most developers will choose XAML and C#, as it will be more productive.

Third, the .NET Framework is not going away. WinRT applications will still need to access services, write to databases, and not all applications will be Metro-style applications.

Getting Ready for Windows 8 Development

Windows 8 and Metro-style apps offer exciting new opportunities for developers. Whether you are a C++, Web or .NET developer, you will be able to leverage your existing skills to create great new applications for you users. If you want to learn more about developing Windows applications using XAML come to Learning Tree course 975: WPF and Silverlight Introduction: Hands-On.

Doug Rehnstrom

How to use HTML5 data-* in ASP.NET MVC 2

In my last post, I gave a couple of tips on working with ASP.NET MVC and HTML5. The only problem was, one of the tips – substituting underscores for hyphens in HTML5 data-* attributes – only works if you’ve upgraded to ASP.NET MVC 3. That got me thinking about the best way to handle data-* attributes in older versions of ASP.NET MVC.  As It turned out that was a really good thing to do, as I found I needed it when created an HtmlHelper that built links – so

Here’s the problem: attributes are supplied to the actionlink helper as properties of an anonymous object, and property names can’t contain hyphens.

The solution in ASP.NET MVC 3 is to substitute underscores, and the actionlink helper converts them to hyphens.

Here’s a solution for ASP.NET MVC 2: write an extension method to convert the _ in attributes to -.

I wrote an extension method for the HtmlHelper class that accepted text for the link, a routevalues object and an anonymous object to hold the HTML attributes. Note that the method is returning an MvcHtmlString rather than a string – otherwise, your HTML is encoded when it’s written into the page, leading to the HTML being displayed rather than interpreted:

Inside the method, I created a TagBuilder and started to build the <a> tag. Most of it is fairly straight-forward, e.g. using a UrlHelper to create the link:

The difficulty comes when you have to work with the htmlAttributes anonymous object. It’s not a collection, so you can’t just enumerate through it. You have to use reflection instead. Here, I get the type, then the properties – then iterate through the properties and use a string.Replace() to generate the correct string name for the attribute. I then combine the corrected attribute string with the  value of the property:

All I have to do now is add the namespace to my page or web.config:

And then I can call the method inside my view:

Which gives me the same output as I get from the actionlink in ASP.NET MVC3:

That’s it for now. More on developing with ASP.NET MVC3, EF4 and mobile jQuery soon!

Kevin Rattan

For other related information, check out these courses from Learning Tree:

Building Web Applications with ASP.NET MVC

jQuery: A Comprehensive Hands-On Introduction

HTML5: Next Generation Web Development

Tips for Using HTML5 with ASP.NET MVC

The mobile version of jQuery is due out in the next few weeks – it’s currently a release candidate – and I’m working on a project using it. I haven’t done much in the way of mobile development so far, as I’ve been kept permanently busy doing traditional Web development. However, the release of mobile jQuery, and the massive uptake of mobile devices, means it’s time to get with the program. I’m learning a lot as I go, and I’ll be sharing anything I think is useful or interesting with you as the project progresses.

The project combines jQuery mobile with HTML5, Entity Framework 4 and ASP.NET MVC3 (with Razor). I’m not using HTML5 on a whim, but because jQuery mobile relies on it – and that, in turn, made me turn automatically to ASP.NET MVC rather than ASP.NET Web Forms, as MVC lets you write all your own HTML. Having said which, there are some gotchas even with ASP.NET MVC – so here are a couple of tips to help you write HTML5 with ASP.NET MVC.

1. Change Visual Studio’s default HTML validation.
   

   By default, Visual Studio validates your HTML as XHTML 1.0 Transitional. This will give you lots of annoying green underlining.

   

   You can get rid of the warnings (and get useful HTML5 validation) by going into Tools > Options > Text Editor > HTML > Validation and changing the target to HTML5:

   

2. Use _ for – in data-*
   

   ASP.NET MVC 3 allows you to pass in the hyphenated data-* HTML5 attributes using an underscore. It then automatically replaces the underscore with the hyphen. So that the following code

   

outputs this HTML:

which, when you’re using jQuery mobile on its default settings on a black footer, produces this rather elegant button:

And if you think that’s lacking in contrast, we can always add in another data-* element from jQuery mobile…

which gives us…

Of course, the _ for – substitution only works if you’re using ASP.NET MVC3 – which begs the question of what you can do if you’re still using ASP.NET MVC 2. It’s such an interesting question, I think I might just address in it in my next blog post….

Goodbye until then.

Kevin Rattan

For other related information, check out these courses from Learning Tree:

Building Web Applications with ASP.NET MVC

jQuery: A Comprehensive Hands-On Introduction

HTML5: Next Generation Web Development

Simplifying Dynamic Ajax Forms with jQuery Delegates

Recently I was working on an ASP.NET MVC application that made extensive use of Ajax. It’s a version of Chutes/Snakes and Ladders using HTML5 and JavaScript. I used jQuery for the Ajax, of course (what do you expect? I wrote the Learning Tree course jQuery: A Comprehensive Hands-On Introduction). As always, jQuery was a pleasure to work with, but even so it was a tough bit of code to write: until I turned to jQuery delegates.

The problem was complexity. I wasn’t just adding Ajax to existing page content – I also had to Ajax-enable an open-ended number of nested links and forms which were themselves dynamically downloaded.

The .load() method

The jQuery .load() method allows you to download fragments of HTML into the current page. I was using it to download multiple forms (and links), which then had to be set up to use Ajax. These new Ajax forms and links would then download further forms which would also need to be set up for Ajax. This led to some very messy coding and all sorts of recursion problems (such as event handlers being bound to the same object more than once). Switching to delegates not only solved the problems – it also made the code much simpler.

The application used two forms of Ajax: form submission using the Forms plugin, and links which which used the .load() method – which looks like this:

In the example, the .load() method retrieves the page at http://myHref and then looks for the section identified by the selector #selector. The resulting HTML is set as the HTML content of the element myID.

I needed to call .load() on every link inside the newly downloaded HTML, and then use the optional callback to add Ajax to any forms that had been downloaded. This screenshot shows the problem – a user can have n games, which can have n players, who can have n player statements – all of which need to be downloaded using Ajax and then set up to make their own Ajax calls.

In my first pass, the callback was very large, with logic to ensure I was not setting up the same event handlers twice, and named elements given individual treatment:

Switching to delegates made the code much simpler – and removed the problem of panels having to be processed multiple times:

So, what is a jQuery delegate, and what does it do for me?

The delegate method looks like this:

The key point is that rather than assigning the event handler directly on the element, you are assigning the handler to any and all matching elements (in this case, input:text) inside the matched set (in this case, the <body> element). This is powerful enough – but the real beauty is that the handlers are assigned, even if the matching child elements have not been added yet. That means the handler will automatically be applied to any child elements that are added dynamically using Ajax.

Now, instead of having to repeatedly set up each element as it is downloaded, I can set up the Ajax behavior I want on the parent element and it is automatically applied to all children – whether or not they have been downloaded yet. This means I can create a general function to set up the links:

And then call it with the appropriate arguments for the particular div/panel:

Now, as the new forms and links are downloaded and added to a container, any matching elements are automatically assigned Ajax behavior.

Without jQuery delegates, wiring up Ajax functionality on dynamically downloaded forms can be a nightmare of recursion. With jQuery delegates, the code becomes simpler, cleaner – and much more elegant.

If you’re interested in the complete code, I’ve put the ASP.NET MVC page including the JavaScript in a text file here.

If you want to learn about jQuery in depth, then you might want to spend 3 days attending jQuery: A Comprehensive Hands-On Introduction. If you’re interested in jQuery with ASP.NET MVC, then that is covered in Building Web Applications with ASP.NET MVC, and if you want to know how to integrate jQuery into ASP.NET Web forms – well, our course Building Web Applications with ASP.NET and Ajax covers that as well, and I just happen to be the author.

Kevin Rattan

For other related information, check out these courses from Learning Tree:

HTML5: Next Generation Web Development

JavaScript for Web Development

Silverlight or HTML 5?

I was teaching Learning Tree course 975: Windows® Presentation Foundation (WPF) and Silverlight Introduction a couple weeks ago and a student asked which was better, Silverlight or HTML 5. I program with both, so let me give you a few reasons why each is better than the other.

Reasons why HTML 5 is better than Silverlight

It works in iPhones and iPads. So far, Apple has decided the best route to open standards is by being a closed platform. They don’t support applications that require virtual machines. This includes Flash, Java and Silverlight. Obviously, support for these devices is really important. If you want to write an application for iPhone or iPad you have two choices: use their native SDK and Objective-C or HTML 5.

If you currently have a Web application, moving to HTML 5 is straightforward. Essentially, HTML 5 consists of a number of new HTML elements and attributes, new JavaScript libraries and an update to CSS. Over time, you can add new features to your Web applications, and you are not forced to rewrite anything.

Reasons why Silverlight is better than HTML 5

From a practical point of view you can only use the great new features of HTML 5 on a closed system like the iPhone. When you write a Web application for iPhone you only have to support one browser, Mobile Safari. That can’t be said for any other computer. If you’re targeting Windows, Mac and/or Linux users, you can’t depend on a specific browser. Browser support for HTML 5 is inconsistent at best, and non-existent in older browsers. Silverlight by comparison works on every modern platform and in any browser (well, except the iPhone).

Silverlight development is proceeding at a blistering pace. Silverlight 5 is now out in beta. There are an amazing set of controls and features in Silverlight. Take a look at this link, http://www.silverlight.net/content/samples/sl3/toolkitcontrolsamples/run/default.html. Because Microsoft is in charge of everything, they can move really fast, and they are. By comparison, HTML 5 is stuck in a standards committee run by the W3C. At this time, the release date for the standard is 2014 (which means there never will be a standard for HTML 5). By then, Silverlight might be in version 10.

In Silverlight, you program in C# or Visual Basic, rather than JavaScript. Also, Silverlight programming is done using Microsoft Visual Studio or Expression Blend. Both of which are great development tools. HTML 5 support within development tools is not as advanced, although I would expect significant support for HTML 5 in the next release of Visual Studio and ASP.NET.

Silverlight works on Windows Phone 7 (just kidding).

Summary

There are reason to use both HTML 5 and Silverlight. To learn more about HTML 5 come to Learning Tree course 2320: HTML5: Next Generation Web Development. If you want to learn more about Silverlight come to Learning Tree course 975: Windows® Presentation Foundation (WPF) and Silverlight Introduction

Doug Rehnstrom