According to HTML5 spec, every attribute that starts with data- should be ignored by browser and considered a data needed for some scripts. For example:

<ul data-sortable="yes">…</ul>

Does it remind you of something? It is a simplified version of XML namespaces, but limited to non-hierarchical data and with much more probability of data clash.

John Resig, in the comments to his blog post on the matter, says that “The learning curve and failure rate are too high to purely XML-based markup, which is why the data-* attribute exists as a means to implementing this solution”. I completely disagree with the learning curve argument, and this is why:

Programming is complex.

It is easy to forget about the complexity while doing smart new stuff. And new cool things is not what I am talking about. Inventing new thing is easy, since you do not have to think about all limitations of the new ones. Making them work for all occasions, that is what is complex.

It is easy to praise HTML5 over XHTML. It is easy to praise microformats.

But all standards are here for a reason. It is easy to punch Microsoft, however first versions of Google’s Picasa didn’t support non-English text in labels, at all. Current version of Adobe Buzzword does not support Russian text. Current versions of Picasa and Opera do not support Drag&Drop outside of application. I have never seen any of such problems in MS applications. In fact, Visual Basic supported Unicode for ages, while relatively modern web languages stumble on it.

I have already blogged about microformats being a hack. And now I read about BBC removing microformats support due to problems with screen readers and semantics of abbr tag. Is it easy to remember that screen readers must be supported? No. Is it a shiny 2.0 kind-of-thing to think about them? No. But it is one of the multiple things you have to think about when making a wide-used standard.

Adding easy solutions when possible is a great thing. But it wrong to think of programmers as people who can only work with easy solutions. Flexibility is much more important than ease of use, and that’s the lesson that produced, for example, ASP.NET MVC. Also, easy ways should exists as shortcuts for flexible ones, not be orthogonal to them.

And while HTML may be about design, and text processing, and other things, data-* is about programming.

This may belong to Twitter.

1. Comic — nicely done, but how about some good words for work of other people (especially when influenced by it)?

   IE8

   • Process per tab
   • Private mode
   • Emphasis of domain name in the address bar

   Opera

   • Search shortcuts
   • Speed dial (but Google improved it)
   • Tabs on top of address bar (which is the sane way to do it)

   Firefox

   • Search/address bar 
   • JavaScript JIT (Firefox 3.1)

   I understand why Microsoft is not saying “just like Firefox”, however a lot of Google PR is about being friendly.

   Also, I was a bit surprised by the multiple references to tab crashes not crashing the application. Does somebody really encounter often tab crashes? Opera crashes in extremely rare cases, and it is possible to restore a session anyway.

2. Future? I still use Google Talk (and converted a lot of people), but it seems no one at Google cares anymore. There are at least three different Google Talk editions, with unrelated features (Labs Edition supports text conferencing, but not file sending).

   So it is interesting if Google is going to support Chrome if it does not get significant popularity. It is open-source, however, so my concerns may not prove important.

3. Process explorer is a fabulous feature, a must have for every other browser. However, aside from that, a good JavaScript debugger is important.

4. Chrome is a bit of a performance hog, not sure how it compares to Firefox, but it is definitely heavier than Opera, especially CPU-wise.

5. Not exactly Chrome-related, but why people seem to want a relational database in the browser (Gears, HTML5)? JavaScript structures are already extremely usable and easy to work with. They also abstract fast searching (hashes). Why not use a JSON storage stored in a browser-specific way, instead of putting SQL specification into HTML?

In general, Chrome may replace Opera for me, depends on how well it works with saved passwords (Firefox is way worse than Opera’s Wand), gestures and its overall performance.

There are several annoying design flaws I often stumble into in .NET APIs.
I haven’t seen Design Guidelines on this matter, so I think I’ll point to 3 of these myself.

1. The Generic Sin

   Do provide a non-generic overloads to generic utility methods.
   Ayende already wrote about it, so it does not make sense to repeat the reasons.
   Fortunately, this is a very rare issue.

   Violating framework: Castle.MicroKernel (DefaultKernel.ResolveServices<T>).

2. The Sin of Shallow Digging

   Do support non-public members when performing type/member discovery.
   Do not ever use Assembly.GetExportedTypes unless this logic can easily be overriden.

   For example, I like to make my Domain Service interfaces public, but keep implementations internal.
   This means that if I use InternalsVisibleTo, I can unit-test implementations, but the clients must use interfaces.
   But if I try to define a common generic test base class, and use it like XTest : TestBase<X>, then if X is internal XTest should also be.
   Now neither MbUnit or TestDriven.Net see my test, regardless of TestFixture attribute.

   So if you use attributes to discover members automatically, the only reason to discard a member should be the absense of an attribute.
   Access modifiers should not be considered, if the member does have an attribute.

   Violating frameworks: MbUnit, Castle.Facilities.BatchRegistration.

3. The Sin of Tivoization

   For each public interface you create, think how user can inject his own implementation.
   (If this interface is directly consumed by API public methods, you can skip this step).

   For example, let’s look at an interface MbUnit.Core.IFixtureFactory.
   It is public, which seems good enough for people who hate internals.
   But it is not possible to provide your implementation without wrapping the whole test-running engine.

   It’s a pity. The framework I am developing right now would really benefit from it.

   Violating frameworks: MbUnit.

I really like what is happening to Web.

Cool-new-ajaxy sites are often actually more friendly, useful and powerful.
Web development seem to become way less hacky.
And a lot of standards that are gaining adoption are actually extremely useful (think about RSS).

But there is a group of new standards that I fail to understand.
They are called microformats.

In my understanding, there are three pillars of Ideal Web:

1. Markup provides semantics
2. Styles provide presentation
3. Scripts provide behavior

These blocks are logical, understandable, maintanable and loosely coupled.
It is worth noting that all strict DTDs are here to make the markup truly semantic and help achieve such separation.
This is why I write <strong> instead of <b>.
And this is what helps Web 2.0 applications to be really rich without being messy.

And for me, microformats are viral semantics.
They infect markup and overload it with additional meaning, turning it into an ill, bloated mess.
The microformats wiki states:

Reuse the schema (names, objects, properties, values, types, hierarchies, constraints) as much as possible from pre-existing, established, well-supported standards by reference

For me it seems more honest to say overuse, since the most interesting thing about microformats is that there are no actual problems they solve.
Consider this fragment:

<span class="tel"><span class="type">Home</span> (<span class="type">pref</span>erred):
  <span class="value">+1.415.555.1212</span>
</span>

I would prefer:

<tel><type>Home</type>(<type>pref</type>erred):
   <value>+1.415.555.1212</value>
</tel>

Now it does not seem that somebody is reusing iron to hammer nails.

It is 2007. XML is here and it is supported. X in XHTML stands for extensible.
IE did not support CSS namespaces, but you could write styles like vcard\:tel for years.
And this syntax does not seem like a show stopper to me.

Actually, upon reading on topic, I immediatelly googled for “microformats are stupid”.
The first thing I found was Why I Hate Microformats? by Robert Cooper.
He points to the same things I do, but he misses the fact that we had no need to wait for the IE7.

There is also a more interesting post Must Ignore vs. Microformats by Elliotte Rusty Harold.
The one point I do not agree is that Elliotte argues that XML does not have to be valid.
I do not see why the properly namespaced XML in XHTML would not be valid, but I will have to test it myself.

Web would be better if microformat authors read more about XHTML and did some browser tests before pushing this standard.