Git Product home page Git Product logo

charles-kingsley_the-water-babies's People

Contributors

gragt avatar

Watchers

 avatar

charles-kingsley_the-water-babies's Issues

Re-review

Just a few minor things.

  • The <div> used for the former tables looks great, except for the page break before/after CSS. I'm not sure why that's there? It is, of course, causing page breaks before and after those lists, which aren't in the scans. I didn't think we want the avoid, either, but when I built the book I saw that it split half of a line on one page and half on the next. What's up with that? Anyway, looks like the avoid is needed. :)
  • Re the ch. 4 lists, I wonder (I know, be afraid)… the "sub-lists" in the first two items are (to me) clearly sub-lists, and should be ul's, as you have them. But looking afresh at 3-5, I wonder if those should just be multiple <p>s in a single <li>? It makes it simpler in structure, and eliminates all of the ol CSS. A li p selector has to be added to the existing li p:first-child, but that's it. And maybe it better represents the data: the "list of things" in 3-5 are not a sub-list, but just a list of things which can be naturally expressed with multiple <p>s. That seems clearer to me on the surface, but I can be talked out of it. :)
  • The replacing the ellipsis with a 3-em dash is editorial since the text is being modified. Sorry, I assumed, but should have said that explicitly. Changing the message requires a rebase, but it's the easiest kind of rebase. If you haven't done it before, let me know and I'll give you the steps.
  • Ditto the changing of the case of that really long title.
  • Again, I should have said explicitly; we don't italicize non-epic poems, but we do quote them (SEMoS 8.2.11.3), so Ode to Duty should have quotes.
  • For the dedication, using a span is not wrong, but we have a lot of precedent in the corpus to use b in that situation.
  • Also, from the scans it appears we want the line-height on the last paragraph as well, so I think the following makes things a little simpler? We format everything using a plain p, then just override what we need to for the last paragraph. (We don't need the margin-bottom: 0 in this particular case (there's nothing after it), but just for completeness…)
section[epub|type~="dedication"] p{
	font-variant: small-caps;
	line-height: 2;
	margin-bottom: 2.5em;
	text-indent: 0;
}

section[epub|type~="dedication"] p:last-of-type{
	font-size: .75em;
	margin-bottom: 0;
}

section[epub|type~="dedication"] b{
	font-size: 1.25em;
}

Review

  • We want elements to be semantically correct, e.g. tables should only be used for tabular data, blockquotes only for actual quotes, etc. IOW, we don't use an element just to get the formatting the element brings. For example, the contents of the tables here aren't tabular data, so something different should be used to accomplish the formatting. I've personally done two different things in different circumstances: one, use display:table, and two, use multiple columns. Either one is going to need a container, which can be a <div> (one of the rare instances when one might be OK), as it doesn't look like anything else is appropriate.
  • Ditto for the first blockquote in ch. 1 and the last in ch. 7; those look like unordered lists, not blockquotes, since there's nothing being quoted.
  • The item in the production notes re "divers" can be removed; modernize-spelling no longer makes that substitution (it was reverted late last year).
  • I don't think the quotes in chapter 6 (a6a4331) are necessary. It's quite common for quotes like that not to have quotemarks, I've seen it quite a bit over the years.
  • The Cu-ru-u-ick, cock-kick, etc. appear to be sounds the cock-grouse is making? If so, then the sounds should be unsemanticate italics (see SEMoS 8.2.6). I think it would be just the sounds, not the words, e.g. come-kick-kick-cock-kick.
  • The smallcaps on Mrs Bedonebyasyoudid in ch. 5 don't seem to be strong emphases (i.e. yelling or close to it), but rather just formatting (especially since the second one is not in dialog). It would seem <b> is more appropriate?
  • (Nit) The "attemps" in the production notes should be "attempts".
  • The M. for Monsieur abbreviations should have a no-break-space between them and the name, just as Mr. and Mrs. do. (Typogrify handles it for Mr/Mrs and others, but since the M. are semanticated manually, the NBSP also has to be added manually.)
  • Only numbers 1 and 2 in the list in ch. 4 need a sub-list; 3/4/5 are at the top-level.
  • It might make the lists more readable to have them match the indentation of the scans, i.e. second and subsequent lines of an item indented? This can be accomplished with something similar to how the "iX" classes of poetry work.
  • Are you sure the three asterisks in the "Suffumigation" line is for obfuscation? I don't know it isn't (if there's a reference there I don't get it), it just seems like an odd use of spaced asterisks.
  • M-W has it as QED, the scans have it as Q.E.D, SEMoS doesn't special-case it, so shouldn't it be capitalized?
  • We only italicize poems that can stand alone, i.e. epic-length (see SEMoS 8.2.11). Bothie qualifies, “Ode to Duty” does not. You can still semanticate “Ode to Duty,” just with a span rather than italics.
  • When we have instances of a poem or part of a poem that have headers on the stanzas, it is another of the rare cases where we use a <div>, which then lets us use a <header> for the stanza header. See, e.g., Ameen Rihani's Poetry. You can then target the headers in CSS.
  • Is there a reason you didn't match the small-caps of the "Come me my riddle…" paragraph in the dedication?

Several corner cases here. I'm fairly confident in the following, but as always feel free to educate me in what I have missed or misunderstood. :) I'm going to ask Alex about at least one them myself, but I don't mind doing so for all of them.

  • The Balzac I just did had a couple of story-specific dedications, and he wanted them put in the file with the story rather than in a separate file. I believe he will want to do the same with these epigraphs, i.e. put them in the chapters as regular epigraphs, not in separate files. Among other things, we don't want them in the ToC. The question is whether they should be "normal" chapter epigraphs, or in their own section so they can, with CSS, still be on their own page. I don't have a strong opinion either way; to keep them on separate pages, the first section would be "chapter-x-epigraph" and the second "chapter-x-body" (which would be sections within the existing "chapter-x" section). See "Gobseck" in the Balzac Shorts from Scenes from Private Life for an example (there it's dedication, but the same concept would apply).
  • Normally lint would flag an se:name title that wasn't titlecased, e.g. "The History of the great and famous nation…", but the current check is only for <= 150 characters. Now, I don't know if that's because Alex doesn't care about titlecase for longer than, or if he's assuming anything longer than that really isn't a title. :) So, even though lint isn't complaining, all English titles normally have to be titlecased, whether they are in the source or not.
  • I know why you used cmn-Latn, I just don't know if it's correct (nor do I know that it isn't correct). The only other instances we have of cmn in the corpus is cmn-Hant for Chinese names in The Art of War; for Chinese Latin characters I only see zh-Latn. This is one I'm truly ignorant on; if you have expertise let me know, otherwise one of our native Chinese speakers can probably speak to it.
  • All of the italicized words in ch. 4 don't feel like emphasis to me. If they are to be italicized, they would be unsemanticated italics, I think, but if there was only one or two they belong to the category of things we would normally scare quote. This is an example (weird italics) that trips me up a lot, so I'm just going to ask Alex about them.
  • As you well know, I'm not very good at long descriptions. This one is very interesting, but the middle three paragraphs are more about Kingsley than the book, and we (Alex) don't want a lot of detail about an author. I'm not suggesting changes, as I'm not qualified, just don't be surprised if Alex wants it shortened. Or, just as likely, he'll think it's the best thing since sliced bread. :)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.