Thomas Weber

Did a quick test with XML generation and maud seems already usable for many use cases. What is it that should be supported for XML? * Respecting Namespaces. This is...

Thinking about namespace validation: Here are examples demonstrating the challenges: ```rust use maud::html as xml; use maud::html as subtree; use maud::PreEscaped; fn subtree() -> PreEscaped { subtree! { subtree ns1:bar="test"...

> You want to treat an accidental like a free floating glyph, but it is always connected to a pitch event, so from my point of view it should be...

@ahankinson I'm perfectly O.K. with considering `@cue` belonging to both the logical and visual domains. But that means that it has implications for both domains, no? I.e. it implies that...

Yes, the examples should be changed, but as `@cue` seems to be misused so frequently, I think it also needs some clarification in the documentation about what it is and...

An alternative and less "radical" approach would be to define a generic font family [similar to CSS's](https://developer.mozilla.org/en-US/docs/Web/CSS/font-family#%3Cgeneric-name%3E) `serif`, `sans-serif`, `monospace` etc. I'd suggest `@fontfam="smufl-text"`. Like this, `` could be used...

Then what about introducing `rend/@encoding.auth`, in analogy to [`symbol/@glyph.auth`](https://music-encoding.org/guidelines/v4/attribute-classes/att.extsym.html)? This would signal the renderer to switch from a text font to a SMuFL font. A more specific font can then...

I find semi-closed lists perfect for this purpose.

@bwbohl You're right, `@fontfam` is not the cleanest solution. [What about introducing `@encoding.auth`](#issuecomment-679030146) – or just allow the existing `@glyph.auth` on more elements?

@bwbohl Do you mean ``, which already works inside ``? Or do you suggest introducing a `` element? Maybe the conclusion of this long-winded discussion might be to stick with...