Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[WIP] Centering / section justification tracking issue

See original GitHub 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
  • 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)

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:13 (7 by maintainers)

github_iconTop GitHub Comments

rondale-sccommented, Jan 31, 2019

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. 🍻

mixoniccommented, Jan 28, 2019

@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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

How to collect Windows Information Protection (WIP) audit ...
Collect WIP audit logs by using the Reporting configuration service provider (CSP). Collect the WIP audit logs from your employee's devices by ...
Read more >
Section Heading Centering problem - LaTeX Stack Exchange
I have a need to create something like this, however when I run this program, it gives error at the second \end{center} ....
Read more >
Track the WIP - Electrical Contractor Magazine
The calculations are shown below, and Figure 2 illustrates a common layout for the “earnings” section of the basic WIP report. Actual Job...
Read more >
WIP Traceability - Cantier Systems
WIP Traceability enables the manufacturer to track the manufactured products or materials as they flow in the production floor as well as record ......
Read more >
Phase II Bay WIP Development Support
The Phase II Watershed Implementation Plan (WIP) is part of a 3-phased planning process to achieve nutrient and sediment clean-up goals for the...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found