Under Community Review

Prevent adding

tags in rich text field when used new sites9.5 /UI

While using new sites9.5 ui, when we enter a line in rich text field, it adds <p> tags around the text after saving. And that mess up the presentation on page.
We had similar problem in tridion 2013 ui which was fixed by updating xslt. But that xslt change is not applicable to new ui.

XSLT filtering is not yet available for the XS UI.
https://docs.rws.com/832080/768986/tridion-sites-9-6-experience-space-help/information-for-users-of-the-------------classic-user-interfaces
The following features that are available in the rich text format area in the Classic user interfaces are not (yet) available in Experience Space:
...
* Applying the custom Filtering XSLT defined for a format area; currently such XSLT is applied only to the Classic user interfaces.

 

Could you please enhance the new ui to fix the issue.

Parents
  • Thanks for the submission, Prashant. Could you perhaps add some of the XSLT filtering logic or describe what it does, especially when the editor has multiple paragraphs?

    The <p> tag wrapping behavior in the Classic UI has a bit of nuance worth mentioning to make sure any potential change handles all the scenarios.

    By default, in the Classic UI, rich text fields do indeed start without a wrapping element. And I have seen this lack of a wrapping element as desired and even expected, especially when the website needs rich text that might be placed inline or in a wrapping element such as a <div> or <p>. A paragraph in a div is okay, but you wouldn't want nested paragraphs.

    As an editor years ago, I would explicitly use backspace (or the source tab) to remove any accidental <p> tags. Grinning

    However, the rich text format area can also store multiple "blocks" of text. And when needed, I would want wrapping <p> tags around each paragraph.

    As a side note, one challenge in the Classic UI, is that without some additional XSLT filtering logic, the wrapping element would vary based on the browser, resulting in a <p>, <div>, or line break (<br/>) depending on the browser. Experience Space's rich text format area now "plasters over" the differences between browsers.

    Anyways, I think it could be worth exploring if a single line/paragraph rich text field option might be interesting as an alternative solution. Perhaps this type of field could only allow line breaks, but no <p> tags. That way editors or developers wouldn't need to manage or filter/template the desired output.

Comment
  • Thanks for the submission, Prashant. Could you perhaps add some of the XSLT filtering logic or describe what it does, especially when the editor has multiple paragraphs?

    The <p> tag wrapping behavior in the Classic UI has a bit of nuance worth mentioning to make sure any potential change handles all the scenarios.

    By default, in the Classic UI, rich text fields do indeed start without a wrapping element. And I have seen this lack of a wrapping element as desired and even expected, especially when the website needs rich text that might be placed inline or in a wrapping element such as a <div> or <p>. A paragraph in a div is okay, but you wouldn't want nested paragraphs.

    As an editor years ago, I would explicitly use backspace (or the source tab) to remove any accidental <p> tags. Grinning

    However, the rich text format area can also store multiple "blocks" of text. And when needed, I would want wrapping <p> tags around each paragraph.

    As a side note, one challenge in the Classic UI, is that without some additional XSLT filtering logic, the wrapping element would vary based on the browser, resulting in a <p>, <div>, or line break (<br/>) depending on the browser. Experience Space's rich text format area now "plasters over" the differences between browsers.

    Anyways, I think it could be worth exploring if a single line/paragraph rich text field option might be interesting as an alternative solution. Perhaps this type of field could only allow line breaks, but no <p> tags. That way editors or developers wouldn't need to manage or filter/template the desired output.

Children
No Data