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
There are quite a few different proposals being made here which has complicated the discussion.
I’ve outlined why there’s an issue with fenced blocks being used for <div>'s (very applicable to the use case of spoilers).
That leaves line blocks and blockquotes, which have proposals for both side-marking and proposals for fenced block styles.
Line blocks that are side marked are a natural extension of sidemarked blockquotes which are already in the spec. It seems likely that sidemarked line blocks will become an extension.
Given this likelihood, if fenced blockquotes and line blocks are added they would be in addition to the sidemarked blocks, and so may not be needed if sidemarked blocks are sufficient.
The question (I think) @jgm was asking is why either sidemarked blockquotes or lineblocks are unusable in their current state? I suggested that it would be good to see some real world examples of the sidemarking syntax creating problems for the writer. Examples of actual text, rather than lists of features.
Let’s clarify. DIV is HTML term. We are speaking about block containers, not divs. Term DIV was used with meaning “block element with markup content”. Representation depends on renderer. For example, spoiler can be rendered to several nested divs. Other containers can be rendered to articles, sections, asides and anything else.
Probably, i missunderstood you, because your replied to my post. None of listed examples can be now expressed with sidemarking, because the only existing container (blockquote) in current state do not support attributes. That’s the root of problem. I would agree to use sidemarking as temporary solution, if attributes are supported. But i don’t believe, that it’s possible to add attributes support in reasonable time.
There are no reasons to say, that one type of block is better than another one. That depends on content type, size, editor and user preference. Even in this thread >1 users prefer sidemarking and >1 users prefer fencing.
1 Like
Forgive me for bumbling in but I really want this feature now that me and my team have a use case for it.
I’m assuming that because the discussion has shifted from ‘what should the markdown look-like to users’ to ‘how many div tags should we use and by the way what exactly is a div tag anyways’ that this issue has been sort’ve accepted. But the last post on this issue is from last year and I’m not sure where it would move forward. Any news?
The use case I’ve got is, on github, my team now reads and votes on issues before sprint kickoff. Right now those votes are just plaintext as comments, so if you’re voting as a junior dev and a senior dev has already voted you cant help but be biased by glancing at the comments. I’d like to put the votes in spoiler tags so that a reader has to have an explicit intent to see the vote. I noticed that stackoverflow was already doing this with a scheme that was perfect for my use case, but github was not.
Again, for this use case, the >! syntax is pretty good. It might get a little terse if vote-commenters simply do
>! 3
instead of
>! my vote is 3 points
but terse comments aren’t really markdowns fault (or problem).
Alternatively this could be a feature request with github. A reasonably elegant work-around would be to leverage the systems typically put in to reduce spam. If Github supported a ‘flag this comment’, which hid the comment (a le youtube or stack overflow), I could leverage that system to achieve this goal.
my .02, hope this happens soon!
>! probably would work neatly and the nice thing of it is that a diff-view extension would fit as well as
>+ and >-.
a spoiler can still be implemented attaching the css class to a normal blockquote.
>
> Fooo
>
{: class}
+++ Groostav [Apr 23 15 21:00 ]:
I’m assuming that because the discussion has shifted from ‘what should the markdown look-like to users’ to ‘how many div tags should we use and by the way what exactly is a div tag anyways’ that this issue has been sort’ve accepted. But the last post on this issue is from last year and I’m not sure where it would move forward. Any news?
No proposal has been accepted.
The use case I’ve got is, on github, my team now reads and votes on issues before sprint kickoff. Right now those votes are just plaintext as comments, so if you’re voting as a junior dev and a senior dev has already voted you cant help but be biased by glancing at the comments. I’d like to put the votes in spoiler tags so that a reader has to have an explicit intent to see the vote. I noticed that stackoverflow was already doing this with a scheme that was perfect for my use case, but github was not.
I’m a bit unclear about what you’re looking for. If you’re trying to do this on github, then only changes to github’s Markdown processor will help you, and this isn’t the right place to be asking.
If you’re asking how one might achieve this with a setup that used a CommonMark parser, then it seems to me that you could achieve what you want without any syntax changes at all, by establishing conventions.
For example, you could establish the convention that any block quote beginning with a single ! will be treated as a spoiler. On the server, you’d then walk the AST after parsing, looking for blockquotes that fit this description, and inserting some raw HTML around them to make them display hidden by default, with a button to display them.
No fancy block attribute syntax is needed for this, and there are some advantages to NOT using a fancy block attribute syntax (your document will degrade nicely on github or another Markdown renderer). Note also that, even if there were a fancy block attribute syntax, you’d still have to do some custom processing of the AST. Although we might consider generic block attribute syntax, “spoiler” seems far too specialized a thing to be part of the spec.
My tendency is to encourage these sorts of requests to be markdown post-processors.
Consider that
>!
produces
<blockquote>
<p>!</p>
</blockquote>
and that
>! example
produces
<blockquote>
<p>! example</p>
</blockquote>
a post-processor can simply look for blockquote > p:first-child and test that the text begins with ! to apply spoiler markup.
The advantage to post-processors is that they can be easily configured to suit individual needs. Want to change the spoiler class? Use a config option. Want to change the wrapping code? Use a config option.
I think this would be better suited to a small webapp which connects to GitHub’s API. The app would list the project’s issues and allow one vote for each GitHub account with access to the project. Maybe an app like this already exists? Edit: Maybe this would do the job.
I also want a spoiler tag, but for a different reason. I’d like to be able
to pgp-sign “looks good to merge” messages. Those messages should otherwise
be a few words, but instead look like a huge mangle of text. Spoiler
message would be a nice way to hide the mess while still making it
available for those who want it.
This is, in fact, the reason I joined this list :).
I’m a bit unclear about what you’re looking for. If you’re trying to do this on github, then only changes to github’s Markdown processor will help you, and this isn’t the right place to be asking.
Actually, github has been referring people here when they ask on https://github.com/github/markup (see, eg, https://github.com/github/markup/issues/411)
1 Like
I see so github admins is waiting for commonmark to implement this first. Interesting that it would be used to keep gpg keys hidden.
If custom containers looks like:
::: warning :::
dragon is here
:::::::::::::::
then a block spoiler could perhaps look like below ( dingus view (Seems to degrade gracefully too) ) :
__________________________
::::::::::::::::::::::::::
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.i
mQCNAi+UeBsAAAEEAMP0kXU75GQdzwwlMiwZBUKFUDRgR4wH9y5NP9JaZfVX8shT
ESbCTbGSEExB2ktEPh5//dkfftsKNlzlAugKFKTgBv20tQ9lDKfdbPVR0HmTLz0e
wVIeqEue4+Mt/Kq7kMcQy+5sX2RBAiZTYl0n/JdY/WxflU0taq1kH/UUPkklAAUR
tB5NYXJ0eSBNY0ZseSA8bWFydHlAZnV0dXJlLmNvbT6JAJUCBRAvlHhGrWQf9RQ+
SSUBAQX+BACnhx7OTb1SfAcJVF/1kuRPUWuGcl57eZgv4syc1O9T3YNr0terWQBT
K0vFR00FdaBv9X9XwlxaBJHGeiBcmhaiOTwB912ysoteUzZHne3sHPw3MkYboAFx
xHg43Cnj60OeZG2PKp/kU91ipOJP1cs8/xYOGkeoAMqDfwPeFlkBiA==
=ddBN
-----END PGP PUBLIC KEY BLOCK-----
::::::::::::::::::::::::::
__________________________
Another idea:
Fenced ^ chevron. Which to me, the chevron fenching either looks like it should be cut out, or collapsing on itself.
^^^^^^^^^^^^^ My PGP KEY ^^^^^^^^^^^^^
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.i
mQCNAi+UeBsAAAEEAMP0kXU75GQdzwwlMiwZBUKFUDRgR4wH9y5NP9JaZfVX8shT
ESbCTbGSEExB2ktEPh5//dkfftsKNlzlAugKFKTgBv20tQ9lDKfdbPVR0HmTLz0e
wVIeqEue4+Mt/Kq7kMcQy+5sX2RBAiZTYl0n/JdY/WxflU0taq1kH/UUPkklAAUR
tB5NYXJ0eSBNY0ZseSA8bWFydHlAZnV0dXJlLmNvbT6JAJUCBRAvlHhGrWQf9RQ+
SSUBAQX+BACnhx7OTb1SfAcJVF/1kuRPUWuGcl57eZgv4syc1O9T3YNr0terWQBT
K0vFR00FdaBv9X9XwlxaBJHGeiBcmhaiOTwB912ysoteUzZHne3sHPw3MkYboAFx
xHg43Cnj60OeZG2PKp/kU91ipOJP1cs8/xYOGkeoAMqDfwPeFlkBiA==
=ddBN
-----END PGP PUBLIC KEY BLOCK-----
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^