Why are you still using XHTML?

March 30th, 2011

I am puzzled by the fact that some people still use XHTML, the HTML-clone which was born, because XML fans couldn’t bare to write <br> and instead desired to write <br />.

The difference between XHTML and HTML is that XHTML has a more complex doctype, forces self closing tags and has more strict validation rules that may have made sense back them but they don’t really make sense now.

XHTML promised interoperability with other XML languages, what it didn’t promise was browser support for them.

The latest release of XHTML that actually has browser support is from 2001, that’s even older than IE6.

Writing in XHTML is worthless if you do not validate it(XML in general is only useful if you actually plan to validate it), the problem is that both the validation rules and the validators are unreasonable also well-formed/academic markup will not guaranty browser support, it even makes it harder to support browsers because the strict rules make it hard to write hacks for lesser browsers. Because of this, most people who write XHTML don’t bother to validate it, which makes the whole thing dubious.

And there was XHTML 2.0, which shows that the XHTML group still doesn’t understand how browsers and users work, they dropped backward compatibility ignoring millions of users and the fact that old browsers don’t upgrade magically overnight. Because of these XHTML 2.0 failed misserably.

We are now in 2011, we have HTML5, which can optionally act as XML if the developer wants enforced well-formed-ness(if the browser actually cares to enforce it), it supports both <br> and <br/>, the developer decides the usage, which is good because nowadays mashups are very common and separate syntaxes make this painful.

The HTML5 doctype is much shorter while providing access to the ‘future’ elements and backward compatibility all the way back to IE6.

Despite all this, why are some people and frameworks still using XHTML 1.x?

Behaviors – Extending HTML

September 13th, 2010

HTML is a markup language which most of the time lacks the elements/capabilities that we really need, not even HTML5 could have all the things we need now and in the future. Most UI frameworks get around this by giving a JavaScript API to create new widgets which utilize the DOM API and CSS to associate looks and behaviors to elements. We don’t need to stop here, we can take this further, we can describe new widgets and extend HTML.

How do we accomplish this?

jQuery has a really powerful method called .live() which can:

Attach a handler to the event for all elements which match the current selector, now or in the future.

So basically we can create CSS like rules for elements with JavaScript. Most of the code we write with jQuery are meant for elements that exist, but with live we can make our code work for future elements as well.

Examples speak for themselves

Let’s say we would want to create a send button which behaves like an input[type=submit] element. Let’s name this tag “send”, and let’s write some markup for it:

<send>Send me</send>

Since this is not a standard HTML element we need to assume that it works like a div and style it:

send {
border: 1px solid #000;
padding: 5px;
cursor: pointer;
}

This styling will only work in older IEs if we hack a little in JavaScript:

document.createElement('send');

Now that we have our new element, but we still need to assign it our desired behavior:

$('send').live('click',function(){
    $(this).closest('form').submit();
});

Translation: whenever you click a send element, submit it’s parent form.

With relatively short and easy to read code, we have created our custom HTML element. Now this is not a very useful element, but that doesn’t mean we couldn’t create something very useful with the same technique. My first idea was to implement the HTML5 placeholder(rollover) feature for browsers that don’t support it.

Sadly jQuery live can only capture events on future elements, but it can’t tell us if a new element has appeared in the DOM, so for this we will need the help of the livequery plugin to give us this feature. Since we are implementing a HTML5 feature we need to be careful and make sure that it’s not already implemented in the browser, for this we will need Modernizr.

The code:

(function(window,document,$,undefined) {
    //check for placeholder support
    if (!Modernizr.input.placeholder) {
        //default to placeholder when loose focus
        var blur = function(e) {
             if (!$(this).val().length) {
                  $(this).val($(this).attr('placeholder'));
             }
        }
        //if the value is the placeholder, empty the field
        var focus = function(e) {
             if ($(this).val() == $(this).attr('placeholder')) {
                  $(this).val('');
             }
        }
        //assign the events
        $("input[placeholder]").live('blur',blur);
        $("input[placeholder]").live('focus',focus);
        $("input[placeholder]").livequery(blur);
    }
}(window,document,jQuery));

Download Examples

Again with relatively little pain we managed to make a HTML5 feature work in all browsers. Of course we could have written a jQuery plugin extension for this, but it’s a lot cleaner to simply think HTML5 and let the browser use it’s built in feature if it has any. jQuery live can be used for a lot of other purposes, in my opinion it is definitely worth learning and using along with the livequery plugin.

The road to HTML5 – Tags

August 12th, 2010

It is probably clear in everyone’s mind that we need HTML5 we can’t go forward without something new, we can’t live off the same decade old technology forever, but still we want to support the old versions of IE, some people can’t even let go of IE 6.

When I started thinking about this, the first question that came into my mind is: why? why do we need various HTML5 technologies?

The first thing that came into my mind were: tags

We need more tags, for applications that care about the semantic structure of our pages, like search engines. We could make search engines identify our content much easier if we can tell them more precisely what semantic meaning does a tag have.

Today’s(and even yesterday’s) browsers were designed to deal with unknown tags, if a browser doesn’t know a tag, it will simply display it’s content, which is almost good, but we need to style it. Luckily it turns out that there is a hack to make even IE 6 apply stylings to undefined tags. I took a look if there are reliable implementations of this.

Here are the implementations I found:

HTML5 Reset (html5reset.org)

This project claims to be a good starting point for developers who want HTML5 tags, fair enough. I loaded it’s homepage in IE 6 and it blew up with a JavaScript error, a “null or not an object” type error that could have been easily caught. I wanted to download this to examine it further, there were 3 download options:

Since I only want a starting point I started off with the Bare Bones version. To my surprise it didn’t have any JS files, so I wondered how they managed to tackle the styling issue that I wrote about above. To my dismay styling didn’t work in IE 6, because it missed the JS hacks required for styling to work.

Since the Bare Bones version didn’t work out I went on and tried the Kitchen Sink version, to my surprise it immediately recommended HTML5 Shiv for IE compatibility in comments, but it used Modernizr which basically provided the same solution.

Since this template had a lot of files, I looked at it’s file structure:

.
|-- [       4096]  -
|   |-- [       4096]  css
|   |   |-- [        133]  core.css
|   |   |-- [        404]  main.css
|   |   |-- [       4096]  _patches
|   |   |   |-- [        132]  mac-ie5.css
|   |   |   |-- [          0]  win-ie5.css
|   |   |   |-- [          0]  win-ie6-below.css
|   |   |   |-- [          0]  win-ie7.css
|   |   |   |-- [        117]  win-ie-all.css
|   |   |   `-- [        218]  win-ie-old.css
|   |   |-- [       4096]  _print
|   |   |   |-- [          0]  core.css
|   |   |   `-- [        128]  main.css
|   |   `-- [       1670]  reset.css
|   |-- [       4096]  img
|   `-- [       4096]  js
|-- [        807]  index.html
`-- [       1488]  license.txt

6 directories, 13 files

(Bare Bones version)

I found out that it has:

  • 2 empty directories
  • 4 empty CSS files
  • supposed support for IE 5 and IE 5 on the mac
  • awkward directory names, using “-” as a directory name
  • html5reset-barebones/-/css/core.css contains only one rule
  • html5reset-barebones/-/css/main.css contains only 3 imports nothing else
  • html5reset-barebones/-/css/_print/main.css contains an import to an empty CSS file
  • the only useful part of this whole package is html5reset-barebones/-/css/reset.css which is basically “html5doctor.com Reset Stylesheet”

In my opinion the Bare Bones package is useless, all it does is include html5doctor.com Reset Stylesheet, which I could probably do myself without having this awkward directory structure.

The Kitchen Sink version is basically the Bare Bones version, plus 2 JS files and a more complex index.html, it includes Modernizr and a JS file that captures the load event with jQuery twice and does nothing, this was probably meant to be template, but then why do the same thing twice?

Bottom line: treat HTML5 Reset only as a sample that showcases some techniques instead of a real starting point, it’s mainly Modernizr with some sample code.

HTML5 Boilerplate

This template promised a lot of IE compatibility. This template uses html5doctor.com Reset Stylesheet too, along with other CSS frameworks like YUI Reset. This template has some good patterns and examples like how to handle mobile orientation changes correctly but I wouldn’t use this as my starting point, it includes too many things like DD Belated PNG for IE6, which someone may or may not need. It basically uses Modernizr to get the job done, to be fair the author of HTML5 Boilerplate is a contributor to Modernizr.

Bottom line: it has good examples on how to accomplish various tasks but it’s too bloated to be a general template and it lacks documentation and modularity.

Modernizr(http://www.modernizr.com/)

Modernizr is a very helpful tool, both HTML5 Reset and HTML5 Boilerplate use it as a starting point. It basically detects the presence a lot of HTML5 features mostly by using tests, which is very good, it doesn’t try to provide fallbacks for missing features, the only thing it fixes is the tag styling for older IEs.

HTML5 Shiv(http://code.google.com/p/html5shiv/)

If someone only wants to fix the tag stylings in IE and does not need the full feature set of Modernizr, then HTML5 Shiv is a good tool for that.

HTML5 Reset Stylesheet(http://html5doctor.com/html-5-reset-stylesheet/)

This stylesheet is pretty good, if I would combine it with YUI Reset and get the ultimate Reset stylesheet. The only problems I have with this is that it defines default styles in a few places, which I don’t really like, because I will probably override them anyway.

Conclusions:

I personally would use either HTML5 Shiv or Modernizr with HTML5 Reset Stylesheet(both templates encourage that) with my other technique. HTML5 Reset is an overkill because it has too many conditional CSS files, no site requires that many. HTML5 Boilerplate encourages a better practice for conditional CSS by giving the body tag a class that corresponds with the IE version.

If I were to choose from the two templates I would probably go with HTML5 Boilerplate, but I would surely remove what I don’t need :)

There is nothing there to stop web developers from start using HTML5 tags right away for providing a more semantic web!

Raphaël – Cross browser drawing API

June 22nd, 2010

I already talked about Excanvas, it is good library that mokey patches  IE to support the HTML5 canvas, just recently I discovered Raphaël, which takes another approach for drawing stuff on the web. Raphaël is a canvas-like framework that has it’s own API for drawing, it uses VML on IE, just like Excanvas, but on better browsers it uses SVG. Overall Raphaël is not a duplication of Excanvas, Excanvas is a cross-browser implementation of Canvas, while Raphaël is a cross-browser implementation of SVG.

Raphaël’s demos so far are a lot more impressive than the ones that come with Excanvas, but it’s biggest advantage is that it has an API documentation unlike Excanvas which refers to the not so good W3C documentation. The reason it is bad to point to a W3C documentation is because Excanvas doesn’t implement all of those, so we have to test and see what is implemented and what is not.

The classic tiger example done with Raphaël

The Raphaël API is simple, it focuses on the things people would normally do:

window.onload = function () {
    var img = document.getElementById("photo");
    img.style.display = "none";
    var r = Raphael("holder", 600, 540);
 
    r.image(img.src, 140, 140, 320, 240);
    r.image(img.src, 140, 380, 320, 240).scale(1, -1).attr({opacity: .5});
    r.rect(0, 380, 600, 160).attr({gradient: "90-#000-#000", opacity: .5});
};

Flash advocates criticized native web applications because it was not possible to do reflections and the reflections had to be stored server side. The above example, proves them wrong, it does exactly that without the need of storing the image server side.

A great feature of Raphaël is that the drawn elements are actually DOM elements, which makes their events scriptable. This means that we can do interactive objects just like this example.

The Raphaël project goes even further, it even has a charting plugin, which can make it really convenient to do interactive graphs. This makes me wonder why does Google Analytics still use Flash.

Thanks to developers like these we don’t have to wait 10 years for the pure HTML5 Canvas and SVG. I may have given a lot of credit to this project, but there are usecases when Excanvas is probably better, the key for choosing is considering the functionalities and speed.

Mobile web libraries – Sencha Touch

June 19th, 2010

When I thought I was through examining the most appealing mobile web libraries, the news came in that the newly (re)formed Sencha has put out a new one called Sencha Touch. Despite being something really new, it provides the best support for iOS(iPhone,iPod,iPad) and Android, in fact it only supports these:

Our initial beta is compatible with iOS and Android, which together represent over 90% of current US mobile traffic.

I neither agree nor disagree with this statement, though I agree that most mobile web market share does in fact come from iOS + Android. Typically this framework is aimed at developers who want to support these, and developers who want to support new technology. Sencha Touch heavily utilizes Webkit, CSS3 and HTML5, it doesn’t seem to be forgiving lesser user agents, this is what seems to differentiate it from jQTouch, despite the fact that Sencha claims to be: Ext JS + jQTouch + Raphaël. They however mentioned that they plan to support other forward thinking devices.

Sencha Touch seems to be the only mobile web framework so far that provides touch support like: tap, double tap, swipe, tap and hold, pinch, and rotate. The problem I found with this is that there is no compatibility chart for Sencha Touch and few of it’s examples actually work on my Android 1.6 phone, which questions Sencha Touch’s Android support.

A weird fact is that Sencha Touch’s API is really Ext JS(see source), even the source codes use the Ext global object. The release I downloaded is labelled 0.90 beta, which discourages me to use it for actual products, because it will probably get a refactoring by the time it reaches 1.0, in fact I wouldn’t have called this beta in the first place.

My final verdict is to use this framework only if it makes sense, it is a superior alternative to writing native applications(because we don’t have to do platform specific builds), but it’s not as compatible as one would expect, which can be a problem because of the Android platform fragmentation. What I would like to see in the future is some jQuery integration(because of jQTouch) and a more forgiving interface, possibly a way to know the browser’s features, my biggest need is a good way to detect drag n drop support.

Update 2010-06-24:

A lot of HTC(and probably others) Android phones will get an upgrade to Android 2.1, which will (hopefully) render some of my above arguments irrelevant. Also worth noting that Sencha Touch is about being future-ready, which in the current circumstances is more reasonable than the opposite.

http://androidcommunity.com/htc-tattoo-getting-2-1-20100311/

http://phandroid.com/2010/03/11/htc-tattoo-getting-android-2-1/

Video JS

June 6th, 2010

As I expected, an intermediate period is coming, when everyone will try to make the most of HTML5 but at the same time build good fall-backs. A good example is Video JS, a project that aims to provide the best video playback solution as possible. It’s basically a HTML5 video player with controls built from JavaScript and customizable via CSS, so far nothing we haven’t seen at Youtube, however what makes this good is that it also shows the way to make it fall back to Flow player when the browser does not support Video. In English: this means that this will work even in IE6.

It is very simple to use this library, it can be done in a few steps:

1. Load the library

<!-- Include the VideoJS Stylesheet -->
<link rel="stylesheet" href="video-js.css" type="text/css" media="screen" title="Video JS" charset="utf-8">
<!-- Include the VideoJS Library -->
<script src="video.js" type="text/javascript" charset="utf-8"></script>

2. Initialize when the page is loaded

  <script type="text/javascript" charset="utf-8">
    // Run the script on page load.
 
    // If using jQuery
    // $(function(){
    //   VideoJS.setup();
    // })
 
    // If using Prototype
    // document.observe("dom:loaded", function() {
    //   VideoJS.setup();
    // });
 
    // If not using a JS library
    window.onload = function(){
      VideoJS.setup();
    }
  </script>

3. Insert the video embed code. This may seem complicated at first, to make it easier to understand I put in some extra comments that describe what and when happens.

<!-- Begin VideoJS -->
  <div class="video-js-box">
    <!-- Using the Video for Everybody Embed Code http://camendesign.com/code/video_for_everybody -->
    <!-- Let's try to use that video element if we can -->
    <video id="video" class="video-js" width="640" height="264" poster="http://video-js.zencoder.com/oceans-clip.png" preload>
      <!--Let's try to use MP4 at first-->
      <source src="http://video-js.zencoder.com/oceans-clip.mp4" type="video/mp4">
      <!--If the browser doesn't support MP4, let's try WebM-->
      <source src="http://video-js.zencoder.com/oceans-clip.webm" type="video/webm">
      <!--No MP4, no WebM, well then our last resort is OGG Theora-->
      <source src="http://video-js.zencoder.com/oceans-clip.ogg" type="video/ogg">
      <!--No HTML5 video element support :(, it's probably IE, let's use Flash(Flow player) then-->
      <object width="640" height="264" type="application/x-shockwave-flash"
        data="http://releases.flowplayer.org/swf/flowplayer-3.2.1.swf">
        <param name="movie" value="http://releases.flowplayer.org/swf/flowplayer-3.2.1.swf" />
        <param name="allowfullscreen" value="true" />
        <param name="flashvars" value='config={"clip":"http://video-js.zencoder.com/oceans-clip.mp4"}' />
        <!--No Flash, let's just show a poster then-->
        <img src="http://video-js.zencoder.com/oceans-clip.png" width="640" height="264" alt="Poster Image" 
          title="No video playback capabilities." />
      </object>
    </video>
    <!--No video element, no Flash, ohh well, offer the user to download the video and use an external player then-->
    <p class="vjs-no-video"><strong>Download Video:</strong>
      <a href="http://video-js.zencoder.com/oceans-clip.mp4">MP4</a>,
      <a href="http://video-js.zencoder.com/oceans-clip.webm">WebM</a>,
      <a href="http://video-js.zencoder.com/oceans-clip.ogg">Ogg</a><br>
      <a href="http://videojs.com">HTML5 Video Player</a> by <a href="http://videojs.com">VideoJS</a>
    </p>
  </div>
  <!-- End VideoJS -->

This library is young, but it is already quite usable. It is the perfect solution for supporting iPhones and iPads.

Homepage: http://videojs.com/

HTML5 Canvas can work even in Internet Explorer 6

May 20th, 2010

The most heard criticism about Canvas is that it’s not supported in IE, and because of that it will only be usable in 12 years. This is certainly not true, I have found a solution that can make a Canvas application work even in IE6, it’s called Explorer Canvas, an Internet Explorer specific implementation of the HTML5 Canvas, and not it’s not a browser plugin, it’s a JavaScript file. We just include excanvas.js like this:

<!--[if IE]><script type="text/javascript" src="excanvas.js"></script><![endif]-->

and let Explorer Canvas do the rest.

This wonderful piece of software was brought to us by Google, and it’s available at http://code.google.com/p/explorercanvas/.

I know this is all nice but: does it really work?

Well I took my very simple graph application and took it for a test run under IE with this included. I got a script error, because fillText is not supported under excanvas, so I took these two lines out and the rest of my code worked, even under IE6:

Now skeptic people may say “HAH, fillText is not supported, this FAILS!”, but the fact is that we could replace these parts, I mean we don’t really need Canvas to draw text most of the time, we can already do that with HTML. So most of the time we could live with this limitation and have a pixel perfect rendering!

There are other things that are not (yet) supported by excanvas, but most of the features are! So I encourage people doing charts to try to use this instead of a flash based solution.

I also made a downloadable package of the experiment I showed earlier, but the excanvas package contains cooler demos. Looking forward to doing more advanced things in the future with all this.

Canvas Demos – All the HTML5 goodness

May 18th, 2010

For people interested in HTML5, I highly recommend http://www.canvasdemos.com/ it is a very good site that contains a lot of demos that make use of HTML5, mostly the Canvas element. A lot of these amazing demos make me wonder when will Adobe start to get nervous, some examples show that a lot of the current Flash applications can be done in HTML5 too.

There has been a very optimistic speculation that HTML5 must be used to build iPhone/iPad web games, well I found a video which showcased that it’s not the case. Canvas applications perform terribly on an iPad. I hope Apple will improve the performance.

Finally I will have some limited time to look for canvas compatibility layers.

Pure CSS3 Spiderman Cartoon w/ jQuery and HTML5 – Look Ma, No Flash!

May 17th, 2010

Last week I came across a very nice demonstration of what the HTML5 stack can do with just CSS(3 to be exact) and some minor JavaScripting.

http://www.optimum7.com/internet-marketing/web-development/pure-css3-spiderman-ipad-cartoon-jquery-html5-no-flash.html

The article describes how the animation was created what problems did it required solving and how could the DOM be used for gaining and advantage.

A commentator replied to this article with a blunt suggestion that “This works in 6% of browsers and spikes CPU usage.” and goes on suggesting that this is not usable because it is not supported everywhere. Well it misses the point because this was a well performed experiment.

The browser vendors will have to give sooner or later, we can’t live with IE6 supported technologies forever.

HTML5 Canvas – First encounter

May 5th, 2010

I’m developing an in house project called Project Timer, it’s essentially a client-server application that helps me keep track of the amounts of work I put into projects. Like most statistics applications it needs to display graphs, when the first version was developed I naturally used tables cause I didn’t want to make it too server specific. When I saw a lot of news about HTML5 and Canvas, I couldn’t help to think that I should be using it.

Since this is my personal application that is basically a Google Chrome extension I shouldn’t have to worry about other browsers not supporting it. So I wanted to learn how Chrome’s implementation of Canvas works, well they didn’t seem to have it documented but they referred to a Mozilla link, which was nice because it looks like there is really not much difference.

First thing to do is to create a Canvas tag, which looks like this:

<canvas id="mycanvas" width="550" height="250"></canvas>

It’s very simple, and it generally works like an image tag, but it only occupies space until we script it. Note that it has a close tag(required in Firefox, optional everywhere else) which can contain alternative content for lesser browsers that don’t support this tag.

To actually make use of this tag we have to get a reference to it from the DOM like any other element.

var canvas = document.getElementById("mycanvas");

Now that we have the element we need to specify the context we like to use it in:

var ctx = canvas.getContext("2d");

The drawing context we most likely to be using is 2D, later on we could probably draw in 3D too. As expected we do the drawing operations trough the context which has some really sensible operations like save() and restore(), where save() backs up the current state and restore() restores it. This is really ideal because this enables us to create reusable code that won’t break the state of the outer code.

A simple example for this:

//some code before
ctx.fillStyle = "rgba(255, 255, 255, 0.5)";
ctx.save();
ctx.font = "9px 'arial'";
ctx.fillStyle = "#000";
ctx.globalAlpha = 1.0;
ctx.fillText('text',0,0);
ctx.restore();
//some code after

This example shows that we can simply hit save() do almost anything we want, hit restore, and the outer code won’t even notice we were there. This is a really clean way of drawing things, it saved me the trouble to do the state preservation manually.

Since I needed to do a simple graph I only used a few drawing operations:

fillText(text,x,y) – draws text starting from x,y

fillRect(x,y,width,height) – fills a rectangle starting from x to x+width, and from y to y+height

And of course the following for drawing lines:

beginPath()

moveTo(x,y)

lineTo(x,y)

closePath()

stroke()

To draw lines we basically create paths and either stroke() or fill() them, like this:

ctx.beginPath();
ctx.moveTo(10,10);
ctx.lineTo(50,60);
ctx.closePath();
ctx.stroke();

This is just a small subset of Canvas, there are a lot of cool features I didn’t try out yet,  there are a lot of cool applications already written with this technology at ttp://www.canvasdemos.com/.

The single bad thing is that lesser browsers do not support this, but I had an idea that it can be (poorly?) emulated using Adobe Flash, and it looks like other people or having similar ideas. So it looks like we are about to see very interesting new web applications.