Nathan Herald

HTML5

Used to be, I would only use a strict XHTML doctype on any webpage I authored. I looked down on people using html4 or transitional even, thinking it was pretty worthless (which it is ;).

Why is XHTML better?

1. XML can be validated, extended, and written by machines easier since it's parsing rules are standardized.
2. XSLT
3. Strictness (if it isn't valid xml, it doesn't work)

Any cons?

1. Strictness. The idea of a comment from someone on my blog being able to derail the entire page because of invalid xml is pretty stupid.
2. application/xml support sucks. Violating the spec just to please IE seems ok at first, but it really is just another thing to worry about. What if the mechanism that does this switch freaks out or doesn't work with IE9 or something?

But I don't care now, because HTML5 is the future

HTML 5 actually provides all the positives of XHTML without any of the cons. It's parsing rules are declared fully, anyone can make a parser and validation will be much more useful. HTML 5 will also define XHTML 5, which will be essentially the same but with XML compatibility, so XSLT is still an option. And strictness is still possible, but doesn't derail the entire thing.

You also get new form inputs, section, nav, header, footer, and other cool tags. You get data- attributes on elements, you get DOM parity with the parsing model, you get SQL storage in the browser, the ability to run apps offline, etc. You really get all the ideas we all already agree on.

Any really, why should HTML have it's own spec and be it's own language? Why do we have to use XML for everything? I already use JSON for almost all of my inter-application communication when I write webapps. Not because it works natively in javascript (I'm not even using it there much), because it works everywhere. There are not attributes or namespaces or anything, just data. It beats the pants off XML for most everything I do. And parsing JSON is dead simple, anyone can write a parser (sound familiar).

And really, the main reason HTML5 is the best to me is because the author of and contributors to the spec care about what works now. They are not hesitating to push things forward, but they are not blindly blazing a trail that no one is going to follow.

Is there anything that is in XHTML 2 that (X)HTML 5 will not have that matters? Contact me and I will amend any comments if valuable.

Also, here is a google search in case you care.

Update: Probly the best overview at immike.net. A quote:

Both working groups have embraced the coming Semantic Web by allowing developers to embed richer metadata in their documents. As with forms, the XHTML2 working group has embraced a more sophisticated technology, while the HTML working group has kept things simple.

The complex looks nice sometimes, but usually the simple wins in the end.

Update 2: An article disagreeing with me.

Update 3: Some more links:

• http://nimbupani.com/blog/the-long-road-from-xhtml-to-html.html
• http://mezzoblue.com/archives/2009/04/20/switched/
• http://www.webdevout.net/articles/beware-of-xhtml

Review posts now show their ratings as stars.

Ratings are stored as floats, so they can have very strange precision like 4.5 or 4.3567. Since I wanted to show the amount of stars as accurately as possible, I decided to make something that can reflect any float value (basically).

Essentially, I laid 5 stars out (15px wide each) with 4px between them. I saved out two versions, one with all stars in the off/disabled state and one with all stars in the on/enabled state. I use these as backgrounds of div's, with the "on stars" on top of the "off stars." I show the current rating with the "on stars" by clipping the image's width. See below:

So, I essentially clip the "on stars" to whatever width they need to be to represent the rating.

How does one calculate the width? Well, it's simply (star_width * rating_amount) + (space_width * floor(rating)). floor() means to always round down, even when the decimal is .5 or more. Example math:

Rating: 1
Width: (15px 1) + (4px 1) = 19px (only shows the first star)

Rating: 4.5
Width: (15px 4.5) + (4px 4) = 83.5px

Since we can't have 0.5 pixels technically, I just round the amount off to the nearest integer.

So, not very hard. Actually, it took me longer to write this post than to make the stars.

5 Problems We Might See in the Next 100 Years

1. Stealing rain from neighboring countries (from seeding clouds)
2. Pushing pollution across continents
3. Global suburbs around nice weather areas (ex: Mediterranean, not really a problem I guess)
4. Exposing food to all shoppers being a legal liability
5. Not having any problems

Background applications on the iPhone are not important to me. I understand the issues and have never liked the idea of having tons of little processes eating away at battery, even when I had a palm.

But there is one inconsistency on the iPhone that has been driving me mad the past two weeks. Mail runs in the background.

I know it does.

The fact that I know that it does is actually the problem. I type an email, hit send, then I immediately hit the Home button and open another app. When the email is actually sent, you hear the woooosh – while in the other app.

Which is great.

It's a time saver and I don't have to watch the little spinny thing waiting for the mail to be sent. However, Tweetie does not run in the background. At least 10 times I have typed a tweet, hit home, then discovered later (upon reopening Tweetie) that it didn't make it. Pretty much, I cancelled sending it by shutting down the app.

Which sucks.

I think Apple could use a facility they already have built in. When memory is tight, they kill your app. Shutting an app down could be moved to a two stage process: closing the window, then real shutdown (dealloc and all that other stuff). There could even be a windowDidClose method so that app makers could dealloc all the UI stuff, but leave any syncing or any critical processes running as long as possible.

Now this could lead to battery draining type apps, so it will probly never happen. And I get that. I just wonder if there weren't a way for it all to work somehow.

Sorry to not have posted for a few days, I broke the site. Well, actually, I just made it incredibly difficult to post new posts, but that's pretty much the same. My text engine (turbine) is what actually was "broke." Let me explain:

When I post text to this blog, turbine attempts to figure out what type of object I actually posted. Well, it does take some instruction to get it going at first. It was my instruction that pretty much killed it. See this commit for the simple fix.

It's really interesting writing your own publishing software. When it breaks it's usually your fault, which is mostly bad. But when it works, it's also your fault, which is always good :)