Browse Prior Art Database

Adding a Content Annotation Syntax in a Non-Modifiable Processor

IP.com Disclosure Number: IPCOM000248309D
Publication Date: 2016-Nov-15
Document File: 3 page(s) / 25K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method that enables web documentation authors to use the extended annotation syntax, while continuing to use Marked, unmodified to generate the corresponding Hypertext Markup Language 5 (HTML5). This approach adds annotation syntax for use with an unmodifiable processor for which the produced output includes neither backward mappings nor direct correlation to the original source.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 3

Adding a Content Annotation Syntax in a Non -Modifiable Processor

Developers use the Marked Markdown processor to convert content authored in Markdown format to publishable Hypertext Markup Language 5 (HTML5). A method is needed to support element-level annotations within the Markdown source, with the purpose of passing the attributes out to generate HTML5. Specifically, developers need setting element attributes, such as ID and class, to apply Cascading Style Sheet (CSS) styling and programmatically include or exclude content.

A popular non-standard syntax for doing this exits, which developers can adopt; however, Marked does not recognize this syntax as it is non-standard, and the looseness of the Markdown specification makes changing to a different Markdown processor undesirable.

The novel solution is a method that enables web documentation authors to use the extended annotation syntax, while continuing to use Marked, unmodified to generate the corresponding HTML5. This approach adds annotation syntax for use with an unmodifiable processor for which the produced output includes neither backward mappings nor direct correlation to the original source.

Without this solution, developers would be unable to deliver contextual, styled, or custom content sourced from Markdown.

The core idea is to leverage the processor to:

1. Generate output for those portions of the source with known syntax, which the processor knows how to handle

2. Reverse-engineer the blocks of text in the source that would have led to the produced output

As the method produces this back-mapping, it enables instances of the extended syntax to associate with the adjacent semantic elements and then apply to the final output.

Similar to HTML, blocks of text can flow over line breaks in Markdown. For example, the following two cases should render identically as "hi there", even though the second case contains a \n character:

hi there

hi there

When Marked scans a Markdown source into tokens, it does not preserve whitespace that is not semantically important. As a result, for the example above it generates an identical token for both even though the respective sources differ.

For introducing the new block attribute list syntax, the specification states that

1


Page 02 of 3

block-level attribute lists must appear on an individual line and immediately follow the block of Markdown to which the list applies. The following are valid and invalid examples of this:

Valid:

a paragraph
{: .className}

Invalid:

a paragraph {: .className}

In the invalid case above, the "{: ... }" should just render as-is, as plain text. This is what Kramdown generates.

Because Marked has no awareness of the block attribute list syntax, and Marked does not preserve non-semantic whitespace, it generates identical tokens for both the valid and invalid cases above. For this reason, simply going through its generated tokens and looking for {: ... } patterns to apply after-the-fact is an insuff...