Friday, November 30, 2007

HTML done right?'s been a while. I've been tied up with work and have a newborn in the house now. A bouncing, healthy, baby boy! Woo-hoo!

Anyway, HTML. This seems to be a bit of a hot topic in terms of what will be the successor to HTML 4/XHTML 1.x. The two major camps appear to be the W3C with XHTML 2.0 and the WhatWG's HTML 5. Both have good ideas, but both have problems.

I'm not going to go into a debate on which is better because regardless of which one is picked, there are still some fundamental problems with both. My biggest complaint is the mixture of different languages in one document. You can have HTML, CSS, and JavaScript all in one file and mixed together. Not very pretty. Also, things aren't as nice and simple as they could be.

My current thought process is to come up with a different standard that's designed from the beginning to ensure the separation of style, content, and script/code. First, we need to have the document divided up into sections. I see 4 sections: metadata, content, style, and script.

First is the metadata section. This should contain information like the character set encoding used and the version of the document specification used. This can contain more than just information. The two mentioned are just those that are required.

The second is either the content or the style. Not really sure which as I don't know which would be better for a browser to handle first. One could either read in the content first then apply styles as they are read or read in the styles first, then render the content as it's read. For now, I'm going to assume the style comes first because from a browser standpoint, I'm thinking that it would be better to know all of the display information first, then apply it as the content is being read.

The style section is the equivalent to the style section of current HTML document. However, I'm not 100% sure that CSS in it's current state is the way to go. The big problem is that using floats to do page layout isn't the most intuitive way to go. Also, absolute positioning doesn't solve all the problems we encounter. I'm thinking that a good, simple grid-based positioning system would work best. An element would have it's position within the grid specified as a pair of (x,y) coordinates (top left & bottom right). Granted, this may not be the best way to go because I'm not sure how to specify stretchiness. I.e. how the element can stretch at least horizontally depending on the size of the screen.

The third section, content, needs to focus on the parts of a document, such as titles, heading, and paragraphs. HTML is pretty close, but it does have some limitations in that a number of different elements, such as lists or tables, are used for things that they weren't meant for, such as navigation or page layout. Also, I'm not sure what to think about div and span tags. They have no meaning other than one's a block be default and the other is inline by default. Each element should describe the content it contains. This may be a bit of an impossibility because how would you style an individual piece of text that's contained within a paragraph?

Another aspect of the content section that needs to be looked into is the semantic aspect. This is interesting because while it is a good way to try to get everyone to mean the same thing when they say "foo," it's really kind-of a pipe dream because there's no central database or semantic model that defines everything. Without that, how can we be sure that everyone means the same thing? My current thought process is that the semantic aspect is knowing what the different components of the document are, thus we can derived the importance of a piece of text and make searches more accurate. Also, it may be nice to have a method of embedding semantic data in the content itself. Something beyond the basic keywords which would be in the metadata section. They key is that additional semantic data would be specific to the domain of the web site. In other words, the semantic data would be specific to the site. The site would then have a RDF file, OWL file, or a semantic database that represents the data model used. Just a thought.

The last section would have the code that would be run on the page if any is needed. The reason for this being last is that we can be sure that the contents and styles have been loaded and applied first before we attempt to do any document manipulation. This has been a problem with many efforts where the page would still be loading when the browser is trying to execute JavaScript. By making it mandatory that the script be on the bottom, we can ensure that this is not a problem.

Now, for all of these, there's no guarantee that the current syntax or technology is really what we want. My main objection is to the XML-like syntax used by (X)HTML. It's very verbose. A LaTeX-like syntax I think is easier and more compact, however I'm not sure which is better for parsing the document into a document tree that can be manipulated dynamically.

Now, the question some of you may be asking is why I am proposing this. Simple: the web has evolved beyond what HTML was originally designed for, so a new forward-thinking approach is necessary. Also, after using it for many years, we have discovered many problems and we should now take the time to make sure they're not a problem anymore. Of course, while all this is nice and good, the problem is getting it accepted. Browsers are notoriously slow in implementing new standards and many people are used to HTML and don't want to use something different.

Labels: , , , ,