David:
This microformat malarkey seems to be taking off. Perhaps it is time I moved contact details over to it.
There are a number of tools that make use of the format, including a couple of Firefox extensions such as Tails Export. Time I took a closer look at these too.
ats:
So, uh.
Why does anyone think that "microformats" are a good idea?
They're a complete and obvious abuse of HTML for something it's not intended for.
There are at least two more appropriate container formats for doing this sort of thing (RDF and XML).
They're even less human-manipulatable than XML. They're not semantically clean. They don't render properly in browsers that don't do CSS.
They can't even be manipulated programmatically in a clean way without jumping through hoops to know which things are encoded as sort-of-but-not-really-appropriate HTML elements.
And the "popular" microformats are simply incompatible reinventions of existing well-established formats.
There's also no attempt at namespacing -- something that XML cares deeply about. If I'm using two different microformats that both talk about URLs, their "url" classes will collide.
David:
I haven't looked closely at them yet, but since there is a lot of buzz, I figure that they are at least worth a look.
There's no doubt, in my mind, that XML namespaces are a far better solution to the issue. The only advantage of microformats is that they play nicely with legacy user agents (like the oh too commonly used Microsoft Internet Explorer).
If you're going to put an address on a webpage, then I don't see much of a problem with using class names that match up with those used by lots of other people.
The HTML elements used might not be ideal, but HTML doesn't have ideal elements for that data. This is one of the reasons we have classes in HTML in the first place - to mark up an element as being a member of a larger group for styling/scripting/etc.
The advantage of hCard and vCard being conversions of another format into HTML is that it is easy for software to convert them into that standard format, which is then usable by lots of other software packages.
ats:
I don't have a problem with defining standard class names for HTML markup, except in that it's a workaround for a spec that doesn't handle new elements gracefully.
I do have a problem with person A defining "url" as a class, and person B defining "url" as a class, and them meaning different things.
But I don't buy the argument about microformats making data easier to work with.
I don't see why encoding it into HTML -- HTML that has no meaning to the sort of user agents that are usually designed to process HTML -- is useful to anybody.
And HTML for general-purpose structured data is not in any way a standard format. HTML is a hypertext markup language, not anything else.
David:
It does seem relatively pointless, and limited almost entirely to firefox extensions (although the amount that people talk about it, you'd think that everyone used supporting clients), but it doesn't seem to do any harm either.
As for namespacing (and we're back in the realm of assumptions here). I was looking at the hCard format earlier and it contained all the elements in an element with the class "vcard".
This suggests that some form of namespacing exists (at least until someone uses foo as a type of data and someone else uses foo as a namespace)
ats: That's not good enough -- I might use "vcard" as a class in existing HTML, I can't select all the class="url" elements using XPath without needing to qualify with "contained inside class="vcard"", I can't nest something else inside that...
David:
Yes, hence "some form". It certainly isn't very good.
I do so love "standards" that haven't gone through a group that is pretty good at spotting problems.
(Although I'm not sure that's the HTML Working Group these days.)
David:
I've been looking at JS more and more of late. This cropped up in my RSS feeds a few days ago, and it is an excellent resource.
I've only read one of the mentioned books (the Definitive Guide), and it is the language Bible. Every JS programmer should have access to a copy.
As for the videos, I've only found time to watch the first of them so far, but I learned a few tricks from it (and this is part one of a JS introduction, hardly deep stuff). It is surprising how much gets missed out when you just pick things up as you go along.
The wesbites have some good stuff in there too. The Mozilla Development Centre is my first port of call when I want to look up a JS or DOM function/keyword/whatever.
I'm rather more dubious about the reference to W3Schools though. I haven't really looked at their JS section, but when it comes to HTML and CSS they are worse then awful.
Still, it is a good list of resources.
ats: Excellent. The migration is proceeding as planned.
David: The super-lasers are due on Tuesday
ats: "KDE has relied on autotools to build most of the project since its inception, but for the last year, KDE 4 has been building with CMake, a newer build system that is rapidly becoming a heavyweight contender in the world of buildsystems."
Regular readers of Us-Lot Log may remember my previous assessment of CMake.
David: Yes. I groaned when I saw that popup somewhere (I think it was LWN)
ats: It appears it hasn't improved a lot since September; see the KDE wiki page on CMake.
The syntax is absolutely horrific. I don't understand how it's possible for people to get away with that sort of thing these days.
Two of my complaints do seem to have been dealt with, though: you can use -D to specify build options, and VERBOSE=1 to get commands printed while building. Those'll be useful for GARstow.