-
James Bennett: In pace requiescat
Another thoughtful piece of the demise of XHTML2.
Visit -
Jeremy Keith: Misunderstanding markup
Easily the best overview I’ve seen of XHTML, XHTML2, HTML5, and the related concerns for your typical standards-oriented front-end web developer. Bottom line: the death of XHTML2 and the move to HTML5 does not mean you lose all the things you love about XHTML 1 and 1.1. Relax, folks. It’ll be okay. :)
Visit -
Zeldman: XHTML WTF
After reading the comments on Jeffrey’s post, I’m surprised and a bit dismayed that people are shocked to hear XHTML2 is dead. It’s been dead for quite some time — just not officially so. As I’ve been saying for the past couple years, HTML5 is the way. XHTML was a nice way to get us all thinking about writing better code, and it helped the Web Standards movement by giving us something to latch onto, but it’s time to let it go, guys. Relax. It’ll be okay.
Visit -
django-html
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 -
James Bennett: Why HTML
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 -
Your markup validator
Your markup validator, whether it’s the one on the W3C site or one built into your favorite coding tool, is a debugging tool. It should be used as such. Its job is to find errors in your code, so that you can fix them (or at least be aware of them).
Your markup validator, whether it’s the one on the W3C site or one built into your favorite coding tool, is not a measuring stick for greatness. It’s not to be used on other people’s code for the purpose of pointing out their shortcomings as a markup coder so that you can make yourself feel better than them. The fact that your code passes a validator does not make it better than the next guy’s code. There is almost never a good reason for you to be validating someone else’s code. Usually, if you’re validating someone else’s code, it’s because you’re being an asshole.
More -
My ideology, from the mouth of another
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 -
It’s not the tool, it’s how you use it.
Today, as I was looking through the referrers for this site, I found a comment from my now-co-worker D. Keith Robinson, dated December 4th, 2003. A few excerpts from the comment:
MoreIt’s an age old debate. Flash vs. HTML vs. CSS — blah, blah, blah. I’ll hammer a few more nails into this dead horse if it’ll help get the message across. It’s not about the tool, it’s about what you do with it. … The problem usually is that some designer or developer latches on to a certain technology (it could be CSS, it could be Flash, it could be anything) and thereafter tries to solve every and all problems with it. … Flash is a tool, CSS is a tool. If you are working on the Web you’d probably want to have both in your “toolbox” and know how and when to use each. … A carpenter doesn’t try to build everything with a hammer, does he? Why should a Web designer be any different?
-
Andrew Rickman: CSS - Art or Science?
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 -
Peter Quinsey on The New Layers of Web Development
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 -
Tools do not a designer make
During the design roundtable at Webmaster Jam Session last weekend, I mentioned that I think employers often value knowledge of tools too much when it comes to hiring web designers. As I think about it more, I realize that it’s not just employers; there are probably thousands of people out there that call themselves “web designers” despite having no real understanding of the basics of design.
But employers’ focus on tools encourages this. Job descriptions far more often demand that potential employees know Photoshop, HTML, CSS, and JavaScript than than you know layout, color, typography, usability, and information architecture. This is really flawed thinking, in my mind.
More -
Daniel Mall and Shaun Inman: Cross-Pollination: Breeding a Better Web.
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 -
Gabe da Silveira on the myth of content and presentation separation
“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 -
Official Google Maps API Blog: Microformats in Google Maps
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 -
Jeremy Keith: Mashing up microformats
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 -
Particletree: Rediscovering the Button Element
I’ve always kind of wondered why the
buttonelement 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 -
Garrett Dimon: Coding for Content
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 -
Web Standards Creativity
-
Web Standards Creativity
-
Web Standards Creativity
-
Web Standards Creativity
-
Web Standards Creativity
-
Web Standards Creativity
-
Web Standards Creativity
-
Web Standards Creativity
-
Web Standards Creativity
-
Web Standards Creativity
-
Web Standards Creativity
-
Web Standards Creativity
-
Web Standards Creativity
-
Web Standards Creativity
-
Web Standards Creativity
-
Web Standards Creativity
-
Web Standards Creativity
-
Web Standards Creativity
-
Web Standards Creativity
-
Web Standards Creativity
-
Web Standards Creativity
-
Web 2.0 … Beyond E-text
A very cool video by Michael Wesch at K-State. A must-see.
Visit -
Andy Budd: HTML 4.5 Anyone?
A great post by Andy on how the web is outpacing (X)HTML and CSS development, and the current version of HTML doesn’t cut it for modern web app developers. The question is, what’s the solution? The WHATWG has a proposal, the W3 is looking at developing HTML further, and frameworks like Flex has a different approach to solving the problem entirely.
Visit
Jeff Croft
I’m a digital product designer and developer in Seattle, WA. I currently work with nGen Works, and recently co-founded Lendle, a Kindle book sharing service.
Some of my clients include Facebook, Microsoft, Yahoo!, Copious, The New York Review of Books, The Lawrence Journal-World, and the University of Washington.
I’ve authored two books on web and interactive design and spoken at dozens of conferences around the world.
Filter content
FeedItems tagged xhtml
By content type
FeedOther tags in these items
- webdesign 1070 (100%)
- design 858 (80%)
- webprogramming 531 (50%)
- django 437 (41%)
- humor 405 (38%)
- worldonline 337 (31%)
- css 309 (29%)
- video 197 (18%)
- webstandards 176 (16%)
- blog 129 (12%)
- javascript 127 (12%)
- ipod 112 (10%)
- personal 109 (10%)
- browsers 93 (9%)
- book 75 (7%)
- flash 72 (7%)
- userinterface 69 (6%)
- shauninman 61 (6%)
- jobs 60 (6%)
- html 59 (6%)
- jamesbennett 59 (6%)
- google 58 (5%)
- web2.0 50 (5%)
- presentation 45 (4%)
- rant 43 (4%)