Handy bits by Simon Willison to make Django work a little cleaner when using forms with an HTML doctype (instead of XHTML). Personally, I think Django should default to HTML, but I bet this matter was argued ad nasuem in some Google Groups thread a year ago and XHTML won out (almost certainly at the chagrin of James Bennett). Am I right? Am I? :) Visit site »
James makes the case for choosing HTML over XHTML. He makes several good points, but overlooks what is, to me, the single biggest reason to use HTML: because HTML is clearly the future, not XHTML. Today, the choice is mostly arbitrary. In my opinion, neither markup language offers significant advantages or disadvantages compared to the other. But, it’s clear (at least to me) that HTML5 is where things are going, so stepping away from XHTML now may better prepare you for the future.
That having been said, I still keep using XHTML out of habit, even if I think HTML is the better choice. :) Visit site »
May 22nd, 2008–May 23rd, 2008 in San Francisco, CA
October 30th, 2007, 6 PM in Seattle, WA
Jon’s post is really good and worth reading, but I’m actually linking to Joe Clark’s comment on it, in which he states, “Jeff is getting craftier at restating his ‘Real code isn’t all that important’ ideology.” I’m not quite sure what “real code” means, but I found it amusing to hear Joe put words in my mouth.
Since I don’t know what he means by “real code,” I can’t speak to whether or not he’s accurately paraphrasing my thoughts. The only code I can call myself any kind of expert on is HTML and CSS, and in the case of those, my only “ideology” is to write clean code that is as semantic as possible (in the case of HTML) and as valid as possible within the constraints of a given project (budget, timeframe, etc.). I can only presume this is what Joe’s referring to. Visit site »
Andrew details each side of the issue I bought up in my latest bog post. HTML and CSS as an art or specialized craft, wherein the code becomes as important as the site made from it:
…given proper thought, a website can be as elegent [sic] in code as it is graphically. It is a concept of precision engineering, as opposed to plain good engineering.
And HTML/CSS as a science, or as the “raw materials” for the site being built, and not an end product in and of itself:
Whatever you think of html and css that fact remains that it exists solely as a way to present data. It is a tool to achieve a good outcome and not an outcome in itself. [snip] This is very much the view that seeks to avoid making perfect the enemey of good enough, and as such is something of a common sense approach.
I think Andrew does a really nice job of explaining both sides to this discussion without showing bias towards one or the other. Visit site »
THis is a very well-written and thoughtful rebuttal to my post, The New Layers of Web Development. However, the rebuttal was unnecessary, because I actually agree with everything Peter says here. He basically says that it’s still important for your (X)HTML markup to be structurally sound, because the World Wide Web doesn’t know (or care) about your database — it only knows about your markup. It’s a very good point, but it’s not at all in contradiction to my post. I, of course, believe that your markup should be as structurally sound as possible. I just believe that that structure begins at the database level, not at the markup level. It is replicated, and sometimes even enhanced at the markup level — but in a typical modern web app, the One True Source™ for structure is the database, not the markup. This is important especially in our multi-contextual web. The (X)HTML markup can bee seen as contextual structure. In other context — say, RSS or mobile or e-mail —the contextual structure of the same data may be different, but the core structure of the content remains. I definitely have more thoughts on this topic after the great discussion; I’ll get to them eventually. Visit site »
Even though I don’t like the crowd-sourcing, I”m still not above suggesting everyone go and vote for this panel. I’d love to see it, myself! Visit site »
“I find it shocking how some people take it to the extreme of total semantic purity. Presentational semantics are not an oxymoron—in fact they are a critical part of the web.” Exactly. This person really understood what I was getting at in my latest post. Visit site »
I say: “Cool, now tell me how this benefits my Mom.” In other words, I say the same thing I’ve been saying about Microformats for a year now: they’re cool, but until someone builds some consumers of Microformats, they’re basically just geek masturbation. Please, someone do something useful with Microformats that affects people who respond to the words “Firefox” and “extension” with a blank stare. Visit site »
Jeremy has a nice post on how you can intermix microformats, rather than creating new ones or extending existing ones. For example, rather than adding a “date of death” field to hCard, why not mark something up as both an hCard and an hCalendar event — the hCard comtains all the person details, and the event (the person’s life) has a start an end date. No need for a “date of death” field. Jeremy’s got other smart examples, too.
Because I sometimes I get asked about my feelings on microformats (people have noticed that I don’t ever really talk about them), here they are:
Microformats are a very good idea, and they can do no harm. They’re just regular, semantic HTML, so implementing them is easy and non-controversial in my mind. However, I don’t feel like they currently add much value, because there are so few useful tools for consuming them. Yes, I know there are Firefox extensions and such — but where are the microformat tools that are going to benefit my Mom or my Grandma? Also, I sometimes wonder why one wouldn’t simply add a read-only REST API to their site, instead of encoding everything in microformats. It seems simpler and less fragile to me.
So, bottom line: I haven’t gotten into microformats much myself. Not because I don’t think they’re a good idea. In theory, they are. But more because I haven’t seen a lot of real-world benefit to taking the time — yet. The flip side is that the time I would have to take is pretty minimal, and implementing them on my sites could do no harm (even if I don’t think it would do much good, either). Visit site »
I’ve always kind of wondered why the button element never really caught on. I suspect it's because people don't want to write the JavaScript hooks to actually make their buttons work (input type="submit" submits a form by default, no JavaScript needed).
After this article, I’m definitely thinking about using it more often. Visit site »
Garrett covers a “markup framework” he created for marking up the figures in his blog posts. His markup is very similar, in many ways, to what I do here, and what we do on our Ellington-powered news sites. Garrett’s is a bit cleaner than mine, though — I may be stealing some of these ideas. :) Visit site »