how to code ordered lists within <span> via markdown for wordpress & free standing .html files?

[kadso]

I’ve recently escaped from conventional word processing. I’m new to all things Scrivener. where is where I would like to end up:

1. infobox callouts, by way of styles to markdown and/or straight to .html where I can, at will add ordered lists (preferably via apple list engine used by Scrivener, while maintain the ability to use command + b, command + i, command +option + L and have them display as bold, italic and linked text (both in the editor and in footnotes (Thanks Keith!)

By way of creating styles with colored highlight + compiling the style’s prefix/suffix: with

I’m able to make multi-colored inbox(es) that meet my needs, except for the colored background of the apple engine lists built into scrivener.

So is I have the terminology down right…

since the above code is not able to keep the lists in the background I want for my multi-paragraph, multi-list inbox, anybody have any idea what might work?

[shout out to nontroppo for this helpful link: literatureandlatte.com/forum/vie … hp?t=49629

[nontroppo]

What exactly do you want to achieve: an ordered list (converted from a scrivener list) that is inside a coloured floating box, or spans within a normal list? If the answer is the former, that may be difficult to achieve with a simple style (as styles and apple lists don’t mix so well), but I’m sure we can come up with some creative workarounds!!!

[kadso]

The quick answer is yes and yes, but let’s start with the part that may not mix so well.
My thinking is I am already using the apple lists tech across so many apple OS environments and apps…

• scrivener scratchpad, scrivener editor, scrivener notes section, scrivener footnotes,
• devonthink,
• daylite
• textedit
• pages
• ithoughtsX
• and more…
  • and my human-to-technology interaction patterns* are pretty well baked in…
    • *my thinking what words to type and the actual act of typing those words, in biofeedback style, happens withl very little latency
      …that it might be best to close this loop before I open another power loop.

I sense the creative workaounds you offer will naturally lift my writing to new levels. But I want to be of clear mind when this happens, so as to see BOTH what is happening AND how it is happening.

Please consider this a kind request from an apprenticing scrivener.

[note: do you see how being able to put infobox(es) around my writing (say for the app list above) will help in providing context?]

[also note: more context flows below » enter at your own risk… (ha-ha)]

By starting from this pragmatic interaction core (the apple lists), and all associated constraints, a horizontal confluence will form that has been surfacing for some time: my leaving MS Word and old styled word processors behind.

Once I close this personal edification loop, I’ll be able to roll to the next level. The next level, I presently sense is the adaptation of using Scrivener for all my notes and using inter-app link backs tech (another demo of horizontal power relationships) when a note I write needs to be associated with another item (calendar event, reminder, etc.)

This may sound complex and/or crazy, but I find the more I get the written English language word to move like power of the physical world to help them negotiate a fast changing world…

This seemingly unconventional move of being willing to explore how horizontal maneuvering (by way of hyper-jumping horizontally between apps, rather than conventional wisdom of trying to stay vertically within a single app/walled garden, etc.) is consistent with ancient wisdom: like the [art of war](amazon.com/Big-Ratchet-Huma … ral+crisis) and other human endeavors that directly engage the physical world.

New technologies often drive new human behaviors. It is no coincidence that the above ‘horizontal hyper-jumping across apps to tap into Scrivener’s core capabilities, and back again℠, and more… is coming just as the latest example (blockchain) of how distributive technology’s to get humans to pay attention to horizontal as well as vertical power flow coming at them is seen surfacing…

[yet another note: The above being published via Scrivener’s markdown compile is just an example of me getting ready for the life altering affects of yet another technology…]

[^fn1]: as is presently being shown by way of the data streams being captured by both earthbound analog data sensors sending data ‘out into the world’ and geo-synced earth orbiting satellites sending data ‘back in to the world’, and more…

[nontroppo]

Um, you can wrap Scrivener lists into a paragraph style with list items that contain inline styles, which can get converted into a styled

and , like so:

BUT, Scrivener links appear to break — here is the MMD output:

consequuntur. Ea mea diam facete democritum, no quidam facilisis dissentias vix.  

<div class="info">
* 	•	This is an **Apple** *list*.
* 	•	It contains inline styles like maths:  $e=mc^2$ in the items.
    * 	⁃	It contains links to other documents.  
    * 	⁃	It contains links to web pages.
* 	•	It contains links to other apps. 
</div>

Pro in [accusamus delicatissimi](http://github.com), ad vis tota 

For some reason the list items get MMD * as expected yet still retain their bullets (doesn’t happen when “Convert Rich text” is off and “Convert Tables and lists” is turned on, but that will always break links). But the links disappear within the list, although they are fine OUTSIDE the list…

I attach the scrivener project: test.scriv.zip (56.3 KB) — AmberV, any ideas?

[AmberV]

Well for one thing, MMD6 uses an implicit behaviour for whether an HTML block ought to have its contents parsed for Markdown, and that is a clear line around the element itself—so basically following the same grammar rules as most Markdown elements:

<div class="info">

* First list item.
* Second list item.

</div>

The way you have your example will switch off interior block parsing and treat the same as raw HTML.

The second problem is that if you apply a style to a list it ceases to be a list. If you go in to your test file you’ll find that this is just text formatted to look like a list at this point. The compiler isn’t going to detect it as a list, so you end up with the tabs and bullet glyphs in the output.

Incidentally, I would approach this using a text-based mechanism rather than trying to get lists and styles playing together nicely (they are a touch oil and water, one being a core blackbox feature provided by macOS, the other being a bespoke system built on top of the text engine as a second layer of non-RTF parsing). Putting “” on a line above the list and “<\InfoList>” below it, and then handling the transformation to syntax as a compile-time Replacement is going to be a more reliable solution I think. That is exactly how I handled call-outs prior to styles, and how I would handle them now if I needed to include a particularly complicated piece of content (which I would consider a nested list to be an example of, at least in a typesetting sense) inside of one.

[nontroppo]

Thanks AmberV, yes, I did initially suggest that styles and apple lists don’t mix, and had first thought to use replacements. Scrivener is however still telling me that list is still a “list” after wrapping with the paragraph style (see the dropdown menu), which was why I thought it seemed to be working (but the fact that the bullets are exported indeed show otherwise):

The problem is that as I understand it kadso wants Scrivener links + apple lists + custom block/span markup. “Convert rich text to markdown” breaks custom markup by escaping everything, but I think it is the only way to convert Scrivener links in apple lists to generate markdown links?

Use replacements:

Compiles to:

\<div class="infobox"\>

* This is an **\*\*Apple\*\*** *\*list\**.
* It contains inline styles like maths:  $e=mc^2$ in the items.
    * It contains links to other documents.  
    * It contains [links](http://github.com) to web pages.
* It contains [links](bookends://sonnysoftware.com/34521) to other apps. 

\</div\>

Being able to toggle escaping would solve this problem instantly, but that discussion is still ongoing Or allow scrivener links to be converted using “Convert tables and lists” where escaping is not done.

So for the moment, I think kadso will need to give up scrivener links and apple lists and switch to using markdown and/or replacements?

[AmberV]

Perhaps a better way of putting it would be that wrapping a list in a style like this will break the list rather than drop it to pure text. It isn’t something that has a graceful fallback, and remnants of list formatting may remain (largely nonfunctional in the editor)—in this case if one compiled your sample to RTF and opened it in Word they would probably get double-bullets since enough of the list remains to declare it, but the bullet structure itself that we can see in Scrivener is no longer a part of the syntax.

The problem is that as I understand it kadso wants Scrivener links + apple lists + custom block/span markup. “Convert rich text to markdown” breaks custom markup by escaping everything, but I think it is the only way to convert Scrivener links in apple lists to generate markdown links?

That’s a good point, I omitted an important ingredient in my suggestion. The above is only a problem if one doesn’t designate their markup. The system was designed for this kind of blending of writing methods, but it needs human guidance to pull it off since it doesn’t have a full parser built-in. Simply wrapping the replacement code in Preserve Formatting (in conjunction with the Treat “Preserve Formatting” as raw markup compile option) or a style set up for raw markup is the correct approach—same thing you would need to do if you wanted to blend raw HTML into something intended for ePub output for example. The compiler needs to be told what it should leave alone.

Original text in Scrivener, using Preserve Formatting.

Here is the intermediary MultiMarkdown output:

<div class="info">

* This is an **Apple** *list*.
* It contains inline styles like `code spans`.
    * It contains [scene b][] document links.
    * And [regular hyperlinks](https://www.literatureandlatte.com/).
* And that is that.

</div>

And the HTML5 converted result:

<div class="info">

	<ul>
		<li>This is an <strong>Apple</strong> <em>list</em>.</li>
		<li>It contains inline styles like <code>code spans</code>.
			<ul>
				<li>It contains <a href="#sceneb">scene b</a> document links.</li>
				<li>And <a href="https://www.literatureandlatte.com/">regular hyperlinks</a>.</li>
			</ul>
		</li>
		<li>And that is that.</li>
	</ul>

</div>

Pros and cons: if one intends to also use Scrivener’s standard RTF outputs as well, then the best approach is to use styles instead of Preserve Formatting. The former have the optional capability of deleting marked text on a per Format basis. Thus one can include special instructions for Markdown outputs, omit them in PDF, or include secondary instructions for ebooks that are omitted for Markdown and PDF. Styles are a way of creating agile source materials. For simple cases though, PF is going to be more straightforward and involve less setup (you don’t even have to make a custom format).

As an aside, you can have lists and tables converted to Markdown along with standard Markdown text, if that is all you need (I use that option for some projects).

[kadso]

First, as an apprenticing scrivener I really appreciate the open dialog among subject matter experts and the ‘show your thinking’ aspect of this unique forum. What I’m learning is pulling together a bunch of things I saw on my own, but could not pull it together on my own. Thank you all!

But I have to admit: I’m lost! Five times I have reviewed what is posted and tried implementing what has been stated. I’m unable to execute anything. To many different areas with to many settings options for me to keep it all straight.

So let’s try something different. Here is a key phrase that stuck out to me: “Styles are a way of creating agile source materials.” As interesting as this interaction has been, if experience has taught me anything, it is I’ll be back with more “interesting situations” I’ll need help on. So, maybe we proceed with the following premise?

Is there any chance someone can help by laying out a step-by-step action list?

Using styles as a base premise, can I create apple lists with colored backgrounds + formatting (bold, Italic) + regular hyperlinks to other webpages + footnote links (cf)? that compile via markdown to;

1. markdown
2. .html
3. .rtf (and if I have to drop off the .rtf/word processing/.pdg tech of the last century, I’m prepared to do so.

[AmberV]

No worries at all! I’ll do my best to summarise the ingredients and demonstrate their synthesis in an example project.

Using styles as a base premise, can I create apple lists with colored backgrounds + formatting (bold, Italic) + regular hyperlinks to other webpages + footnote links (cf)? that compile via markdown to;

To that specifically, no, on account of limitations in the interaction between Scrivener’s style system, and the underlying list system. As demonstrated above, if you try to put a style around a list then the list can be damaged by doing so. While it may look nice in the text editor, it’s really not a functional solution for anything other than looking nice in the editor, I’m afraid. Those highlights don’t even mean anything outside of Scrivener. But like the bubbles around inline footnotes and annotations, they are internal ‘syntax highlighting’ if you will.

Hence the best available solutions are those that seek to generate the output you desire, by putting markers around the list. Good callout boxes are really only something you can achieve with Scrivener’s non-word processing methods, as those require complex technology not supported by Scrivener, like floating boxes, background colours, borders and such.

The implications are that while you can create a callout box with its ebook HTML-based formats and of course the Markdown-based stuff, there is nothing you can do to create such a thing with the RTF-based stuff. Therefore there is no material advantage in having a style wrapped around the entire list anyway, and there is not much you can do short of hinting to yourself where a box should be, and formatting these things in a proper layout environment after compiling.^[1]

simple_list_example.zip (117 KB)

So with that in mind, more of the focus will be on those formats where callouts can be achieved. In the example project attached to this post, have a look at the following ingredients:

• Note the “InfoBox” text around the list in the editor, and how it is styled with “Raw Markdown”. That’s all we need to do in the writing phase. The actual text in the styled range is up to you of course, you could use “@start:callout” and “@end:callout”, or whatever—but if you experiment with changing it around you’ll want to continue going through these bullets first.
• In the “Compiled Examples” folder you’ll find the output results from the different compile formats I designed for this test. Markdown itself doesn’t have a callout box, so we just use HTML, which is acceptable. Note how the marker becomes full HTML in the first two examples. In the RTF example, nothing remains. The ePub example will need to be opened in a viewer.
• Now open compile, which you should find in MultiMarkdown mode. The only notable thing here is that in the General Options tab on the right, we have the Convert rich text to MultiMarkdown setting applied.
• Double-click the “Callout Box Example” format in the left sidebar and examine its settings:

  • In the Styles pane, we have our “Raw Markdown” style, with the Treat as raw markup setting enabled. This tells Scrivener to leave text marked like this alone.

  • In the Metadata pane I’ve added an “HTML Header” key with a little sample CSS so that we can see the results of the div in a browser.

  • Finally, in Replacements the markers used in the editor are converted to the desired HTML. Here is where you would need to change the settings if you wanted to use a different style of marker while writing.

    You could even type the HTML into the editor itself. The advantage in using an abstract marker is identical to the avantage we have in using Markdown however: it can be things other than HTML without a bunch of work. We could make another format that is designed for LaTeX, which would use different syntax for making a callout box, or DocBook.^[2]

• Back in the compile overview screen, you could have a look at the MultiMarkdown→HTML settings as well. There is nothing different however, they use the same Format. All this does is automate turning the .md file into .html when compiling.
• Switch to Compile for: RTF. We now have two completely different compile Formats in the sidebar. The only interesting things they do will be found in the Style pane. One leaves the markers in the output as styled text (making them red so they are easier to spot). The other makes use of the Delete text of this style option to strip them out. While you don’t get any kind of callout box marking, it is at least something useful for proofing and similar.
• Finally, I know you didn’t ask for it, but I thought it worth including a demonstration to ePub as well, and it only took a few seconds to do so anyway. If you switch over to Compile for: ePub 3, you might notice we’re using the same Format we do for MMD and MMD→HTML. That’s because the solution is essentially identical (we want the InfoBox tags to be converted to HTML and then left alone by the compiler), we just need to put information in different pane for the CSS stuff:
  • In the CSS pane, I enable “Append Custom CSS to Stylesheet”, and paste in the example CSS used by the MultiMarkdown format.

Hopefully that gives you some ideas of where you can go with this idea in your projects. There are other approaches as well of course, but I think this one has the best balance of getting what you want in two (or three) cases, and what best leads to what you want in the case of RTF.

Notes

1. That is after all what we are doing with Markdown and HTML. The difference is that outside of WYSIWYG environments, one needn’t do everything with formatting codes. You’ll see similar even in traditional publication environments, the concept of using text markers for stuff like callouts is common place, rather than trying to affect these designs in office software and writing programs.
2. Hopefully not to confuse the matter, but refer to this post. Note that although I use a single style around a block of text for callouts, I am not using Scrivener like a word processor. My text is Markdown, and if I were to put a list into a callout box, I would type it in using Markdown syntax.

[kadso]

Amber » thanks for your quick, comprehensive reply » I’ll be working this through this weekend » Nice Work!

[nontroppo]

…there is nothing you can do to create such a thing with the RTF-based stuff…

While that may be true for strict RTF, if you were to think about other compatible output formats you may consider legacy like Word or LibreOffice, then this does not strictly apply if you were to use Pandoc. Pandoc allows you transform arbitrary block / inline chunks of text into named paragraph and character styles . Practically, you would use replacements as AmberV has excellently detailed, to gwnerate the block and inline markup for Pandoc. Pandoc would then do the transformation when necessary to HTML/DOCX/ODF or many other outputs. So a simplified example of the markdown:

Dickinson [starts]{.Emphatically} the poem simply:

::: {.Poetry}
| A Bird came down the Walk---
| He did not know I saw---
:::

You could create an emphatically character style in Scrivener, and use replacements or the markup directly for the block (:::{.stylename} — this is readable in the markdown, would be converted into divs and spans in HTML, and converted into block and inline styles for Word etc.

[kadso]

OK, so I have had a chance to sit down and hold space for all you two have shown me. Just let me say, “This is awesome!”
I was able to follow Amber’s “step-by-step-look-here-see this-for this-is-what-is-all-about-and-why-it-is-important” style of writing. (a skill I need to improve upon and now that is see how it is done, I can get on with improving my skills…)

I found an additional component that when using Amber’s critical inputs brings me to a minimum viable product/publishing level. Of which, I would simple not get on my own. Thank you Amber. Thank you Nontroppo!

when publishing in one of two desired output environments, strictly to .html, Amber’s

did the trick. That’s all that was needed. (see attachment: div 1-html]

when publishing to wordpress (with JetPack plugin’s markdown option enabled) more was needed:

Once I added the "markdown=“1” the outpost went from not working (see attachment: div 1-wp) to better (see attachment: div 2-wp

for reference, on page 18 of Fletcher Penny’s MULTIMARKDOWN USER’S GUIDE
“This option tells MultiMarkdown to process the text included within HTML tags in the source document. This can feature can also be implemented on a tag-by-tag basis within the document itself, such as

.”

So where does this leave this item today? I’m good with where we are. If the code and intra-document link items can be worked out to make them both operational in the wordpress publishing environment, great! But I’m good with the way things lay today.

now, on to the writing in the omnidirectional ∞ multifaceted way that began al this…

[AmberV]

You are quite welcome; glad to hear you go things working well at this point!

“This option tells MultiMarkdown to process the text included within HTML tags in the source document. This can feature can also be implemented on a tag-by-tag basis within the document itself, such as

.”

That’s a bit outdated at this point in time (the user guide was written for MMD5, and never updated for 6). I’m not sure if it is in fact documented anywhere, as I don’t see it in the MMD6 Quick Start Guide either, but this nomenclature is no longer respected by the engine, and instead it uses a transparent switch that requires the text content within the HTML to be separated from any block level HTML by an empty line. That is why it is important that our output look like this:

[code]

…

[/code]

And not this:

[code]

…

[/code]

We get the correct behaviour for free, even though the “InfoBox” tags in the editor are not spaced out, because Scrivener’s RTF → MMD conversion will automatically add empty lines between paragraphs.

Importantly, the ‘markdown=“1”’ attribute itself will not be stripped out by MMD6, leaving it in the output HTML, which will cause validation errors since it is not a formal attribute. If you do indeed run into such issues down the line, you could consider having two different compile formats, one for JetPack and the other for MMD, each with their own Replacement settings.

[kadso]

Thank Amber » for now I’ll go with the two different versions…

If I may, how would I go about having a second colored box with the same features?
I’m not a coder so I don’t know how to go about doing that exactly. I sensing that i has to do with the metadata area?
am I close with:

.infobox-y { background-color: #FBF198; width: 75%; margin-top: 1rem; margin-bottom: 1rem; margin-left: auto; margin-right: auto; } .infobox-p { background-color: #F6D6FD; width: 75%; margin-top: 1rem; margin-bottom: 1rem; margin-left: auto; margin-right: auto; }

and then use the following in scrivener’s editor?
for the yellow box
and
for the purple box
both followed by the or perspectively?

[AmberV]

If I may, how would I go about having a second colored box with the same features?

You’ve got the right idea—HTML/CSS is pretty simple like that!

To get a little more picky: good practice is to establish general rules that apply to many things separately from specific rules. Say you change your mind about how much margin you want around all boxes. If each infobox class has its own margin setting, you’d have to go through and fix each one of them. However if all infoboxes have their margins set up collectively, you only need to fix one thing. Here’s an example (keeping it simple for the sake of brevity):

.infobox-y,
.infobox-p { width: 75%, margin: 1rem auto; }
.infobox-y { background-color: #FBF198 }
.infobox-p { background-color: #F6D6FD }

The first part sets up the common details for how infoboxes in general should look. Each new callout class would be added here in the common-delineated list. The other two rules only concern themselves with what is different about them: the background colour.

Now for your Replacements in Scrivener, considering that both callout boxes end the same way:

</div>

You don’t really need two separate ways to close them off. So maybe just have the extra Replacements for the two different ways to start them:

<div class="infobox-y">

<div class="infobox-p">