In https://github.com/xsf/xeps/pull/1300#issuecomment-1850475278 it
was said that we do not longer simply bump the copyright year
range. But keeping the copyright year at 2021 of all XEPs, including
newer ones from 2023, is also far from ideal.
So let's simply extract the copyright year from the revision
information we already have.
In Firefox the XML+XSLT would render in some weird mode causing some CSS
rules, notably the dark mode background to be applied wrong, or if it
was the box model that was different.
Comparing versions is a thing you may want to do when dealing with a
more or less living standard. Locating these versions in the attic is
often tedious since there are so many XEPs and revisions.
Linking them from the XEP revision history makes this easier, at least
where the relevant revision does exist in the attic, not all do, and
some are called jep rather than xep for historical reasons.
When a XEP has been superseded (or supersedes something else) it's not
always immediately obvious in the HTML output. It exists at the bottom
of the page in the appendices, but this requires a lot of digging, and
in the status message, but this is a big red blob of text that we don't
expect to differ from XEP to XEP and is harder to parse through than the
information we want being in a table.
This adds the information to a third place, the table in the header to
make it more obvious.
In case the XEP has not yet a shortname assigned, the transformation
would add a superfluous line break in the postfix due a missing
<xsl:text> element.
I am tired of seeing all those badly or misreferenced XEPs out
there. This produces a high-quality BibLaTeX entry that follows the
recommendations of the biblatex Package and
draft-carpenter-rfc-citation-recs-01 § 5.2 [1].
It also uses proper 'date' attribution, from the first date in the XEP
history to the date of the latest revision entry.
1: https://tools.ietf.org/html/draft-carpenter-rfc-citation-recs-01#section-5.2
While a draft "standard" of the CSS Working Group of the W3C (as
much as any W3C "living document" is a "standard" in any meaning of
the word) says in a (non normative) section that both semicolon and
comma are allowed [1], the MDN has the following thing to say [2]:
> To mitigate this problem of virtual viewport […], Apple introduced
> the "viewport meta tag" […]. Apple's documentation does a good job
> explaining how web developers can use this tag, but we had to do
> some detective work to figure out exactly how to implement it in
> Fennec. For example, Safari's documentation says the content is a
> "comma-delimited list," but existing browsers and web pages use
> any mix of commas, semicolons, and spaces as separators.
This leaves us to believe that although some W3C document says that
both are ok, comma is the more portable choice.
[1]: https://drafts.csswg.org/css-device-adapt/#viewport-meta
[2]: https://developer.mozilla.org/en-US/docs/Web/HTML/Viewport_meta_tag
We were previously generating HTML5, while claiming to be
XHTML 1.0 and serving the content with text/html Content-Type.
Not ideal.
This change generates the proper HTML5 document type using a
slightly awful, but required, hack because HTML5 is using a weird
doctype format not supported by XSLT (1.0, anyways).
Using indent='no' prevents any spurious whitespace from being
generated in the output. This ensures that user agents do not
render such whitespace in places where none should be, for example
between the <li/> elements of an authors list.
Thanks to @flowdalic for finding and reporting.
