It’s just data

XHTML, as practiced

Tim Berners Lee: The attempt to get the world to switch to XML, including quotes around attribute values and slashes in empty tags and namespaces all at once didn’t work.

Nor, apparently, did the attempt to get people to separate attribute names and attribute values with an equal sign as Firefox, IE, and Opera all display this blog entry just fine.  (Can somebody test this for me in Safari?)

This common behavior isn’t reflected in the WHATWG draft.

I am growing increasingly of the belief that one of the ramifications of driving towards “Radical Simplification” is that one must plan for, and accommodate, those that use simple text editors and templates.


Rather, I am of the belief that words (like MUST) mean nothing unless you can shoot traitors.

Being highly visual, I think of standards as flags waved in battlefields and, since we can’t do anything about those who bolt from the battle line for whatever reasons, more than mere words is necessary to win battles.

Posted by Don Park at

No, the GRDDL ‘link’ doesn’t do anything in Safari.

Posted by Malcolm Rowe at

Hmm, my version of Firefox (1.5.0.7) does seem to display it right, but the link leads to the breadcrumbs home page, not the GRRDL page.

Safari does show it as a link, but it doesn’t have hover effect and doesn’t work.

Posted by Morten Frederiksen at

While no browser fails to render the page (why would they, since all the talk from Microsoft and Netscape about wanting XML so they would have brutal error handling was just that, talk), I don’t quite see how to describe that as “just fine” - of the things I’ve got within arm’s reach, Firefox (which, btw, is the only thing in the Moz universe which doesn’t have any InterCaps) produces a working link to the page’s base href, while Safari and IE6 produce something with the appearance of a link but not the behavior, so apparently we treat it as an hrefless href link, and they treat it as a nameless name anchor. Seems to me like a fine example of how, if you want to render error-filled things, you have to specify error recovery, in all its trillions of possible permutations.

Posted by Phil Ringnalda at

Once again, my slow and distracted comment typing style makes me wish your comment preview page also previewed the current state of the other comments. How often do I do that here, half the time? More?

Posted by Phil Ringnalda at

Always worth the wait, Phil ....

Posted by Jacques Distler at

Looks fine in Safari.

Posted by Robert Sayre at

I am growing increasingly of the belief that one of the ramifications of driving towards “Radical Simplification” is that one must plan for, and accommodate, those that use simple text editors and templates.

The page in question was generated by a CMS (though the input may, indeed, have been cut and pasted from a simple text editor). What sort of “accommodation” should (have) be(en) made here?

1. Should the text editor have done syntax-colouring, which might have highlighted the fact that the link was broken?
2. Should the CMS have refused to permit invalid input?
3. Should interpolation of missing “=” signs on attributes be part of standard browser error correction?
4. Should browsers attempt to correct spelling (herf="" to href="") as well? (Etc...)

One purported solution (send the page over the wire with an XML MIME-type, and hope someone notices the problem) is, we’re all agreed, not the solution. But what is?

Posted by Jacques Distler at

But what is?

[link] seems like a good place to start.

Posted by Mark at

One purported solution (send the page over the wire with an XML MIME-type, and hope someone notices the problem) is, we’re all agreed, not the solution.

That particular solution has certainly motivated me to fix quite a number of edge cases in my CMS, and in Planet.

While I would not say that that solution is for everyone, I dare say that it would have worked for T-BL.

Posted by Sam Ruby at

While I would not say that that solution is for everyone, I dare say that it would have worked for T-BL.

I daresay that, unless T-BL is, like you, in a position to fix his CMS, that solution probably would not work for him.

You now have a lot of experience post-processing random junk into well-formed XML. What should (for argument’s sake) T-BL’s CMS have done when it encountered the input in question?

1. Spit out a well-formedness error message?
2. Used Beautiful Soup to post-process the input into something well-formed (if not, necessarily, what T-BL intended)?
3. Something else?

Posted by Jacques Distler at

2/3 seem sensible: convert to valid markup on the server-side.  When the HTML5 algorithm is done, you could use that, and then at least you’d have a standardised way to deal with malformed markup at the server-side.

Posted by Andrew Sidwell at

Appears to be fixed : [link]

“hope someone notices the problem” - or bring it to their attention : [link]

Posted by Danny at

If there is a genuinely interoperable behavior that is not covered by the WHATWG/HTML5 spec, please submit it to the mailing list. Whatever your view of the correct approach to markup and validity, having a well specified algorithm for turning real world web pages into a DOM tree (which can be reserialized as XML if needed) can only be a good thing.

Posted by jgraham at

Rounded Corners - 54

Bring back the people. Tim Berners Lee is planning a new future for HTML, away from XHTML 2.0. It promises to bring HTML back to the people, and bring the people back to HTML. Either way, simple is good. It doesn’t have to be radical, it just...

Excerpt from Labnotes at

Links - 11.01.2006

IT Architecture - The Usual Suspects Maybe no architect is better than a bad architect. Does Writing Code Matter? Why do people talk down to their compiler? Business versus Technical Solutions I don’t see any value in distinguishing between...

Excerpt from discipline and punish at

Add your comment