Whidbey support for HtmlHead, Part II
Note: this entry has moved.
Now its turn to peek at how <meta> child elements are being supported. Let’s take for example the following markup:
<head runat=”server”>
<title>Foo</title>
<meta name=”one” content=”uno” />
</head>
As the <head> element has a proper runat=”server” attribute, it will be parsed as an instance of HtmlHead and you will be able to programmatically play with it at runtime like this:
this.Header.Metadata.Add (“two”,”dos”);
What output would you expect from the previous code?
This one:
<head runat=”server”>
<title>Foo</title>
<meta name=”one” content=”uno” />
<meta name=”two” content=”dos” />
</head>
Or this other real funny one:
<head runat=”server”>
<meta name=”one” content=”uno” />
<title>Foo</title>
<meta name=”two” content=”dos” />
</head>
Of course you should expect the first one, but with the March04 preview bits you’ll get the second one.
What causes this strange reordering of the tags? Uff... I mean… once we finally got VS.NET to *never* touch our markup now it’s the HtmlHead control that decides to rearrange them in the previously shown “clever” way of meta-title-meta…
Let’s try to shed some light on what’s happening here…
HtmlHead has associated a control builder, HtmlHeadBuilder. By looking at HtmlHeadBuilder.GetChildControlType we can tell that it only recognizes two different child types: HtmlTitle and HtmlLink. There is no recognition here for the <meta> element, moreover, there is not even a HtmlMeta control (as there are HtmlTitle and HtmlLink ones).
This means any <meta> elements that you may specify at design-time will be parsed as a single LiteralControl.
When it is time to render, HtmlHead rendering basically does the following (warning: very-simplistic-pseudo-code-follows):
- Render HtmlHead’s child controls (this will render the LiteralControl containing the <metadata> specified at design-time)
- Render HtmlTitle (or a blank <title></title> if none is found)
- Render Metadata items that were added programmatically
Remember our <meta> elements specified at design-time were parsed as a single LiteralControl and added to HtmlHead’s control collection. So they will be rendered before any other output of the HtmlHead control.
I’m hoping for this funny reordering to go away soon. I believe that modifying HtmlHeadBuilder to recognize childs of type HtmlMetadata (and adding such a control in the meantime) will make everyone (or at least me!) happy.