Content Block/Inline Syntax

Alternative to <div>. Basically trying to codify the {} syntax

Inline Syntax via <span>:

Good for styling content within a paragraph.

...  [ inline content here ]{#id .Style attribute=value }  ...

As usual, it’s pretty much the url syntax {}

...  [ inline content here ](url){#id .Style attribute=value }  ...

Examples

 This my friend is a [ Cat ]{ .catStyle ] for all season
 You can find it at [ here ]( www.google.com ){ .googleStyle }
 You could just also do a normal link [like so]( www.google.com )

Counter examples

Should this be allowed? For some reason it looks dangerous to allow, but I could be wrong.

 ( www.google.com ){.googleStyle}

Possible HTML representation

If only define then:

<a href="http://example.net/">This link</a>

If fully defined as {}:

<span id="id" class="class"  attribute=value  >
 <a href="http://example.net/">This link</a>
</span>

#Block Syntax via <div>:
Quite simply its a block with content in it. Good for “note”, “warnings”, “tips”. Saw it used in the wild, not exactly sure how often however, but it’s out there.

Based on fenced code:

Since fenced code block is:

```ruby
require 'redcarpet'
markdown = Redcarpet.new("Hello World!")
puts markdown.to_html
```

then direct eqv is:

:::spoiler
spoiler content here
:::

syntax

:::<$className$>
... content of emphasis block ...
::: 
{ #id .classOverride }

::: <$className$> : <$HeaderText$> :::
... content of emphasis block ...
::: 
{ #id .classOverride }

:::
... content of emphasis block without header ...
:::
{ #id .classOverride }

##Example:

:::::::::::: Note :::::::::::::::
   Please Don't Touch The Cake
:::::::::::::::::::::::::::::::::

:::::::::::: WARNING :::::::::::::
   Well... its a warning message.
::::::::::::::::::::::::::::::::::

::::::::::::::::::::::::::::::::::
This block is used to style
a block of text. Using consistent
attribute syntax.

Allowing for handling of multiple
paragraphs too!
::::::::::::::::::::::::::::::::::
{ #id .class }

Possible HTML representation

In class representation, if $Key$ has spaces inside, perhaps just join it.

<div class=" <$className$> " > 
   <h1><$HeaderText$></h1>
   ... content here...
</div>

if no header text given, then key field is assumed to be a header

<div class=" <$className$> " > 
   <h1><$className$></h1>
   ... content here...
</div>
1 Like
[ inline group ]{ .attribute}

Looks fine

[[[ { .class key=value #id }
This is a paragraph inside a custom block

This is a second paragraph
]]]

Is more regular than using ! and matching the use we have for backtick and triple backtick.

I chose the !!! format because I often see it used in Warnings or Tips boxes. The benefit to this approach over [[[ ]]] is that you can make it look more like a box. Also doesn’t your approach feel a bit programmish?

!!! is inconsistent with [ and overall looks not fit if the block you want to mark is not something that requires additional attention.

On top

!!!

!!!

!!!

!!!

Is ambiguous and I’d just have the problem with the fence syntax and not add one more.

I see, so the main concern is parsing difficulties. @vitaly , if you would implement something like this, which method would you find easier to code in remarkable, and still be safe in practice?

someone here proposed this, and I think it looks aright for divs:

:::

... div container ...

::: { #id .style key=value }

Another suggested that we need some ways to generically redefine the actual tags itself.

So for <html>custom content</html> this is how we could potentially approach this:

Block

html:::::::::::::::::::::::: { #id .style key=value}
custom content
::::::::::::::::::::::::::::

inline

html[ custom content ]{ #id .style key=value}

Originally from: What could a "spoiler tag" extension look like? - #61 by vitaly

This is a strong indicator that the div element should not have it’s own Markdown syntax, even as an extension. We should aim to add more semantic elements on a case by case basis instead.

If I wanted to create a box that applies for “warnings” or “notices”, via say… “.warning” or “.noticebox” classname. Then how would I do it? I usually do it via a div container, but that’s not very markdownish.

e.g.

:::: Success Notification :::::
 ... lorem ipsum etc...
:::::::::::::::::::::::::::::::

:::: Error Notification :::::
 ... lorem ipsum etc...
:::::::::::::::::::::::::::::::

:::: Info Notification :::::
 ... lorem ipsum etc...
:::::::::::::::::::::::::::::::

:::: Warning Notification :::::
 ... lorem ipsum etc...
:::::::::::::::::::::::::::::::

:::: Print Notification :::::
 ... lorem ipsum etc...
:::::::::::::::::::::::::::::::

:::: Purchase Notification :::::
 ... lorem ipsum etc...
:::::::::::::::::::::::::::::::

<div class="success-notification" ><p>lorem ipsum</p></div>
etc...

It’s worth asking if notifications are content suited for a Markdown document. At an application level, sure, block containers are common. As something generated by users, are notifications actually needed? This ties into the question, what are the intended fields of application for Markdown?

1 Like

In technical textbooks, and online tutorials you really do need ‘boxes’, which is used in textbooks, to draw eyes to “very very very” important information.

E.g. A warning that you must not accidentally miss a switch, or your command will erase your entire hdd.

::::::::::::::::::::::: WARNING  ::::::::::::::::::::::::::::
            # rm -rf / – Deletes Everything! #

  The command rm -rf / deletes everything it possible can,
 including files on your hard drive and files on connected 
                 removable media devices. 
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

text from: http://www.howtogeek.com/125157/8-deadly-commands-you-should-never-run-on-linux/

tl;dr: saw it in textbooks, not just applications

1 Like

A few more experimentations with variations of “header text” for block content (WARNING is the classname .warning ):

::: WARNING : Back away from him :::
Well... its a warning message.
::::::::::::::::::::::::::::::::::::

:::::::::::: WARNING :::::::::::::
# Back away from him #
Well... its a warning message.
:::::::::::::::::::::::::::::::::::

::: WARNING # Back away from him # :::
Well... its a warning message.
::::::::::::::::::::::::::::::::::::::

::: WARNING : #Back away from him# :::
Well... its a warning message.
::::::::::::::::::::::::::::::::::::

Maybe we should only have class name in ::: field in middle option (easier to parse). But I rather like the first option in terms of presentation. Last 2 options doesn’t look presentable (but may others might object).