This page discusses pros and cons of various inline component binding syntaxes.
The hard requirements are:
- The binding has to be done at element creation time
- The binding has to be immutable during element lifetime
- The syntax must not make authors think the binding is mutable
- The syntax must be as terse as possible
- The syntax has to convey the element's standard semantics (a specified HTML tag name) in the document markup, for legacy UAs and future non-supporting UAs like spiders.
- Musn't step on the HTML vocabulary namespace (where it would prevent future standard extensions)
- Needs to encourage authors to put a real semantic rather than just skipping that step.
The proposals below show the syntax for binding a "geomap" component to a <select> element:
Meets: 1, 2, 3, 4 Fails: 5, 6, 7
Pro: Looks good to the original author — this is the closest thing to extending the language that we could do. Con: Doesn't say what the standard semantic is.
Meets: 1, 2, 3, 4, 6 Fails: 5, 7
Pro: Looks like a new element. Con: Doesn't say what the standard semantic is. The "x-" prefix is ugly.
Proposal: <select is="geomap"> .. </select>
Meets: 1, 2, 5, 6, 7 Fails: 3, 4
Pro: No parser change. Con: Makes authors think they can change the binding.
Proposal: <select/geomap> .. </select>
Meets: 1, 2, 3, 4, 5, 6, 7
Pro: Meets all requirements. Con: Requires parser changes.
Proposal: <x-geomap><select> .. </select></x-geomap>
Meets: 1, 2, 3, 5, 6 Fails: 4, 7
Pro: Looks like it allows new elements. Con: Doesn't actually bind the component to the fallback, so you end up with two elements instead of one. Authors will quickly stop including the fallback when they realise it doesn't give _them_ any immediate benefit.