What could a "spoiler tag" extension look like?
@mb21 wrote: 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...
View ArticleWhat could a "spoiler tag" extension look like?
@vitaly wrote: 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...
View ArticleWhat could a "spoiler tag" extension look like?
@mb21 wrote: 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...
View ArticleWhat could a "spoiler tag" extension look like?
@jgm wrote: +++ 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...
View ArticleClik here to view.
What could a "spoiler tag" extension look like?
@vitaly wrote: jgm: Why are they "unusuable" (supposing a mechanism was provided to add attributes)? I've written, that those are unuseable in current state, not unuseable at all. It was in context of...
View ArticleClik here to view.
What could a "spoiler tag" extension look like?
@chrisalley wrote: vitaly: I've written, that those are unuseable in current state, not unuseable at all. It would be good to see some real world examples of where the current syntax is unusable. Read...
View ArticleClik here to view.
What could a "spoiler tag" extension look like?
@vitaly wrote: chrisalley: 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...
View ArticleWhat could a "spoiler tag" extension look like?
@mofosyne wrote: 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...
View ArticleClik here to view.
What could a "spoiler tag" extension look like?
@chrisalley wrote: vitaly: 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...
View ArticleClik here to view.
What could a "spoiler tag" extension look like?
@chrisalley wrote: vitaly: 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...
View ArticleClik here to view.
What could a "spoiler tag" extension look like?
@vitaly wrote: chrisalley: extensions are not the priority over the next six months. There are no need to blindly follow abstract principles, if it cost nothing to satisfy more people in shorter time...
View ArticleWhat could a "spoiler tag" extension look like?
@mofosyne wrote: Comment about how div is still needed for practicality, even if we seek for mostly semantic tag. Moved to http://talk.commonmark.org/t/content-block-inline-syntax/815/8?u=mofosyne...
View ArticleClik here to view.
What could a "spoiler tag" extension look like?
@vitaly wrote: 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...
View ArticleClik here to view.
What could a "spoiler tag" extension look like?
@chrisalley wrote: vitaly: 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...
View ArticleClik here to view.
What could a "spoiler tag" extension look like?
@vitaly wrote: chrisalley: I've outlined why there's an issue with fenced blocks being used for <div>'s (very applicable to the use case of spoilers). Let's clarify. DIV is HTML term. We are...
View ArticleWhat could a "spoiler tag" extension look like?
@Groostav wrote: 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...
View ArticleWhat could a "spoiler tag" extension look like?
@lu_zero wrote: >! 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...
View ArticleWhat could a "spoiler tag" extension look like?
@jgm wrote: +++ 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...
View ArticleWhat could a "spoiler tag" extension look like?
@zzzzBov wrote: My tendency is to encourage these sorts of requests to be markdown post-processors. Consider that >! produces <blockquote> <p>!</p> </blockquote> and that...
View ArticleClik here to view.
What could a "spoiler tag" extension look like?
@chrisalley wrote: Groostav: 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...
View Article