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?

[kyrias]

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.)

I meant Djot implementations in general where they would meaningfully treat the following identically.

{.foo}
> Foo

::: foo
> Foo
:::

In particular djot.js and djot.lua do not treat them meaningfully identically as the AST they return are different, but as you pointed out in the other thread above pandoc does indeed treat them the same way, which I feel unfortunate, since it makes pre-write processing more difficult.

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)?

While I think it's fine to make up a convenient meaning of what a class should imply in a given context, I ultimately just feel like any given annotated metadata should be accessible to the user when they define whatever commands end up implementing the final rendering behavior. Silently turning one of the above examples into the other and then not giving easy access to the metadata that was actually input feels rather unfortunate to me? I feel like if I can provide a certain set of metadata in the source language, it's rather sad if I can't then access that metadata while trying to override how a certain element is rendered.

(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?)

I mean, fair enough, it could certainly be argued that using Djot block quotes here is abusing the concept of block quotes, it's just what feels like be the local maxima of "simplest" and "most appropriate" tool for teaching to non-technical people to transcribe something like the following, while ending up with an end-result source format that's easily understood by the same group of people:

But I don't really see that my specific wanted rendered state is really that relevant to the overall desire to have access to the annotated metadata. The desired state could just as well be wanting to be able to annotate a given block quote with metadata which would affect the text color, or maybe with the author name such that that a given author's quotes can be rendered in a certain typeface, or whatever else one might want to do, which would then be contained in the relevant \blockquote implementation.

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...

That would probably be usable for what I want to do, sure. Personally I'd much rather be able to use simple classes though so that the source text wouldn't need to be adapted for this specific tool and could instead easily be used as-is in other contexts.

[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