Last month I was in the Argentinian part of Patagonia on vacation. While in Ushuaia Arjan and I partook in a one-day trip to see penguins. The penguins were living on a small island that is part of a larger set of land that was once given by the Argentina government to a British settler. The government did this because they were afraid that Chile would claim their part of Tierra del Fuego if it was uninhabited. And since the settler was planning on going home giving him lots of land that nobody was using anyway was presumably thought as an easy way to keep him around. (He and now his descendants cannot ever sell the land under the agreement.) At some point a large batch of penguins settled on this land and his descendants now earn a lot of tourist money with them. Given that their main source of income used to be cattle and that most of the cattle died in an extreme winter, I guess they are lucky!

This started as a joke, but I thought I would share the additional thoughts I have anyway in an attempt to make my blog more "boeiend" (ask Krijn). A few of these tips are only valid under HTML5, but will work everywhere else too (e.g. in HTML4 or XHTML1). Because well, as you know, HTML5 actually reflects reality. Blah blah. (In the event you have no idea what I am talking about, this is a somewhat response to Optimizing HTML.)

1. <link rel="stylesheet" href="…" type="text/css"> — Nobody is using that type attribute. It is just sitting there making your link element less readable and makes it consume slightly more memory due to the additional attribute. You can do this right now as this is valid in all versions of HTML. Apart from the validator versions is a dead concept as far as HTML is concerned, but people seem to care about them. (And some even care enough about them to battle for introducing them in HTML5. Weird world.)

2. <style type="text/css"> — Same trick, different element. There is only one styling language for the Web in existence and that is CSS. Whenever we introduce a new one (if ever) we can start to use the type attribute. It is a waste of bandwidth and source code reading time to include it now. Then again, including the style element itself is hardly ever needed. Think again when you do it.

3. <script type="text/javascript"> — The only reason you ever want to include this attribute is if you want to specify a different JavaScript version. Indeed, you do not use the language attribute for this. However, you probably do not want to do that either since it is very much vendor-specific. You know, dragons and all. Having said that, to enable e.g. JavaScript 1.8 in Gecko you would use type="text/javascript;version=1.8".

   The type attribute can very often also be nuked from other elements, such as a and object (if your server configuration is correct). The cases mentioned above are just the most common (well, there is input of course, but it was already mentioned in the original post).

4. <link rel="shortcut icon"> — While this should actually be just type="icon" you can remove this element altogether by simply having a /favicon.ico resource. This will also reduce the amount of 404 traffic you get on your site; potentially substantially. Do not worry about the extension, you can put any file format there your browser supports and configure the Content-Type header appropriately using your server. If you have no idea how to do that let me tell you that it does not really matter anyway since browsers will sniff the MIME type of the resource regardless. Oooh, evil. Just avoid the HTTP gods and you should be safe. (Well-known locations are evil too, but we lost this battle.)

5. Trashing Trailing Slashes — Including the space usually in front of them, to be complete! Lots of people bought into the XHTML fad and end their tags with  /> rather than >. Besides that this is useless it takes up two more characters per element of which the only effect is that it increases the time (not noticeable though) that software will take to download and parse the document. The claim that everything is now consistently closed makes no sense since e.g. script does not accept this notation. You need to know exactly which elements do not have an end tag and if you already do why would you add cruft to their start tag? I know, I know, to please the XML gods. Pleasing the XML gods makes no sense in a HTML world. There.

The original post mentions anti-patterns as well. Let me give some contradictory advice. Please do replace em with i and strong with b. The resulting markup is likely more accurate. Especially with WYSIWYG software it is extremely unlikely they will be used correctly, but also because the notion spread that they are interchangeable with the sole difference being that strong and em are semantic a lot of misuse happened. When in doubt, use i and b. And in most other cases probably too. (Does anyone know if there is a plug-in for WordPress that fixes this?)

As a final "tip", if you do not care much for cross-browser compatibility you can get rid of <link rel="stylesheet"> entirely. Investigate id.annevankesteren.nl for details.

I had fun compiling this last year so I thought I would do it again now I am pretty sure I will not leave the country before it is 2010. This time it is in chronological order with duplicates removed, as far as I can remember anyway. I renamed it to places (rather than cities) mostly because of Greenland and Iceland, that deserve a mention, but in neither we stayed in a city long enough. Also added some annotations here and there.

• Oslo, Norway; I celebrated new year abroad
• Utrecht, the Netherlands; contrary to what some people believe, I actually do still live here
• Zeist, the Netherlands
• Tokyo, Japan; CSS WG, staying at Michael(tm)'s place was a lot of fun. Really want to go back to Tokyo. Hopefully in 2010.
• Nikkō, Japan; hiking around a lake in the snow, very much awesome
• Lisbon, Portugal
• Coimbra, Portugal
• Madrid, Spain
• Maraña, Spain; I love this place
• New York City, NY, United States
• Washington, D.C., United States
• Sophia Antipolis, France; CSS WG
• Antibes, France; also went to Italy and Monaco with Alex
• Copenhagen, Denmark; reboot11! Stayed at Mark's place, thanks!
• Greenland (camping/boat)
• Iceland (camping)
• Port de Couze, France; jumped off a bridge
• Linköping, Sweden; De Klomp for the win!
• Stockholm, Sweden
• Halmstad, Sweden; Opera's engineering seminar was held here. Went skinny dipping in the sea. Cold!
• Yosemite National Park, CA, United States; saw some big trees and hiked for twenty-five miles the day after we arrived in SFO. A little crazy, but a lot of fun too!
• San Francisco, CA, United States; Halloween!
• Santa Clara, CA, United States; W3C meeting time, lots of fun meeting friends again, though quite exhausting too.
• Rio de Janeiro, Brazil; this was an awesome visit, however short. Thanks a lot Patrick!
• São Paulo, Brazil; crazy road trip the night after I gave my presentation…
• Berlin, Germany
• Vienna, Austria

We are getting a little better at this iteration stuff. Opera 10 was released in September and now we are releasing the first public build of Opera 10.5. Yay Desktop Team! Philip was on vacation so the HTML5 media elements (i.e. video and audio) are not yet in, but CSS transformations and transitions are. Hopefully we get this to final soon as it is a major improvement not just in standards support, but also in usability and speed. (And also so we get to try it on Ubuntu!)

On The Official Google Blog: Open systems win. Fail.

Mark Pilgrim on IRC in a discussion about RDFa and Microdata: When people say "I want to extend HTML in arbitrary, private, and probably proprietary ways," the appropriate answer is "fuck you" Made me laugh.

I planned to post this way earlier but travel, jetlag, and a general feel that the entry was not quite finished got in the way. It seems to slow process on posting other things though so here it is.

I was somewhat disappointed by the lack of fights. The W3C did their part by providing us with popcorn and nachos, but none of the discussions about accessibility, distributed extensibility, extensions to host objects that cannot be implemented by ECMAScript directly, a language specification for HTML, et cetera went beyond polite discourse. Boring!

It is pretty clear we are reaching the end of the process. The specification no longer has major holes and the remaining issues are around differences of perspective on how certain issues need to be tackled. Of course, if at one point we decide to go the other way on one of these the outcome may be disruptive, but it does not seem all that likely.

The HTML WG did run again in unconference-style and the only thing I think we should here is gauge the level of interest in certain topics before giving them a one or half an hour slot. If there is just one person talking all the time it is not that interesting and we might as well have read an email outlining his position at some other point.

The Plenary Day was not that interesting this year. There was a Developer Day the next day, which was probably better, but I could not make it due to a conflict with the HTML WG meeting (labeled HTML5 WG by the W3C Team for unstated reasons). There was the recurring HTML5 and extensibility panel. Organized each year since 2007 to gather some thoughts on how to solve a problem of which it is not very clear what the problem actually is. The whole debate made me think about the Hitchhiker's Guide. The answer is XML namespaces, but what is the question? Admittedly the comparison with unicorns and ponies is a lot cuter and likely more accurate. Unicorns in particular dominated the entire TPAC "secret" backchannel (#unicorns on irc.w3.org:80). Actually, not just the backchannel, they appeared in Working Group meetings, questions, presentations, and editors are adding them to specifications. Lovely.

The problem with the Plenary Day is that there are three-hundred or so people in the room and at least half of them is not paying attention to what is happening. Running the whole thing in unconference-style (maybe even TPAC entirely as Hixie suggested) would probably be much more productive for most people. So while some people are debating WS-DeathStar in one room I could be having a great time discussing the intricacies of the CSSOM with just the people that care about it without having to bore anyone else or having to explain all the background information to the one person that was not prepared. I am not really persuaded that this would go against broadening your horizon because I would not really be following a discussion on WS-DeathStar anyway.

TPAC is supposed to be a place where groups with some overlap in interest can work together, but in practice it is only a subset of the groups that has a particular shared interest. Given that I think it is much more productive if only the subsets meet (and maybe report back) rather than having an additional thirty people in the room who could not care less and essentially just take up space that prevents the interested people from sitting closer together and communicating more directly. The uninterested can also take up a lot of time in the round for introductions. Furthermore, the uninterested could be the interested in a different room with a different topic.

Another thought I have had about TPAC for a while is that it might make sense to have such a meeting for all Working Groups of which the deliverables essentially evolve around Web browsers and Web authors. I realize not everyone is a fan of that characterization but when it comes down to it there are a few groups where implementations in Web browsers that can be used by Web authors are the primary goal. I.e. WebApps, HTML, CSS, Geolocation, SVG, and a few others. Having at least one event per year to coordinate on the direction of the Web Platform would be really good I think. (Come to think of it, also a good target for terrorists.)

During TPAC I discussed with various people how we should tackle CSS values within the CSSOM. I had sort of given up on this myself but it seems that in order to get rid of the current CSSValue interface and friends we need to find a suitable alternative. And we really want to get rid of those because they are super ugly. Ian pointed this out long ago though unfortunately only in Member-only space. I have since made it available publicly as CSSValue replacement proposal from Ian Hickson so everyone can take a look at it. Hopefully it is clear that Ian no longer stands behind everything that is stated there. In fact, it was more a proof of concept. Having said that, the idea of turning the attributes that currently return a string into some kind of object does have a certain appeal. And if we can make them behave almost identically to strings I think we can make it work. It would be pretty awesome if you can increase the pixel value of the left property using the following rather than using all kinds of string manipulation:

var ele = document.getElementsByTagName("div")[0]
ele.style.left.px++

Theoretically this model can actually work though once we are a little further in drafting the details of the proposal we do have to test it to make sure we are not going to break the Web because that would be bad. For instance, triple-equality checking for these special type of strings would no longer work.

Some noteworthy bits from the first two days during the WebApps WG (see the mailing list for further details):

• The XMLHttpRequest specification will go to Last Call again. Yay!
• We are removing the concept of multiple views and the default view. The members of the interfaces of DOM Level 2 Views will be supported forever of course. This was virtually not implemented at all and the implementation with limited support is removing it. On top of that a lot of the newly and DOM Level 0 APIs did not take the view concept into account so architecturally it already did not make a lot of sense.
• XMLHttpRequest Level 2 will define a FormData object which can be passed to the send() method. The FormData object will get a single method called append() which can be either passed a Blob or DOMString. After send() is invoked FormData is serialized as an multipart/form-data entity body.
• XMLHttpRequest Level 2 will get support for timeouts. I am not a big fan of this since I am afraid people will start using synchronous requests more while they really should not do that at all (except in Web Workers). If this turns out to be the case I do know who to blame (apart from myself for caving in) :-)