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 IRC (such as one of these permanent autoconfirmed members).


From WHATWG Wiki
Revision as of 21:27, 11 January 2013 by Bkardell (talk | contribs) (Proposal: <geomap></geomap>)
Jump to: navigation, search

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 binding has to be immutable during element lifetime
  3. The syntax must not make authors think the binding is mutable
  4. The syntax must be as terse as possible
  5. 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.
  6. Musn't step on the HTML vocabulary namespace (where it would prevent future standard extensions)
  7. 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: 1) Doesn't say what the standard semantic is. 2) throws random tags in the main space - 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. 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 Fails: 7

Pro: Meets all requirements but 7.

Con: Requires parser changes. Requires devs to repeat the extended "native" tag for every component instance.

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.