Why do Experience Manager TBBs insist on outputting a new tag around every Component Presentation and Component Field?

Question

So Tridion UI/XPM/SiteEdit default TBBs output a <span> tag around each Component Presentation and Field changing the DOM and sometimes conflicting with your site's styles. So a project has been created (https://github.com/TridionPractice/tridion-practice/wiki/TridionUI2012FunctionsForUseInHtmlTemplates) that proves these are not necessary. It looks like you can simply print the SiteEdit markup in front of the editable field (btw, very cool).

So why aren't the default functions @@RenderComponentPresentation(...)@@ and @@RenderComponentField(...)@@ doing that straight out of the box?

I thought that maybe backwards compatibility could be one reason, but upon second thought this doesn't make sense because if you upgraded you'd still need to swap out your TBBs and republish your pages. So you'd be good to go.

I'm assumming there had to be some other architectural reason(s) why the <span> tags were needed and I'm curious what that scenario is.

Answer 1

The reason for the extra element is to ensure that there is a containing element which can show the border and allow you to edit the content. As you mentioned, this is often already the case but there is no way of knowing that without actually parsing and interpreting the HTML.

It just wasn't feasible to do, so the decision was made to always add such an element. Span was chosen because it doesn't typically interfere with the layout. Ideally, HTML would have a tag for something like this but that hasn't happened yet as far as I know.

I agree that it should be possible to overwrite the behavior so that it doesn't output this element. There is an open enhancement request for that in our system.

Answer 2

When the XPM markup is parsed, everything up until the end of the containing HTML element is treated as part of the "editable" region.

My assumption, then, is that because the RenderComponentField function (and others like it) have no access to the surrounding context, the only way to ensure that the output value is properly encapsulated for the SiteEdit markup is to wrap it in a span or similar element.

Of course, most of the time, the value will already fill an existing container, rendering the additional container redundant. But there's no way to be sure.

Perhaps not the most elegant approach - hence the introduction of third-party libraries to give you better control of the rendered markup - but it's a simple OOTB solution that probably works fine in the majority of cases and prevents you from having to revise all of your DWT TBBs.