A solution here might be to improve Markdown editors instead of adding additional syntax options. For example, on this forum I’ve never manually typed the full quote syntax (e.g. [quote="jgm, post:43, topic:767"]) because it is easier to highlight a passage of text and click “quote reply”. The same might be applicable to lists, blockquotes, and other repetitive aspects of Markdown.
Could you summarize pending problems of fenced markup? It allows identation (based on marker offset), and should provide user choice for both cases:
- indented style for readability (or if you like it and have descent editor)
- not indented style for easy typing in any enviroment.
Also it allows resolving nested blocks and possible cases are already investigated & covered in spec (as fenced blocks for code).
Someone can dislike need of tailing marker, but it’s not a big price for universality and ability to accept this markup in reasonable time. Also, it will not pervent to add pure indented style later if required.
1 Like
Quotes should not be edited, that’s an edge case. Improving editors can solve problem, but it’s unsafe to assume that all users always have editor with good indented style support.
Just some thoughts.
-
Note that attribute blocks for side-marked blocks should not be inside the sidemarks, this precedent was set by Kramdown to avoid clashing with attributes on paragraphs within the side-marked content. But this could work:
{ .TIP } : # Don't use closed-source tools! : : You can't change them and you can't count on them : being around in the future.However, here it’s clearer to what the attribute belong to:
:::::::::::::::: { .TIP } ::::::::::::::::::::::: # Don't use closed-source tools! You can't change them and you can't count on them being around in the future. :::::::::::::::::::::::::::::::::::::::::::::::::And you’d probably rarely use a div without attributes.
-
For very long or nested content, the side-lined syntax seem to have the edge again.
::::::::::::: {#outer} blah blah blah ::: {#inner} ok :::::::::::: blah blah blah ::::::::::::::::::::::vs.
: blah : blah : blah : : : ok : {#inner} : : blah : blah : blah {#outer}
Yea I can see some convergence in regards to ::: . The difference tho is that I see it more as a block/div version of the inline/span []{}. Thus my logic is that since !extName[](){} is grammatically Verb/act + content/arg for inline, the same logic should apply for block directives as !extName: + content/arg. This allows for easily converting an existing block of content into a directive block. e.g.
This is spoiler text
Can be acted upon as
!spoiler:
This is spoiler text
Which is good for single paragraph content.
While for multi paragraph blocks, the ::: fence kicks in as:
!spoiler:
:::
This is a spoiler
With a second paragraph.
:::
I do not intend this to be a directive as it doesn’t have a block directive signifier !spoiler:. It’s just a div with classname .spoiler. E.g. you might want a warning, or notice box, and that would be rather overkill with directives
:::::::: Spoiler ::::::::::::::
Just a normal div container
:::::::::::::::::::::::::::::::I’ve handwritten and edited quotes numerous times. For example, when writing down a quote that is in printed material, embedded in an image or heard in spoken audio.
Agreed that we cannot make the assumption that the writer is using a specific editor. If the writer is quoting large blocks of text, perhaps they are an advanced user and likely to be using a more sophisticated editor? It would be good to see some use cases for long quotes. From my experience in academia it was generally frowned upon to quote more than a few paragraphs at a time; long quotes are at the expense of original content (perhaps @jgm would like to weigh in here).
With line blocks for song lyrics I can see a potential issue for marking up lengthy multi-paragraph songs.
If it is decided that a block syntax is necessary, perhaps we could use the same marker for familiarity, similar to how fenced code blocks use the same backtick as inline code:
>>>
This is a blockquote
Covering three paragraphs
Final paragraph
>>>
This could be an alternative to:
> This is a blockquote
>
> Covering three paragraphs
>
> Final paragraph
And for line blocks:
|||
This is a line block
Covering three paragraphs
Final paragraph
|||
This could be an alternative to:
| This is a blockquote
|
| Covering three paragraphs
|
| Final paragraph
I’m not entirely convinced of the need for this but it’s worth looking at options.
2 Likes
At this point, I see a block directive as basically a div that in addition to containing block elements, has:
- inline content
- a name (could be rendered as a HTML5 custom tag)
In absence of a filter or something handling a directive, a div is a natural fallback.
1 Like
To quickly recap the arguments in favour of each div-syntax proposal (nobody seems to like indented syntax):
Side-marking
- more readable for long sections (because it’s always obvious that you’re in a div-environment, even if the section is longer than the height of your screen)
- more local (removing one line doesn’t change large parts of your document)
Surround-marking
- more readable for short sections (because of the almost-line-long surrounding markers)
- doesn’t require a decent editor to write easily
- better for copy’n’pasting / wrapping existing stuff in a div
3 Likes
I’d say, both should be supported at the end. Because side-marking is nice for small peaces of text. But, side-marking needs much work. Surround-marking is fenced-blocks like, and can be accepted very easy.
For me, it’s more management question, how to reorder spec priorities. Having one well working DIV markup is much better than having zero. I don’t count blockquotes, because i think those are unusable in current state.
2 Likes
I agree. And the longer I think about it, the more I’m convinced that we should go for surround-marking for now. An alternative side-marking syntax could still be implemented later if needed.
1 Like
+++ Vitaly Puzrin [Nov 03 14 13:25 ]:
For me, it’s more management question, how to reorder spec priorities. Having one well working DIV markup is much better than having zero. I don’t count blockquotes, because i think those are unusable in current state.
Blockquotes are just a form of side-marking, and you don’t seem to be against side-marking in principle. Blockquotes can already contain arbitrary block elements. Why are they “unusuable” (supposing a mechanism was provided to add attributes)?
1 Like
I’ve written, that those are unuseable in current state, not unuseable at all. It was in context of comparison “what is more simple”: (a) finilize attributes spec a then consider fenced style divs or (b) consider fenced style divs and then work with attributes.
It would be good to see some real world examples of where the current syntax is unusable.
We mentioned it multiple times in different topics. In all cases, where container content needs different styling & still should have markup:
- collapsable spoiler, with title (layout, style)
- spoiler with hidden visibility (style)
- sidenotes, epigraphs, … (style)
- lyrics in text (style) (if you keep \n, hard breaks can be forced vith CSS for specific divs)
- forum quotes (source post & user info, layout, style)
That’s not complete list, only examples that i can remember immediately. But it’s enougth to demonstrate, that problem is not in single case.
Under style i mean everything, that can be done via CSS. That means, such blocks should have custom CSS class. All examples above need markup in content and can’t be implemented via fenced blocks (at least, without dirty hacks). Also, those need metadata (custom class name at least) and can’t be implemented via blockqoutes now.
I don’t see big technical problem to quickly add such blocks support to remarkable, but don’t like to introduce one more syntax and split community one more time. With plans about my own projects i can wait about 1-2 months, if there is any hope that at least 1 type of “normal” DIV will appear in spec. At least in draft state.
1 Like
Agreed. This discussion about <div> block syntax sounds related to Content Block/Inline Syntax
I haven’t seen any objection for fenced ::: as the <div> block syntax. And I think it’s also a good candidate for fencing generic detectives that can fall back as normal content.
Since github does (where ‘ruby’ is a css class name I think):
```ruby
require 'redcarpet'
markdown = Redcarpet.new("Hello World!")
puts markdown.to_html
```
then a direct eqv using the spoiler example for div would be:
:::spoiler
spoiler content here
:::
to which we can prettify it like so (perhaps classnames should have no spacing):
:::::::spoiler::::::::
spoiler content here
::::::::::::::::::::::
What do you think about this approach @vitaly ?
1 Like
I don’t think we should be rushing new syntax additions, even if draft state, based on other project requirements. Refer to @codinghorror’s comment in the strikethrough topic; extensions are not the priority over the next six months.
My suggestion is that you use raw HTML in the meantime which is already included in the spec.
Most of these wouldn’t require a div. They could be marked up with either blockquotes or line blocks (pre), plus additional markup for the extra data. Here’s what I suggest:
- Collapsable spoiler, with title. Use the blockquote syntax with a class for spoiler. Set a parser rule to make a heading and/or link directly before the blockquote the collapsable title.
- Spoiler with hidden visibility. Blockquote with spoiler CSS class.
- Sidenotes, epigraphs. The proposed line block syntax (
|) with a specific class. - Lyrics in text. Line blocks again.
- Forum quotes (source post & user info). Perhaps a blockquote/definition list combination, I’m not sure. Discourse solves this very specific requirement by using a custom tag instead of Markdown. Blockquote seems like the right element to use in any case.
The problem with using the div tag is that is contains no semantic meaning other than being a container. The HTML5 spec even advises against using it (emphasis added):
Authors are strongly encouraged to view the div element as an element of last resort, for when no other element is suitable. Use of more appropriate elements instead of the div element leads to better accessibility for readers and easier maintainability for authors.
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.
There are no need to blindly follow abstract principles, if it cost nothing to satisfy more people in shorter time by swapping order of 2 steps. I’ve explained above, that 1/2 of DIV spec (for fenced style) needs very few work for acceptance.
May be i have wrong estimate about efforts. But at least, nobody said the opposite.
I would do it, but it’s not acceptable. @chrisalley, i’m not going to push anyone for making fast decisions. I just share info, to better plan my own work. Because if alternatives possible, i’ll select one, which is better for CommonMark.
1 Like
Comment about how div is still needed for practicality, even if we seek for mostly semantic tag. Moved to Content Block/Inline Syntax
1 Like
IMHO you mix completely different things. You explain that “fenced container” not needed, because it can be replaced by several things, that not exists now but will be available sometime 
.
- Those are needed anyway, it’s a question of usability and preferences. For example, i don’t need lyrics, but i don’t say that line blocks are useless.
- Fenced blocks can be accepted faster, that other. I never said, that those are better or more important. I said, that now we have no containers at all with full attributes support, and it worth to accept at least one type. Then i explained, that acceptance of fenced block is the most easy in terms of time and efforts, not because i like those.
1 Like