You're mixing up elements and element attributes. There is an <cite> element, which it appears Standard Ebooks uses, and a cite attribute, which is seldom used, probably because it's not exposed to the user in any way.

Writing "<download>", with the word in angle brackets, makes it look like an element but it's not, download is an element attribute.

Ack. Yeah, the first one is my mistake looking at it again - although I would argue this element is relatively underused because it's not something you would need outside of contexts where printing is a concern - SE is a slight exception in that they are starting from print transcriptions in most cases.

I am aware of the distinction, I only used that way b/c HN doesn't really have a good way to indicate code without multiple spaces or just blindly using the ` character which is...not great.

<cite> does have a default browser style (italic), Standard Ebook's use of <i> within it would be redundant on the web, I don't know if the conventions are different in EPUB.

How to use <cite> is often misunderstood. Many think it can be used to identify the author of a quotation but it should only be used to name the work a quotation is from. Standard Ebook placed it inside the <blockquote> but I've also seen it placed after <blockquote>, I don't know whether both are considered correct or if it's a point of disagreement; to me, <blockquote> should contain only the quoted material itself but I understand the appeal of having the quote and its source be neatly contained within one semantic element.

Using the Markdown convention of putting backticks around `code` may not be great but at least it won't be confused for the wrong actual code.

SE Editor-in-Chief here. We include <i> within <cite> because 1) reading systems often have different default CSS which may not even recognize <cite> and 2) <cite> often contains both a title and an author, and in those cases we want only one or the other to be italicized. SE's default CSS for epigraphs (probably the most common place where <cite> is found) is to give <cite> small caps, italicize the title if there is one, but don't italicize the author.

I believe our use of <cite> predates the modern definition of its use, and in any case it's so infrequently found in a web context that I don't think there's much agreement about how it should be used anyway. (For example MDN says the work title must be in <cite>, but at SE we often only include an author name, like <cite>--Shakespeare</cite>.)

Interesting, the permissible content in <cite> is mentioned as an example of conflict between the HTML standard as maintained by the W3C and that maintained by WHATWG [0] (W3C allows title and/or author, WHATWG title only). Since WHATWG has been the sole maintainer for a few years, I guess their definition "won."

[0] https://en.wikipedia.org/wiki/HTML5#W3C_and_WHATWG_conflict

> cite attribute, which is seldom used, probably because it's not exposed to the user in any way

I recall in a (lost) blog theme I had at one point in time I'd scrounged a nice bit of CSS to add cite attributes visibly appended to blockquote and q elements. Exposing it to the user is possible in just pure CSS, but it is a bit of a shame that browsers didn't style it by default so many people didn't learn it was a thing.

Yes, you could do something like this:

  <q cite="https://www.w3.org/Consortium/">To lead the
  World Wide Web to its full potential by developing protocols and
  guidelines that ensure long-term growth for the Web</q>

  q::after {
    content: attr(cite);
  }

That will show the source URL for a quote but it's not very useful, the URL isn't clickable (unless you wrap the whole <q> in a link), it's not even selectable text.

While the semantic web mindset (especially the "Xanadu" inspired subsets) thought cite should always be a URL, it didn't technically have to be per the spec. (Without browser behavior backing it as a URL, it certainly didn't have any enforcement to be a URL.) In my case I think I was using it for author annotations in a more "APA or Chicago Style Manual" style at the time I had CSS like that in the style of: —Author Name from "Book/Webpage Title"

Not selectable is still a bit annoying in that case, but Author Names don't need to be clickable links and the point comes across.

The current HTML spec says a cite attribute's value has to be a valid URL [0]. I don't know if that's a point at which the WHATWG and W3C versions differed, like on the <cite> element. I do think it came from a semantic web mindset, that the attribute isn't really for the user, it's for programmatic use by the web host, like a CMS, or other systems.

It used to be the case that the values of `content` properties weren't read by screen readers so this technique would mean the information was solely conveyed visually, that blind screen reader users wouldn't get it, but screen readers have been reading `content` properties for a while.

In any case, if the citation is important information to convey, it should probably exist at a text node in the document, not as metadata that gets pulled out and displayed by the styling.

[0] https://html.spec.whatwg.org/multipage/indices.html#attribut...

  blockquote::after, q::after {
    content: " - " attr(cite);
    display: block;
    font-style: italic;
  }

Should do the trick nicely.