Ordering of attributes for fenced divs, spans, and code blocks?

[rundel]

Description

Based on the quarto documentation (and pandoc) the order of arguments for fenced divs and spans in important - see here. Basically, identifier -> classes -> key-values is the expected order of these within the fenced attribute syntax.

The quarto documentation links back to the original pandoc documentation which mentions that this is based on fenced code attributes for code blocks. Which seem to use the same process for attaching attributes to code blocks.

I am trying to get a sense of how important is this in practice for the basic functionality of quarto and pandoc without having to manual test the various combinations and permutations.

My interest in this comes from the parsermd package I am working on and I'm trying to decide if mis-ordering of these arguments should be treated as a must fix issue (error) or a should fix issue (warning).

[mcanouil]

I'm not sure to understand, the documentation states that attributes should be in a specific order and you are asking if you can disregard the documentation?

---

Accessibility: For better accessibility, please ensure link text is descriptive and meaningful rather than using generic terms such as "here". This helps all users understand the link's destination. See Writing meaningful link text (WCAG).

[rundel]

I am interested in what the consequences of ignoring this are - this is a very easy mistake to make and it is not clear from the documentation what will happen when the order is not respected. From my limited testing of rendering quarto docs with variations on the order sometimes it matters and others it does not. I realize most of this is down to pandoc's handling of things but this specific requirement is only described in quarto's docs and not pandoc.

My package parses quarto docs and I'm trying to make a decision with regard to the error vs warning behavior on my side of things which amount to saying an incorrect order is not a valid quarto document or an incorrect order is a valid but potentially broken / wonky document.

I've been testing against the qmd in this repo's tests to find edge cases and there are a number of documents with this issue, I currently have a pull request #13220 about fixing a couple of them. I've found a few more in spans that I can fix as well but wanted a better understanding before I do that.

[mcanouil]

I believe the requirement is a Quarto one for Quarto specific features such as special "classes" (e.g., panel-tabset, callout-*) and cross-références prefix. These change how the fenced divs are processed, thus why the order matters.

In a standard fenced divs, the order does not really matter as it would only have meaning for HTML output and it would be a direct translation to <div id="" classes="" key="value"> and for HTML, the order does not matter.

For short, if the fenced divs is only the Markdown syntax for HTML => you can ignore the order.
For all other cases, you should observe the described order if you want to ensure the right result.