[WIP] Centering / section justification tracking issue

The main chunks of work necessary for this are as follows:

• Update the format itself to allow section attributes (we can handle those _section (baseclass))
  • This will be done similarly to how markups handle attributes (for example: PostNodeBuilder#createMarkup)
    • We will create one valid section attribute of data-md-text-align. The data-md- namespace for attributes will be where we create any future section attributes. Like with markers arbitrary attributes (like class, style, etc) are not part of the spec though it seems like that has not stopped anyone from adding them.
• Update the editor renderer to handle section attributes
  • This will be handled very similarly to how markups are currently handled in editor renderer (for example EditorDOM#createElementFromMarkup) We’ll likely need to add something to the EditorDom to wrap sections in an element with a style tag for centering et, al
• Update DOMRenderer to handle section attributes
  • Handled like markups (for example: bustle/mobiledoc-dom-renderer/renderUtils#defaultMarkupElementRenderer)
• Update TextRenderer to not fail when attributes are present on section. This is mostly just to prevent errors when MD format changes since we don’t/can’t do anything with section style information in text rendering (basically this is just a noop for section attributes)

[rondale-sc]

Upon initial consideration I believe the text renderer can safely remain unchanged since the presence or absence of the attributes in the section won’t affect it.

Marking as completed, unless someone has a better insight than me. 🍻

[mixonic]

@apfelbox the restriction on attributes ensures that the mobiledoc document format itself is portable. For example if we document data-md-text-align as having four valid values (left, right, center, justify) we can obviously map that to CSS either through styles or classes+CSS. Anyone writing a renderer for mobiledoc that is not outputting HTML, for example rendering in a native mobile app, can also reproduce those styles. Even in the land of HTML this abstraction is nice: For example in email you may want to use a different method to style this content than in the browser.

If we permit arbitrary attributes we will empower Mobiledoc users to create their own bespoke versions of Mobiledoc which can’t benefit from shared tooling, shared rendering, and interoperability (full fidelity copy/paste for exmaple).

Now if you don’t care about of that stuff and you really insist, The whitelists for attributes/elements are all just arrays in JS. I know some people import those and add bespoke attributes for example. Just keep in mind that by doing so you’ve effectively opted in to a bespoke, unique document format. A goal of Mobiledoc was to avoid that very end point.

The alternative is that you think about how your bespoke change can be generalized into a part of the Mobiledoc format and official editor/renderer. That is exactly what is being done in this ticket. You could already hack this via private API, now we’re making it public/documented API.

tl;dr I don’t expect Mobiledoc will every allow arbitrary tags or attributes because that would be at odds with our baseline goals for interoperability and common tools. If you want to break with that for now you can hack it through private APIs. We won’t go out of our way to block people doing this.