View source

Sterling Hughes: If you had ever browsed an early HTML document, you could look at it, and figure it out. Moreover, you could save it to a file, play around with it, change it, etc. You could steal code from other sites and use their tricks, so by the time you read the HTML specification, you already knew HTML.

Do me a favor.  View source on my weblog.  It is valid XHTML 1.0 strict.  And valid CSS.

And don't ever underestimate HTML's usage as an input format.


View Source

Sam Ruby writes, "Do me a favor. View source on my weblog. It is valid XHTML 1.0 strict. And valid CSS. And don't ever underestimate HTML's usage as an input format." I don't think I'm underestimating it. It is important, and its cool to boot. But... [more]

Trackback from Sterling Hughes at


flaminCSS

Dave Winer, in a follow up to his recent CSS problems: I used to work reasonably well with designers until CSS came along. Now my writing is supposed to be a soldier in the fight for Web "standards." Help. My work has to look great in MSIE, and I ...

Pingback from Simon Willison: Archive for 20th April 2003 at

Sam, come on. If someone with only HTML experience uses your XHTML as starting point, and makes one change, he's going to get an invalid XML error. And there's no way he can understand from reading the source what he has done wrong.

Posted by Sjoerd Visscher at


Sjoerd: not unless they also change the MIME type...

Familarity with XML is a prereq for a number of formats, like RSS, for example.

Posted by Sam Ruby at

I'm not as familiar with this stuff as I'd like-ta be, and have avoided commenting on specifics for that reason.

But, from what I have seen, the diagnostic messages and debugging aids are far, far less than what You'd find for almost any other programming language.  Do I sit corrected?

(And mebbe I'm just used to better, which is not *nix.)

Posted by jt at

So, Sterling first has to learn XML, and then look at your source. That kind of proofs his point, doesn't it?

Posted by Sjoerd Visscher at

The truth ofcourse is that you couldn't learn HTML from looking at the source alone. At least not valid HTML.

However, you could get a working webpage. But whether this is a good thing...

Posted by Sjoerd Visscher at

Sjoerd, I disagree with that "truth".  Bear with me a moment.

It is clear from looking at the web that most people "learn" RSS by copying.  And I will contend that that is the way that most people "learn" HTML the same way.

I learned SOAP by looking at wire traces.  WSDL by using "?wsdl" in ASP.Net.

The next step for most people isn't to reach for the manual, but to see what works.  The next step is to try a validator.  That's why I worked with Mark to write one for RSS.

My experience is that only when faced with a specific and tangible problem do people reach for the specification.

Posted by Sam Ruby at

Right. And for that to work, you have to have a validator that gives very good error messages. Recently a friend of mine tried to make his weblog html valid.

He got an error: P close tag found, with no matching open tag. Yet the open tag was clearly there.

But the P contained a UL, which automatically closes the P before it.

It even hard to find the problem in the spec.

If creating valid HTML is just a nice sunday afternoon pastime, then you're just going to give up.

Posted by Sjoerd Visscher at

Sjoerd: you just identified a case where the XHTML validator provides much better information than a simple HTML validation can.

I learned a lot about HTML when I decided to make my site XHTML.

Posted by Sam Ruby at

Sam, RSS is a different beast.  First its usually a very small document.  Second it has a very specific purpose.  Finally, its a wire protocol.

I know XML and I know XHTML (and I "understand" css, while I don't know the all the tags).  The problem is that XML takes thought to get right.  Escaping proper attributes, proper ending tags, proper encoding sets, etc.  These rulesets make it great for data interchange, but for publishing (and personal publishing) they make it more work than necessary.

Deadline is Monday, I'm rapidly producing HTML along with my code.  The chances that it will be valid XML?  Slim to none.  First handcoding a data format is something you rarely get right on the first try (unless its very loose and forgiving).  Second, CSS is all about positioning, tables are all about formatting.  Formatting content is much easier, and requires much less forethought.  Finally, mozilla and IE will take my HTML 3.2/4.0 markup, so why be pedantic about the semantic?

Perhaps CSS based layouts are better, their proponents seem to think so.  It may be more elegant, smaller, sexier, but it's not *easier.*  And that's what its all about for me, the easiest/fastest tool for the job.

Also, I'm not saying CSS and XHTML with fancy divs, etc. have no purpose either.  When you have a site that's very position oriented, then CSS is a godsend, I'm sure.  But why deprecate tables and friends, when they are (imo) equally useful for other layouts?

Posted by Sterling Hughes at

Despite the coherent look and feel of my site, it is controlled by a ragtag collection of half a dozen different systems.  I have several separate Movable Type weblogs site up, one for the main weblog, one for the projects, one for the 100.  The photo galleries are generated by a homegrown script.  The Safari CSS hacks pages are generated by another.  The main Safari page is handcoded.  There is no one CMS available that does everything I want to do on my site; I use a best-of-breed approach and glue the pieces together myself.

I recently redesigned my entire site.  I don't know if you saw the previous version, but it was very minimalist layout, with the big Orb O' Zen on the side.  No section-specific colored headers, no tabs.  Search box at the very bottom of the page.  About the only thing the designs had in common was the breadcrumbs along the top.

You know how many files I changed during my redesign?  One: my CSS file.  My markup didn't change at all.  I have 4000 pages of clean HTML markup, generated by half a dozen separate systems, and I didn't have to touch a single one of them.

If you think tables are simpler, use them.  Enjoy your redesign.

Posted by Mark at

Sterling, I didn't say anything about deprecating tables.  You said that CSS required a PhD in computer science to hack together.  I use both as appropriate.  It seems to me that you are the one who advocates deprecating somthing.

Also: HTML and CSS are wire formats.

Posted by Sam Ruby at

One CSS File to Rule Them All

Here's an informative comment from Mark in Sam Ruby's blog, emphasis mine: Despite the coherent look and feel of my site, it is controlled by a ragtag collection of half a dozen different systems.  I have several separate Movable Type weblogs...

Excerpt from Matt Croydon::postneo at

Add your comment












Nav Bar