Under Community Review
over 2 years ago

HTML5 support is a familiar request but we need more details and use cases to make this a tangible request to consider. The referenced example refers to the desire to wrap HTML block elements with an anchor (i.e. <a>). Does that represent this interest in this idea? Or are the votes about broader support?

HTML5 or any format has multiple aspects, which can include:

  • Specific desired content storage and/or output in terms of element wrapping, specific tags, or the closing of tags
  • Ability to configure/change/override the default format settings either during save or publish
  • Editor abilities to work with HTML5 elements (tags or attributes)

Support HTML5 in Rich Text field.

There was a discussion about "HTML5 in Rich Text field" in the link below. "HTML5 in Rich Text field" is not supported.
https://tridion.stackexchange.com/questions/16779/let-sdl-web-8-rich-text-field-support-html-5

We have a request that it should be supported.

  • @Frank Taylor. A lot of what you say coincides with my point that the storage language to represent an RTF in the CMS is most definitely not the language that needs to come out of your templating. For the former, an XML dialect is very well suited, and for what you need to have in your website, well I don't care and Tridion doesn't care. The implementer can generate what he wants.

  • I think there's challenges to this. Chiefly that HTML5, *by design*, is not XML (stackoverflow.com/.../is-html5-valid-xml)

    I would certainly support things like block-level links, and HTML5 semantics, but many other front-end developers (and IDEs that they use) have objections to the HTML5 syntax.

    HTML5 allows things like

    <table>

    <tbody>

    <tr>

    <td>text

    <td>text

    as well as <img> and <p>text<p>. IDEs and Linters throw errors at such markup. Even though it is "valid". `<div class=foo>` is also valid -- the " isn't required so long as the value is a single word.

    All of these things are "fine" for the browser because it's been built to parse these things. But almost any front-end developer's toolset will throw errors because... this looks like mistakes. Relying on the browser to know where to insert a tag has, many times, had dangerous results. I can't imagine it'd be better with Tridion.

    I would get on board with block level links, and semantic elements, and microdata. But not for any of the formatting pieces that are part of HTML5.

  • :

    Thanks for the vote. Votes for any given idea help show community interest in an idea, but don't necessarily guarantee implementation nor timeline since Product Management and Development needs to consider the product fit, business impact, and feasibility for any given idea.

    For ways to improve this or other ideas please see community.sdl.com/.../.

    :

    Giving users the ability to manage the output of source content could introduce a few challenges including the ability to break a site's markup with the incorrect choice, the need for additional template logic to handle both scenarios, and most importantly, an inability to share content between sites.

    Perhaps adjusting this format during publishing would be a better approach in case of transitions between formats.

    Here's my own view on custom XML and attributes in the rich text format area:

    www.tridiondeveloper.com/rich-text-format-area-css-classes-vs-custom-xml-nodes

    More tangible use cases could help make this request better.

    : If possible, I'd prefer a single way to control the allowed markup in a rich text field which might even influence the visible RTF controls. Ideally we wouldn't need XSLT to adjust Component source.

  • Is HTML5 the right thing to aim for? Tridion needs to have a native storage format for RTFs that is amenable to templating. Sure there will be HTML5 features that you want to have, like anchors over blocks, but it should be about the features you want to support in an RTF. Separation of concerns FTW! OK, it's sometimes handy to let power-users chew on some HTML, but if you /need/ to, then that's a deficiency in the editor. Still - some of the things that Tidy does are pretty obscure, especially when combined with J. Random Hacker's XSLT. Might there be ways to make that more obvious?

  • We have a lot of XHTML pages. We need to maintain XHTML pages. However, We want to make HTML5 pages.

    So we need both format setting.

    If user can easily select XHTML format or HTML5 format for thereselves, it is so nice.

    I think user want to ability to make valid HTML5 document.

    http://www.w3.org/TR/html52/