A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.
To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).
Components: Difference between revisions
(Created page with "This page discusses pros and cons of various inline component binding syntaxes. The hard requirements are: 1. The binding has to be done at element creation time 2. The bindi...") |
No edit summary |
||
| Line 2: | Line 2: | ||
The hard requirements are: | 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: | The proposals below show the syntax for binding a "geomap" component to a <select> element: | ||
Revision as of 20:42, 11 January 2013
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:
Proposal: <geomap></geomap>
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.
Proposal: <x-geomap></x-geomap>
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.