-
-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Syntax for divs #168
Comments
I think that using the delimited code block syntax as a model for a new div syntax is a good idea. It will be familiar to Pandoc users, and will be easy to remember. Since delimited code blocks require only 3 or more tildes, I think a div syntax requiring only 3 or more characters would be consistent and desirable. Using dots for delimited divs may not be the best choice because it's not uncommon to type "..." into a document (and "..." & "...." are too similar). Also, since the dot glyphs are at the bottom of a line, the closing dots look a bit odd hanging there all by themselves. Dashes would be nice but are too similar to the tildes used for delimited code blocks. Angle-brackets (greater-thans) might be nice, but are already used for blockquotes. "At" signs are a bit too obtrusive looking, IMO. Percent signs might be ok... IMO though, forward slashes probably look the nicest:
They look unobtrusive enough to me. The "///" is not a pattern that anyone uses in their writing with any regularity (that I know of). And I think that folks who have worked with html will think "closing html element" when they see "///", so that should make users feel fairly comfortable with them. As for nested divs, I very much do not like the idea of using indentation. In markdown, indentation is for code blocks and for making lists look pretty. :) If you want to support nested divs, but in a way that makes it obvious how many levels deep you are, how about requiring a space between each set of 3 forward slashes:
|
As I noted on the mailing list, I like the looks of this:
Optionally the attribute could be put on the same line as the underlines. (Note: currently the attribute parser requires the id to come first; this ought to be changed in any case.) Nesting can be handled the way I handle it with delimited code blocks -- a block is only ended by a string of underline characters that is at least as long than the one that opens it. So, you can use long strings of underlines for outer divs, shorter strings for inner divs.
|
Yes, I think that syntax fits nicely along with the syntax for delimited code blocks. The only thing I don't like is using underscores, because:
Since Pandoc is already using tildes for delimited code blocks, I think it would be consistent to also use tildes for generic delimited blocks -- however, maybe do it like so:
That is, the repeated pattern is "~ " (with a space), rather than "~" (no space). Some benefits of this syntax:
|
FWIW I like the tilde-space idea over underscores |
I think that it's desirable that the syntax for divs is
The reason I originally suggested a row of four periods |
+1 for this. I would love to set attributes (especially classes for styling) on more generated entities than just code blocks. |
I agree with the ability to set attributes (at least, id, classes and languages) for other blocks than code blocks. And having a RawSpan would be also interesting to be able to set attributes to any arbitrary text passage, not being an element. (I'm thinking of languages, but different font properties, such as small caps, fit here.) The syntax for spans in extended markdown should be different than periods, because this would be misleading. |
And how about square brackets for marking divs?
|
Wow! This issue is still open. :) Just stumbled upon it searching for something else. Not sure any of these proposals (including my own from a year ago) are significantly better than just using raw html. This may be one of those cases where Markdown wins simply by being able to embed raw html. |
For your consideration:
The carets make me think "metadata" (data, ^up there^, see?), and I can live with the space underneath much better than the space above (like you'd get if using dots). That, together with some [span syntax]{.other-class} would be very nice. |
Also, the carets look nice; not too obtrusive. Almost look like an underline at the bottom, but go ok at the top too. Clojure uses a similar caret syntax to mean metadata, and it looks pretty right to me. And, I think Pandoc is currently only using the caret for footnotes and for superscript, so it wouldn't conflict to allow it to be used here for this purpose (which would always be at least three carats). |
What about something from Bash and similar shells? |
I think it's agreed that some syntax for div and span elements is needed to tidy up markdown code which uses them. This discussion has turned into an exercise in bike shedding. Suggestions so far include
and various combinations of the above. To move things forward - I'm personally a fan of |
For what it's worth, the most popular idea on the CommonMark forum is I'm still undecided, including about side or surround marking, but I think I like Also, if anything is done on this, it should work like fenced code blocks -- the opening sequence can be of variable length, and the closing sequence must be of equal or greater length. That allows these things to be nested. |
Disclaimer: I still feel that smallcaps should be |
BTW it has occurred to me that having successively fewer marks for nested divs would lead to unpleasantness if you run out of markers. I'm not convinced that having an editor smack on a few |
I really like |
@jgm said: I really like Absolutely true. I keep forgetting that because I always use only ATX-headers. My commandline wrapper is set to pass |
Hi there. I'm completely new here, but these are my two cents anyway...
because that makes the desired result really obvious to both humans and parsers. But markdown started off as a minimal markup, so here's an idea how to simplify this further:
What do you think? |
@jgm, would it be possible that syntax for generic division and spans make its way into release 1.14? I would say that having different opening and closing characters (such as previously proposed Indenting is more problematic because not everyone feels comfortable with a coding editor (or you may not have one in your mobile device [tablet or smartphone]). And it doesn’t necessarily increase readability. But after more than five years that the original message had been posted in the mailing list, I guess it is time to implement a syntax for generic division and span elements. |
1.14 is going to be released very soon, so I'm not adding +++ Pablo Rodríguez [May 24 15 08:31 ]:
|
It does seem a little inconsistent that this syntax
(where you're combining the
the addition of the attribute is separate from the syntax of the block. Sorry, not sure if that's worded very clearly... In other words: if a writer learns the general rule that you can mark a block with Maybe there should be different rules for adding attributes to side-marked blocks vs adding them to delimited blocks. If so, then the indented div syntax muddies the waters of that distinction. |
Some points regarding side-marked div syntax (I'm already sold on
I've complained in the past about using
Consider this syntax for side-marked divs:
Regarding generic syntax for marking attributes on blocks, while you could leave the future option open for adding attributes to anything side-marked or delimited (line blocks, blockquotes, paragraphs (!)), for now just white-list:
I think the syntax being discussed here ( |
|
This thread reminds me of what it is like in my brain when choosing food in a Cantonese restaurant... 😄 So many factors, I am quite persuaded by the recent worries against indentation, and then we are left with delimited vs. side marking, and I think the practicality during writing of delimiting wins. And I think the : has the upper hand overall, so i vote for:
|
So to sum the last posts up (before things start to drag along for years again -.-) i see the following trends in the discussion: For delimited syntax we seem to have a winner (voted for: DaveJarvis, uvtc, iandol, me; proposed at least as option by: mb21, ickc; voted against: noone):
with possible expansions (at least 3
Further discussion-point for delimited syntax:
For the side-marking syntax there was suggested:
I personally would prefer having Further discussion-point for side-marked syntax:
|
Although there's a lot here, for me, this thread (reading, and contributing to it) has helped clarify a number of things about Pandoc Markdown. I've seen better and better suggestions, and changed my mind on at least a few things. Some bits I've learned:
|
One qualm: if the side-marked syntax is supposed to be the handsomer more markdownish one, it should as a special case provide a less-marked-up-looking syntax for when supplying exactly one class to the div. Could this:
work as a synonym for:
? |
- added attributes so side-tracked syntax - added test-cases
I updated my PR to reflect the new syntax. Two minor things that came up:
Otherwise the testcases should be complete. |
Additional test cases to consider (content and closing
|
Awesome 🎉 😄 🎆 |
WOW! ITS DONE! 🎈 🎈 🎈 |
I think I hear an angel choir… |
Same here! It took a while but this looks amazing!!! |
This is great, really happy to see this arriving! Two things:
|
Good suggestions, I've just done both.
+++ Mauro Bieg [Oct 24 17 14:58 ]:
… This is great, really happy to see this arriving!
Two things:
1. Maybe add the following sentence to the MANUAL:
The attributes can also be replaced with a single word which will form the class
name.
2. Add and fix the following test case (And another should be Para
instead of Plain)
% pandoc -t native
::::: Warning
Here is a paragraph.
And another.
:::::
^D
[Div ("",["Warning"],[])
[Para [Str "Here",Space,Str "is",Space,Str "a",Space,Str "paragraph."]
,Para [Str "And",Space,Str "another."]]]
—
You are receiving this because you modified the open/close state.
Reply to this email directly, [1]view it on GitHub, or [2]mute the
thread.
References
1. #168 (comment)
2. https://github.com/notifications/unsubscribe-auth/AAAL5D1LZG7SgPA2N-t4Rzm_6heK-fJVks5svfsIgaJpZM4AOGXV
|
Many thanks for this implementation. |
At last! 👍 🎆 |
Just curious, and I hope I don't open a can of worms, but was the idea of a side-marked syntax dropped ? Thanks for all the care that was put into this. |
+++ Simon Michael [Oct 30 17 07:25 ]:
Just curious, and I hope I don't open a can of worms, but was the idea
of a side-marked syntax dropped ?
I wanted to keep it simple, I guess. We could reconsider a
side-marked syntax later, but let's see how this works out.
|
It's been a year, are we interested in discussing side-marked syntax again? Indentation is great. How about the following one. It avoids fences, and use indentation.
|
The text was updated successfully, but these errors were encountered: