#196 Revert header/footer borders in minimal.css

[Ximin Luo]

These were uncommented in r8472 but that commit only talks about switching to html5 semantic tags, not changing the actual meaning of minimal.css

I assume this is a mistake; it interferes with the purpose of this stylesheet as a minimal stylesheet, and plain.css overrides this later anyway with border:none.

[Ximin Luo]

Link to r8472 for convenience: https://sourceforge.net/p/docutils/code/8472/

[Adam Turner]

The patch is reasonable, but I defer to @milde for rationale here as he authored the original change.

A

[Günter Milde]

Lines separating header and footer from the main part of the document were hard-coded as <hr> elements until [r8472] (cf. the changes to the test documents in this commit).
This hard-coded line was replaced with CSS markup that retains the appearance used in the html4css1 writer but is easier to re-style.

The "minimal.css" style sheet is intended to make all logical markup elements defined by Docutils/rST visually discernible. This is especially important for Docutils elements that do not have a HTML equivalent.
Since HTML5, header and footer have a native HTML representation, however the default rendering in Mozilla and Chromium does nothing to make them stand out from the rest of the document.

Removing the CSS definitions as proposed by the patch would break backwards compatibility for users of "minimal.css" together with a custom style sheet.

[Ximin Luo]

I would argue that, a true meaning of "minimal" means a common subset of what all documentation generators might expect from the background browser. In which case, headers and footers don't naturally start off having lines. This is my motivation for the patch in the first place - I am mixing different documentation generators whilst trying to retain their "minimal.css" equivalents, and this definition from docutils is making its output look different from the others. (And my current workaround is to override these definitions to none locally for my use case.)

However, if you consider strict backwards compatibility more important, then this is a judgment I can't argue against, and we can leave this patch out and close this issue. This information is useful for me though - at least I can expect this behaviour to be stable for docutils in the long run, and therefore my workaround can also remain stable in the long run.

[Günter Milde]

Thank you for the patch and the explanations.