This page contains the style used on Backdrop CMS's web sites and also provide guidelines for textual documentation that appears on web pages and/or in code.
Legend
= Recommended style to use
= Style to avoid using
Contents
- Recommended resources
- Titles and headings
- Procedure style
- HTML and code formatting
- Links
- Paths and navigation
- Including new users and visitors
- Person-to-person communication
- Backdrop-specific terms
- Referring to a specific module or theme
- explaining version differences
- "Upgrade" vs. "update"
- Naming
- industry-related words
- acronyms and abbreviations
- numbers and dates
- Punctuation
- symbols and icons
- writing style
- Voice
- British/American differences
- miscellaneous notes on usage
Recommended resources
- Elements of Style by Strunk and White (but Backdrop's style guide overrides this when there are differences)
- Oxford American Dictionary
- The American Heritage Dictionary
- The Chicago Manual of Style (Our ultimate reference, but too expensive for the average user.)
- The Economist Style Guide (Wonderful book, but much information is British-based. Contains excellent section on British/American differences.)
- Wikipedia: Manual of Style (spelling) has a quick summary of the main differences between American and British English.
Titles and headings
Page titles should use sentence case (capitalize the first word only, also any proper nouns).
Menu entries for book pages should be the same as the page title (also in sentence case).
Menu item descriptions should use sentence case.
All headings within pages should use sentence case.
Use short descriptive titles to label a handbook entry. Titles should be 80 characters or fewer. Avoid redundancy; the words "Backdrop" and "Handbook" should rarely be used in titles.
- Exception: The titles of major works of literature such as books, movies, and magazines follow the capitalization used by the actual book or magazine. These titles should also be emphasized using the <cite> tag.
Things we made with Backdrop
We were watching The Lord of the Rings.
When referring to a title in the middle of a sentence, use the same capitalization that the title itself uses. If this creates confusion in meaning (as it may if it is unclear exactly where the title words end), the title may be set off with the <strong> element.
See the About page for more information.
Announcing a new O'Reilly Backdrop book: Using Backdrop
The What to do when confused page tabs can be useful.
The What to do when confused page tabs can be useful.
Put initial words in bold in sentences that begin with a description of the item in a list, or otherwise clarify the contents of a paragraph. Use the <strong> element for bolding words. Only use <em> if a particular word needs to be emphasized for a specific reason.
Even better: Make those initial words into a heading. See for yourself which looks better. If many headings break up a page too much, include the bolded words in the beginning of each sentence or item. If headings bring clarity to a page, use them instead.
See the administration section to learn how to configure and manage your site and use modules, blocks, permissions, and themes.
Administer your site
Learn how to configure and manage your site and use modules, blocks, permissions, and themes.
Avoid numbering child pages on Backdrop sites (backdropcms.org, docs.backdropcms.org, events.backdropcms.org, and forum.backdropcms.org). Page weights can properly order them, but this requires site maintainer rights. If you need pages reordered, create an issue in the relevant GitHub queue at https://github.com/backdrop-ops/<site-name> (for example, https://github.com/backdrop-ops/docs.backdropcms.org for the documentation site). In your issue, state which pages are affected and the order you want them. If you do use numbering (e.g. temporarily) use "1." style numbering, not "1)" or "1-"
A heading should never be followed by another heading. For example, you should never start a page with a heading (other than what is in the page's Title field).
Mark headings with the appropriate "h" tag (<h2>, <h3>) not the <b> or <strong> tag. The <b> and <strong> tags do not have any semantic sense: they are for emphasis.
Never use the <h1> tag for headings. This tag is added automatically to the page title. If a page has major sections use <h2> instead and use <h3> for the subsections. Use of <h4> etc. should not be necessary. Never use heading tags for emphasis. These rules are important for enabling accessibility.
Never end a heading or page title with a period (.), colon (:), semi-colon (;) etc.
Section links
If there are many sections (or subsections) on the page, consider including a list of links to all the sections at the top, as on this page. This makes it easy for users to jump directly to the relevant section.
Procedure style
For sequential steps, use a numbered (ordered) list. For a set of options, use bullets (unordered list). When describing actions, avoid unnecessary words.
Click x.
Drag x to y.
Click on x.
Drag and drop x to y.
HTML and code formatting
Avoid the underline tag <u>; use emphasis <em> instead. The <em> tag is also used for things that must be in italics. Use the <cite> tag for book titles.
Use ordered lists <ol> for step-by-step instructions and for lists of items that have an order of priority. All other lists should be "unordered." However, it is often helpful to the reader if a list is still sorted in a way that is appropriate for the context (alphabetical, earlier to later etc.)
Enclose HTML code samples within <code> tags.
Enclose PHP code samples within <?php and ?> tags.
Links
When embedding a link in a Handbook page, always make sure the link text describes the destination of the link. "Click here" is not a good description, because (a) it does not tell the user where the link will take them, and (b) on many modern devices, people don't "click"; they "tap." (And people who use assistive devices, like screen readers, do neither.) If you can't fully describe the destination of the link and still maintain good sentence flow, add a title tag. Title tags, used appropriately, are important for making the handbooks accessible.
Examples of link text:
how to organize a Backdrop event (this is the best one, given the subject)
organize a Backdrop event
visit this page
Backdrop event
event
The best place to learn how to organize a Backdrop event is on the Backdropcon homepage.
Do not repeat the same link text on the same page if it links to different destinations. (This is another good reason not to use "click here.") Someone who cannot see the page and is using a screen reader cannot tell which link goes where if the link text is the same for both.
Always warn users if clicking on a link will lead to a PDF or other download, including modules, etc. They may think they are clicking on something that merely provides more information, rather than immediately downloading a file.
[link text: Learn how to organize a Backdrop event]. (PDF 3MB)
If the link text has punctuation at the end, be careful not to include the punctuation in the link itself. (See example above.)
Use relative links where possible.
<a href="http://www.drupal.org/node/1234567">
<a href="/node/1234567">
Embed links within normal descriptive body text.
Backdrop now uses Git as its <a title="An introduction to version control systems" href="http://www.example.com">version control system</a>
Git rules! To learn about it <a href="http://www.example.com">click here</a>
Use 'example.com' as the domain name when describing an example domain name and www.example.com when using a fully qualified domain name and do not use "yourdomain.com" or other creative domain names, and embed the "link" in <code> to avoid it turning into a clickable links.
Use an IP address out of the RFC1918 IP space when you need to use an IP address, for example 10.2.3.4
Do not use target= attributes on links to make them open in a new window or tab. This is no longer considered to be good practice on the web in general.
Link to relevant documentation and forum posts wherever it would be helpful. Provide a link to any specific item only once, on its first occurrence in a page.
Glossary links:
- Link to a specific Backdrop term:
<a title="see Taxonomy" href="/node/937#t">Taxonomy</a> - Link to a common expression used on Backdrop.org:
<a title="Find under A - List" href="/node/302232#a">AFAIK</a>
Paths and navigation
When describing how to get to a specific user option in the interface (e.g., the "add vocabulary" option in the categories section of the administer screen) show the path needed to access the option using this format:
destination (<em>path > to > item > destination</em>)
Which will yield text that looks like this:
- destination (path > to > item > destination)
- Do not abbreviate words in the navigation path (e.g., use administer instead of admin).
- Menu items can move. So rather than just describing which menus or links to click, also include the path, using
example.comfor the web site (ex: path > to > item > destination, orhttp://example.com/path/to/destination). If you enclose your URL in a <code> tags, you will avoid having it turn into a clickable link. - If the path in search leads through a sidebar note, include the sidebar heading or link in parentheses after the page's heading.
Home > Modules (sidebar) > Popular modules >
Including new users and visitors
Introductions to sections
- should use a welcoming, friendly tone, as one colleague to another,
- should specify what sort of things people can do to help Backdrop (the site, community, or software), and
- should pay particular attention to indicating how even those new to Backdrop can help.
For example, for new users visiting the Documentation landing page, it is encouraging to see words like these:
"If you are new to Backdrop and have trouble understanding any part of the documentation, please [link this text: notify those of us who work on this section] and clearly explain what you don't understand and why. We're happy to hear from you. Your contribution helps everyone at Backdrop!"
Why say "notify those of us who work on this section" rather than just say "notify us"? It subliminally suggests that a group of people-volunteers rather than a distant or intimidating authority-write these pages.
Text like this has a brand—consistent voice and helps more people to use Backdrop—not just to download it—and it shows new users how they can be important to Backdrop. That, in turn, will encourage them to begin the journey to mastering Backdrop and telling others about their great experience with Backdrop.
Person-to-person communication
Brand-consistent communication in forums, groups, and other points of contact is essential for reinforcing the brand and inspiring people to not only use the software but be passionately involved in the Backdrop community.
Communication should, of course, be in your own voice. Make a point, though, to review your tone and choice of words before hitting "Send." Is your message off-putting, or does it encourage further communication, inspire participation, or include other people in a collaborative manner? Does it meet others halfway?
Even if other people irked you intentionally, did you rise above that and respond in a friendly way, or did you go down to their level? Remember that a forum or group may be the first page that a potential user sees at Backdrop. This new person may hurry past any login and only start reading once reaching the forums. Be informative, kind, welcoming, informal, and full of good humor.
See www.alistapart.com/articles/puttingourhotheadstogether/ for ideas on how to use the forums for the betterment of Backdrop, its brand, and its users (experienced and new).
Also see the comprehensive "forum tips" section, linked to in the introduction to the Forum.
Backdrop-specific terms
The first use of a Backdrop-specific word on a page should be spelled out, even in a list. Thereafter, on that page, only the jargon, shorthand word, or nickname is necessary. This is important in the Forums, as well, because this may be the first entry point for a new user.
Backdrop versions: Don't use phrases like "latest version" or "Backdrop," as in "Download Backdrop." Always call a version by its full name: "Backdrop 1.21" or "Backdrop 1.x" or even "Backdrop version 1.21" (replacing "21" with the relevant version, or use "1.x" for a generic reference). Don't use "Update" when referring to versions of Backdrop.
Download Backdrop version 1.21 before using this module.
With Backdrop 1.21, you can do amazing things.
Download the Backdrop update before using this module.
In the latest version of Backdrop, you can do amazing things.
Terminology is not capitalized unless you are referring to a section or page on the site.
Use modules to add features to your site.
Use Modules to add features to your site.
See the Modules page to discover new features for your site.
See the modules page to discover new features for your site.
Ideally, of course "the Modules page" would be linked to that page in that example.
Referring to specific modules and themes
To refer to a specific module or theme, use this style:
the Contextual Links module
Start with "the", followed by the exact name of the module (what you would see on the Modules page) in Title Case, followed by the word "module" in lower-case. Similar for themes and/or layouts.
Explaining version differences
When explaining differences between Backdrop versions, there are two options. If a procedure or interface is substantially different between the two versions, consider creating two separate pages and noting the version at the end of the page heading. For example:
- Creating a widget (Backdrop 1.21+)
- Creating a widget (Backdrop 1.20 and earlier)
If there are only minor differences between versions (for example, if a step in a procedure is different), place each chunk of information in a separate paragraph and note the version at the beginning of the paragraph, more recent version first, earlier version second. For example:
- (Backdrop 1.21) Click Y.
- (Backdrop 1.20 and earlier) Click X.
"Upgrade" vs. "update"
An "upgrade" is an involved process that impacts the whole site, while an "update" is what happens to the code and database regardless of whether it's a major, minor, or bugfix release (for instance by dropping in a replacement file and running update.php). When describing processes for end-users or developers to "update" or "upgrade" core, modules, and themes, be as consistent as possible using these terms. Learn more about major and minor releases.
The process of moving from Drupal 7 to any version of Backdrop is always an "upgrade."
Upgrade
"Upgrade" should be used only for the act of performing a major version upgrade, the process of moving between major core releases or (and this is the most common use case) moving from Drupal 7 to Backdrop CMS. For example:
When upgrading your site from Backdrop 1.x to Backdrop 2.x, be sure to fully back up your site before beginning.
When you upgrade Backdrop core from 1.x to 2.x, you must also update each module you have installed, as well as any themes that are not part of core.
When you receive a security update notice, be sure to upgrade any affected modules.
Update
"Update" on the other hand, should be used for minor and/or bugfix version updates or the task of modifying a module/theme you maintain to a subsequent release. As part of the overall upgrade process, you also do a lot of updating; replacing contributed modules with new versions, updating custom themes or modules, updating site configuration. For example:
You or your development team should update your installed core version to the next minor release (1.18 to 1.19, or 1.20 to 1.21).
You or your development team should update a contributed module to the next minor release (1.x-2.1 to 1.x-2.2)
You should update a contributed module for a major release (1.x-2.1 to 2.x-3.2, and also 1.x-2.1 to 2.x-3.2, although the latter is part of the major site upgrade process).
A hook_update_N() (an update hook) may be run both for minor and major releases, for both core and contributed modules/themes, and always via update.php.
Module maintainers will be updating their modules for major Backdrop core releases.
Module maintainers will be updating their modules for major Backdrop contributed module releases (e.g., Views Bootstrap 3.x).
It is important to inform your client that their site needs security updates.
When Backdrop 2 is released, you will need to prepare to update your site.
Porting
Usually, for developers, the term "to port" can be used for the act of converting a module (or theme or layout) from Drupal 7 to Backdrop CMS.
Naming
When naming modules, themes, and other features, avoid jargon and Backdrop nicknames as best you can, as well as names with private meanings. It alienates the new user.
Timekeeper
Beastmaster_IQ4
ab.cron_cctime
You should avoid giving your module the same name as an existing Drupal 7 module unless your module is a port of that module or does the same thing as that module (and, ideally, provides an upgrade path from the Drupal 7 module to your module).
Industry-related words
Correct:
- Ajax, not AJAX or ajax
- back end, front end, unless describing a noun. Correct: Change the front end. He's a front-end designer.
- blog (not weblog)
- Backdrop, not backdrop
- (e-words are always lowercase, except at the beginning of a sentence or in a heading)
- e-commerce, not ecommerce
- e-learning, not elearning
- email, not e-mail
- FAQ stands for Frequently Asked Questions; don't add an "s" to pluralize it
- homepage, not home page
- HowTo:, not HOWTO:
- HTML, not html
- installation profile, not install profile
- internet, not Internet
- JavaScript, not Javascript
- log in (verb): Ex. Log in by entering your username.
- login (noun): Ex. Use the login section.
- MySQL
- nonprofit
- online, not on-line
- page view
- PHP, not php
- server-side, not server side or serverside
- sidebar
- style sheet, not stylesheet
- sub-page
- the web, not the Web
- URL, not url
- username, not user name
- web page
- web publishing
- web server
- web, not Web
- webmaster
- website or site, not web-site or web site
- XHTML, not xhtml
Exception:
- When a word is lowercase, such as web, it uses an uppercase first letter when it is the first word in a sentence or heading.
Acronyms and abbreviations
Always abbreviate identification/identifier as ID, not id. This is standard English (check your favorite dictionary -- id is a psychological term).
Pluralize them by adding an "s" without an apostrophe. Only use the apostrophe if you're describing something possessed by the acronym.
URLs, DVDs
URL's, DVD's
The DVD's surface is scratched.
The first use of an acronym or abbreviation on a page should be spelled out, even in a list, unless the acronym is widely used and familiar to non-technical visitors (like DVD or URL). Thereafter, on that page, only the acronym or abbreviation is necessary. This is important in the Forums, as well, because this may be the first entry point for a new user.
The Content Construction Kit (CCK) allows you to add custom fields to nodes using a web browser. Once you update the core CCK modules and ensure that they are working properly, add other CCK modules to the modules folder.
Numbers, dates and time
- A billion is defined as an American billion: 1,000,000,000
- Thousands should be separated by commas, i.e 100,000
Dates
Express dates either in full (December 6, 2008) or use the proper ISO date format: yyyy-mm-dd, as in 2008-12-06, depending on where it is being used. This may be unfamiliar to some users of American English, but the ISO standard is the widely-accepted date format for modern software. An American event probably would use the full word version (e.g., BackdropCon Seattle, December 6-7, 2021) whereas a date for an entry or update might use the ISO version-but keep pages consistent.
Dates in full: December 6, 2008
ISO standard: 2008-12-06
Time
ISO 8601 uses the 24-hour clock system. The basic format is [hh][mm][ss] and the extended format is [hh]:[mm]:[ss], for example 13:47, or 13:47:30.
ISO standard: 13:47
1:47 PM
Punctuation
Use curly (smart) quotes unless you are providing code examples.
Use only one space after a period.
Don't use the ampersand in text. Use it only in code examples or when referring to a page title that uses an ampersand (Community & support). The only places ampersands should be used in titles are in the main navigation buttons and in the title of each corresponding page.
Community & support is a legitimate title because it is in the main navigation. The title of that landing page should also be Community & support.
Backdrop's most popular modules and themes
Backdrop's most popular modules & themes
If a phrase in parentheses is within a sentence, put the period at the end of the sentence, not within the parentheses. If the phrase in parentheses isn't within a sentence, place the period within the parentheses.
(We are new here and didn't know what we were doing.)
I don't know why we did that (I guess we didn't know what we were doing).
Hyphens
Use em dashes (HTML entity 8212, "-") for abrupt breaks in a sentence, to temporarily change subject within a sentence, for clarity, to draw attention to a point, or to signify the origin or author of a quotation.
- Don't use double hyphens; use the HTML entity.
- Don't place spaces on either side. There shouldn't be any space between the word or words next to an em dash and the en dash.
Use an en dash (HTML entity 8211, "-") to indicate a range of numbers or dates. (See www.alistapart.com/articles/emen/ for more information about the subject of dashes and hyphens.)
Punctuating Lists:
Precede an ordered or bulleted list with a sentence or phrase ending in a colon.
In Groups, you can：
- Get to know other Backdrop users．
- Collaborate on projects in a small group．
- Voice your opinion on a particular project．
Begin each item with a capital letter (unless it is a product or company name that begins with a lowercase letter).
Complete sentences in a list should have a period at the end. If a line item is not a complete sentence, do not use a period. If you are breaking a sentence into a list, as in the first example in this section (In Groups), periods aren't necessary.
Be consistent, if possible, when writing the items in the list. Make them "parallel." In the first example, Get, Collaborate, and Voice are the same form of verb.
- Getting to know other Backdrop users
- Projects that need lots of people
- State your opinion
Symbols and icons
Provide a key or footnote on every page that uses a symbol, even a symbol that seem obvious to you. For example, the symbols used on the Modules page (e.g., checkmarks [1]) should be explained in a short footnote.
Writing style
- Keep sentences to 15 words or fewer. Don't be wordy. Long sentences are difficult to understand.
- Spell check.
- Avoid slang terms. Be sure any English-language idioms you use are common and well-known. This benefits all readers, but especially Backdrop users with a first language other than English.
- Do not assume that the reader will be familiar with cultural references.
- Use language that includes people with vision or hearing disabilities wherever possible. For example, "You will see a block at the top of the page ..." assumes that the reader can see. It's better to write "A block is displayed at the top of the page ...". .
Voice
Reinforce the Backdrop brand: Anything written at Backdrop.org becomes part of the Backdrop experience and should convey the Backdrop philosophy.
- Be clear, simple, and concise.
- Be respectful, honest, and approachable.
- Be engaging, welcoming, lively, and fun where appropriate.
New to themes? Here's [link text: how to get started]. Only cut-and-paste PHP knowledge needed. Questions? Find people happy to [link text: help in the forums] or [link text: hire a developer].
You should already know about themes in general. If you want to find out more, read that section because it will give you all the details you need. You will need to know some PHP but not much. If you aren't an experienced developer, I don't think this section will help you very much and you probably should hire someone to do it for you.
Use ordinary, everyday language instead of words that sound more elevated—they usually don't.
Use this to...
Leverage this to...
Utilize this to...
Know your audience: Tone of voice, use of jargon or Backdrop nicknames, and complexity of language should be appropriate for the type of page:
- Major landing pages must be approachable and appropriate for a wide audience that could include beginners, company managers, designers, developers, business owners, first-time bloggers, tech-savvy entrepreneurs, educational organizations, or advanced Backdrop developers. Keep them in mind.
- Deep-level pages (e.g., discussing the complexities of module-building), while still using the Backdrop tone of voice, can be more complex and use jargon and "insider" names for Backdrop functions and features.
- Use empathy: Put yourself in the place of the readers. Try to look at your text through the eyes of a variety of visitors.
- You don't need the word "Please" in order to sound friendly. At times, it will be appropriate; usually, it will not. It sometimes comes across as condescending.
Get them there: Ask yourself what visitors want to get done and help them get there quickly.
Short isn't always best: Concise (brief yet comprehensive) is good, but shortness? It depends. What does the user expect and need?
- If you are just trying to attract attention, do that, with a short, snappy headline. Snappiness, though, is not always necessary. To persuade someone or show Backdrop's personality to a new visitor, use attractive, compelling words. To simply get someone to the proper destination, link text "See Documentation" is fine, and so is the heading "Documentation."
- If the user needs or is looking for a lot of information at this point, provide it. Don't be afraid to go into detail, no matter what advice you've read. With proper headings, whitespace, subheads, padding, links, short paragraphs, charts, and lists, length here is a good thing. Unnecessary words? Not good.
Open source not market-speak: Avoid fluffy sales talk. "We're great! Backdrop is great!" "We're the best!" These sentences are only believed by those who write them, not those who read them.
- Words such as "very, really, truly" tend to weaken a statement, not strengthen it.
This module reduces the time you need to set up a forum.
The module really reduces the time you need to set up a forum.
Even better: This module reduces forum set-up time.
Edit and edit again: Strip away unnecessary words. Examine them. Is each one lively, direct, and doing a job? Or, is it empty or deadening? Because an informal voice is brand-consistent, complete sentences aren't always necessary:
"Can't find the answer?"
"Are you having trouble finding the answer to your question?"
PHP expertise necessary? Yes.
PHP expertise is necessary.
Expertise in the use of PHP is very necessary for using this module.
Think globally: Avoid phrases that aren't easily translated, such as puns and social or local references. Beware of wit or cleverness that won't have the same meaning in other countries. Light humor, in good taste, is good, but will it translate?
(PDF 514 MB)
(PDF 514 MB) Better get out the popcorn and watch The Big Lebowski while you're waiting for this bloody thing to download.
Be clear about benefits for the reader: Backdrop is here to make people awesome at what they do. Using the word "you" can be powerful.
In general, use active, not passive, voice: In active voice, the subject performs the action ("The dog ate the bone."). In passive voice, the subject is the target of the action ("The bone was eaten by the dog.").
Don't twist sentences into knots trying to avoid this, though. Also, at times, passive voice emphasizes words that active voice would downplay. In that case, use passive voice, but, in general, use it sparingly.
You should clearly identify links.
Clearly identify links. ("You should" is implied.)
Links should be clearly identified. (Here, the links aren't doing something; someone is doing something to them.)
Click the download button to get the core files.
The download button should be clicked in order to obtain core files.
Quick Resource: https://owl.english.purdue.edu/owl/
Resource for variations in non-English languages: see Wikipedia: Voice (grammar)
Avoid first-person: Avoid first-person (I, we, my, our) on editorial/landing pages. Use "Backdrop" instead. At times, because Backdrop is community-based, use "we" to sound inclusive or to reinforce the community concept. Avoid first-person in sections such as Documentation or Modules, etc.
This module helps you add feature x.
I created this module to help you add feature x.
Backdrop releases a new minor version every four months.
We release a new minor version every four months.
Things we made with Backdrop (Exception to first person rule, on homepage. "We" conveys sense of real Backdrop people with real stories.)
Balance the needs of new and experienced users. Provide links to additional or clarifying information new users may not know. At the same time, experienced users need quick steps.
User-test your writing: Choose at least one person from your intended audience to make sure directions are clear and complete, and the tone is correct. User-testing is critical for sections like Modules and Documentation. If it is written for a new user with basic skills, you should test it on new users with basic skills. They should be able to achieve the final goal just by reading and following the directions, without asking you any questions.
British/American differences
Backdrop uses American English rules for spelling and punctuation.
Spelling examples:
- Color, not colour
- Organize, not organise
- Gray, not grey
- Spelled, not spelt
- While, not whilst
- Center, not centre
- Meter, not metre
Treat companies and organizations, although made of groups of people, as single entities:
Microsoft has many products.
Microsoft have many products.
Harvard University has decided to close for the summer.
Harvard University have decided to close for the summer.
The Backdrop community needs more money.
The Backdrop community need more money.
Punctuation examples:
- Use a serial comma∶ It is a comma that separates all items in a list, including the final two (before the ， and). The exception is when two associated items that form a name or pair are on the list. These are not separated by a comma.
I like writing, reading, spaghetti and meatballs, bicycling, and receiving Christmas presents.
I like web designs by Happy Cog, Clearleft, Veerle and Geert at Duoh!, Airbag, and Mark Boulton Design.
I like apples, pears and pineapples.
- Don't use the serial comma in headings and titles.
When a colon precedes a full sentence or question, the first letter after the colon should be a capital letter.
Consider this: Cats are different from dogs.
Consider this: cats are different from dogs.
She wants many things for Christmas: boots, lingerie, shoes, perfume, and jewelry.
Quotation marks:
Single quotes are used only when a quote appears within a quote.
Mary said, "I don't know why she said 'No,' when I asked her."
Mary said, 'I love to attend Backdropcon.'
Final quotation marks in a sentence or phrase are used after the period or comma, even when naming something.
Add features to the Backdrop core by using things called "modules."
Put quotation marks before semicolons, and colons.
Miscellaneous notes on usage
Generally, when giving examples, use "such as" rather than "like."
BackdropCMS.org has many sections, such as About, Showcase, Add-ons, Support, and News.
Backdrop.org has many sections, like About, Showcase, Add-ons, Support, and News.
Many people, such as chronos and fastdraw, participate frequently in the forums.
Use "like" to replace "in the same way as."
Participate in the forums frequently, like chronos and fastdraw.
Alt attributes: All images, other than purely decorative ones (such as background colors) should be described using an alt attribute.
[1] This is where the footnote explanation would go, if there were a real footnote for this page. - return to "Symbols and Icons".