pre considered harmful
Dorothea says that using the HTML <pre> element to display formatted code in weblog posts is a bad idea. She’s right: since a <pre> line can’t be broken, everything else in the page has to break, and break it will; floats will float down to the bottom of the page, things will overlay the code, and it will all fall apart. If you don’t see a problem, it just means your browser window is too wide.
Then she suggests that instead you use font-family: monospace and, if you must, non-breaking spaces for indentation. Oops, considered harmful. That’s the way I used to display code that I intended people to copy and paste, until I finally realized why so many people were having trouble with my code. Apparently at least in some browsers on some platforms with some systems (you try getting the details of a problem out of someone after you’ve already told them the solution), gets copied and pasted as some character other than a simple space, and so when you tell people to “copy this and paste it in your Blogger template”, you end up having to look at their page source and explain that javascript won’t work if it’s being published as
if (foo){
??if (baz){
????doSomething();
??}
}
The solution? I’m not sure. I got distracted by the shocking news that RadioUserland apparently still has its double-decoding of HTML entities bug which causes perfectly correctly encoded code, intended for display, to be interpreted by the browser instead, so that if you post an example of the sort of javascript that will cause someone’s page to redirect to goatse.cx, in a Radio.Userland user’s aggregator the page actually will redirect, and will continue to until they unsubscribe from your feed. That bug can’t really still be around, can it? Surely he just hasn’t updated Radio.root since last March? Tell me that’s it, please.
Good point. I suppose the cure is not to ask people to cut-and-paste — put the code in a separate file, link to that, and then do it up pretty for display on the blog.
Which is annoying as all get-out. There’s got to be a better way. Hmmm.
Phil & Dorothea:
How about using
<code style='white-space: pre; font-family: monospace'>
// Your code goes here
</code>
I think it’ll work ok, with no problems. I don’t think
<pre>
is harmful, but if the page breaks, also means that you’re writing a very long line in your HTML. AFAIK<code>
will not break the page, I’ve made a test in a local page and it breaks between lines, but doesn’t break my style.CSS white-space property: more info
Regards, inkel
PS: excuse my english, I’m from Argentina
I’m all up-to-date on radio.root, so that’s not it. And yes, I’ve redirected my subscribers several times. I’m surprised I still have any.
white-space: pre is not supported in IE 5.x, which is why no one uses it.
The irony of all this is that my original post which prompted Dorothea’s critique doesn’t use PRE; it uses P + CODE + BR + nbsp characters. But because it was a one-liner, there wasn’t enough room and her browser doesn’t break intelligently enough. (Opera is better about this, so I didn’t notice the problem until she mentioned it.) And I use the little-known overflow: hidden property to keep this sort of situation from totally destroying my layout, which is why she saw the code disappear under the right-hand nav bar. (I am attached to my page layout, and I mean that in a Zen sense. Letting go of this attachment is on my to-do list.)
You will be happy to know that UserLand has replicated the double-decoding bug and is actively working on a fix.
http://groups.yahoo.com/group/radio-dev/message/6799
*rofl*
Mark, that’s hysterical. Serves me right for not viewing source. But why’d you use br and nbsp on a one-liner?
Yes, Mozilla has breaking problems. It doesn’t consider hyphens a character to break on, for one thing.
The only thing that we’ve found for code that works for everyone is to put the code into a textarea form field. That way, everyone can copy and paste, and it’s clear what’s part of the code and what isn’t.
If you click on any of the ”View Source” links at our book’s site, you’ll see what I mean.
Mark:
Ok, white-space: pre is not recognized by IE 5.x (I believe in what you say, I’m not at home where I’ve IE 5.x), but I don’t think that it’s a valid argument. Why? I love your 30 days to a more accesible weblog, it was just great… but when you recomend to use ABBR, well, it doesn’t work neither IE 5.x & 6.0, and this is something I’m pretty sure :)
Bye!
Ooops…. excuse my double post.
No problem – I think I’ve got MT overloaded with too many templates, so it saves the comment but dies before it gets all the pages rebuilt. You don’t see your post, so you can’t tell it was saved until you make it again, when the page rebuilds with both comments.
Actually, I specifically suggested *not* using ABBR, specifically because it is not supported by IE/Win.
Day 17: Defining acronyms
Ok, it’s true, but not using an element from W3C HTML recomendation is not the solution. I think that if nobody uses it, it’ll never be supported by IE/Win.
In the same page you say this:
acronym:after {
content: " (" attr(title) ")";
}
which it’s not supported by IE/Win. Ok, quoting you:
and <abbr> is harmless two!. It doesn’t seems coherent to me say: ”use
acronym:after
but don’t use<abbr>
. Neither will work on IEIn IE/Win:
1. [acronym title=”bar”]foo[/acronym] will display the word ”foo” and pop up a tooltip saying ”bar” when you hover over the word ”foo”.
2. [abbr title=”bar”]foo[/abbr] will display the word ”foo” and nothing else. No tooltips.
Therefore, use [acronym] for both.
Purists will try to tell you that there is a semantic difference between acronyms and abbreviations, and they’re right, but it’s irrelevant. 90% of the world uses Internet Explorer on Windows. Start a campaign to add [abbr] support in IE7 if you want, but use [acronym] for now.
Furthermore, the XHTML 2.0 draft finally gives up and says that [acronym] and [abbr] are interchangeable. Even the W3C has given up on this fight. Use [acronym].
Don’t even get me started on the Q tag.
Ok, you’re right. I really respect what you said, but I can’t accept this reason: ”90% of the world uses Internet Explorer on Windows”. I know it’s true (I’m not that blind ;-) ) but I don’t want to accept it. I’ve see the same reason in a lot of places to justify actions or ways of doing the things in a bad manner, IMHO. Anyway, you’ve more experience than I do… and you have a weblog :-) (very nice one, by the way)
Bye!
Nothing stopping anyone from using
[abbr title=”bar”][acronym title=”bar”]foo[/acronym][/abbr]
Yes it’s a bit cumbersome, but it allows one to provide the ’correct’ element and be wrong, all at the same time. Now try to do that in your everyday life…
I still use
abbr
andq
, and I think other people should too. You can’t fix browsers without breaking them first. They won’t listen otherwise.