Q. Could you please tell me the difference between “press” and “push” in the context of computers?
A. The keys on a physical keyboard are normally pressed, not pushed, as in “press the Enter key,” or “press Ctrl+Alt+Delete.” The Apple Style Guide (October 2022 ed.) agrees, adding this: “Don’t use click, hit, push, tap, or type” (under “press” as it relates to physical keys and buttons).
However, according to the Microsoft Writing Style Guide, the term to use is “select,” whether for a key or a button, physical or virtual, as in “Select the Modify button” or “Select Shift+Enter.” This style accounts for any input method, from physical keyboard or mouse to touch screen and voice.
Microsoft’s and Apple’s guides both allow for hardware-specific exceptions, like using “click” when describing something done with a mouse or “tap” when referring to a touch screen.
But unless you need a word to help you define press (e.g., “the pushing of a physical button”), it’s probably best to avoid push.
[This answer relies on the 17th edition of CMOS (2017) unless otherwise noted.]
Q. I’m editing a bibliography that has many URLs that end in a slash. Should these be deleted?
A. A URL copied out of a browser’s address bar and pasted into a document will often include a trailing slash. For example, if you call up the home page of the New York Times and copy its address from Chrome, Edge, or Firefox, you’ll get this: https://www.nytimes.com/. That slash will appear in the pasted result even if it isn’t there in the address bar.
You don’t need to keep the slash at the end of the URL for the Times; trailing slashes can generally be omitted from domain-level URLs like that one. But deleting a bunch of slashes from a long reference list would risk introducing errors—and any URL that goes deeper than a home page would need to be double-checked without a final slash to make sure it still works that way.
So the safest approach is to leave them alone (assuming they work).
By the same token, there’s usually no need to add a slash to a URL that doesn’t already end in one. Especially if the URL points to a specific file, you’re likely to break the link if you modify it in any way.
[This answer relies on the 17th edition of CMOS (2017) unless otherwise noted.]
Q. When referring to general website pages such as home, login, bill payment, and account balance, we opt for roman text, no quotation marks, and down-style casing. But it gets tricky with pages such as “My account,” “Contact us,” and “About.” Does CMOS have guidance on how to style references to these common web features?
A. To refer to a titled page on a website—even if the title names a generic category—we would advise using quotation marks and applying headline-style capitalization (a.k.a. title case): “My Account,” “Contact Us,” “About.” See CMOS 8.191.
[This answer relies on the 17th edition of CMOS (2017) unless otherwise noted.]
Q. What is the CMOS ruling on the following: “esports” or “eSports”? Are esports games (e.g., Call of Duty: Warzone) italicized or put in quotes? Or neither?
A. Chicago style would call for “e-sports,” with a hyphen, usage that extends to all other e-words with the exception of “email” and any trade names like “eBay” that don’t use a hyphen. The title of a video game, whether or not it is considered an e-sport, and whether it’s the name of the series or an individual game in that series, would be in italics: Call of Duty: Warzone, the Call of Duty series. For hyphens, see CMOS 7.89 (section 3, under “e”); for video games, see CMOS 8.190.
[This answer relies on the 17th edition of CMOS (2017) unless otherwise noted.]
Q. When publishing a web address in a print publication, do you recommend underlining it (as it would appear on the web), bolding it, or doing nothing? Is one way better than another when the web address is at the end of the sentence (thus, followed by a period)? Example: For more information, visit www.chicagomanualofstyle.org.
A. No, we don’t recommend any special treatment for URLs, and we don’t worry when they come at the end of a sentence. (Sometimes, your browser won’t fuss if you include a period at the end of a URL in the address box—try it.) You can find samples of Chicago-style citations that include URLs right here at this site. Just go to our Citation Quick Guide.
[This answer relies on the 17th edition of CMOS (2017) unless otherwise noted.]
Q. In your bibliography, do you type in your websites so they will be “active”?
A. Most of the manuscripts we edit are going to be printed on paper, so there’s no possibility of a live
link. When we prepared the manuscript for CMOS Online , however, we made the URLs active in the bibliography as a convenience to readers.
[This answer relies on the 17th edition of CMOS (2017) unless otherwise noted.]
Q. The CMOS standard is to paginate front matter with lowercase roman numerals, and then use arabic numerals in the text and back matter. This causes a problem when I publish an electronic book in PDF format. PDF numbers the book sequentially, ignoring the different numbering of the front matter. Reading between the lines in CMOS, I have come to believe that numbering the front matter separately is a historical artifact. When the text was written first, followed by the front and back matter, and all were done mechanically, one could not number everything sequentially from the title page. In these electronic times, though, sequential numbering takes seconds, literally. Why then use a separate numbering scheme for front matter?
A. This “historical artifact” is still useful in printed books. Chicago books use roman numerals for front matter because it’s still common for pages to be inserted or deleted after the book is typeset (a dedication page is suddenly needed; a promised preface doesn’t arrive), and having to repaginate the entire book is expensive. In addition, a change in pagination in late production could cause inaccuracies in the index. In PDF, repaginating is a snap, but if there is a back-of-the-book index, reindexing may or may not be easy, depending on how the index was compiled.
[This answer relies on the 17th edition of CMOS (2017) unless otherwise noted.]
Q. According to CMOS, computer menu items are capitalized. The editors I work with insist that a menu item from a specific website (such as yours) should also be placed in quotation marks. Here’s an example: Click on “About the Manual” to learn about changes made to the recent edition. I think the quotation marks are unnecessary. What do you think?
A. I think they’re fine, especially when the item consists of several words. Otherwise it could be confusing, especially if the sentence contains words that must be capped but that aren’t part of a menu item name. In a given document, if all menu items are single words or familiar phrases (such as Page Down), then caps are enough. If some items require quotation marks, however, then all should have them.
[This answer relies on the 17th edition of CMOS (2017) unless otherwise noted.]
Q. My question is, is there any standard for the usage of emoticons? In particular, is there an accepted practice for the use
of emoticons that include an opening or closing parenthesis as the final token within a set of parentheses? Should I (1) incorporate
the emoticon into the closing of the parentheses (giving a dual purpose to the closing parenthesis, such as in this case.
:-) (2) simply leave the emoticon up against the closing parenthesis, ignoring the bizarre visual effect of the doubled closing
parenthesis (as I am doing here, producing a doubled-chin effect :-)) (3) put a space or two between the emoticon and the
closing parenthesis (like this: :-) ) (4) or avoid the situation by using a different emoticon (Some emoticons are similar.
:-D), placing the emoticon elsewhere, or doing without it (i.e., reword to avoid awkwardness)?
A. Until academic standards decline enough to accommodate the use of emoticons, I’m afraid CMOS is unlikely to treat their styling, since the manual is aimed primarily at scholarly publications. And the problems you’ve
posed in this note give us added incentive to keep our distance. (But I kind of like that double-chin effect.)
[This answer relies on the 17th edition of CMOS (2017) unless otherwise noted.]
Q. We’re trying to find a definitive style for representing file names, commands, and computer buttons
(e.g., click “exit”) in text. For file names, for example, I’ve
found quotation marks, italics, all caps, boldface . . . you name it, including
no differentiation at all. How would you suggest treating a file name in a sentence such as “Open the
readme.rtf file before continuing with the installation”? What about commands in a sentence such as
“Click on File and select Open”?
A. For commands, icons, keys, etc., an important consideration is to match the capitalization of the software or hardware being
invoked. Fortunately such items tend to be capitalized, which helps to set terms off from the run of text without introducing
italics or other distinctions:
Choose Save As, under File (or press F12), before you make another move.
You can assign shortcuts to a Ctrl+Alt key combination to launch most Windows applications.
File names may be set in italics or in a different font. An elegant alternative is to relegate them to parentheses:
Open the third chapter (John Doe and the problem of anonymity.wpd) and run the cleanup macro (clean_me).
Words to be typed can be set in bold or in a different font, or both, like this:
Type vacation stop at the prompt, then hit Enter.
Quotation marks, unless they are an explicit element of a command or label, should be avoided—though
they may be helpful, used consistently, to delimit file names (which may or may not have telltale extensions and even if they
do may be impossible to distinguish from the run of text, as in the WPD example above). Consistency is the key—set
up a style sheet tailored to your needs (e.g., a software manual would generally merit greater use of bold and italics to
distinguish commands from labels and file names), and stick with it.
[This answer relies on the 17th edition of CMOS (2017) unless otherwise noted.]