Make HTML5 header easier to style precisely in default template

[jbrains]

I've added an ID to the header element of the HTML5 template in order to style the element with a more-precise CSS rule. This should enable more flexibility without damaging any existing style rules out there which styled the header tag without reference to the ID I've added.

Composing an article in Typora triggered this change. Pandoc's HTML5 template generates a header with document information that I didn't want to display, which led me to style it as header { display: none; }. Typora, unfortunately, uses the header tag to implement its editor sidebar, including useful things like a file tree and a document outline. By styling the document with header { display: none; }, I was turning that useful feature off. I wanted it back on.

Yes, I could use just a local template override, but it seems to me that this change can only benefit users and not hurt them. Anyone who needs to style header will not be affected by the change and anyone who would be annoyed by styling header instead of more specific subset of HTML nodes is pleasantly surprised by the helpful ID to select for their style rule. By the look of it, everyone wins.

This would introduce a slightly different incompatibility between the HTML4 template (<div id="{header-prefix}header">) and the HTML5 template (<header id="document-summary-header">), but a similar incompatibility was already there, so this change doesn't make that any worse. We could argue for a better ID for this element, and I really don't mind what it's called.

[mb21]

I don’t understand the use case. How do you integrate Typora’s html/css with the one generated by pandoc? Shouldn’t you just produce an html fragment (without header/body) and place that in your cms?

[jbrains]

I use the same custom CSS stylesheet both as a Typora theme and when I use Pandoc to generate either a standalone HTML document or an HTML fragment. Sometimes I want a fragment (blog post) and sometimes I want a standalone document (article published as PDF, for which I use print-only CSS styles). It would be convenient to be able to use the same CSS stylesheet for all three cases. This also increases the likelihood that what I see in Typora is what I get when I process the document with Pandoc.

Without this proposed change, I would need to maintain two different CSS stylesheets: one for Typora to use that doesn't style header and one for Pandoc to use for standalone documents that adds a rule to style header. The change I propose here is still compatible with using a different stylesheet for Typora than with Pandoc/standalone, but it becomes easier to use the same CSS stylesheet for both. Otherwise it doesn't hurt any existing users, who either ignore header altogether or whose CSS style rules for header will continue to work. This change appears to add flexibility without adding constraints.

[jgm]

Why not use CSS to suppress header h1.title and header p.author and header p.date? That would suppress the metadata elements pandoc adds, without affecting the Typora header.

Agreed that this is a fairly innocuous change, though there's always some risk of collisions with auto-generated identifiers when you put an identifier in the template. (Auto-generated identifiers are aware of duplicates within the document content, but they're not aware of what's in the template, so if you had a header # Document summary header you'd get a duplicate id.)

As far as naming goes, I might favor something like title-block-header.

[jbrains]

@jgm I don't want to play Whack-a-Mole with whatever might show up in the header in the future as that template changes. It more directly reflects my intent to hide header.

I'm happy to change the name to title-block-header or anything else for that matter. Perhaps you have a suggestion for something that contains nonce or some other string very unlikely to be automatically generated by a heading/outline element.

[jbrains]

It looks like the Travis CI job failed, rather than the changes failing the build. I don't know how to re-trigger a build, otherwise I would just try it again. The Travis CI message suggests a stalled build, since it stopped after exactly 10 minutes.

I'm trying to close, then reopen the pull request, hoping that will trigger a new build attempt.

[jbrains]

I can't read the Travis CI test failure here and I don't know why it only happens with the stack nightly build and not the other platform versions. That seems very strange to me and I don't know what I'm missing, nor even how to start to figure that out.

If someone more familiar with running the development environment for this project would point me in the right direction, I'd appreciate it; otherwise, I'm stuck and hoping that someone would be willing to step in.

[jgm]

@jbrains this failure has nothing to do with your change.

[jbrains]

Thanks! I hoped so, but when the same thing failed twice, I wasn't sure any more.