editing tsunami rendering: monospaced fonts (312)

links

history

item nametags

===Introduction
Different browsers render HTML & CSS differently.  Yay*.  The place where I struggle with this most now, with tsunami, is in rendering monospaced fonts.

* Here, "Yay" means "browsers are horrible pieces of software".

===Inline monospaced font (`<code>`)
For some reasons, browsers disagree violently on how to do it.  Compare:
- "Firefox 2.x linux"[1]
- "Firefox 2.x WinXP"[2]

[1]http://luke.breuer.com/upload/tsunami_headers_firefox_2x_linux.png
[2]http://luke.breuer.com/upload/tsunami_headers_firefox_2x_winxp.png

===Block monospaced font (`<pre>`)
==Update
It appears that the following use of the `width` attribute for `<pre>` solves the problem below, "excepting Safari"[1], and actually, IE7:
{{
const int MinLenForExplicitWidth = 81;

return string.Format("<pre{0}>{1}</pre>",
	maxLen >= MinLenForExplicitWidth
		? string.Format(" width='{0}'", maxLen)
		: "",
	processed);
}}

[1]http://luke.breuer.com/upload/safari_does_not_respect_pre_width.png

According to the W3C, "`width` is deprecated"[1], but it seems to work.

[1]http://www.w3schools.com/tags/tag_pre.asp

==Implications for long line length code
I automatically increase the width of `<pre>`s so that the boxes around code renders well.  Unfortunately, this doesn't work so well on all browsers.
{{
// MAGIC: boo yah! (works with Firefox 2.x on Windows, but not others, because inconsistencies => FAIL)
const int MinLenForExplicitWidth = 81;
const double WidthDivisor = 1.77;

return string.Format("<pre{0}>{1}</pre>", 
	maxLen >= MinLenForExplicitWidth 
		? string.Format(" style='width:{0:0.00}em'", (maxLen + 0.8) / WidthDivisor) 
		: "",
	processed);
}}

some permissive license goes here
contact