Accessing Djot attributes from overriden command

[kyrias]

I wanted to try using markdown.sile's Djot inputter for a project I'm working on which involves re-typesetting an old book. As part of this I need to be able to have, depending on context, block quotes treated as being part of the same contiguous paragraph, meaning, among other things, that e.g. the paragraph following it should not have any paragraph indentation.

The simple solution would be to just define my own blockquote environment which ends in SILE.call("set", { parameter="current.parindent", value="0pt" }), which works. The problem I had though is that I'd like to be able to toggle this behavior based on e.g. specifying a class attribute for the block quote, but attributes don't end up being passed in to the called commands.

Is this intentional, and is there any simple way to access the attributes from my custom command?

[Omikhleia]

I think is was originally intentional and the attributes, if present, are passed to an implicit div around the underlying blockquote, where linking etc. is implemented.

This being said, I realize that for a captioned blockquote the attributes are passed both to the underlying environment (= epigraph when resilient.sile is used) and a surrounding div.... So there's some small discrepancy here, so perhaps we could do something about it...

Yet, it has always been a grey area here, due to the fact that SILE originally didn't have a working blockquote environment (I proposed one upstream, which went into SILE 0.15.0); we had (and still have) a fallback in markdown.sile; and resilient.sile provides its own "styled" environments... -- So I refrained adding too "clever" options, there, due to the multiple path...

I haven't tested them, but djot.lua also has filters (similar to Pandoc in that regard), so perhaps they could also be used for such things?

[kyrias]

I think is was originally intentional and the attributes, if present, are passed to an implicit div around the underlying blockquote, where linking etc. is implemented.

I find this behavior rather surprising since this automatic div wrapping doesn't follow how other Djot implementations work. If you e.g. throw {.foo}\n> Foo at the JavaScript implementation you'd get a blockquote with a class, not a div-wrapped blockquote without any classes.

I could work around it, but it would require overriding markdown:internal:div, which feels rather icky, and would then require parsing content to figure out what the context is.

What's the rationale for the automatic div wrapping? If it's just for creating labels on things with an id attribute I feel like it would probably make more sense to split that functionality out into something more generic that could be used by everything, including the div implementation, rather than silently wrapping everything in something that you didn't write.

I haven't tested them, but djot.lua also has filters (similar to Pandoc in that regard), so perhaps they could also be used for such things?

I don't think djot.lua filters would help with my needs since they just let you modify the AST before it's rendered, but the AST already looks like what I want want it to.

[Omikhleia]

this automatic div wrapping doesn't follow how other Djot implementations work.

By the way:

$ pandoc -f djot -t markdown
{.test}
> Hello quote

::: {.test wrapper="1"}
> Hello quote
:::

Or

$ pandoc -f djot -t html
{.test}
> Hello quote

<div class="test" data-wrapper="1">
<blockquote>
<p>Hello quote</p>
</blockquote>
</div>

I'd call that an implicit div wrapping here too, no? 🤣

[Omikhleia]

I find this behavior rather surprising since this automatic div wrapping doesn't follow how other Djot implementations work.

Which "other" implementations? Markdown.sile's Djot support Lua predates the Djot support in Pandoc by several months. (And "standard" Djot doesn't have captioned block quotes yet either, or citations, etc.)
So it's comparing oranges and apples, maybe? SILE is not a web browser (= no HTML, no CSS): What is a "class" supposed to mean in such a context? And what is a "class" even if the broader context of resilient.sile, which has a styling paradigm (similar, but different from CSS)?

(By the way, style guides varies a lot between countries, so I cannot speak in general without more research, but some would argue that a "block" quote is always paragraph-indented... and starts with an ellipsis (possibly bracketed) if not quoted in full -- or one doesn't use a blockquote in those case, but an inline quotation. Is your mentioned use case generic enough for being considered?)

Anyhow, maybe it is. And I did say it above:

I think is was originally intentional .... So there's some small discrepancy here, so perhaps we could do something about it...

Or to put it otherwise, SILE didn't have half of the constructs needed at the time (hey, it didn't have multi-line strikethrough or underline then! And it still doesn't really has BCP47 language support at this time!). It was a constant effort on bringing new things to SILE upstream, improving resilient.sile and adding Djot while re-using as much as the existing Markdown / Pandoc AST support already in place. There are sure some areas where it could be improved. But "I feel like it would probably make more sense to split that functionality out into something more generic" is just a reinvented history, in some ways...

I also explained the rationale:

it has always been a grey area here, due to the fact that SILE originally didn't have a working blockquote environment

E.g. What if it supported the custom-style attribute, and allowed to pick a different style? (This would imply using resilient.sile, obviously. Would this be a problem, though?) -- after all that's what I eventually did for underline/strikethrough etc. that can be fully styled and hence even used for another semantics...

And that's only one of the possibilities.
What do you think is the best approach?

[Omikhleia]

Let's keep the discussion open, and I'll consider our options eventually...

TBH, Djot is in such a flux (with ongoing discussions on metadata, "side-marking", "fencing", "tags" etc. that could change the language so much that it doesn't look eventually similar to what we currently have)... The AST for djot-js already differs from that of djot-lua... And it's hard to say what its future will be, under which type of governance...

[kyrias]

Fair enough!

If I continue with this project using Djot then for now I guess I'll probably just throw together a simple inputter myself which does just enough for my needs.

[Omikhleia]

#139 = Fixing the discrepancy here at least. Since neither SILE's blockquote nor resilient's blockquote use options, this still requires one to provide their own (re-)implementation to take advantages from the passed attributes.

I'll also open an issue on resilient.sile to track it = Omikhleia/resilient.sile#117

[Omikhleia]

@kyrias I'll make a patch release soon here, including that fix #139.

On resilient's side, does Omikhleia/resilient.sile#117 (comment) sounds good to you?

(I'm planning a resilient.sile release also, though I'll have other things to put in it)