Add section on sub-field input and formatting

[bdarcus]

Evolving out of citation-style-language/schema#278, we should add a section on this, to at least establish the baseline sub-field input and formatting features of:

• italic
• bold
• verbatim/code
• quotes
• preserve case

... and maybe strikethrough (though I'm unclear on the use case here related to citations) and small-caps (this is a presentional detail unsupported by semantic markup languages like HTML, markdown, etc).

Small-caps and preserve-case, however, can be supported with a reserved span/@class value, like so:

Some title with <span class="preserve-case">foo</span> and <span class="small-caps">bar</span.

Note that CSS has text-transform=none for case preservation.

Questions

1. Which variables should this apply to, beyond titles?

Proposal

We need additions in two places:

1. Either in the specification document, or (probably better) in a separate document, to specify the input format, including a section on this. If we address Add title and description annotations to JSON Schema elements schema#190 correctly, this could be auto-generated from the json schema. Per this comment, we could even integrate the document generations into the github actions workflow.
2. The specification section on "Text" needs to say how 1 will impact on formatting; what the processor should do with these data. This would include the "flip-flopping" behavior and such.

[bwiernik]

We need preserve case for at least two cases:

1. Preventing uppercasing of species names in Title Case.
2. Preventing upper casing of things like software titles at the beginning of titles.

Strikethrough is occasionally used in titles, usually for light comic effect.

I think this can apply to any name or standard variable.

[bdarcus]

I think this can apply to any name or standard variable.

Really? Maybe a couple/few examples, with at least one name?

[bwiernik]

e. e. cummings should not be uppercased ever

[bdarcus]

Great example. Also "bell hooks".

But where would that be exposed as a problem? Don't we assume no messing with case in names; that the data represents the proper casing? I do see it is a problem if the name is in a title, because while a processor can know how to title case sentence case, it will fail on names that are all lower?

[bwiernik]

We permit @text-case on cs:name-part.

[bwiernik]

In terms of common field markup, we should also consider underlining.

[bdarcus]

How would that relate to italic/emphasis?

…

On Wed, Dec 16, 2020, 10:57 AM Brenton M. Wiernik ***@***.***> wrote: In terms of common field markup, we should also consider underlining. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#104 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAI3SWEOJ4DMORV64BA5LSVDKFDANCNFSM4OKRILSA> .

[bwiernik]

Separate (e.g., <i></i> versus <u></u>). The specific use case I am encountering at the moment is that my university wants graduate student names in bold and my name underlined for our CV formatting.

[bdarcus]

This is tied to a larger discussion of how we will deal with mapping input subfield formatting to output. Generally speaking, over the long history of typography, italics and underlines have both been used to indicate some kind of emphasis; to set it off from the base text formatting. In bibliographic data, that data is often representing titles, names, etc. What I'm wondering about is this: Underlining is an archaic practice completely unnecessary, and arguably exceedingly tacky, in the 21st century. So what if we have a style that takes that position, and insists underline not be used in output, and instead some other convention (bold or italic)? For this example, let's say italic. What happens if we have an input field with both underline and italic, and the output for the field as a whole is italic? Not sure if I'm explaining this well; do you get what I'm saying?

[bwiernik]

I understand the history and context. What I am saying is that from the perspective of CSL, underline and italics should be treated as completely independent of each other. Italics is italics. Underline is underline. They have nothing otherwise to do with each other. Just like how we call underlining "text-decoration" in CSL styles that that has no interaction with "font-face='italic'".

If the style field is italic and a word is marked up to be underlined, that word would be italic and underlined. If it were marked up to be italic and underlined, that word would be non-italic and underlined (italic flip-flopping). We could potentially implement general flip-flopping for bold/italic/underline, but I don't see much demand for that.

I certainly agree that underlining is generally archaic, but underlinining is (1) one of the few major text decoration features we aren't supporting and (2) especially for one-off field markup like highlighting a specific name or group of names in a reference list, is a format that generally doesn't conflict with other styling (e.g., most styles use italics, so it doesn't really stand out if italics is also used for emphasis).

[bdarcus]

If the style field is italic and a word is marked up to be underlined, that word would be italic and underlined. If it were marked up to be italic and underlined, that word would be non-italic and underlined (italic flip-flopping).

And what if a style doesn't allow underline? Is that out of scope for us, at least for now?

[bwiernik]

Yeah, I don't think we intervene between styles and in-field markup generally. That's similar to other data entry concerns.