Details

    • Epic Name:
      Rich Text Custom Tag M1

      Description

      Provide a sample dummy custom tag to be used as a basis for developers. This custom tag could be “Quote”.
      Adding the custom tag to the editor, users would get a simple window with a text area for the quote, and a field for the author, when saving, it would be previewed in the online editor.

      In scope of this milestone: block level custom tag
      Out of scope: inline level custom tag that could be used for stylig

      Suggested stories:

      • Custom tag extension point in platform UI
      • Custom tag generic interaction (create / save / edit / cancel ...)
      • Quote custom tag
      • Youtube custom tag

        Issue Links

          Issues in Epic

            Activity

            Hide
            André Rømcke added a comment -

            Ideally should cover custom tags available in 5.x commonly (so they can migrate):

            • strike (this might be supported natively by docbook, if so would be better to handle in migration script)
            • sub (this might be supported natively by docbook, if so would be better to handle in migration script)
            • sup (this might be supported natively by docbook, if so would be better to handle in migration script)
            • separator (this might be supported natively by docbook, if so would be better to handle in migration script)
            • underline (this might be supported natively by docbook, if so would be better to handle in migration script)
            • factbox
            • quote

            Less common custom tags not enabled by default normally:

            • pagebreak (ezoe)
            • children_menu (ezdemo)
            • video (ezdemo)
            Show
            André Rømcke added a comment - Ideally should cover custom tags available in 5.x commonly (so they can migrate) : strike (this might be supported natively by docbook, if so would be better to handle in migration script) sub (this might be supported natively by docbook, if so would be better to handle in migration script) sup (this might be supported natively by docbook, if so would be better to handle in migration script) separator (this might be supported natively by docbook, if so would be better to handle in migration script) underline (this might be supported natively by docbook, if so would be better to handle in migration script) factbox quote Less common custom tags not enabled by default normally: pagebreak (ezoe) children_menu (ezdemo) video (ezdemo)
            Hide
            Damien Pobel (Inactive) added a comment -

            I took the time to experiment the current custom tags support in RichText in EZP-25560 and we have quite some work before having the option to add custom tags in the Online Editor toolbar.
            André Rømcke Bertrand Dunogier Roland Benedetti [~jince.kuruvilla@ez.no] Inaki Juaniz-Velilla please read that carefully, I guess we'll talk about that tomorrow in the planning.

            Here is the outcome of the spike:

            Defining a custom tag in RichText

            This is absolutely not documented. So here's the configuration with some comments related to custom tags

            <siteaccess|siteaccess_group>:
                fieldtypes:
                    ezrichtext:
                        # list of XSLT extending the core docbook to xhtml5 (for frontend)
                        # eZ/Publish/Core/FieldType/RichText/Resources/stylesheets/docbook/xhtml5/output/core.xsl
                        # not really mandatory, the twig template per tag can be used for that
                        # if <eztemplate> element is transformed by this stylesheet, the twig
                        # template is not even used (but twig tpl is mandatory because of config
                        # parsing...)
                        # /!\ path is taken from web/
                        output_custom_tags:
                            # - {path: ../app/Resources/output_youtube.xsl}
             
                        # list of XSLT extending the core html5edit to docbook
                        # eZ/Publish/Core/FieldType/RichText/Resources/stylesheets/xhtml5/edit/docbook.xsl
                        # used when parsing a RichText field value
                        # not mandatory. Useful only if we want to use something else than
                        # <eztemplate> tag to represent a custom tag in the html5edit format
                        # in input. If this feature is used, it makes almost impossible to
                        # correctly support custom tags in the editor.
                        # /!\ path is taken from ezplatform root
                        input_custom_tags:
                            # - {path: app/Resources/input_youtube.xsl}
             
                        # list of XSLT extending the code docbook to html5edit
                        # eZ/Publish/Core/FieldType/RichText/Resources/stylesheets/docbook/xhtml5/edit/core.xsl
                        # opposite of input_custom_tags.
                        # not mandatory. Useful only to get a different representation of
                        # custom tag than a `<eztemplate>` tag in html5edit.
                        # /!\ path is taken from web/
                        edit_custom_tags:
                            # - {path: ../app/Resources/input_youtube.xsl}
             
                        tags:
                            <name_of_customtag>:
                                # path directly passed to the template engine service
                                # see http://symfony.com/doc/current/book/templating.html#template-naming-and-locations
                                template: <name_of_twig_template>.html.twig
                                # arbitrary configuration object, did not manage to have access to it in the Twig template, but I did not dig
                                config:
            

            The XSLT files are not mandatory. The path is relative to web/ except for input_custom_tags where it's relative the ezplatform root . They allow to tweak how the custom tag are represented in different contexts. By default, custom tags are represented by a eztemplate or eztemplateinline tag in docbook (internal format) and HTML5edit formats.

            input_custom_tags and edit_custom_tags XSLT allow to use a different tag in HTML5edit format for a custom tag.

            There's an overlap between the Twig template per tag and XSLT in output_custom_tags. The twig template is mandatory because of the way semantic configuration setup but if you transform the custom tag with an XSLT in output_custom_tags, the Twig template is not used at all.

            Issues in current code to implement custom tags in Online Editor

            • no information in config on whether a custom tag is a block tag or an inline tag
            • no config for built in custom tags (quote, sup, sub, ...) so now way to get a list
            • edit_custom_tags / input_custom_tags make it very complex to implement custom tags. I don't really see the point in that feature, can we just remove this ability ?.
            • in html5edit, custom tags are represented with eztemplate or eztemplateinline tag. We have to change those to use valid HTML5 elements (<div> and <span>) otherwise we'll have issues in browser (we did the same for embed)

            DX issues

            • No documentation (no, unit tests fixtures are not a documentation), we need a tutorial/cookbook recipe on that topic
            • Misleading comment in the output of php app/console config:dump-reference EzPublishCoreBundle for XSLT settings
            • output_custom_tags and the Twig template does the same thing => do we need output_custom_tags setting ?

            Specifications needed

            https://doc.ez.no/display/PR/Online+Editor:+Scope only mentions custom tags a few times. I guess, for a block tag, we'll have a corresponding entry in the add toolbar but besides this, the feature is not described.
            There are several things to consider:

            1. inline custom tag vs. block custom tag (how do we add inline custom tag ?)
            2. the attributes of custom tag are an important topic. For instance, a typical use case for the custom tag is to define a youtube custom tag that accepts 3 attributes: height, width and src. Those attributes are (by default) not visible in the editor, how do we edit them ?
            3. some custom tag are designed to have a content (for instance quote), some are designed to have only attributes to configure it (youtube for example) and some both. This is also something to take into account. As well.

            Show
            Damien Pobel (Inactive) added a comment - I took the time to experiment the current custom tags support in RichText in EZP-25560 and we have quite some work before having the option to add custom tags in the Online Editor toolbar. André Rømcke Bertrand Dunogier Roland Benedetti [~jince.kuruvilla@ez.no] Inaki Juaniz-Velilla please read that carefully, I guess we'll talk about that tomorrow in the planning. Here is the outcome of the spike: Defining a custom tag in RichText This is absolutely not documented. So here's the configuration with some comments related to custom tags <siteaccess|siteaccess_group>: fieldtypes: ezrichtext: # list of XSLT extending the core docbook to xhtml5 (for frontend) # eZ/Publish/Core/FieldType/RichText/Resources/stylesheets/docbook/xhtml5/output/core.xsl # not really mandatory, the twig template per tag can be used for that # if <eztemplate> element is transformed by this stylesheet, the twig # template is not even used (but twig tpl is mandatory because of config # parsing...) # /!\ path is taken from web/ output_custom_tags: # - {path: ../app/Resources/output_youtube.xsl}   # list of XSLT extending the core html5edit to docbook # eZ/Publish/Core/FieldType/RichText/Resources/stylesheets/xhtml5/edit/docbook.xsl # used when parsing a RichText field value # not mandatory. Useful only if we want to use something else than # <eztemplate> tag to represent a custom tag in the html5edit format # in input. If this feature is used, it makes almost impossible to # correctly support custom tags in the editor. # /!\ path is taken from ezplatform root input_custom_tags: # - {path: app/Resources/input_youtube.xsl}   # list of XSLT extending the code docbook to html5edit # eZ/Publish/Core/FieldType/RichText/Resources/stylesheets/docbook/xhtml5/edit/core.xsl # opposite of input_custom_tags. # not mandatory. Useful only to get a different representation of # custom tag than a `<eztemplate>` tag in html5edit. # /!\ path is taken from web/ edit_custom_tags: # - {path: ../app/Resources/input_youtube.xsl}   tags: <name_of_customtag>: # path directly passed to the template engine service # see http://symfony.com/doc/current/book/templating.html#template-naming-and-locations template: <name_of_twig_template>.html.twig # arbitrary configuration object, did not manage to have access to it in the Twig template, but I did not dig config: The XSLT files are not mandatory. The path is relative to web/ except for input_custom_tags where it's relative the ezplatform root . They allow to tweak how the custom tag are represented in different contexts. By default, custom tags are represented by a eztemplate or eztemplateinline tag in docbook (internal format) and HTML5edit formats. input_custom_tags and edit_custom_tags XSLT allow to use a different tag in HTML5edit format for a custom tag. There's an overlap between the Twig template per tag and XSLT in output_custom_tags . The twig template is mandatory because of the way semantic configuration setup but if you transform the custom tag with an XSLT in output_custom_tags , the Twig template is not used at all. Issues in current code to implement custom tags in Online Editor no information in config on whether a custom tag is a block tag or an inline tag no config for built in custom tags (quote, sup, sub, ...) so now way to get a list edit_custom_tags / input_custom_tags make it very complex to implement custom tags. I don't really see the point in that feature, can we just remove this ability ?. in html5edit, custom tags are represented with eztemplate or eztemplateinline tag. We have to change those to use valid HTML5 elements ( <div> and <span> ) otherwise we'll have issues in browser (we did the same for embed) DX issues No documentation (no, unit tests fixtures are not a documentation), we need a tutorial/cookbook recipe on that topic Misleading comment in the output of php app/console config:dump-reference EzPublishCoreBundle for XSLT settings output_custom_tags and the Twig template does the same thing => do we need output_custom_tags  setting ? Specifications needed https://doc.ez.no/display/PR/Online+Editor:+Scope only mentions custom tags a few times. I guess, for a block tag, we'll have a corresponding entry in the add toolbar but besides this, the feature is not described. There are several things to consider: 1. inline custom tag vs. block custom tag (how do we add inline custom tag ?) 2. the attributes of custom tag are an important topic. For instance, a typical use case for the custom tag is to define a youtube custom tag that accepts 3 attributes: height , width and src . Those attributes are (by default) not visible in the editor, how do we edit them ? 3. some custom tag are designed to have a content (for instance quote ), some are designed to have only attributes to configure it ( youtube for example) and some both. This is also something to take into account. As well.
            Hide
            Petar Spanja (Inactive) added a comment -

            [~damien.pobel@ez.no]

            edit_custom_tags / input_custom_tags make it very complex to implement custom tags. I don't really see the point in that feature, can we just remove this ability ?.

            output_custom_tags and the Twig template does the same thing => do we need output_custom_tags setting ?

            I think I need to explain the intention here.

            The idea is that what was called "custom tags" in the XmlText field type is now, in the RichText field type, called "template tags" – meaning generic configurable tags rendered through template engine. In this POV, "built-in custom tags" does not make sense / is really an oxymoron. What I mean is – if they are built-in, how can they custom at the same time?

            "Custom tags" in the RichText speak would then really mean adding custom elements to the internal format, and "pluggable" XSL snippets is the extension point for users to customize the internal format. For the purpose of flexibility even the main/core transformation is componentized, see https://github.com/ezsystems/ezpublish-kernel/blob/master/eZ/Publish/Core/FieldType/RichText/Resources/stylesheets/docbook/xhtml5/edit/xhtml5.xsl.

            So there is really no duplication here, but two different things instead.

            Show
            Petar Spanja (Inactive) added a comment - [~damien.pobel@ez.no] edit_custom_tags / input_custom_tags make it very complex to implement custom tags. I don't really see the point in that feature, can we just remove this ability ?. output_custom_tags and the Twig template does the same thing => do we need output_custom_tags setting ? I think I need to explain the intention here. The idea is that what was called "custom tags" in the XmlText field type is now, in the RichText field type, called "template tags" – meaning generic configurable tags rendered through template engine. In this POV, "built-in custom tags" does not make sense / is really an oxymoron. What I mean is – if they are built-in, how can they custom at the same time? "Custom tags" in the RichText speak would then really mean adding custom elements to the internal format, and "pluggable" XSL snippets is the extension point for users to customize the internal format. For the purpose of flexibility even the main/core transformation is componentized, see https://github.com/ezsystems/ezpublish-kernel/blob/master/eZ/Publish/Core/FieldType/RichText/Resources/stylesheets/docbook/xhtml5/edit/xhtml5.xsl . So there is really no duplication here, but two different things instead.
            Hide
            Roland Benedetti added a comment -

            Thanks Damien for the feedback.
            On the spec, clearly we'll gear up and provide something more solid.

            For now, the goal, as mentioned on the scope page, is really to provide an "hello word" custom tag - eg an example for developers to develop their own. But yes, this still has to be defined more precisely.
            We can try to specifiy a bit more this "Hello word" example as well as other requirements.

            In the scope, we also have the "quote" element, but this one, I am unsure if it is something you want to do with Custom tag or with built-in formatting capabilities? In other words, this opens the discussion on how to do custom styles.

            ping Sylvain Guittard and [~david.liedle@ez.no] who should be interested in the topic.

            Show
            Roland Benedetti added a comment - Thanks Damien for the feedback. On the spec, clearly we'll gear up and provide something more solid. For now, the goal, as mentioned on the scope page, is really to provide an "hello word" custom tag - eg an example for developers to develop their own. But yes, this still has to be defined more precisely. We can try to specifiy a bit more this "Hello word" example as well as other requirements. In the scope, we also have the "quote" element, but this one, I am unsure if it is something you want to do with Custom tag or with built-in formatting capabilities? In other words, this opens the discussion on how to do custom styles. ping Sylvain Guittard and [~david.liedle@ez.no] who should be interested in the topic.
            Hide
            Damien Pobel (Inactive) added a comment - - edited

            Petar Spanja

            The idea is that what was called "custom tags" in the XmlText field type is now, in the RichText field type, called "template tags" – meaning generic configurable tags rendered through template engine. In this POV, "built-in custom tags" does not make sense / is really an oxymoron. What I mean is – if they are built-in, how can they custom at the same time?

            Indeed that makes sense.

            "Custom tags" in the RichText speak would then really mean adding custom elements to the internal format, and "pluggable" XSL snippets is the extension point for users to customize the internal format. For the purpose of flexibility even the main/core transformation is componentized, see https://github.com/ezsystems/ezpublish-kernel/blob/master/eZ/Publish/Core/FieldType/RichText/Resources/stylesheets/docbook/xhtml5/edit/xhtml5.xsl.

            I'm sorry but I still don't see the point in customizing that much a format like HTML5edit. OK This brings a flexibility but what for ? where is the current need for that ? which real usecase does that solve ? Worse, this complicates things to implement the rich text editor which is needed now! Also, you seem to forget that we have developers that are supposed to use this feature and to be very frank, it's a really confusing and even with documentation (I mean a real one not fixtures laying somewhere in a git repository) it would still be confusing.

            Also while at it, in my opinion (and I know Bertrand Dunogier shares it), eztemplate is a very bad name for that feature. The point of using a custom XML instead of just HTML in RichText (and in XMLText) is to think in terms of structure and semantic, not to think in terms of how it will be rendered. In that regard, eztemplate is kind of the opposite. From a RichText field point of view, how a custom tag or a eztemplate tag is rendered is a detail until it is rendered in the frontend where yes we could use a template but we can imagine some tag rendered differently.

            Show
            Damien Pobel (Inactive) added a comment - - edited Petar Spanja The idea is that what was called "custom tags" in the XmlText field type is now, in the RichText field type, called "template tags" – meaning generic configurable tags rendered through template engine. In this POV, "built-in custom tags" does not make sense / is really an oxymoron. What I mean is – if they are built-in, how can they custom at the same time? Indeed that makes sense. "Custom tags" in the RichText speak would then really mean adding custom elements to the internal format, and "pluggable" XSL snippets is the extension point for users to customize the internal format. For the purpose of flexibility even the main/core transformation is componentized, see https://github.com/ezsystems/ezpublish-kernel/blob/master/eZ/Publish/Core/FieldType/RichText/Resources/stylesheets/docbook/xhtml5/edit/xhtml5.xsl . I'm sorry but I still don't see the point in customizing that much a format like HTML5edit. OK This brings a flexibility but what for ? where is the current need for that ? which real usecase does that solve ? Worse, this complicates things to implement the rich text editor which is needed now! Also, you seem to forget that we have developers that are supposed to use this feature and to be very frank, it's a really confusing and even with documentation (I mean a real one not fixtures laying somewhere in a git repository) it would still be confusing. Also while at it, in my opinion (and I know Bertrand Dunogier shares it), eztemplate is a very bad name for that feature. The point of using a custom XML instead of just HTML in RichText (and in XMLText) is to think in terms of structure and semantic, not to think in terms of how it will be rendered. In that regard, eztemplate is kind of the opposite. From a RichText field point of view, how a custom tag or a eztemplate tag is rendered is a detail until it is rendered in the frontend where yes we could use a template but we can imagine some tag rendered differently.
            Hide
            Petar Spanja (Inactive) added a comment -

            [~damien.pobel@ez.no]

            Worse, this complicates things to implement the rich text editor which is needed now!

            Sorry, but how so? Custom tags are covered by template tags and new RichText custom tags is additional customization feature that previously did not exist. If this level of customization is deemed not necessary, you can just remove the semantic configuration for it and be done with it.

            The point of using a custom XML instead of just HTML in RichText (and in XMLText) is to think in terms of structure and semantic, not to think in terms of how it will be rendered.

            Of course, and that is why I added tags like <sub>, <sup>, <strike>, <quote> and the like to the internal format. Initially RichText's internal format was limited to support what XmlText supports, because migration (and then open question about converting back to XmlText), but post that we are of course free to evolve it further. Template tags are for easy customization and stuff like nested markup, they are generic by nature and the name actually reflects it.

            Also while at it, in my opinion (and I know Bertrand Dunogier shares it), eztemplate is a very bad name for that feature.

            FWIW it was implemented and reviewed two years ago now, naming is hard and if it is very bad we should improve it.

            Show
            Petar Spanja (Inactive) added a comment - [~damien.pobel@ez.no] Worse, this complicates things to implement the rich text editor which is needed now! Sorry, but how so? Custom tags are covered by template tags and new RichText custom tags is additional customization feature that previously did not exist. If this level of customization is deemed not necessary, you can just remove the semantic configuration for it and be done with it. The point of using a custom XML instead of just HTML in RichText (and in XMLText) is to think in terms of structure and semantic, not to think in terms of how it will be rendered. Of course, and that is why I added tags like <sub>, <sup>, <strike>, <quote> and the like to the internal format. Initially RichText's internal format was limited to support what XmlText supports, because migration (and then open question about converting back to XmlText), but post that we are of course free to evolve it further. Template tags are for easy customization and stuff like nested markup, they are generic by nature and the name actually reflects it. Also while at it, in my opinion (and I know Bertrand Dunogier shares it), eztemplate is a very bad name for that feature. FWIW it was implemented and reviewed two years ago now, naming is hard and if it is very bad we should improve it.
            Hide
            Damien Pobel (Inactive) added a comment -

            Sorry, but how so? Custom tags are covered by template tags and new RichText custom tags is additional customization feature that previously did not exist.

            with that system a custom tag can be represented by anything in HTML5edit, I mean by looking at the HTML5edit document, there's no easy way to know if a given tag transformed by the XSLT is representing a custom tag or not since we completely loose control on how a custom tag is represented. Of course, we could bring some knowledge of HTML5edit to the JavaScript but this is exactly the complexity you should/could avoid. Also this will kind of duplicate what is already implemented in PHP. While if a custom tag is always represented the same way let's say a <div data-ezcustomtag="nameofyourtag"></div> for a block, it becomes super easy to find them, the markup is auto-descriptive and semantic for an editor and we can still put something in that div to give a visual representation of it to the editor.

            If this level of customization is deemed not necessary, you can just remove the semantic configuration for it and be done with it.

            that's exactly the question I wrote in the first comment.

            Show
            Damien Pobel (Inactive) added a comment - Sorry, but how so? Custom tags are covered by template tags and new RichText custom tags is additional customization feature that previously did not exist. with that system a custom tag can be represented by anything in HTML5edit, I mean by looking at the HTML5edit document, there's no easy way to know if a given tag transformed by the XSLT is representing a custom tag or not since we completely loose control on how a custom tag is represented. Of course, we could bring some knowledge of HTML5edit to the JavaScript but this is exactly the complexity you should/could avoid. Also this will kind of duplicate what is already implemented in PHP. While if a custom tag is always represented the same way let's say a <div data-ezcustomtag="nameofyourtag"></div> for a block, it becomes super easy to find them, the markup is auto-descriptive and semantic for an editor and we can still put something in that div to give a visual representation of it to the editor. If this level of customization is deemed not necessary, you can just remove the semantic configuration for it and be done with it. that's exactly the question I wrote in the first comment.
            Hide
            André Rømcke added a comment -

            Petar Spanja Side question, does the current xsl transformations used by migration handle migrating the old custom tags to the new internal format when there is one? (ref first comment)

            Show
            André Rømcke added a comment - Petar Spanja Side question, does the current xsl transformations used by migration handle migrating the old custom tags to the new internal format when there is one? (ref first comment)
            Hide
            Petar Spanja (Inactive) added a comment -

            with that system a custom tag can be represented by anything in HTML5edit, I mean by looking at the HTML5edit document, there's no easy way to know if a given tag transformed by the XSLT is representing a custom tag or not since we completely loose control on how a custom tag is represented. Of course, we could bring some knowledge of HTML5edit to the JavaScript but this is exactly the complexity you should/could avoid.

            Yes, that's the nature of it. Wheter you want to avoid it depends on what you need.

            Also this will kind of duplicate what is already implemented in PHP. While if a custom tag is always represented the same way let's say a <div data-ezcustomtag="nameofyourtag"></div> for a block, it becomes super easy to find them, the markup is auto-descriptive and semantic for an editor and we can still put something in that div to give a visual representation of it to the editor.

            Well, that would be a template tag, or am I missing the point?
            BTW I wouldn't say it is semantic, to me it is really a generic tag carrying some configuration parameters with it.

            Show
            Petar Spanja (Inactive) added a comment - with that system a custom tag can be represented by anything in HTML5edit, I mean by looking at the HTML5edit document, there's no easy way to know if a given tag transformed by the XSLT is representing a custom tag or not since we completely loose control on how a custom tag is represented. Of course, we could bring some knowledge of HTML5edit to the JavaScript but this is exactly the complexity you should/could avoid. Yes, that's the nature of it. Wheter you want to avoid it depends on what you need. Also this will kind of duplicate what is already implemented in PHP. While if a custom tag is always represented the same way let's say a <div data-ezcustomtag="nameofyourtag"></div> for a block, it becomes super easy to find them, the markup is auto-descriptive and semantic for an editor and we can still put something in that div to give a visual representation of it to the editor. Well, that would be a template tag, or am I missing the point? BTW I wouldn't say it is semantic, to me it is really a generic tag carrying some configuration parameters with it.
            Hide
            Petar Spanja (Inactive) added a comment -

            André Rømcke

            Side question, does the current xsl transformations used by migration handle migrating the old custom tags to the new internal format when there is one? (ref first comment)

            Yes indeed, in RichText's internal format there is a native support for these tags that were previously implemented as built-in custom tags:

            • <custom name="underline"> => <emphasis role="underlined">
            • <custom name="sup"> => <superscript>
            • <custom name="sub"> => <subscript>
            • <custom name="strike"> => <emphasis role="strikedthrough">
            • <custom name="quote"> => <blockquote>

            The rest is converted to <eztemplate> and <eztemplateinline> and will also need to have templates in order to be rendered properly.

            Show
            Petar Spanja (Inactive) added a comment - André Rømcke Side question, does the current xsl transformations used by migration handle migrating the old custom tags to the new internal format when there is one? (ref first comment) Yes indeed, in RichText's internal format there is a native support for these tags that were previously implemented as built-in custom tags: <custom name="underline"> => <emphasis role="underlined"> <custom name="sup"> => <superscript> <custom name="sub"> => <subscript> <custom name="strike"> => <emphasis role="strikedthrough"> <custom name="quote"> => <blockquote> The rest is converted to <eztemplate> and <eztemplateinline> and will also need to have templates in order to be rendered properly.
            Hide
            Petar Spanja (Inactive) added a comment -

            [~damien.pobel@ez.no]

            From a RichText field point of view, how a custom tag or a eztemplate tag is rendered is a detail until it is rendered in the frontend where yes we could use a template but we can imagine some tag rendered differently.

            Sorry, I skipped this. If you preclude templates and XSL, different how?

            Show
            Petar Spanja (Inactive) added a comment - [~damien.pobel@ez.no] From a RichText field point of view, how a custom tag or a eztemplate tag is rendered is a detail until it is rendered in the frontend where yes we could use a template but we can imagine some tag rendered differently. Sorry, I skipped this. If you preclude templates and XSL, different how?
            Hide
            Damien Pobel (Inactive) added a comment -

            Well, that would be a template tag, or am I missing the point?

            No, not a eztemplate tag because browsers don't like custom tag name in HTML5 document, since they don't know what to do with it and it's even worse in contenteditable zone with CKEditor (remember you did the same change, <ezembed> to <div> with data attributes in https://github.com/ezsystems/ezpublish-kernel/pull/1435/ for the exact same reason).

            BTW I wouldn't say it is semantic, to me it is really a generic tag carrying some configuration parameters with it.

            semantic in the context of an WYSIWYG like editor with the trade-off of not using a custom element in HTML5 for the reasons exposed above.

            Sorry, I skipped this. If you preclude templates and XSL, different how?

            with a service or not rendered at all in some context. Again when you include a custom tag in a RichText, you include a thing, a widget or whatever you call it but that's not necessarily end up in template. The template is a way to render it not what you include.

            Show
            Damien Pobel (Inactive) added a comment - Well, that would be a template tag, or am I missing the point? No, not a eztemplate tag because browsers don't like custom tag name in HTML5 document, since they don't know what to do with it and it's even worse in contenteditable zone with CKEditor (remember you did the same change, <ezembed> to <div> with data attributes in https://github.com/ezsystems/ezpublish-kernel/pull/1435/ for the exact same reason). BTW I wouldn't say it is semantic, to me it is really a generic tag carrying some configuration parameters with it. semantic in the context of an WYSIWYG like editor with the trade-off of not using a custom element in HTML5 for the reasons exposed above. Sorry, I skipped this. If you preclude templates and XSL, different how? with a service or not rendered at all in some context. Again when you include a custom tag in a RichText, you include a thing, a widget or whatever you call it but that's not necessarily end up in template. The template is a way to render it not what you include.
            Hide
            Petar Spanja (Inactive) added a comment - - edited

            No, not a eztemplate tag because browsers don't like custom tag name in HTML5 document, since they don't know what to do with it and it's even worse in contenteditable zone with CKEditor (remember you did the same change, <ezembed> to <div> with data attributes in https://github.com/ezsystems/ezpublish-kernel/pull/1435/ for the exact same reason).

            Of course, but that does not really change the nature of it and is really an implementation detail.

            with a service or not rendered at all in some context. Again when you include a custom tag in a RichText, you include a thing, a widget or whatever you call it but that's not necessarily end up in template. The template is a way to render it not what you include.

            Of course, I would not think to argue that, so I guess we really discussing naming here.
            FWIW as far as I remember my reasoning here, you can also understand "template" as matrix for something and not a template engine. But even if it is not the happiest choice, I didn't hear the improvement proposal so far

            PS Maybe "custom" tags would still fit here, but please only as far as we don't ship any

            Show
            Petar Spanja (Inactive) added a comment - - edited No, not a eztemplate tag because browsers don't like custom tag name in HTML5 document, since they don't know what to do with it and it's even worse in contenteditable zone with CKEditor (remember you did the same change, <ezembed> to <div> with data attributes in https://github.com/ezsystems/ezpublish-kernel/pull/1435/ for the exact same reason). Of course, but that does not really change the nature of it and is really an implementation detail. with a service or not rendered at all in some context. Again when you include a custom tag in a RichText, you include a thing, a widget or whatever you call it but that's not necessarily end up in template. The template is a way to render it not what you include. Of course, I would not think to argue that, so I guess we really discussing naming here. FWIW as far as I remember my reasoning here, you can also understand "template" as matrix for something and not a template engine. But even if it is not the happiest choice, I didn't hear the improvement proposal so far PS Maybe "custom" tags would still fit here, but please only as far as we don't ship any
            Hide
            Eirik Alfstad Johansen added a comment -

            This is quite a big deal for us. Our new web site is based on eZ Platform, and we have a set blog publication plan. However, the lack of a code custom element is making it very difficul (nearly useless) to publish technical blog posts with code examples, as the code with a normal body formatting is very close to unreadable.

            Has there been discussed any ETA for this?

            Show
            Eirik Alfstad Johansen added a comment - This is quite a big deal for us. Our new web site is based on eZ Platform, and we have a set blog publication plan. However, the lack of a code custom element is making it very difficul (nearly useless) to publish technical blog posts with code examples, as the code with a normal body formatting is very close to unreadable. Has there been discussed any ETA for this?
            Hide
            André Rømcke added a comment -

            As for ETA I'll let Roland Benedetti give some insight into this.

            As for code examples, preformated text should probably be added at some point, and benefit with that is a bit more native handling in editor, while maybe not at first having features like code styling and so on. Would that help or do you prefer custom tag for this?

            Show
            André Rømcke added a comment - As for ETA I'll let Roland Benedetti give some insight into this. As for code examples, preformated text should probably be added at some point, and benefit with that is a bit more native handling in editor, while maybe not at first having features like code styling and so on. Would that help or do you prefer custom tag for this?
            Hide
            Petar Spanja (Inactive) added a comment - - edited

            FWIW, if not implemented through template/custom tag, maybe this is something to consider for internal format:

            Show
            Petar Spanja (Inactive) added a comment - - edited FWIW, if not implemented through template/custom tag, maybe this is something to consider for internal format: http://www.docbook.org/tdg5/en/html/code.html http://www.docbook.org/tdg5/en/html/programlisting.html
            Hide
            Eirik Alfstad Johansen added a comment -

            Preformatted text would be fine as a start. Custom tags allowing the selection of a specific code style, for instance, is more of a nice to have.

            Show
            Eirik Alfstad Johansen added a comment - Preformatted text would be fine as a start. Custom tags allowing the selection of a specific code style, for instance, is more of a nice to have.
            Hide
            Damien Pobel (Inactive) added a comment -

            André Rømcke Roland Benedetti Bertrand Dunogier Following our yesterday meeting, I created EZP-26838 to change the representation of the custom tags in the xhtml5edit format so that browsers are not confused by unknown tag.

            As I was saying yesterday (and in my first comment in this EPIC), if developers are able to tweak that with an XSLT file (edit_custom_tags setting), it's impossible to detect a custom tag in a reliable way in the editor so I would lean toward removing that feature (unless I'm missing a clear usecase for it)

            I was also about to create an another story to improve each custom tag settings so that it contains whether it's a block or an inline tag, whether it is supposed to have an editable content and its potential attribute definition but I've just realized that the custom tag configuration is siteaccess aware. This makes sense for defining the template to use to render a given tag but for structure information about a tag I have the feeling this is wrong and will inevitably lead to issues. Do you guys have an opinion on that ?

            Show
            Damien Pobel (Inactive) added a comment - André Rømcke Roland Benedetti Bertrand Dunogier Following our yesterday meeting, I created EZP-26838 to change the representation of the custom tags in the xhtml5edit format so that browsers are not confused by unknown tag. As I was saying yesterday (and in my first comment in this EPIC), if developers are able to tweak that with an XSLT file (edit_custom_tags setting), it's impossible to detect a custom tag in a reliable way in the editor so I would lean toward removing that feature (unless I'm missing a clear usecase for it) I was also about to create an another story to improve each custom tag settings so that it contains whether it's a block or an inline tag, whether it is supposed to have an editable content and its potential attribute definition but I've just realized that the custom tag configuration is siteaccess aware. This makes sense for defining the template to use to render a given tag but for structure information about a tag I have the feeling this is wrong and will inevitably lead to issues. Do you guys have an opinion on that ?
            Hide
            André Rømcke added a comment -

            > I created EZP-26838 to change the representation of the custom tags in the xhtml5edit format so that browsers are not confused by unknown tag.

            Ignoring the duality of custom vs template tags for a bit here, can't we theoretically map these to custom elements?
            We would just need to make sure it does not conflict with other tags, and be able to generate basic css to define if block or inline, and let user define additional styling if he wants.
            The css could be reused for front3end as well if the custom transformation is generating a similar tag there.Thus keeping semantical meaning of the custom tag both in stored as as well as displayed data.

            > but I've just realized that the custom tag configuration is siteaccess aware.

            Would think definition of tags should be global per repository, content is typically shared across sites per repository so I also don't see point of making this siteaccess aware.

            Show
            André Rømcke added a comment - > I created EZP-26838 to change the representation of the custom tags in the xhtml5edit format so that browsers are not confused by unknown tag. Ignoring the duality of custom vs template tags for a bit here, can't we theoretically map these to custom elements? We would just need to make sure it does not conflict with other tags, and be able to generate basic css to define if block or inline, and let user define additional styling if he wants. The css could be reused for front3end as well if the custom transformation is generating a similar tag there.Thus keeping semantical meaning of the custom tag both in stored as as well as displayed data. > but I've just realized that the custom tag configuration is siteaccess aware. Would think definition of tags should be global per repository, content is typically shared across sites per repository so I also don't see point of making this siteaccess aware.
            Hide
            Damien Pobel (Inactive) added a comment -

            > Ignoring the duality of custom vs template tags for a bit here, can't we theoretically map these to custom elements?

            André Rømcke in theory (and in an ideal world ) yes we could declare the eztemplate tag as a custom element so that it is somehow recognized by the browser. This would involve embedding the polyfill for browsers not supporting that. When viewing a RichText field that would probably work but in the editor (so in a contenteditable area with CKEditor), I have the feeling this won't be that easy. This is only a feeling, we could test/prototype that of course.

            Show
            Damien Pobel (Inactive) added a comment - > Ignoring the duality of custom vs template tags for a bit here, can't we theoretically map these to custom elements? André Rømcke in theory (and in an ideal world ) yes we could declare the eztemplate tag as a custom element so that it is somehow recognized by the browser. This would involve embedding the polyfill for browsers not supporting that. When viewing a RichText field that would probably work but in the editor (so in a contenteditable area with CKEditor), I have the feeling this won't be that easy. This is only a feeling, we could test/prototype that of course.
            Hide
            Roland Benedetti added a comment -

            I've just realized that the custom tag configuration is siteaccess aware ... Do you guys have an opinion on that ?

            I think rendering of tag (presentation) should be siteaccess aware, but what is the structure of a tag should be siteaccess neutral. Should apply to any use case including use cases without siteaccess - APIs.

            Show
            Roland Benedetti added a comment - I've just realized that the custom tag configuration is siteaccess aware ... Do you guys have an opinion on that ? I think rendering of tag (presentation) should be siteaccess aware, but what is the structure of a tag should be siteaccess neutral. Should apply to any use case including use cases without siteaccess - APIs.
            Hide
            Damien Pobel (Inactive) added a comment -

            > André Rømcke in theory (and in an ideal world ) yes we could declare the eztemplate tag as a custom element

            actually no I was re-reading various Web Components/Polymer documents lately and to be a valid custom element name, the name must contain a - (dash) so we could defined ez-template but not eztemplate.

            Show
            Damien Pobel (Inactive) added a comment - > André Rømcke in theory (and in an ideal world ) yes we could declare the eztemplate tag as a custom element actually no I was re-reading various Web Components/Polymer documents lately and to be a valid custom element name, the name must contain a - (dash) so we could defined ez-template but not eztemplate .
            Hide
            André Rømcke added a comment -

            > the name must contain a - (dash)

            I was mostly talking about custom tags with semantic meaning, not eztemplate generic tag.
            So we could then either map it to "ez-" or similar naming, or state custom tags must use hyphen where first part is vendor name, meaning "ez-" would be reserve for us.

            Show
            André Rømcke added a comment - > the name must contain a - (dash) I was mostly talking about custom tags with semantic meaning, not eztemplate generic tag. So we could then either map it to "ez-" or similar naming, or state custom tags must use hyphen where first part is vendor name, meaning "ez-" would be reserve for us.
            Hide
            Jackson Murtha added a comment -

            This issue blocks every one of my potential upgrades to Platform, including enterprise subscribers. Has any solution started development yet?

            Show
            Jackson Murtha added a comment - This issue blocks every one of my potential upgrades to Platform, including enterprise subscribers. Has any solution started development yet?
            Hide
            André Rømcke added a comment - - edited

            Hi Jackson Murtha,

            yes there has been development efforts on this, however we hit a roadblock that means this feature has been postponed to later this year (eta: summer), and once we solve it we hope to deliver this feature both to 1.x (will probably serve the last 1.x release) and 2.x.

            Show
            André Rømcke added a comment - - edited Hi Jackson Murtha , yes there has been development efforts on this, however we hit a roadblock that means this feature has been postponed to later this year (eta: summer) , and once we solve it we hope to deliver this feature both to 1.x (will probably serve the last 1.x release) and 2.x.
            Hide
            Bertrand Dunogier added a comment -

            Moved remaining stories to custom tags M2 (EZP-28940).

            Show
            Bertrand Dunogier added a comment - Moved remaining stories to custom tags M2 ( EZP-28940 ).

              People

              • Assignee:
                Unassigned
                Reporter:
                Roland Benedetti
              • Votes:
                8 Vote for this issue
                Watchers:
                17 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: