Review: Blockquotes

[vr8hub]

• [x] Blockquotes that are verse and have endnote references should have the reference inside the last span, not outside it. For example, if you look at endnotes 17 and 18 in Protagoras in the built epub, 17 is immediately following the closing quote (as it should be), while 18 is on a line by itself after the closing quote. If you move reference 18 inside the closing </span>, it will also appear on the same line immediately following the quote. There are more references like that; you might just be able to search for "</span><a href". (While looking at something else, I do see that you have several instances where the reference is inside the span, so I may have just stumbled upon a couple of mistakes.)
• [x] Speaking of note 17, the blockquote that note is on doesn't have an epub type, but the quote is from the Iliad, which is (properly) tagged as a poem. That would make a quote from it verse, so it should a) have a verse tag on the blockquote, and b) use verse styling, i.e. a <span> within the <p>. We do this even if it's only a single line of verse. I haven't looked at all the blockquotes yet, so if there are others like that (quoting a single line from a poem), they should be formatted that way as well.
• [x] And speaking of note 18, the blockquote that note is on doesn't have any ending punctuation. Also, the second line has a comma instead of the semi-colon in the scans. The former was probably accidentally dropped when the source ("Works and Days") was moved from inline to an endnote. The comma to semi-colon change was made by the transcription for some reason; I'm not sure whether we care, but punctuation in verse is usually important. (I only saw the comma to semi-colon because I was already looking at it because of the missing ending punctuation.)
• [x] Blockquotes that are entirely a foreign language should have the tag on the blockquote rather than on the span. For example, the Greek quote towards the beginning of "Sophist" (ὅς χ’ ἕτερον…) should have the language tag on the blockquote, e.g. <blockquote epub:type="z3998:verse" xml:lang="grc">. See SEMoS 8.2.9.6. I will note that I have never gotten body [xml|lang] to work without causing other problems; I use blockquote[xml|lang].

[irontigran]

Should be fixed in the linked PR.

Edit: I checked other instances of blockquotes not having ending punctuation besides note 18 - the rest of them matched scans.

[vr8hub]

I was following up looking at everything mentioned, and saw a (different) Greek blockquote in the endnotes that wasn't italicized. It is properly tagged, so this is due to the CSS not being updated per what I mentioned in the last item above (be sure to look at the SEMoS link; there's another line required at the top of the CSS).

[irontigran]

I'm sorry, I completely skipped over adding the CSS. I added body [xml|lang] without seeing any obvious problems (though I didn't check the entire book). Is there anything I should be looking for?

[vr8hub]

No worries, lots going on.

Unfortunately, in my experience, you have to check the entire book. For example, if there are spans with the tag, e.g. <span xml:lang="lang">, it will italicize those when obviously they should not be. And my theory is that shouldn't be necessary; we added the tag to one or more blockquotes, so we want to target the blockquote with the tag, and we don't want to target anything else. At least that's what makes sense to me. That's why I said I use blockquote[xml|lang] (notice there is no space).

I've never understood why the manual has that, and I've never been able to successfully use it. But, this conversation is going to motivate me to ask again.

[irontigran]

I scanned all the elements that had an xml:lang attribute - all of them were either <blockquote> or <i> elements. I also scanned the ebook and visually confirmed that each blockquote with an xml:lang attribute displayed correctly.

I'll wait for the discussion on the mailing list to conclude, but I don't think body [xml|lang] is causing any problems at the moment.

[vr8hub]

No need to wait; the discussion is just about what the manual says as the "default" when this happens, he's already said it can be "tweaked" on an individual production. If you're positive it's not causing any problems, then we're good. (My discussion isn't about whether it ever works, but whether it should be the default in the manual.)

I believe that's it. Let's send this thing to Alex!