[djedr]

I was talking about is making up a new markup language, which doesn't have to inherit the distinctions and behaviors of HTML.

If, in this language, you wanted to have this feature in combination with what I proposed, you could simply mark the attribute-like children, to inform the engine that it should apply different defaults for them and unmarked children that it doesn't recognize.

This is what I do in the first variant of my language:

  a [
    href=[...]
    [...]
  ]

the `=` appended to `href` marks it as an attribute.

This certainly simplifies things when translating to HTML.

But if we were not constrained by the legacy of HTML then perhaps bothering with this when designing a new language would be unnecessary. Maybe not having this default behavior does not matter in practice and you can have a simpler language without it.

To determine whether that's the case it would help to answer: when is the feature you described useful in HTML? And also: when is this feature harmful?

[notriddle]

If you just want to have your language throw up an error whenever it sees an unrecognized element, then you’ll probably be able to simplify it a lot. It’s probably fine, since

* as long as you use a build tool the errors will be seen by the author (who will know how to fix them) and not the reader

* graceful degradation and format extensions are a crapshoot due to Hyrum’s Law [1]

[1]: https://news.ycombinator.com/item?id=30726668

[djedr]

Yes, this is probably the most sensible approach.

Other options would be to ignore everything you don't recognize or ignore all nodes of the form:

  unrecognized tag [value]

i.e. where you don't recognize the key and the value is not complex.

You could still display stuff like:

  unrecognized tag [
    [text]
    ...
  ]

i.e. text nodes which are children of unrecognized elements.

But approaches like these would need a good justification.