-
Slim - A Fast, Lightweight Template Engine for Ruby
Very cool-looking lightweight way to write HTML. Along the lines of Haml, but perhaps even simpler and cleaner. I dig it.
Visit -
On CSS preprocessors
Over the past couple of years, I’ve become a huge fan of Sass. It’s really the only way I write CSS now, and frankly, if anyone tried to make me write plain ol’ CSS I’d probably knee them straight in the taint.
But CSS preprocessors like Sass and LESS aren’t for everyone. At least not yet. There’s still a lot of resistance to them from the community. In fact, I resisted them for a long time, myself (here’s an old post from Nathan Borror’s blog where I outwardly hated on Sass). When you’re very comfortable with something, like many of us are with CSS, it’s hard to switch to doing it a different way.
More -
On the term “HTML5”
Yesterday, Jeffrey Zeldman linked up a very cool project entitled html5test.com. It’s very well-done, and incredibly useful. You should check it out.
Today, the always-insightful Tantek Çelik responded to Jeffrey’s post, accurately noting that many of the items the so-called “HTML5 Test” was checking are not actually part of the HTML5 specification at all (for example, Microdata, Geolocation, and more.) Tantek goes on to say, “We as a community that is learning/relearning/teaching all this stuff need to vigilantly clarify what’s what rather than calling things “HTML5? that are not actually HTML5.”
I say: Why?
More -
HTML5 Readiness
Very cool CSS-powered infographic by Paul Irish and Divya Manian.
Visit -
Jeremy Keith: The format of The Long Now
I’m sorry, but the idea of HTML as a universal data storage format is pretty ridiculous. If the “data” in question is blog posts, maybe. But what if your data is tables and tables of numbers? Or heaps of video? Or needs to represent complex relationships between objects? No serious company would ever attempt to store all of their data in HTML, and neither should you.
Visit -
When can I use…
Handy chart detailing “when you can use” various advanced web development techniques.
Visit -
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 -
Jeffrey Zeldman: Web Standards Test: Top 100 Sites
I still have a hard time seeing any good reason to ever validate someone else’s code, but I guess maybe research for a book is one. Still, I don’t understand the point of posting the results here. Jeffrey says himself, “If all the home pages of the top 100 sites were valid, it would not mean that the pages beneath the home page level were valid, nor would it prove that the sites were authored semantically,” and “nothing causal or predictive can be determined from these results.” I agree with him, and that begs the question: then why post it at all? Because I know enough about Zeldman himself, I am guessing the answer is simply, “I thought it was interesting,” but I’m afraid it feels like the point is simply to publicly praise some and berate others.
Visit -
The Skinny on Doctypes
I love this post of Dustin’s about how Google uses a shortened version of the
VisitDOCTYPEstring to save bytes, even though it makes a validator say their pages are invalid. I don’t personally get too worried about a few bytes, but that’s a Very Big Deal™ to Google, and this is a perfect example of what I mean by “use web standards and best practices when they make sense, and don’t when they don’t.” Here, they’ve found a better solution for them than the understood “best practice.” That’s awesome. -
Jina Bolton: Make it modular
More great thoughts on markup and CSS coding practices, this time from my homey J.B., who I am (apparently) doing a world tour with this month.
Visit -
Two thousand twenty two
Today, it was brought to my attention that HTML 5 Editor Ian Hickson, in an August 27 interview with TechRepublic outlined a timetable for the “new” spec, which began life back in 2003. Hixie suggests HTML 5 will reach the “Proposed Recommendation” stage sometime in 2022. Go ahead, read it again. It’s not a typo. Two thousand twenty two.
I immediately stopped reading. Didn’t even bother with the rest of the interview. Why? Because it just doesn’t matter. The whole concept of web standards, which I once strongly advocated for, has now become so incredibly ridiculous as to be not even worth the time and attention of serious web designers and developers.
As I pointed out on Twitter today (much to the dismay of certain standardistas, who have previously asked me to name names instead of referring to a “shadowy cabal”): it ultimately doesn’t matter if HTML 5 is available next month, next year, or fifty years from now. Those of us who do real work in this industry know that the only thing that really matters is what specs and technologies are supported by the browsers real people use.
More -
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 -
Authentic Jobs: Bainbridge Studios, Seattle: Web/Interface Designers
Bainbridge, a small studio here in Seattle, is looking for freelancers to do both web design (potentially with HTML/CSS work) and [Flash development[(http://www.authenticjobs.com/jobs/1576).
Visit -
A List Apart: A Preview of HTML 5
Lachlan Hunt has a nice introduction to HTML 5 over at ALA. At this point, I’m pretty much convinced that HTML 5 is the future of our medium (not XHTML). If you’re not up on the latest good, give this article a read.
Visit -
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 -
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 -
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 -
New elements in HTML 5
Sometime, probably around July of 2017, we’ll be able to use all this cool stuff. I’m really looking forward to it.
Visit -
I’ve joined the Vitamin advisory board.
Carson Systems’ Vitamin asked me to join their Advisory Board, and I jumped at the chance. I’ll be helping them “determine what’s important in the web industry today, what topics we should cover, which products we should review and who should be our next interview.” James Archer and Jina Bolton are also new board members.
Visit -
On separation of content and presentation…
“Separation of content and presentation is a continuum, not a binary proposition, and only begins with clean HTML and CSS.”
I really hate it when someone manages to say everything I was trying to say more succinctly and elegantly than I every could have. :)
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 -
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
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 html
By content type
FeedOther tags in these items
- webdesign 1068 (100%)
- jeffcroft 1048 (98%)
- design 857 (80%)
- webprogramming 531 (50%)
- django 437 (41%)
- humor 405 (38%)
- worldonline 337 (32%)
- css 309 (29%)
- business 225 (21%)
- video 197 (18%)
- webstandards 175 (16%)
- jinabolton 133 (12%)
- blog 129 (12%)
- javascript 127 (12%)
- browsers 93 (9%)
- microsoft 89 (8%)
- xhtml 86 (8%)
- book 75 (7%)
- flash 72 (7%)
- tips 64 (6%)
- shauninman 61 (6%)
- jamesbennett 59 (6%)
- google 58 (5%)
- ruby 53 (5%)
- web2.0 50 (5%)