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
(removed opinion) |
|||
| Line 28: | Line 28: | ||
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> == | ||
Revision as of 22:14, 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: (potentially) Makes authors think they can change the binding.
Proposal: <select/geomap> .. </select>
Meets: 1, 2, 3, 4, 5, 6 Fails: 7
Pro: Meets all requirements but 7.
Con: a) Requires parser changes.b) Requires devs to repeat the extended "native" tag for every component instance. c) doesn't look like anything today but actually is parsable today as an attribute, however you couldn't use the attribute version. Many 'fallback scenarios' will want to understand that it is an attribute for purposes of script or css, but attempts to use attribute version will fail. Any early prollyfill could not distinguish between the two cases and will likely lead to people learning a preference for a broken way d) puts unprefixed attributes in the global space on an existing tag where there are already many reserved and potentially limits ability to grow html attributes.
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
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.