That time has long passed.

When you really only had to target IE6, you could pretend the web was platform independent.

The truth is now the web is neither, nor will ever be platform independent.  It’s just an illusion based on the simple notion that browsers basically just render HTML.

How many platforms are there then?

This is a surprisingly difficult question to answer.

Back before the web really took off there were basically 3 platforms to develop an app for: Windows; Unix/Linux; and Mac.

When we answer this question for the web, really we have to look at browsers as if they are the operating system.  Since the same browser exists on multiple base OS’s but could be different, we have to count each combination of browser and OS as a potentially separate version.

Windows: IE6, IE7, IE8, IE9 (beta), Firefox, Chrome, Safari

OSX: IE, Firefox, Safari (more?)

Linux: Firefox, Chrome

Android: Webkit

iPad, iPhone: Safari

I don’t have nearly every combination listed, but this is what I would consider a good coverage for any kind of public facing website.

Oh, don’t forget to cross this again with localization and globalization, because you might have a localization problem that only happens in a certain language in a certain browser on a certain OS.

Not just rendering level differences

It is also very interesting to consider that a web developer now has to consider how their site will not just render, but be used on a mobile platform. 

Consider how Google released an iPad version of Gmail.  And although, you may not really care if your site works on an iPhone or an Android phone, you probably should start caring about how it works on tablets like the iPad, because that market is only growing.

If you have a website that doesn’t work on someone’s iPad when they are shopping online, do you think they will get up, go turn on the computer, and go to your site to make the purchase or they will buy from a different site with a few touches?

With a phone size resolution, the considerations are even more important.

Tools help me make the web platform independent

No tool exists right now that can handle the non-technical aspects of platform independence for your web application, but let us imagine for a second that a library like JQuery really made your javascript platform independent.

If we were to hold onto that shaky assumption, we would need to make sure that we never wrote javascript that wasn’t written through the JQuery API.  (Which happens to be an extremely leaky abstraction over javascript, CSS, and the DOM.) We would still have to make sure our HTML and CSS tags were platform independent.

So even if we could get parts of our development to be mostly platform independent, we would still need to test on all of the major platforms, because we could not rely on the platform independence.

Now, don’t get me wrong here.  I love JQuery.  It makes the job of a web developer so much easier.  But, there is an important distinction.  APIs and libraries like JQuery make it easier to write platform independent web code, but they don’t make our code platform independent.

What does all this mean?

We’ve gotten to the point where the most platform independent technology you can use is either Flash or Silverlight.

I’m not sure if this is the future of development, but it very well might be.

One important point to draw from this realization is that we shouldn’t necessarily choose to make our application a web application, because we need it to be platform independent.  It seems like about 5 years ago, the web became the default choice, because it was better to have platform independence than a rich UI.

Hopefully, for the sake of web developers some of these paths die off or converge, or that standards compliance becomes so good that you could really write code for one browser and expect it to work on all the others.

As always, you can subscribe to this RSS feed to follow my posts on elegant code.  Feel free to check out my main personal blog at http://simpleprogrammer.com, which has a wider range of posts, updated 2-3 times a week.  Also, you can follow me on twitter here.

But why the bottom of the page? 

But how bad is this?

What else should I be doing that I’m not?

oEmbed is a format for allowing an embedded representation of a URL on third party sites. The simple API allows a website to display embedded content (such as photos or videos) when a user posts a link to that resource, without having to parse the resource directly.

Providers must specify one or more URL scheme and API endpoint pairs. The URL scheme describes which URLs provided by the service may have an embedded representation.

Requests sent to the API endpoint must be HTTP GET requests, with all arguments sent as query parameters. All arguments must be urlencoded (as per RFC 1738).

{
"provider_url": "http://www.youtube.com/",
"title": "Insert a YouTube Video With oEmbed Wordpress 2.9",
"html": "<object width=\"480\" height=\"295\">
    <param name=\"movie\" value=\"http://www.youtube.com/v/6lbDyXu7gUQ&fs=1\"></param>
    <param name=\"allowFullScreen\" value=\"true\"></param>
    <param name=\"allowscriptaccess\" value=\"always\"></param>
    <embed src=\"http://www.youtube.com/v/6lbDyXu7gUQ&fs=1\" type=\"application/x-shockwave-flash\"
        width=\"480\" height=\"295\" allowscriptaccess=\"always\" allowfullscreen=\"true\"></embed></object>",
"author_name": "adriarichards", "height": 295, "width": 480, "version": "1.0",
"author_url": "http://www.youtube.com/user/adriarichards",
"provider_name": "YouTube",
"type": "video"
}

Consumers may wish to load the HTML in an off-domain iframe to avoid XSS vulnerabilities.

I must say that I was pleasantly surprised by some of the features that this IDE has to offer. The first and most obvious one is probably intellisense that just works as expected.

Also notice the on-the-fly code inspection (colored marker bar on the right) that should be familiar when you’re a Resharper addict like me. Web IDE provides W3C XHTML/CSS validation while working in the editor which is really useful.

Being the uncertain type, it was also nice to see all the familiar refactoring features from Resharper being available as well. Renaming a class or id is just a breeze. All the corresponding HTML or CSS files are consistently updated.

Navigation is there as well (CTRL-N and CTRL-SHIFT-N).

This looks just like Resharper for web developers, but there’s more. At first, I had all the HTML and CSS files including all the image file in the root folder of the project. I wanted to divide and conquer by putting the images and CSS files into their own separate folder. As I prepared myself to change all the references in the HTML files, Web IDE did that all for me when I dragged the files to their final destination. Now I didn’t had to go over all the HTML files and manually change the links. How cool is that!

Web IDE also provides source-control integration Subversion, Git, Perforce, etc … and that’s just the tip of the iceberg. While working on the prototype of the web application, I mostly focused on the layout and not so much on the behavior so I didn’t use much of the JavaScript capabilities. But I was told that it is comparable with the JavaScript features in RubyMine as described by Peter in this blog post. This is something that I’m going to explore when I start learning more about JavaScript :-).

Although being the first version and still in beta, the IDE seems pretty stable and I couldn’t notice any performance hiccups so far (which cannot be said for all IDE’s these days).

I do hope that there will be some support for ASP.NET or other view engines like Spark, NVelocity, etc. … in future versions. In fact, I still silently wish that JetBrains would come up with an IDE for .NET. Being realistic about it, I don’t have high hopes for something like that coming out but it would totally rock if they decided to build one. Sweet dreams :-)

Bottom line, when you’re doing web development in Visual Studio, make sure to also check out Web IDE. It will probably help you to become more productive along the way.

Bad news is that this means I’m behind.  That sucks.  I was using JQuery MONTHS before Microsoft officially started supporting it (at least 6 months – but I’m too lazy to look it up).  Anyway, now you can use Microsoft’s bandwidth to get JQuery to your customer’s browser with this line:

<script src="http://ajax.microsoft.com/ajax/jquery/jquery-1.3.2.min.js" type="text/javascript"></script>

And you can add the JQuery Validation library like this:

<script src="http://ajax.microsoft.com/ajax/jquery.validate/1.5.5/jquery.validate.js" type=”text/javascript”></script>

Note: see those end tags, great annoyance of my life, but you have to have them, you can’t do <script src=”http://…” />.  That sucks, but I’m learning to live with it.

Anyway, back to validation.

The more I play with this library, the more I like it.  It is very configurable, easily style-able, the documentation isn’t half bad, and the code is readable.

Getting Started with JQuery Validation:

The JavaScript Way:  OK, assuming you have JQuery and the JQuery Validation library included, lets start with a simple customer form:

   1: <form id="CustomerForm">

   2: <p>

   3: <label for="firstNameEdit">First Name:</label>

   4: <input id="firstNameEdit" type="text" />

   5: </p>

   6: <p>

   7: <label for="LastNameEdit">Last Name:</label>

   8: <input id="LastNameEdit" type="text" />

   9: </p>

  10: <p>

  11: <label for="EmailEdit">Email:</label>

  12: <input id="EmailEdit" type="text" />

  13: </p>

  14: <p>

  15: <button type="submit">Submit</button>

  16: </p>

  17: </form>

Nothing special there.  Just a bunch of inputs and labels.  If you hit the submit button, a postback is fired and the data is sent back to the server.

But, business requirements dictate that all fields are required.  Simple enough, using JQuery the hookup looks like this:

   1: $("#CustomerForm").validate({

   2:     rules: {

   3:       FirstNameEdit: { required: true },

   4:       LastNameEdit: { required: true },

   5:       EmailEdit: { required: true, email:true }

   6:     }

   7: });

OK, the first name, last name, and email will now be required.  I also threw a little extra in there: email validation.  If you submit the form like this will be added after any of the required fields:

   1: <label class="error" for="FirstName" generated="true">This field is required.</label>

Key part there is the ‘error’ css class which is great for styling the messages.  So you can use the ‘label.error’ in your css class.

Another way

You can also use css classes to setup which fields are required.  It is a nice and simple way to hook everything up, but it is not as easily configurable (as we will see in a moment):

   1: <form id="CustomerForm">

   2: <p>

   3: <label for="FirstNameEdit">First Name:</label>

   4: <input id="FirstNameEdit" type="text" class=”required”/>

   5: </p>

   6: <p>

   7: <label for="LastNameEdit">Last Name:</label>

   8: <input id="LastNameEdit" type="text" class=”required” />

   9: </p>

  10: <p>

  11: <label for="EmailEdit">Email:</label>

  12: <input id="EmailEdit" type="text" class=”required email”/>

  13: </p>

  14: <p>

  15: <button type="submit">Submit</button>

  16: </p>

  17: </form>

The the Javascript is actually much simpler:

   1: $("CustomerForm").validate();

And you will get the same results.  But, the rest of the samples will use the prior code setup.  Also note: you can mix and match the css style with the JavaScript style.

Moving the message

Next problem you might encounter is you want to move the messages to another part of the screen.  Remember, default behavior is the messages go next to the control.

To solve this we will add a div to the page:

   1: <div id="RegisterErrors" style="display:none">

I can setup the Validation library to use this by going back to the validate method and adding errorLabelContainer directive.

   1: $(“#CustomerForm”).validate({

   2: errorLabelContainer: $("#RegisterErrors"),

   3: rules: {

   4:         FirstNameEdit: { required: true },

   5:         LastNameEdit: { required: true },

   6:         EmailEdit: { required: true, email: true }

   7:     }

   8: });

Now this is great, but there is still a problem.  Each of the messages will be “This field is required”.  That doesn’t say which field is the problem.  Lets add custom messages for each field.

   1: 

   2:     $("#CustomerForm").validate({

   3:     errorLabelContainer: $("#RegisterErrors"),

   4:     rules: {

   5:             FirstNameEdit: { required: true },

   6:             LastNameEdit: { required: true },

   7:             EmailEdit: { required: true, email: true }

   8:         },

   9:         messages: {

  10:             FirstNameEdit: "First name is required",

  11:             LastNameEdit: "Last name is required",

  12:             EmailEdit: "Valid email address is required"

  13:         }

  14:     });

Which then gives better messages.

For next time

Ok, this is not all the JQuery Validation library can do, there is a lot more, but this is enough for now.  Next post will show how to validate fields using web service results, and various callbacks that can be used to customize the library.

That time has long passed.

When you really only had to target IE6, you could pretend the web was platform independent.

The truth is now the web is neither, nor will ever be platform independent.  It’s just an illusion based on the simple notion that browsers basically just render HTML.

How many platforms are there then?

This is a surprisingly difficult question to answer.

Back before the web really took off there were basically 3 platforms to develop an app for: Windows; Unix/Linux; and Mac.

When we answer this question for the web, really we have to look at browsers as if they are the operating system.  Since the same browser exists on multiple base OS’s but could be different, we have to count each combination of browser and OS as a potentially separate version.

Windows: IE6, IE7, IE8, IE9 (beta), Firefox, Chrome, Safari

OSX: IE, Firefox, Safari (more?)

Linux: Firefox, Chrome

Android: Webkit

iPad, iPhone: Safari

I don’t have nearly every combination listed, but this is what I would consider a good coverage for any kind of public facing website.

Oh, don’t forget to cross this again with localization and globalization, because you might have a localization problem that only happens in a certain language in a certain browser on a certain OS.

Not just rendering level differences

It is also very interesting to consider that a web developer now has to consider how their site will not just render, but be used on a mobile platform. 

Consider how Google released an iPad version of Gmail.  And although, you may not really care if your site works on an iPhone or an Android phone, you probably should start caring about how it works on tablets like the iPad, because that market is only growing.

If you have a website that doesn’t work on someone’s iPad when they are shopping online, do you think they will get up, go turn on the computer, and go to your site to make the purchase or they will buy from a different site with a few touches?

With a phone size resolution, the considerations are even more important.

Tools help me make the web platform independent

No tool exists right now that can handle the non-technical aspects of platform independence for your web application, but let us imagine for a second that a library like JQuery really made your javascript platform independent.

If we were to hold onto that shaky assumption, we would need to make sure that we never wrote javascript that wasn’t written through the JQuery API.  (Which happens to be an extremely leaky abstraction over javascript, CSS, and the DOM.) We would still have to make sure our HTML and CSS tags were platform independent.

So even if we could get parts of our development to be mostly platform independent, we would still need to test on all of the major platforms, because we could not rely on the platform independence.

Now, don’t get me wrong here.  I love JQuery.  It makes the job of a web developer so much easier.  But, there is an important distinction.  APIs and libraries like JQuery make it easier to write platform independent web code, but they don’t make our code platform independent.

What does all this mean?

We’ve gotten to the point where the most platform independent technology you can use is either Flash or Silverlight.

I’m not sure if this is the future of development, but it very well might be.

One important point to draw from this realization is that we shouldn’t necessarily choose to make our application a web application, because we need it to be platform independent.  It seems like about 5 years ago, the web became the default choice, because it was better to have platform independence than a rich UI.

Hopefully, for the sake of web developers some of these paths die off or converge, or that standards compliance becomes so good that you could really write code for one browser and expect it to work on all the others.

As always, you can subscribe to this RSS feed to follow my posts on elegant code.  Feel free to check out my main personal blog at http://simpleprogrammer.com, which has a wider range of posts, updated 2-3 times a week.  Also, you can follow me on twitter here.