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
No edit summary |
|||
| (6 intermediate revisions by 2 users not shown) | |||
| Line 18: | Line 18: | ||
Pro: Looks good to the original author — this is the closest thing to extending the language that we could do. | Pro: Looks good to the original author — this is the closest thing to extending the language that we could do. | ||
Con: | |||
Con: Doesn't say what the standard semantic is. Throws random names into the tag namespace - makes it hard to add new tags. | |||
== Proposal: <x-geomap></x-geomap> == | == Proposal: <x-geomap></x-geomap> == | ||
| Line 26: | Line 27: | ||
Pro: Looks like a new element. | Pro: Looks like a new element. | ||
Con: The standard semantic is located on the <element> element, somewhere else in the document or in a linked document | |||
Con: The standard semantic is located on the <element> element, somewhere else in the document or in a linked document. | |||
== Proposal: <select is="geomap"> .. </select> == | == Proposal: <select is="geomap"> .. </select> == | ||
| Line 33: | Line 35: | ||
Fails: 3, 4 | Fails: 3, 4 | ||
Pro: No parser change. | Pro: No parser change. Vanilla html, no tools break, no parser harmed during the making. | ||
Con: | |||
Con: Authors have assumed that it means they can change the binding. | |||
== Proposal: <select/geomap> .. </select> == | == Proposal: <select/geomap> .. </select> == | ||
Meets: 1, 2, 3, 4, 5, 6 | Meets: 1, 2, 3, 4, 5, 6, 7 | ||
Pro: Meets all requirements | Pro: Meets all requirements. | ||
Con: | Con: New syntax, requires parser changes and would be unfamiliar to today's authors. Requires authors to repeat the real semantic for every component instance. Shims might be hard to implement generically since in legacy UAs the component name would end up as an unadorned attribute. | ||
== Proposal: <x-geomap><select> .. </select></x-geomap> == | == Proposal: <x-geomap><select> .. </select></x-geomap> == | ||
| Line 51: | Line 53: | ||
Pro: Looks like it allows new elements. | 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. | 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. | ||
== Proposal: <x-geomap> for the default extension (specified in <element>), <x-geomap/select> to override == | == Proposal: <x-geomap> for the default extension (specified in <element>), <x-geomap/select> to override the extension == | ||
Meets: 1, 2, 3, 4, 6, 7 | Meets: 1, 2, 3, 4, 6, 7 | ||
Latest revision as of 23:09, 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. Throws random names into the tag namespace - makes it hard to add new tags.
Proposal: <x-geomap></x-geomap>
Meets: 1, 2, 3, 4, 6, 7 Fails: 5
Pro: Looks like a new element.
Con: The standard semantic is located on the <element> element, somewhere else in the document or in a linked document.
Proposal: <select is="geomap"> .. </select>
Meets: 1, 2, 5, 6, 7 Fails: 3, 4
Pro: No parser change. Vanilla html, no tools break, no parser harmed during the making.
Con: Authors have assumed that it means they can change the binding.
Proposal: <select/geomap> .. </select>
Meets: 1, 2, 3, 4, 5, 6, 7
Pro: Meets all requirements.
Con: New syntax, requires parser changes and would be unfamiliar to today's authors. Requires authors to repeat the real semantic for every component instance. Shims might be hard to implement generically since in legacy UAs the component name would end up as an unadorned attribute.
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.
Proposal: <x-geomap> for the default extension (specified in <element>), <x-geomap/select> to override the extension
Meets: 1, 2, 3, 4, 6, 7 Fails: 5
Pro: Looks like a new element. Tagname is the same in both modern and legacy UAs. Allows authors to add an API to an entire class of element (all <hN> elements, all sectioning elements, etc.) without having to define multiple components.
Con: Requires parsers to read the (possibly linked) element definitions to know what the default extensions are. Requires parser changes to support the override extension.