Change Proposal for ISSUE-127 - Revision history

Hixie at 03:05, 16 June 2011

2011-06-16T03:05:53Z

← Older revision		Revision as of 03:05, 16 June 2011
Line 1:		Line 1:
	Latest draft is at: http://lists.w3.org/Archives/Public/public-html/2011Feb/0243.html		Latest draft is at: http://lists.w3.org/Archives/Public/public-html/2011Feb/0243.html


			[[Category:W3C Issue]]

Hixie: Replaced content with 'Latest draft is at: http://lists.w3.org/Archives/Public/public-html/2011Feb/0243.html'

2011-02-14T09:14:06Z

Replaced content with 'Latest draft is at: http://lists.w3.org/Archives/Public/public-html/2011Feb/0243.html'

← Older revision		Revision as of 09:14, 14 February 2011
Line 1:		Line 1:
	* Fundamentally, the change here is ~~editorial, and should be left up to editorial discretion~~. ~~The suggested change is to a non~~-~~normative table, and despite claims to the contrary in the change proposal, the change will do nothing to actually affect how future link relations are designed.~~		Latest draft is at: http://lists.w3.org/Archives/Public/public-html/2011Feb/0243.html
	* There is no "goal to make link relations handling inside HTML consistent with link relations in other contexts". There is no particular benefit or use case to making link relations consistent between Atom and HTML. The two technologies are distinct and do not share link handling logic, even when a single software package implements both.
	* The proposal claims to simplify the spec by removing a degree of freedom, but even if the section it proposed to change was normative, in practice it merely trades one degree of freedom (the ability for a relationship on <link> to be defined differently than on <a>) for two others (the ability for a link relation to be allowed on <area> but not on <a>, and the ability for a link relation to have an effect on an element but not be allowed on that element), which would be a net increase in useless degrees of freedom, not a net decrease.
	** The ability for a link relationship to be allowed on <area> but not <a> has no use case and would be more confusing than a link relationship having different meaning on <link> and <a>, since <a> and <area> are interchangeable in a way that <link> and <a> are not.
	** A link relationship having a defined effect is not something that should be encouraged. If it is needed, it would be better to handle it as a special case in prose, since that would not give the appearance of it being a regular expected occurrence.

Hixie at 09:05, 14 February 2011

2011-02-14T09:05:45Z

← Older revision		Revision as of 09:05, 14 February 2011
Line 1:		Line 1:
			* Fundamentally, the change here is editorial, and should be left up to editorial discretion. The suggested change is to a non-normative table, and despite claims to the contrary in the change proposal, the change will do nothing to actually affect how future link relations are designed.
	* There is no "goal to make link relations handling inside HTML consistent with link relations in other contexts". There is no particular benefit or use case to making link relations consistent between Atom and HTML. The two technologies are distinct and do not share link handling logic, even when a single software package implements both.		* There is no "goal to make link relations handling inside HTML consistent with link relations in other contexts". There is no particular benefit or use case to making link relations consistent between Atom and HTML. The two technologies are distinct and do not share link handling logic, even when a single software package implements both.
	* The proposal claims to simplify the spec by removing a degree of freedom, but in practice it merely trades one degree of freedom (the ability for a relationship on <link> to be defined differently than on <a>) for two others (the ability for a link relation to be allowed on <area> but not on <a>, and the ability for a link relation to have an effect on an element but not be allowed on that element).		* The proposal claims to simplify the spec by removing a degree of freedom, but even if the section it proposed to change was normative, in practice it merely trades one degree of freedom (the ability for a relationship on <link> to be defined differently than on <a>) for two others (the ability for a link relation to be allowed on <area> but not on <a>, and the ability for a link relation to have an effect on an element but not be allowed on that element), which would be a net increase in useless degrees of freedom, not a net decrease.
	** The ability for a link relationship to be allowed on <area> but not <a> has no use case and would be more confusing than a link relationship having different meaning on <link> and <a>, since <a> and <area> are interchangeable in a way that <link> and <a> are not.		** The ability for a link relationship to be allowed on <area> but not <a> has no use case and would be more confusing than a link relationship having different meaning on <link> and <a>, since <a> and <area> are interchangeable in a way that <link> and <a> are not.
	** A link relationship having a defined effect is not something that should be encouraged. If it is needed, it would be better to handle it as a special case in prose, since that would not give the appearance of it being a regular expected occurrence.		** A link relationship having a defined effect is not something that should be encouraged. If it is needed, it would be better to handle it as a special case in prose, since that would not give the appearance of it being a regular expected occurrence.
	* Fundamentally, the change here is editorial, and should be left up to editorial discretion.

Hixie at 09:00, 14 February 2011

2011-02-14T09:00:10Z

← Older revision		Revision as of 09:00, 14 February 2011
Line 1:		Line 1:

	* There is no "goal to make link relations handling inside HTML consistent with link relations in other contexts". There is no particular benefit or use case to making link relations consistent between Atom and HTML. The two technologies are distinct and do not share link handling logic, even when a single software package implements both.		* There is no "goal to make link relations handling inside HTML consistent with link relations in other contexts". There is no particular benefit or use case to making link relations consistent between Atom and HTML. The two technologies are distinct and do not share link handling logic, even when a single software package implements both.
			* The proposal claims to simplify the spec by removing a degree of freedom, but in practice it merely trades one degree of freedom (the ability for a relationship on <link> to be defined differently than on <a>) for two others (the ability for a link relation to be allowed on <area> but not on <a>, and the ability for a link relation to have an effect on an element but not be allowed on that element).
			** The ability for a link relationship to be allowed on <area> but not <a> has no use case and would be more confusing than a link relationship having different meaning on <link> and <a>, since <a> and <area> are interchangeable in a way that <link> and <a> are not.
			** A link relationship having a defined effect is not something that should be encouraged. If it is needed, it would be better to handle it as a special case in prose, since that would not give the appearance of it being a regular expected occurrence.
			* Fundamentally, the change here is editorial, and should be left up to editorial discretion.

Hixie: Created page with ' * There is no "goal to make link relations handling inside HTML consistent with link relations in other contexts". There is no particular benefit or use case to making link rela...'

2011-02-14T08:51:27Z

Created page with ' * There is no "goal to make link relations handling inside HTML consistent with link relations in other contexts". There is no particular benefit or use case to making link rela...'

New page

* There is no "goal to make link relations handling inside HTML consistent with link relations in other contexts". There is no particular benefit or use case to making link relations consistent between Atom and HTML. The two technologies are distinct and do not share link handling logic, even when a single software package implements both.