Components - Revision history

Hixie at 23:09, 11 January 2013

2013-01-11T23:09:24Z

← Older revision		Revision as of 23:09, 11 January 2013
Line 37:		Line 37:
	Pro: No parser change. Vanilla html, no tools break, no parser harmed during the making.		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.		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
	~~Fails:~~ 7

	Pro: Meets all requirements ~~but 7~~.		Pro: Meets all requirements.

	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~~.		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> ==

TabAtkins: /* Proposal: <x-geomap> for the default extension (specified in <element>), <x-geomap/select> to override */

2013-01-11T22:19:32Z

Proposal: <x-geomap> for the default extension (specified in <element>), <x-geomap/select> to override

← Older revision		Revision as of 22:19, 11 January 2013
Line 57:		Line 57:
	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

Bkardell: removed opinion

2013-01-11T22:14:44Z

removed opinion

← Older revision		Revision as of 22:14, 11 January 2013
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~~. The "x-" prefix is ugly~~.		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> ==

Bkardell: /* Proposal: <select is="geomap"> .. </select> */

2013-01-11T22:14:15Z

Proposal: <select is="geomap"> .. </select>

← Older revision		Revision as of 22:14, 11 January 2013
Line 35:		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: Makes authors think they can change the binding.		Con: (potentially) Makes authors think they can change the binding.

	== Proposal: <select/geomap> .. </select> ==		== Proposal: <select/geomap> .. </select> ==

Bkardell: /* Proposal: <select/geomap> .. </select> */

2013-01-11T22:13:09Z

Proposal: <select/geomap> .. </select>

← Older revision		Revision as of 22:13, 11 January 2013
Line 46:		Line 46:
	Pro: Meets all requirements but 7.		Pro: Meets all requirements but 7.

	Con: Requires parser changes. Requires devs to repeat the extended "native" tag for every component instance.		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> ==		== Proposal: <x-geomap><select> .. </select></x-geomap> ==

TabAtkins: /* Proposal: <geomap></geomap> */ formatting

2013-01-11T21:56:59Z

Proposal: <geomap></geomap>: formatting

← Older revision		Revision as of 21:56, 11 January 2013
Line 19:		Line 19:
	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: 1) Doesn't say what the standard semantic is. ~~2) throws~~ random ~~tags in~~ the ~~main space~~ - makes it hard to add new tags.		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> ==

TabAtkins: formatting

2013-01-11T21:56:15Z

formatting

← Older revision		Revision as of 21:56, 11 January 2013
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: 1) Doesn't say what the standard semantic is. 2) throws random tags in the main space - makes it hard to add new tags.		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.

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. The "x-" prefix is ugly.		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.

Line 34:		Line 36:

	Pro: No parser change.		Pro: No parser change.

	Con: Makes authors think they can change the binding.		Con: Makes authors think they can change the binding.

Line 51:		Line 54:

	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.

Bkardell: /* Proposal: <geomap></geomap> */

2013-01-11T21:27:40Z

Proposal: <geomap></geomap>

← Older revision		Revision as of 21:27, 11 January 2013
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: Doesn't say what the standard semantic is.		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> ==		== Proposal: <x-geomap></x-geomap> ==

TabAtkins: /* Proposal: <select/geomap> .. </select> */

2013-01-11T21:20:24Z

Proposal: <select/geomap> .. </select>

← Older revision		Revision as of 21:20, 11 January 2013
Line 38:		Line 38:
	== Proposal: <select/geomap> .. </select> ==		== Proposal: <select/geomap> .. </select> ==

	Meets: 1, 2, 3, 4, 5, 6, 7		Meets: 1, 2, 3, 4, 5, 6
			Fails: 7

	Pro: Meets all requirements.		Pro: Meets all requirements but 7.
	Con: Requires parser changes.
			Con: Requires parser changes. Requires devs to repeat the extended "native" tag for every component instance.

	== Proposal: <x-geomap><select> .. </select></x-geomap> ==		== Proposal: <x-geomap><select> .. </select></x-geomap> ==

TabAtkins: /* Proposal: <x-geomap> for the default extension (specified in <element>), <x-geomap/select> to override */

2013-01-11T21:19:04Z

Proposal: <x-geomap> for the default extension (specified in <element>), <x-geomap/select> to override

← Older revision		Revision as of 21:19, 11 January 2013
Line 56:		Line 56:
	Fails: 5		Fails: 5

	Pro: Looks like a new element. Tagname is the same in both modern and legacy UAs.		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.		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.