8fold / commonmark-abbreviations
An extension of PHP League's CommonMark library to enable abbreviation usage.
Installs: 7 941
Dependents: 1
Suggesters: 0
Security: 0
Stars: 1
Watchers: 4
Forks: 1
Open Issues: 4
Requires
- php: ^7.2|^8.0
- league/commonmark: ^2.0.2
Requires (Dev)
- phpstan/phpstan: ^1.2.0
- phpunit/phpunit: ^9.5
- squizlabs/php_codesniffer: ^3.6
README
This library is an extension for the CommonMark parser from the PHP League adding abbreviation syntax and rendering to Markdown.
Warning: This text is written using that syntax enabling extension testing; therefore, it will most likely not render as intended without a rendering extension using this syntax.
Installation
composer require 8fold/commonmark-abbreviations
Usage
2.1.0 to 3.0.0
[.Eightfold](8fold)
Becomes:
<abbr title="Eightfold">8fold</abbr>
You MAY also use the syntax prior to 2.1.0.
2.0.0 and before
[.8fold](Eightfold)
Becomes:
<abbr title="Eightfold">8fold</abbr>
The syntax
Inspired by the link syntax - []()
- and the footnote syntax in the extension from MultiMarkdown - [^]
.
The syntax is a square bracket followed by a period or dot: [.]()
.
Just like the footnote indicates superscript, the abbreviation syntax was found to indicate shortening to more people than previously proposed options. Placing the dot inside the opening square bracket allows the abbreviation to exist next to other glyphs as opposed to forcing empty space. (A conversation in the [CommonMark .Spec board](https://talk.commonmark.org/t/abbreviations-and-acronyms/890) was also referenced, and informative.)
Given the traditional use of the abbr
tag commonly combined with the title
attribute, the link syntax makes sense as the a
tag combines inner text with href
and the img
tag uses two attributes, src
and alt
to be valid and accessible.
Replace-all .vs. inline
We decided to go with inline, single instance over footer, replace-all.
Two main options exist for implementing this capability.
The first is to place the abbreviation and definition at the bottom of the document and render all occurrences of the abbreviation with the abbr
element and title. The drawback here is possible impact to readers using [.AT](Assistive Technology) like screen readers; potentially being read the full abbreviation each time.
The second option is to have the abbreviation be inline with the surrounding text. The drawback here is the need to write more each time an author uses the abbreviation.
This library looks at Markdown as being a way of writing potentially rich-text documents first, which can be transformed into .Hypertext Markup Language or something else. The recommendation from the [.US](United States) Plain Language Guidelines is to avoid abbreviations and acronyms in general and specifically to:
- Try to keep them to a maximum of two a page.
- Use them if spelling them out would annoy your readers.
- If you must use an abbreviation or acronym, spell it out the first time you use it. For example: [.CBT](Computer-based training).
As a document editor and author, I tend to recommend defining "first use" as "first use per section," where "section" is further defined as beginning with a header; so, if writing a 20 page document and an abbreviation is defined on page one, it's poor [.UX](user experience) to require a reader on page 20 to turn back to page one to jog their memory of the abbreviation's definition. This also speaks to the definitions being at the end of the document, similar to a glossary.