- Why do you want to do that?
- Why is it not there out-of-the-box?
- Is it supported?
So, here's my take on why you're doing it for the wrong reasons. Yes, you can modify the rich text settings to allow entering any possible tag, but everytime you do this you are breaking the experience of your content editors for the sake of making your html markup work on your site.
When editors must create content that includes non-standard XHTML tags they will have to edit the html source of their content and add the tags themselves - guess how much of that will work when using Experience Manager? When implementing Tridion (or any other WCM) you may be tempted to take shortcuts to implement faster, and also to avoid having to review the HTML/Web app that you intend to use. But if your content editors are expected to edit their source html to insert "data-rule" attributes in links, you just made their life harder.
What should you do instead?
In my view, non-XHTML attributes required on content should be dealt with in the most user-friendly way. If you need to use <article> or <section> tags in your RTF, why not convert <div class="article"> to <article> at publish time? If you need to insert data attributes to links, then do consider a similar approach replacing other, normal attributes (or, at the very least, consider writing an extension that allows to add those tags without editing the html source).
Every time you ask an editor to edit the source of their html to add attributes you are asking them to dislike the system. Consider this when designing applications, making it hard to edit content has never been one of the goals for a WCM implementation project...
6 comments:
Very true, however I feel most people either don't know or are scare of transformations after a user hit the save button.
Is that because they do not know that it's even possible?
The rich text field displays for editing within an HTML text area, Display using the editor applet, allowing for a broader range of editing options and JavaScript control, allowing for a broader range of editing options.
I must say it is one typical technical guy's mind. This issue's true reason is the gap between the Technical guy like you and the content editor people.
As one quick example. When our company's new game release, there maybe many customized tags which will be used by our Game or CRM system. It is not good to convert them each time, since the number is huge and not fixed. We want to host them inside Tridion but right now we couldn't, because Tridion always made the change by itself. Real project's requirement is very complex.
Well, then why not use a "standard" text field - since what you're storing is not Rich Text anyway?
I'm as guilty as many others of doing many implementations where we publish components (or only certain fields) "as is", without any real template code.
@Anonymous, the requirements and options are simple, please don't over-complicate the message here, which is to make inserting custom-whatever-tags easier for authors. Huge numbers of non-fixed references do not need to be resolved at publish time--consider the fact that "custom tags" means they are transformed or processed at some point. So change what authors enter at save, in delivery, or even client-side. "Huge" implies authors are doing this all the time which means there is practical and measurable cost to the business (training, validation, testing, and/or copying & pasting custom tags) that impacts projects no matter how complex they are. Given a choice between more time per custom tag insertion vs. longer publishing times vs. a performance impact for visitors, what do you want to optimize? By default Tridion treats rich text as rich text, but as a system Tridion does not prevent you from storing custom tags. By all means do what you'd like, just understand there's a cost to authors and some technical debt with any custom tag (that you'll pay off if/when the CRM, game system, or a custom tag format changes). Easy for authors happens to correlate "easy for the business in the long run" in this case.
Post a Comment