(I would have filed this as a bug report in mbutterick/pollen: book-publishing system - pollen - Gitea: Git with a cup of tea, but there’s no sign up button).
Consider the following evaluation:
> (decode-paragraphs '((div "First block") (@ (div "Second block") (div "Third block"))))
'((div "First block") (p (@ (div "Second block") (div "Third block"))))
The addition of
p is invalid.
Maybe try manually adding
@ as a block tag in the
setup submodule of your
If that works, maybe the fix in Pollen is to include
pollen/private/constants by default in
setup.rkt. Or to always include it via
decode-paragraphs doesn’t do any splicing, and we probably want to keep it that way.
I tend to agree with @joel. If the
@ were automatically spliced by default, it would violate the Principles of Least Astonishment and Generality. For instance, there would be no way to put two
div elements inside a
p. What’s the counterargument, @sorawee? Seems like it would be easy to splice the
@ elements within your own code before passing them to
I sent two email replies, not realizing the mailing list mode was not activated on this Discourse
@ as a block tag is not the same though. If I have
(@ (span "abc") (span "def")), I definitely want a paragraph wrapping there.
I agree that “magic behavior” is mostly harmful. But I am not asking for magic behavior.
@ promise that it will splice, so it should honor that promise (when interacting with other features). It’s a leaky abstraction otherwise.
It never makes sense to have a
div inside a
p. This is not a personal preference. It creates an invalid HTML, and the browsers will arbitrarily move the
One argument that I can see for not making the change is to avoid backward incompatibility (though I fail to see how anyone would rely on
@ not getting spliced). But in that case, I hope the behavior should be highlighted in the documentation, with the workaround mentioned.
I have now activated mailing-list mode. I wasn’t aware that it was deactivated by default.
This still doesn’t persuade me that this behavior counts as a bug, because the timing of the splicing should be consistent and predictable. As for your recommendation—should the
@ be evaluated everywhere, or only in places where it would result in a spurious
p tag? (That strikes me as even weirder and more magical.)
Pollen is not the HTML police. Furthermore, though the optional paragraph-wrapper argument defaults to
p, it could be
div, which would make your proposed behavior wrong, because a
div can contain other
The splicing of
@ is handled by the
splice function in
pollen/private/splice. If you invoked that function on your txexpr before you pass it to
decode-paragraphs, would that suffice?
Another idea: could
decode-paragraphs simply ignore the splicing tag for purposes of decoding? (edit: in other words, act as though the elements have been spliced without actually splicing them)