(Hey, I’m back!)
This is all getting fairly specific, now. I think it’s important that there aren’t too many edge cases for specific elements–this particular spec is intended for power users, but it shouldn’t be unfeasible for, say, someone just learning HTML/CSS to pick up quickly. The more deviations from a generalized syntax there are, the more nightmarish it all becomes. I’d very strongly recommend keeping the metadata at the end of the element for this reason.
@sam, on the data-
prefix front, it’s worth mentioning the work the fine folks over at AMCSS are doing. They don’t use “data” as a prefix at all, since support for arbitrary attributes is almost universal (read what they say on the topic, however–they know their reasons better than I do). In the case of quote
, I’m inclined to just have the user type out “data-quote” if that’s what they want the output to be. There isn’t really any need to add a processing step between what the user types and what it actually turns into. From a user-experience point of view, more steps means higher mental load and more confusion.
As for the
> {test}
use case, I don’t think this is really an issue. I can’t think of a reason why anyone would need to render an empty block quote with nothing but metadata attached to it, so the spec would state that you can’t have such an element (thereby solving the ambiguous case). Again though, I very much think we should be careful not to stray too far from a standard syntax. How would you explain to a user that metadata on a paragraph is entered in curly braces on the line following, while metadata on a block quote is entered within the quote on the first line while preceded by an exclamation mark, without curly braces? It all seems terribly arbitrary. Let strange derivative syntaxes belong to other implementations–CommonMark is for intuitive, standard solutions.