I can’t quite understand the terminology you use here: what do you mean by “web-components”? What is a “generic extension”? An extension of the CommonMark syntax (specification)?
It is a bit unfortunate to have two or even more discussions running in parallel about the same topic, which I would state as:
How could one implement “special processing” of specially-labeled code blocks (and code spans), in a generic, flexible, and robust way, in accord with the CommonMark specification as well as existing Markdown practice?
I have put forward arguments over there why I think that it would be neither useful nor required to distinguish (by prefixing the label with “!” for example, or in any other way) between
-
“what settings is being passed to the plugin/extension/preprocessor” (I think you mean here: raw text contents of blocks, not settings are passed to the “external” processor, or did you mean that the label specifies which processor will have the these raw block contents passed to?), in other words: processing the raw block content using an “external” tool, and which; and
-
“regular” CommonMark semantics for labeled code blocks, which as a matter of fact does not specify anything how these labels ought to be interpreted, and would them process just the same, disregarding the label alltogether. (I guess that you mean something like this by the words “if we take the logic these defines the fallback states of generic extensions/web-components”.)
Doing otherwise—forcing the CommonMark author to make a distinction between those “labels” (which really mean: labels for syntaxes, raw text classes, or what you want to call it) that can and should be processed and those that can not by a specific implementation (say a web site)—well, doing otherwise would fly in the face of portability of CommonMark documents in my view.
I really would want to gain (or retain?) the ability for an author to write, for example:
~~~~C
int foo = bar;
~~~~
and having a good chance that a CommonMark (or Markdown for that matter) implementation either
-
does know what to do with “
C” labeled code blocks, and does interpret their content as C programmin language source code, in the implementation’s own way—probably producing syntax-highlighted HTML rendering (whether by using an external processor or by any other means is irrelevant for an author, or the CommonMark syntax); or else -
doesn’t know what to do with this “
C” label, and just falls back to the default behaviour, the onecmarkshows right now: treat it and render it like any other, ordinary code block, and simply present the content as mono-spaced text with hard line-breaks and no other interpretation or processing.
You would have to come up with a really good argument to convince me otherwise, that is: that distinguishing in the author’s marked-up typescript between “!C” labels (meaning “do process”), and “C” labels (meaning “do not process”) would actually achieve something valuable, and for whom.
As far as I can see, it wouldn’t—not for the author, and even less so for the implementor, and even lesser so for the maintainers and adherents of a stable, simple, and portable CommonMark syntax specification.