bjuppa / macropiche Goto Github PK

Within the macropiche() method, set another parser (and content-getter?) for blade template files.

Perhaps we should use the "global" blade parser if one is accessible, and create our own blade parser only if $path ends with '.blade.php'?

So... <samp> may only contain phrasing content which doesn't include <pre>.
This means the current <samp><pre><code> output around processed templates is invalid HTML.

Could this be solved by putting the <samp> inside the <code> element?

See #5 for the discussion leading to the current solution.

Prism makes a big thing out of forcing semantically correct html for displaying code (http://prismjs.com/#features-full) so our current use of <pre><samp class="language-html"> for markup of the html generated by a template will probably not trigger Prism's highlighting...

Suggestion:
Replace samp with code and instead put a <samp> inside:
<pre><code class="language-html"><samp>
or outside:
<samp><pre><code class="language-html">

I'm not sure which one is best. The first example makes selecting both code blocks together with CSS easier, e.g. using something like :target ~ pre. But on the other hand, the second one seems more appealing semantically to me, stating early that the whole block is sample output.

We could also drop the use of <samp> altogether as it only makes a difference to a computer consumer and we can differentiate between the original template and its output using css classes anyway.

The figure element represents some flow content, optionally with a caption, that is self-contained (like a complete sentence) and is typically referenced as a single unit from the main flow of the document.

Would it be appropriate to switch our self-contained helper-output's <div> into <figure> with the path wrapped in <figcaption>?

See examples in the spec: https://html.spec.whatwg.org/multipage/semantics.html#the-figure-element

It's just a javascript that triggers on the .microlight class:
https://asvd.github.io/microlight/

Perhaps it can be supported by importing <script src="path/to/microlight.js"></script>, then running a custom little js that adds the microlight class to macropiche's <code>-elements and then call microlight.reset(); to activate?

We could have the package include some basic CSS for quick styling and perhaps a simple javascript for toggling code-display on/off on the macropiche elements.

Within the macropiche() method, set another parser (and content-getter?) for twig template files.

This is quite similar to #1 for Blade templates and I plan to do that first so we have pattern to follow for external template engines.

The element ids currently generated by macropiche can start with a number... which is really hard to select in css.

The first digit needs to be prepended with a \3 and and appended with a space
An element with id 893690-resources/components/colors needs to be selected with #\38 93690-resources\/components\/colors. See https://mathiasbynens.be/notes/css-escapes

Escaping the forward slashes with a backslash isn't too hard, but the starting digit is a bit of a pain I think.

It could be solved by prefixing all id's with a single character, like m for macropiche?