Moving away from Markdown to straight HTML for Inclusive Design Guide site

[Tony Atkins]

Hi, Jonathan:

I agree with a lot of Alan's points, moving to pure HTML seems like a step
we should only consider once we have reasonably exhausted the remaining
options.  Thankfully, I can already think of a few options off the top of
my head that would get us back to more pure markdown.

Let's start with the markup from the "Cause and Effect" page
<https://github.com/inclusive-design/guide.inclusivedesign.ca/blob/master/src/documents/activities/CauseAndEffect.html.md.handlebars#L35>
:

<ul class="idg-articleContentUseWhyHow">
>
> <li>
>
> <span role="presentation" class="idg-iconInsights">{{{getCategoryIcon
>> "insights"}}}</span>
>
> [Interconnectedness](/insights/Interconnectedness.html)
>
> </li>
>
> <li>
>
> <span role="presentation" class="idg-iconInsights">{{{getCategoryIcon
>> "insights"}}}</span>
>
> [Virtuous Cycles](/insights/VirtuousCycles.html)
>
> </li>
>
> </ul>
>
>
What I see here is that we need to:

   1. add a class to the list
   2. add classes and roles to each list item.

The underlying markdown rendering engine supports overriding individual
rendering methods
<https://github.com/chjj/marked#overriding-renderer-methods>, including
both "list" and "listitem".  Assuming you can use generic class names, that
would give you the option to use pure markdown lists for everything, as in:

# [Interconnectedness](/insights/Interconnectedness.html)
> # [Virtuous Cycles](/insights/VirtuousCycles.html)


You could also handle at least the list items with a more helpful block
helper <http://handlebarsjs.com/block_helpers.html>, one that also
generated the span.  Block helpers can be called with literal strings, so
assuming that overriding "list" works, you'd end up with markdown like:

# {{{myIconHelper "insights"
> "idg-iconInsights"}}}[Interconnectedness](/insights/Interconnectedness.html)
> # {{{myIconHelper "insights" "idg-iconInsights"}}}[Virtuous
> Cycles](/insights/VirtuousCycles.html)


This is not to suggest this approach, only to suggest that if markdown
alone won't work, perhaps mixing markdown and block helpers is more
palatable.

Anyway, keep the discussion going, I suspect with a few more details about
why those classes are needed we can figure out how to meet our goals
without giving up on markdown.

Cheers,


Tony

On Wed, Oct 5, 2016 at 7:33 PM, Hung, Jonathan <jhung at ocadu.ca> wrote:

> Hi everyone,
>
> For the Inclusive Design Guide site we have been using a combination of
> both markdown and native HTML in the source document files.
>
> Examples of mixed HTML and Markdown:
>
> Cause and Effect
> <https://github.com/inclusive-design/guide.inclusivedesign.ca/blob/master/src/documents/activities/CauseAndEffect.html.md.handlebars> -
> typical example (Design Guide)
> Virtuous Cycles
> <https://github.com/inclusive-design/guide.inclusivedesign.ca/blob/master/src/documents/insights/VirtuousCycles.html.md.handlebars> -
> example with images (Design Guide)
> Metadata
> <https://github.com/fluid-project/docs-inclusive-learning/blob/master/src/documents/Metadata.html.md.handlebars> -
> also in the Inclusive Learning Design Handbook and elsewhere (ILDH)
>
> The main motivation for using Markdown was to make it easy for
> contributors to author content without having to know HTML. However,
> because of our styling and formatting requirements, we have both HTML and
> Markdown in the same files. Thus requiring the author to use both formats
> in a document.
>
> To complicate matters for authors of all skill levels, Markdown is very
> particular how you mix HTML - nesting Markdown inside a block level HTML
> element causes it not to render properly as described by Point #3 of this
> article “Three Markdown Gotchas
> <https://blog.stackoverflow.com/2008/06/three-markdown-gotcha/>”.
>
> Given our increasing need to control style and formatting in our
> documentation, I wonder if it would be beneficial to switch to straight
> HTML within documentation source files for the Inclusive Design Guides site?
>
> Transitioning to straight HTML would also make the task of creating
> print-ready duplexed layouts easier as we would be able to use block level
> containers and not worry about the content not rendering.
>
> Any thoughts?
>
> - Jon.
>
>
> ---
> Jonathan Hung, Inclusive Designer
> Email: jhung at ocadu.ca
> OCAD University
> Inclusive Design Research Centre
>
>
> _______________________________________________________
> fluid-work mailing list - fluid-work at lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20161006/4457c900/attachment.htm>