Read / Write Support for non-standard HTML Attributes

Description:

We have to provide Apps using Aztec a streamlined mechanism to read-from and write-to non-standard HTML attributes and CSS attributes related to NSAttributedString styles.

The purpose of this ticket is to detail and discuss the complications and implications of trying to provide such support.

One of the possible outcomes of this discussion it to realize that offering support for non-standard HTML attribute editing is not worth the added complexity, in which case we'll most likely need to define which attributes can be edited on a style-by-style scenario.

Current Status:

Right now the only elements that allow editing all of their attributes are <img> and <video> tags.

This information is accessible through the MediaAttachment.extraAttributes (property).

Analysis:

The advantage of this approach is that the attributes are immediately accessible through the attachment object itself, which Apps have access to.

That said, the solution we used for the <img> and <video> tags wouldn't work for other styles. There are two main reasons why this is the case:

• <img> and <video> tags have a 1:1 correspondence with the NSAttributedString style used to represent them (ImageAttachment and VideoAttachment), whereas a <strong> and an <em> tag will both be represented using the same NSAttributedString style (UIFont).
• ImageAttachment and VideoAttachment always map to an HTML Element (<img> and <video>) whereas the bold style could map to an HTML Element (<strong>) or to a CSS attribute (font-weight: bold;). In the latter case, it wouldn't make sense for it to have extraAttributes.

Paragraph-Level Styles vs Regular Styles:

An extra level of complexity is added by Paragraph-Level Styles.

These are styles that can only be applied to full paragraphs (such as <p> or <blockquote>). There are stored inside our custom Aztec.ParagraphStyle class (which subclasses NSParagraphStyle).

Whatever solution we come up with, it has to take Paragraph-Level styles into account.

Proposal:

The proposed solution is based on the intuition that the simplest approach is to separate these styles into different, and as few as possible, categories.

The assumption is that by breaking styles into separate categories, each with its own solution, we can cover all angles.

1st Category: Paragraph-Level Styles

One possible solution to deal with attribute editing in Paragraph-Level styles could be to add an extraAttributes dictionary to our ParagraphProperty class (which is used to represent all of these Paragraph-Level styles).

2nd Category: Attachments & Links

Since attachments are always represented by one HTML element (whether it contains child elements is irrelevant), we could maintain the current approach of offering an extraAttributes dictionary.

We could implement something similar for links, since they're always represented by an <a> element. This would require us to replace URL objects being inserted into Aztec.TextView with our own URL subclass containing an extraAttributes dictionary.

3rd Category: Font Styles

[TO BE DEFINED]

[THE EDITION OF THIS DOCUMENT IS IN PROGRESS]

Start by reviewing MediaAttachment.extraAttributes, Aztec.ParagraphStyle, ParagraphProperty, and the Aztec.TextView URL handling described in the issue. Compare the existing attachment approach with paragraph, link, font, and CSS styles, then establish a decided category model and its supported read/write behavior. Done means the design resolves the open complications, including paragraph-level styles and the unfinished font-style category.