WordPress mulls standardizing their HTML

I have believed for quite sometime that the blogging industry would benefit a great deal from standardizing its HTML in some way. I mean seriously - look at the blogs out there, almost all of them utilize one of just a hand full of layouts: a one, two or a three column variant. Yet why are there as many HTML structures as there are blogs? It just doesn't make any sense.

Dave Shea showed the world what we all doubted - that a single HTML layout can be used to create a huge variety of designs. We at Six Apart saw this potential and began to deploy a standardized HTML format to its products, and then joined the community in an effort to evangelize that HTML coding convention to produce over 147 different designs that all utilize the same HTML structure - and some of them are flat out amazing, and some may even make you think differently about the way a blog could be laid out.

I think it is excellent that WordPress is [finally] at least considering such a move - because if there is one thing that both Six Apart and WordPress communities have to benefit from is the ability to leverage the creativity of our respective communities.

Of course many will think that the designs available on different platforms is a differentiator for them, and insist on being closed with their designs. But doesn't that run counter to the heart of our products? WordPress is founded on the concept of openess; why should openess stop with code? Shouldn't it also extend to the world of design? Seems like theres an opportunity for WordPress to show some leadership and embrace the efforts by others and contribute to their evolution and enhancement so that the greatest number of people stand to benefit?

5 Comments

[...]why are there as many HTML structures as there are blogs? It just doesn't make any sense.

It makes total sense. But I see this as more a question of viewpoint. The code is just a symptom.

For a system with theme switching built into it, standardized and highly flexible markup is obviously ideal, and everything you say is absolutely true. But only for people who actually want themes. I think it's a safe bet that the development of StyleCatcher was a definite and direct influence on how (complicated) the new default MT templates turned out. Flexible markup generally means there's a lot of extra "stuff" [1], but they can be complicated because theoretically, nobody will be touching the markup, and it's at least partially intended for people who don't want to, anyway.

But the problem as I see it is that because MT has not until recently had any way of doing this(prior to StyleCatcher, the styles offered at the 6A site pretty much amounted to changing some colors in the default templates), the culture that's grown up around it is more inclined to just start over with custom code than mash a standard(and then-inadequate) template into shape. For those people, if all those new "inner" divs aren't actually doing something, they're clutter. They're not just going to leave them around in the future hope of applying someone else's stylesheet to their site, which they've already spent all this time customizing. I think this is part of why as far as I could tell, StyleCatcher got such a cool reception prior to the style contest. It's probably going to be some time before that gets reversed. And it's actually kind of surprising that it was never implemented for Wordpress.

[1] The Zen Garden's markup itself has a comment stating that in a "real-world" situation, it'd be much lighter. Also note the six completely meaningless "catch-all" divs at the end of the document.

I think it's a safe bet that the development of StyleCatcher was a definite and direct influence on how (complicated) the new default MT templates turned out.

I can see how one might think that, but as an insider I can say that the statement above is inaccurate. Style Catcher was built as a demonstration of how powerful and easy a purely CSS driven style can be. The most complicated part of Style Catcher is the javascript, the backend logic that actually makes it work is just a couple lines of code that simply installs a single CSS file. If StyleCatcher had to install HTML, CSS, Javascript and the like, then it would become a much more complicated plugin - both from a UI and backend perspective.

But let’s take a step back for a second.

First, Movable Type has a culture of template tweaking because its core user base skews more technical, and is more willing and able to make changes – indeed they actually like making these changes. And in some cases they have to make these changes. Why? Because an HTML design standard is not for everyone. No HTML standard we could devise could be suitable for every single design one might want to create. So in those cases where the standard we came up with is not adequate, people deviate from it and that is ok.

Therefore such a design standard doesn’t directly serve that audience, nor may it serve WordPress’ core audience as well - for the same reasons. But that doesn’t lessen the need for such a standard. But why?

To answer that question we must force ourselves to stop looking at this problem from the perspective of our existing customer base. If you were to combine MT’s and WP’s user bases they would still only account for a relatively small percentage of the potential market. One only has to look at the scale of MySpace to realize that. And when you think about that audience, you realize that most people don’t have time to tweak their HTML. Most people don’t want to. Most people don’t know how to. In fact most people just want to look at a thumbnail and say, “make my site look like that.”

This design standard is important to MT, not because it is a feature existing customers will use, but because of the markets it opens MT up to. Its important to Six Apart because it lowers the cost for all of our products to incorporate new designs. And that is true for any company adopting the “standard" - WordPress included.

Taking the perspective of a designer for a second, a widely adopted standard helps me because it gives me greater potential reach with any design I create. It also gives me a system in which to more accurately judge my CSS skills relative to other designers. And it gives me a more re-usable and portable framework from which I can more easily borrow and learn from others.

I'm honestly not so sure about the default template changes. Maybe it's less than I think in some ways, but I still have to observe that IfArchiveTypeEnabled didn't exist in the 3.1 series, and wouldn't make much sense except in a case where you have distributable themes and someone might still opt not to have monthly archives, say. That's another one of those cases where I said if I don't need something, I wouldn't make it a contingency, it just wouldn't exist. But I ultimately have to give in to your arguments there, for obvious reasons. (For what it's worth, I was initially baffled by IfArchiveTypeEnabled, because I just couldn't think of a reason anybody would ever do that. Related, I was also completely uninterested in Stylecatcher.)

I don't want to seem like I'm arguing against the desire for a design/template standard outright or trying to lock you into the habits of the current user base. But I do think that the need itself has to be framed as around those people who actually need or want it, which I think is what you were getting at just above, and I feel has been better accomplished in MT by making it a plugin(which I can remove grin) rather than core code. What I said probably had a bit more to do with the "not making sense" part of what I quoted than with the question of need, really. What I was musing about was more what I see as possible reasons for what I saw as the 6A standard's slow adoption, at least as regards MT/Stylecatcher. I think Wordpress will run into some of that, though not as much, since there's already a very well-established theming culture.

I agree with you wholeheartedly, Byrne. You know I do, we've talked at great lengths about this. But I think there is a kernel of truth in what Su is saying.

Movable Type (by 6A and ProNet's own admission) is geared for tech-heads. You have to know how to FTP, create MySQL databases and chmod to get it up and running. These people aren't going to be terribly intimidated by templates.

To put it another way, MT is made for customizing. It's what it does best. It's an app targeted for tinkering. So while I think a standardized template is a great necessity, I'm not sure MT is the best audience for "establishing" it. It would probably be better implemented in Vox, TypePad and LiveJournal where you have a huge number of people all doing the same thing. That's when standardization flourishes.

Great thought provoking article, though!

Jesse, Jesse, Jesse - I think we are all in violent agreement about MT's audience, and that a design standard may not be for everyone.

But it is important to start developing a perspective that embraces our less technical brethren. Certainly the people who sign up for Yahoo Small Business hosting are not as technical, nor are a number of the folks using MT through one of our many hosting partners. Those users don't need to know about MySQL, or chmod, or whathave you.

But if we want to bring MT to a broader audience then we need to start solving their problems. I am not suggesting this is a silver bullet - but I do think we need to start somewhere.

Leave a comment

what will you say?


Recent Comments

  • Jesse, Jesse, Jesse - I think we are all in violent agreement about MT's audience, and that a design standard may not be for everyone. But it is important to start developing a perspective that embraces our less technic...

  • I agree with you wholeheartedly, Byrne. You know I do, we've talked at great lengths about this. But I think there is a kernel of truth in what Su is saying. Movable Type (by 6A and ProNet's own admission) is geared f...

  • I'm honestly not so sure about the default template changes. Maybe it's less than I think in some ways, but I still have to observe that IfArchiveTypeEnabled didn't exist in the 3.1 series, and wouldn't make much sense e...

  • I think it's a safe bet that the development of StyleCatcher was a definite and direct influence on how (complicated) the new default MT templates turned out. I can see how one might think that, but as an insider I can ...

  • [...]why are there as many HTML structures as there are blogs? It just doesn't make any sense. It makes total sense. But I see this as more a question of viewpoint. The code is just a symptom. For a system with theme s...

Close