HTML5: Header and footer not created in TOC file

[lakokkonen]

I'm not sure if this is a bug or a feature, so I didn't raise an issue yet.

Using the args.hdr and args.ftr parameters in HTML5 output does not create the header or footer in the TOC file (the cover page).

Looking at the plugin files, the cover.xsl file indeed calls for the corresponding templates (gen-user-hdr, processHDR, etc..), but the issue seems to be that the HDR and FTR parameters are never passed on to the XSL stylesheets from build_dita2html5.xsl.

As soon as I place, manually or via a plugin:

<param name="HDR" expression="${args.hdr.url}" if:set="args.hdr.url"/>

in the macrodef name="html5.map", the header is created automatically. Same goes for the footer with the FTR parameter.

I was just wondering if this is intentional behavior, since there have been some questions about this in the DITA-OT users group. Here for example. It would seem logical that these common elements were created automatically. Hard-coding them in a custom args.html5toc.xsl works, but it's additional work to manually update them if there's a change in the header or footer. And since the parameters are not passed on, the user can't use the args.hdr or args.ftr files in their custom toc.xsl file, either.

Using DITA-OT 4.1.1. from the command line.

(My terminology might be a bit off, sorry about that)

[jdwinfodesign]

By default, the HTML5 transform outputs your HTML topics, along with a file that contains the TOC. The XSL file map2html5-cover.xsl (or whatever you are using to override it) provides the rules for the TOC page. I usually use this file for a logo and whatever else we want, like metadata from the map file, to create a landing page. We don't use a header or footer on our landing page. I'm not sure what I would do the get that info into the XSL, but that's the place to start. Maybe a real expert will chime in and educate us both!

[chrispy-snps]

@lakokkonen - given that the header and footer templates are explicitly called in cover.xsl, it seems like a bug that the parameters they require are never passed.

I suggest filing an issue for this, then we can submit a pull request to get it fixed.