Unexpected output from modified template

Topics: Developer Forum
Feb 7, 2014 at 1:28 PM
I'm getting strange output from what appears to be a straightforward modification of a template. To observe this behavior, make the following change:
  1. Apply the patch shown in commit e917070
  2. Change the output of the project to use the VS2010 presentation style with the Website output.
If you open the resulting HTML file, observe the following details:
  1. The OH_outerContent div is located as a child of Experiment, where I expected it to be the following sibling.
  2. The OH_footer div is located as a child of OH_outerDiv, where I expected it to be a sibling. Note: Prior to applying the patch mentioned above, the OH_footer div does actually appear in the correct output location.
Do you have any insight into why the template is producing output at the described locations, and how I could get it to instead be located at the expected locations?
Feb 7, 2014 at 8:26 PM
There are other templates in body.xsl which is included by ps-body.xsl that may be interfering with or changing how that template's output ends up. Search for "OH_outer" to find them. That might be the place to start looking.

Feb 9, 2014 at 12:09 AM
The problem occurred because the example div was created as a self-closing element in the output, e.g.
<div class="Experiment" />
In HTML 5, a self-closing element is treated the same as an opening tag, so the browser is treating the code equivalent to the following:
<div class="Experiment">
Obviously this would cause a problem regarding the nesting of HTML elements. The solution is to find a way to force the templates to never use self-closing elements in the output, resulting in correct operation:
<div class="Experiment"></div>
Do you know how this can be accomplished?
Feb 9, 2014 at 12:26 AM
 <xsl:element name="div"><xsl:comment/></xsl:element>
Will produce:
Putting in a zero-width space or something might work too.
Feb 9, 2014 at 3:55 AM
A non-breaking space should work too
Feb 9, 2014 at 4:40 AM
I ended up solving this by tweaking the Save Component to set the output method for XmlWriterSettings it uses. The approach is based on this StackOverflow answer.
var propertyInfo = typeof(XmlWriterSettings).GetProperty("OutputMethod", BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic);
propertyInfo.SetValue(settings, XmlOutputMethod.Html, null);
This could be generalized by updating the Save Component to recognize a new method attribute for the save element.
<component id="Save Component">
    <save method="html" ... />
The attribute would be optional, and if specified needs to be auto, xml, html, or text, in order to choose the correct XmlOutputMethod value.
Feb 9, 2014 at 4:49 AM
I'll create a patch for this change so other styles can benefit from it as well.