Custom attribute not pushed in the XHTML map

[gbv34]

Hello,
I created a plugin to include a custom attribute in my topics.
Concretely, I needed to add a data-target-id to a p element.
My plugin and the associated dtd are now correctly recognized.

image.png (66.14 KiB) Viewed 1438 times

However, when publishing a test page, I noticed that the new attribute isn't processed in HTML.
I would just like to get confirmation, in addition to the ent file used for the attribute plus the topic dtd customization, if I need to modify another file to make OT able to process and include the attribute in an XHTML source.

Here is the plugin if anyone would like to check it out. It's very simple.

com.gbv.collapse.zip

(7.74 KiB) Downloaded 253 times

Thanks for any feedback or tips

[chrispitude]

Try creating a "passthrough.ditaval" file like this:

Code: Select all

<val>
  <prop action="passthrough" att="data-target-id"/>
</val>

then reference this during publishing:

Code: Select all

dita -i test.dita -f html5 -o out -filter passthrough.ditaval

and you should get the attribute passed through to the output:

Code: Select all

<p class="p topic/p ft-expanding-block-link" data-data-target-id="test-koko"></p>

Note that the DITAVAL "passthrough" appends "data-" to the attribute, so you might want to remove it from your attribute specialization.

I can't take credit for this one. Radu reminded me of this passthrough mechanism a couple weeks ago for something else, and so I happened to remember it for your question.

[gbv34]

Oh that's excellent! Thank you so much Chris for this workaround.
I continued working on it yesterday and I understood that I needed to add an extension in my plugin.xml with

Code: Select all

  <feature extension="dita.xsl.xhtml" value="./xsl/collapse.xsl"/>

Then, I edited the dita2htmlImpl.xsl to support my custom attribute. But, wow, that makes such a work just to add a single attribute in the XHTML publication.

I definitely prefer your solution!

[gbv34]

Hi again!
There's something I don't get though. When I apply the integrator.xml after my changes and check the dita2html-base.xsl file to see if the xsl override file is correctly imported, I noticed the xsl override wasn't precisely targeted.

Here is how the path is inserted:

Code: Select all

<xsl:import xmlns:dita="http://dita-ot.sourceforge.net" href="../../../../../../../../../../../xsl/collapse-min.xsl"/>

instead of:

Code: Select all

<xsl:import href="plugin:com.gbv.collapse:xsl/collapse.xsl"/>

If I manually edit the path, that works perfectly. However, each time I'll integrate the OT, it's likely the path will be updated with a wrong value.
I wonder why it isn't correctly targeted.

[chrispitude]

Can you attach a .zip of the latest version of your plugin, and I'll see if it happens here too?

[gbv34]

Sure!
Here it is attached.
I'm curious to see if you'd have the same behavior.

com.gbv.collapse.zip

(9.3 KiB) Downloaded 253 times

[chrispitude]

Yes, I get the same behavior.

In plugin.xml, can you try using file= for your file references and see if it works for you?

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<plugin id="com.gbv.collapse">
  <feature extension="dita.specialization.catalog.relative" file="catalog.xml"/>
  <feature extension="dita.xsl.xhtml" file="./xsl/collapse-min.xsl"/>
</plugin>

[gbv34]

Fantastic, Chris!
That solved the problem. Thank you

[gbv34]

Ok, I'm back with a minor issue.

I use the following xsl snippets to manage my custom attribute

Code: Select all

<!-- Set data-target-id only -->
  <xsl:template name="setdataTargetId">
    <xsl:if test="@data-target-id">
      <xsl:call-template name="setdataTargetIdattr">
        <xsl:with-param name="dataTargetIdvalue" select="@data-target-id"/>
      </xsl:call-template>
    </xsl:if>
</xsl:template>
  
 
  <!-- Set the dataTargetID attr  -->
  <xsl:template name="setdataTargetIdattr">
    <xsl:param name="dataTargetIdvalue"/>
    <xsl:attribute name="data-target-id"
      select="dita-ot:get-prefixed-id($dataTargetIdvalue/parent::*, $dataTargetIdvalue)"/>
  </xsl:template>
  

However, I notice that the

Code: Select all

<xsl:attribute name="data-target-id"

is not processed.
If I declare:

Code: Select all

<xsl:attribute name="dataa-target-id"

it will pass in the transformation.

Another interesting fact if I add a namespace:

Code: Select all

 <xsl:attribute name="data-target-id" namespace="http://dita-ot.sourceforge.net/ns/201007/dita-ot"

The result will display:

Code: Select all

<p xmlns:dita-ot="http://dita-ot.sourceforge.net/ns/201007/dita-ot" class="p ft-expanding-block-link" dita-ot:data-target-id="testingHere">Link to click</p>

How strange is that? Why the name is conflicting with the process?

[Radu]

Hi,

That's kind of intentional, you are publishing DITA to XHTML, that XHTML needs to be valid according to the XHTML specification which did not allow data-* attributes on elements.
So the DITA Open Toolkit's XHTML plugin has a template in the stylesheet "DITA-OT3.x/plugins/org.dita.xhtml/xsl/dita2html-util.xsl" which strips all HTML5 attributes:

Code: Select all

 <xsl:template match="@*[starts-with(name(), 'data-')]" mode="remove-html5" priority="10"/>

If you would publish DITA to HTML5, the filter would not apply and allow data- attributes to make it through.

Regards,
Radu

[gbv34]

Ok, I understand. Thanks for pointing that out. For now, I just changed the nature of the string in the utils xsl.
I have a correct rendering of the attribute.

Yet, I wonder if there's any way to remove the p attribute class as shown below:
<p class="p ft-expanding-block-link" data-target-id="test-koko">

I checked in

Code: Select all

org.oasis-open.dita.v1_3/base/dtd/commonElements.mod

and I have tried to deactivate it in the declaration of the attributes.

image.png (23.37 KiB) Viewed 1313 times

But I got errors and I don't think it is possible to get rid of this class.

[Radu]

Hi,

Is there a reason in particular you do not want that part of the @class attribute value to be present there? Does it impede rendering the HTML in the browser in any way?
Modifying the DITA DTD is the wrong way to go, editing tools like Oxygen rely on the DTD and on default @class attribute values to properly identify elements, the publishing engine also does. Also the DTD is given by the DITA specification committee, once you modify the DTD officially you are no longer working with DITA XML documents.
If you edit in Oxygen the transformation scenario you are using to publish, in the Parameters list there should be a parameter named "args.xhtml.classattr" which should remove that fragment from all class attributes in the generated HTML docs.
https://www.dita-ot.org/dev/parameters/ ... .classattr

Regards,
Radu

[gbv34]

Oh, yes, Radu, you are definitely right.
However, the reason why I have been looking for this option is that I am forced to make the generation compatible with a script I have no control over. And as for the moment, before giving feedback to the developers who integrated the javascript function into the core of their product, I would like to make sure that my plugin is fully operational.
While testing with handwritten HTML, I found that the "<p class="p" was disrupting the function to operate.
This can be handled later, but the latencies of working with developers being more complex and important than for me, on my side, directly producing a working test content.
So I will test the class.attrs parameter in my publication.
Thanks a lot