As for the difference between before and after… For me it is a matter of how we see the attributes…
If we consider them merely like HTML attributes (ignoring all other considerations I make below) then to put them after would make sense since they are just seen as side parameters only there to serve the purpose of being used in the HTML generation process.
I point out in my previous comment that putting them before would make them easier to use to identify blocks. In the vision I have for those attributes, yes, they are used to feed the HTML rendering process (or any other kind of generation process…) but I see them mainly as semantic identifiers. They can tell us something about the text we are looking at or we are looking for.
For example, I could have a text like this:
# title level one
{.content}
Some text.
…that I want to comment…
# title level one
{.content}
Some text.
{.comment}
Author, could you make this sentence longer?
If I take the same text and I put the parameters blocks after, it gives something like this:
# title level one
Some text.
{.content}
Author, could you make this sentence longer?
{.comment}
For me, the first one is easier to read, in the second, it’s more difficult to know what goes with what.
Other point to consider in favor of putting attributes blocks before is consistency. The semantic information in a fenced code block, the parameters, is put before the block so parameters blocks should follow I think.
Another point regarding the spec. I see that there is no way to specify multiple classes in the attributes blocks:
Markdown authors shouldn’t write multiple key-value pairs with the same key in an attribute block. However, to ease the burden of implementation, the behaviour in such cases is left undefined—although most implementations will probably parse the attributes sequentially and insert them into a map, which would result in a last-one-wins semantic.
On this, I think a syntax like this should be allowed:
{.author .john}
Again, if we see classes as semantic tagging, or meta-information about the block, a bit like in fenced code blocks parameters, the support of multiple classes and the syntax that goes with it should clearly be defined in my opinion. The parsing would simply need to have an array(or a set to avoid duplicates…) per map entry and fill it in as the parsing is done.
Thank you very much for the link to the source code: exactly what I needed to get me started! I will look into it for sure, really appreciated!