@mofosyne since there’s no element to attach attributes to, this seems more a problem for a directive.
Seems rather messy to use generic directives. How would you write slides for a slideshow presentation and style each differently? ( Imagine that ---- means make a new slide ). But doing it in a visually nice way.
# Presentation Title
---
# List
1. thing1
2. thing2
---
# header 2
Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
---
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.True, in such a case I would recommend using (for example) Pandoc’s --section-divs option which does:
Wrap sections in
<div>tags (or<section>tags in HTML5), and attach identifiers to the enclosing<div>(or<section>) rather than the header itself.
Then you can style them by targeting the generated identifier.
Would it work to do this? This uses ----- rules that you would see, when writing slides for slideshows
---
class: slideTitle
# Presentation Title
---
class: slideInspirationalQuote
> Lorem Ipsum - The Quote
---
class: slideList
# List
1. thing1
2. thing2
---
This ties into my proposal for metadata attributes
The metadata is placed in attribute of the div tag for that section. As seen in the example Metadata in documents .
For slides specifically, there are some good Markdown-based tools like remark. For a general solution to styling arbitrary-sized sections (without resorting to HTML), we could use a modification of the proposed span syntax, using square brackets.
The currently proposed way to insert span elements in text is using the following inline notation:
This is a sentence, and [this part is inside a span]{class=some-class}
You can see a larger example in previous posts
This could be extended to wrapping things in div elements when the brackets operate on a block level, perhaps like so:
[
This is all inside of a div. [This is inside a span, inside the same
div.]{class=styled}
> This is a blockquote.
> Still a blockquote.
1. And now a list:
2. See how these are all different blocks?
```
If the indentation seen here was part of the syntax, then the parser would have
to make sure to remove that leading whitespace when parsing other elements.
This code block, for example, should not be rendered with the leading
whitespace.
Except for this line, which would be indented relative to the fence.
```
]{class=styled data-slide-number=3}
I indented it for readability – in my opinion it looks better, but an argument could be made either way. The indentation could actually be part of the syntax, to help reduce ambiguity.
A quick set of rules:
A div wrapper is applied when the following is true:
- A line starts with a single opening square bracket, followed by no other non-whitespace characters.
- The following line contains at least one non-whitespace character.
- All the lines between the brackets are indented. (Optional? Discuss.)
It would then be closed by a single ] character occupying its own line.
What do you guys think?
Edit: General fixes and corrections
Argument could be made that indents are annoying. How about
[[[
non indented paragraph
]]]{ .styled slideNumber=3 }
still not quite as elegant as slide divider as ----
Btw my initial example is based off remark’s example http://gnab.github.io/remark/#11 which suggest this. I like this approach of having section attributes being defined in YAML.:
---
name: agenda
class: middle, center
# Agenda
The name of this slide is {{ name }}.
---What about the following, as a div syntax)?
::: { .styled slideNumber=3 }
one paragraph
another paragraph
:::
1 Like
For the record, I believe that completely hijacking essentially any use of ASCII braces for the attribute syntax is misguided. Maruku/kramdown had it right by requiring the colon; that is a combination much less likely to occur in running text. Markdown should err on the side of keeping simple things simple, and having to escape any brace is not simple.
Most curly braces wouldn’t need to be escaped with the current colon-less proposal either, since you always need to attach the attribute to something like a header or blockquote, see the examples. Btw, the colon has been discussed before.
Yes, I do see that this concern has been brushed aside before. I just don’t see any discussion.
From Maruku/Kramdown, I’m used to be able to attach an IAL to anything.
So the proposal here is to only allow to attach it to some things?
How, then, do you supply attributes to the other things?
I think a proposal needs to be very explicit about the way it avoids being too intrusive, and I’m not seeing that here.
(And, yes, I know that Maruku/Kramdown already allow attaching IDs to headings without giving a colon.)
Yes, every element (except list items) can have attributes, but the braces must be well-placed (e.g. for paragraphs they must be on an otherwise empty line trailing the paragraph): see the proposed spec. Therefore, you almost never have to escape curly braces when you want to use them as part of your text.
> Blockquote without attributes.
{.nope}
this should render as a blockquote with a paragraph with the attribute class=nope
@lu_zero Maybe you are right. Although I still tend to think that the non-lazy syntax should be required:
> Blockquote with a paragraph that has attributes.
> {.class}
A case could be made that this is consistent with how lazy blockquotes are defined (emphasis added):
Laziness. If a string of lines Ls constitute a block quote with contents Bs, then the result of deleting the initial block quote marker from one or more lines in which the next non-space character after the block quote marker is paragraph continuation text is a block quote with Bs as its content. Paragraph continuation text is text that will be parsed as part of the content of a paragraph, but does not occur at the beginning of the paragraph.
So if the attribute block of a paragraph (or more specifically its first character: the opening brace) is not part of the content of a paragraph, then my interpretation is consistent with lazy blockquotes, otherwise yours is.
Not sure which one is the easiest to implement or the more intuitive.
For what it’s worth, I think
> para
> {.attr}
is more intuitive. I find attributes on paragraphs a bit much though.
The alternative,
> para
{.attr}
implies to me that the attributes are on the blockquote.
I am also a fan of
> {.attr}
> blah blah
for attributes on blockquotes.
The latter is an attribute to the paragraph.
I started implementing that on CommonMark-py btw.
consider a todo list, with both completed and incomplete items.
This way the class of the li item can be used to control the icon (via css). Example vith one syntax from those mentioned above:
- buy bread
- buy milk {.done}
- buy cheese
{.todo}
1 Like
Why not—at least for links to sections and subsections—refrain from eagerly uglifying the proper text syntax, and rely on the fact that very likely every section and subsection already has a distinguishing property: simply the header’s text!
One could use this property (concrete: the wording of the section’s header) in an extended kind of reference, maybe like that:
## Introduction to Mark-up ##
### Special cases ###
As we have seen in the [introduction](@intro...mark-up), the most common cases are already [...]
In other words: use a pattern to refer to a section where the header matches this pattern.
It would be the implementation’s job to derive consistent and acceptable id attributes (ie conforming to the HTML rsp XML requirements) for the generated header elements (like <H2>) and in the generated href attributes (of, say, <A>), of course.
Details are of course TBD, like in the example above to do case-folding while matching, or ignoring punctuation, or provide more advanced forms of patterns like glob or even regexp syntax (for the experts among the Markdown writers 
I haven’t yet thought about linking to other elements however. Any ideas?
1 Like
@tin-pot, yes, this was already discussed at length here and has been implemented by e.g. pandoc. However, consistent attribute syntax solves a lot more problems.
2 Likes
Thanks for the pointers, I didn’t know about the existing discussion. Looks like the idea isn’t that far-fetched after all.
1 Like