I just posted newtelligence dasBlog version 1.2.3230.0 to the GotDotNet workspace and to the download section on the dasBlog site.

With this drop, I now have a feature set that makes me happy for my own blog and which some of you out there hopefully find useful for your own blogs. It’s been 5 weeks that were a lot of fun and I learned a lot about other user’s requirements through the feedback that I’ve gotten in the three weeks that the code has been public now.

And with this drop, I will therefore also stop the feature rush and likely not post more than fixes or updates to the language files and templates. Don’t expect significant new features from me in the upcoming weeks. What that means is clearly that I expect that something happens in the GotDotNet workspace from people other than me. There’s been a lot of complaining in the BlogX workspace about BlogX being stalled in terms of features and that the code-base has been locked and checked out the whole time. So, there you go: dasBlog is not checked out and open for all workspace members to change. I am going to be on the road for 3 1/2 weeks starting Wednesday, so don’t expect me to organize anything in the workspace or watch it. It’s yours. I’ll delegate accepting new members and begging to Microsoft for more workspace resources to someone around here, but that’s about it.

That also means that my private copy I am carrying around on my notebook is now forked off from the main code base and is going to be my own private little playground for new things to try.

Even if you are not at all interested in running the software as-is, you may want to go and grab the code base, because I am sure there’s a lot of useful little things in there if you are developing ASP.NET apps. It turned out to be so much new code and so many new little utilities and tricks that I could hardly keep track of the “new new” things, let alone document them. There’s a lot of fodder for articles, tips and tricks columns or for highlighting aspects here on the blog.

One thing you’ll find digging into the code-base is that almost always when there’s something that doesn’t need to be done synchronously, I don’t do it synchronously. Every referral gets queued up in an in memory queue and is written to the referrer-log on a secondary thread. All mail notifications, pingbacks, trackbacks and the pining of weblogs.com and blo.gs are also done on secondary threads.

You’ll also find that the little drop-shadows on the configuration page for the content-filter are neither rendered by IE, not will you be able to find the displayed images anywhere in your site’s directories. Instead, the drop shadows are all dynamically rendered. The magic is done by the “ShadowBox” control that’s in the newtelligence.Web.UI.WebControls assembly. You can configure the shadow depth, the background color onto which the shadow is to be rendered, etc.

The DHTML editor is also a reusable component from that assembly. It loads its toolbar from an embedded resource using the same technique: The ControlImageHandler class is an IHttpHandler which is capable of redirecting requests for images back to the controls that rendered the image links. So, in essence, you get something similar to Windows Forms’ OnPaint() support for WebControls.

There’s a complete (and working) implementation of a class WindowsTimeZone, derived from System.TimeZone and a matching WindowsTimeZoneCollection that grabs all the time zone information known to Windows and exposes that in a .NET Framework compatible way, including daylight savings time and all that.

The UrlMapper is a generic component that lets you use regular expressions to filter incoming URLs and map them to internal URLs, which comes very handy if you change a site’s structure around, MailToWeblog contains a five-liner showing how to create thumbnails from images, …

…. many things to explain in more detail and so little time. Stay tuned. ;)

Consider Norwegian-Bokmal (NO and nb-NO) done. Christian did it. Already installed here; best seen in the comment view if you’ve got Norwegian as the most preferred language.

So.... dasBlog 1.2 nears completion and this will then also conclude the “feature rush“ for a while, because the allocated time for this “summer project” (5 weeks) is up and I have to shift gears. The last step for 1.2 is localization. Based on the user’s top preference in the Accept-Language header, dasBlog 1.2 presents all “hard coded” strings for publicly visible elements like the “Comment” link and the entire administrator interface in the preferred language, if the respective resources are available.

There’s now also an additional macro “localString” that you can use to define a multilingual expression in your templates: <%localString(“This is the English default|DE:Das ist die deutsche Alternative|IT:Questo e in italiano”)%>. This will resolve into German or Italian if that’s on the user’s language preferences list (Accept-Language header, again) and fall back to the default expression before the first delimiter if there’s no proper mapping. And, yes, you could also differentiate between “en-GB”, “en-US” and “en-CA”.

On the posting side, all posts are posted with the “invariant culture” (empty identifier) by default and will therefore show up on the blog independent of the user’s language preference. However, you can also select a language/culture pair when posting (for instance either “de” for German in general or “de-AT” for Austria, specifically) and then the post will only show up for users who have this language/culture listed in their browser’s language preferences. In the RSS feeds, the <item> tag will then carry the proper xml:lang designation (which propagates down to all its children as per XML 1.0).

By now, I have two complete language sets for the localized resources for English (en-US) and German (de-DE), but that’s as far as my “active” language skills take me. So if any of you folks out there (especially dasBlog users – hint, hint) have some 20 minutes of time and want to help me with localization into languages other than those two, grab the three files below (it’s just XML), translate the stuff between the <value> tags (except the topmost four) and send them, with the filenames reflecting the culture (such as Web.StringTables.ES.resx for Spanish), back to me at clemensv@newtelligence.com 

Of course, I will have to figure out how trust the correctness if I am getting translations into languages that aren’t from Latin or Germanic descent (most of those I can usually figure out), but that’s something to determine if and when it happens. For now, this is also a great experiment to see whether this little call for help yields any results. You’ll definitely get a permanent link and mention prominently on the dasBlog website and I can also put your blog into the blogroll that is included the setup archives, how’s that for a “payment”?

DateTime issued;

[XmlIgnore]
public DateTime IssuedUtc
{ get { return issued; } set { issued = value; } }

[XmlElement("issued")]
public DateTime IssuedLocalTime
{ get { return Issued.ToLocalTime(); } set { Issued = value.ToUniversalTime(); } }

Why?

In 1.1 (hidden) and in 1.2 (no longer hidden) of dasBlog, you can enable a feature for Mail-To-Weblog that will automatically turn attached pictures (not embedded pictures) into thumbnails in the post and you can also control the maximum height for the thumbnails. The relevant settings in site.config for 1.1 are

<Pop3InlineAttachedPictures>true</Pop3InlineAttachedPictures>
<Pop3InlinedAttachedPicturesThumbHeight>200</Pop3InlinedAttachedPicturesThumbHeight>

In 1.2 the config settings are the same, but I added them to the config page. Here's an example of how it comes out:

Das Blog-splash.jpg

Jon Udell found  (and Stefan Tilkov did too) that my new design doesn’t (didn’t) work in Mozilla Firebird.

The issues were inconsistencies in the behavior of the "float" and "clear" CSS properties between Opera, IE and Mozilla and, on top of it all, the rustiness of my CSS skills. All the "side-bar" elements on the left side of the page (calendar, navigator links, category list and blogroll) were "width:220px", "float:left" and "clear:both", saying "show this thing on the left hand side of any content that is rendered with regular layout and put the box under all other left floating boxes". So that causes all of these boxes to come out vertically aligned.

Now, the content section was also "float:left" but with "clear:right" and "width:70%". Opera and IE were showing the content as I intended it, to the right of the side-bar. As per the words of the spec, that indeed seems to be proper behavior for "clear:right", because it says that "The top margin of the generated box is increased enough that the top border edge is below the bottom outer edge of any right-floating boxes that resulted from elements earlier in the source document."  In other words, since all other elements rendered before this element were "float:left" and there isn't any "float:right" up to this point, the top margin for the new float is should be at relative/top:0px. Opera and IE are right, Mozilla is wrong.

Now... I fixed this for all by simply removing the float/clear properties from the content box and not making the content floating anymore. ... and tripped over another problem: widths.

I set the content box's size to 78%. In IE, that turned out to be 78% of the available horizontal <body> space excluding the width of the already rendered side-bar boxes (now all set to 18% width). In Mozilla and Opera, that's simply 78% of the available horizontal <body> space (in effect, the available page width). So, 78% of 82% of the page width are roughly 64% (63.96%). Measuring pixels of what IE renders and taking the margins of the item boxes into account, I indeed got 64.3% for the content boxes. In Opera, measuring pixels yielded 78.6% of the page width and Mozilla came in at 78.1%.

Since I couldn’t find anything supporting IE's behavior reading the spec section on the width property and the definition of the containing block, I concluded Mozilla and Opera are doing this right and IE is doing it wrong. This was a bit surprising to me, because (a) I don't do web design for a living and would know otherwise and (b) because IE actually needs to perform extra work to get to these numbers, so that behavior is surely no accident.

Switching IE into “standards-compliant mode” by injecting <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> ultimately fixed the width calculation problem, but who would know that intuitively?

This left the problem that Mozilla doesn’t get the clear property right. So, I settled on an absolute horizontal positioning for the content box using “position:absolute;left:22%;width:73%” . Now with that, the footer (yet another <div> at the <body> level) was getting confused, because now I had only floating and absolutely positioned elements and therefore I wouldn’t know where the bottom is. Moving the footer into the content box below the content placeholder fixed that, too. Now it looks good for Mozilla and Opera and IE6.0. If you use an earlier version of IE, upgrade.