9

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.

Improve this question
3
  • Hi Nick, I think this is meant to be on the normal site rather than meta? – Rob Stevenson-Leggett Mar 29 '14 at 10:03
  • I don't think so Rob. I put it on meta on purpose to discuss. – Nickoli Roussakov Mar 29 '14 at 13:50
  • 2
    I see where you're coming from but it's not about the Tridion Stack Exchange site. It's a question about the product so therefore should be on the main site even if it is a discussion type question. – Rob Stevenson-Leggett Mar 29 '14 at 14:06
7

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.

Improve this answer
7

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.

Improve this answer
6
  • 2
    You're right on the money. We either ask you to ensure every field and CP is neatly "wrapped" in a container, or we take care of it ourselves. No way to keep everyone happy :) – Nuno Linhares♦ Mar 30 '14 at 18:27
  • 1
    @NunoLinhares Except maybe with a TBB parameter ;) – Ant P Mar 30 '14 at 20:41
  • Exactly. A TBB parameter could specify the list of valid containers, and a default set (e.g. span, div, article, section) could easily be set. [BTW, this is why I originally posted this on Meta]. – Nickoli Roussakov Mar 30 '14 at 23:37
  • 3
    I understand the newest approach in 2013 SP1 also gives per-field control through DWT functions like @@FieldStartMarker("fieldname")@@. See Elena's Serghie's post explaining things she bets we didn't know about 2013 SP1. :-) – Alvin Reyes♦ Mar 31 '14 at 0:13
  • 1
    I think I stand corrected and read too much into the new syntax--it's only for multivalued embedded fields. I agree with your point and would actually go farther--you wouldn't just want a parameter but also control over attributes such as class and its value. This is still a good question, but the best place for the feedback isn't Tridion Stack Exchange meta, but SDL Tridion Ideas. ;-) – Alvin Reyes♦ Aug 28 '15 at 2:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.