Talk:RelExtensions - Revision history

Ocolon: /* canonical-wwwnone */ added a question on handling different values in different files under one domain

2010-08-23T02:08:00Z

canonical-wwwnone: added a question on handling different values in different files under one domain

← Older revision		Revision as of 02:08, 23 August 2010
Line 106:		Line 106:

	I'm sorry these case explanations became so long. Might look complicated. Actually your proposal <code>canonical-domain</code> is simple yet powerful. Google webmaster tools show there's a need for this. I like this one very much. [[User:Ocolon\|Ocolon]] 00:48, 23 August 2010 (UTC)		I'm sorry these case explanations became so long. Might look complicated. Actually your proposal <code>canonical-domain</code> is simple yet powerful. Google webmaster tools show there's a need for this. I like this one very much. [[User:Ocolon\|Ocolon]] 00:48, 23 August 2010 (UTC)

			=== Handling different values in different files under one domain ===

			Another thought on <code>canonical-domain</code>/<code>canonical-wwwnone</code>: Is this to be handled individually for each file or domain-wide? If this should be interpreted domain-wide, how should conflicting values in different files be handled?

			Example:
			* <nowiki>http://foo.example/001.html</nowiki> contains <code><nowiki><meta name="canonical-domain" href="http://one.example/"></nowiki></code>
			* <nowiki>http://foo.example/002.html</nowiki> contains <code><nowiki><meta name="canonical-domain" href="http://two.example/"></nowiki></code>

			On the one hand it seems to be more appropriate to have this applied for each file individually (a link-tag in a file usually adds meta information just to this file, that's why it's in this file's head). On the other hand applying this to one file only would "degrade" <code>canonical-domain</code>/<code>canonical-wwwnone</code> to something very similar to <code>canonical</code> which works also on a file basis.

			Considering this, it might even be cleverer to do this with [http://en.wikipedia.org/wiki/Robots.txt robots.txt]? [[User:Ocolon\|Ocolon]] 02:08, 23 August 2010 (UTC)

Ocolon: /* Usage conflict */ further notes on why canonical-domain covers canonical-wwwnone already

2010-08-23T00:48:01Z

Usage conflict: further notes on why canonical-domain covers canonical-wwwnone already

← Older revision		Revision as of 00:48, 23 August 2010
Line 84:		Line 84:

	Thanks. [[User:Nick\|Nick]] 17:42, 22 August 2010 (UTC)		Thanks. [[User:Nick\|Nick]] 17:42, 22 August 2010 (UTC)

			: Thank you for your examples – I see that cases like the ones you describe can occur. However, bigfabulouswidgetstore.example and www.bigfabulouswidgetstore.example are de facto two different domains, because technically "www" is a subdomain like "wiki" or any other prefix would be. Therefore <code>canonical-wwwnone</code> is already covered by <code>canonical-domain</code> (it doesn't have to be explicitly folded into it anymore), unless it is explicitly defined as not being implied. I don't think such a definition would be justified by the given example.

			: Let's have a closer look at two cases that are similar to the scenario you described:

			:* Case 1: A website owner wants to name bigfabulouswidgetstore.example without www as <code>canonical-domain</code> for widgetstore.example. He also wants to name www.bigfabulouswidgetstore.example with www as <code>canonical-domain</code> for appstore.example. And he doesn't want to define a general preference for bigfabulouswidgetstore.example or www.bigfabulouswidgetstore.example.
			:** Does this work when <code>canonical-domain</code> includes the power of <code>canonical-wwwnone</code> as well ("www-sensitive")? Yes. That's because a general preference for using bigfabulouswidgetstore.example with or without www, meaning one is the canonical domain of the other, would only be defined if <code>canonical-domain</code> was set with one of these values at (www.)bigfabulouswidgetstore.example. Setting different values at appstore.example and widgetstore.example is perfectly possible and only affects appstore.example and widgetstore.example, not (www.)bigfabulouswidgetstore.example.
			:** Does this work if <code>canonical-domain</code> does not differentiate between a domain with or without www ("www-neutral")? No. The websites appstore.example and widgetstore.example can only define an unspecific (www.)bigfabulouswidgetstore.example as canonical domain name for both or with the add of <code>canonical-wwwnone</code> at (www.)bigfabulouswidgetstore.example a general preference.

			: It turns out that the "www-sensitive" <code>canonical-domain</code> allone offers more possibilities in this case than <code>canonical-wwwnone</code> and/or a "www-neutral" <code>canonical-domain</code>.

			:* Case 2: A website owner wants to specify a <code>canonical-domain</code> at widgetstore.example, namely (www.)bigfabulouswidgetstore.example, without specifying whether bigfabulouswidgetstore.example or www.bigfabulouswidgetstore.example should be the canonical domain for widgetstore.example. I'm not sure which benefit could arise from this but let's consider it anyway:
			:** This is clearly not possible with a single "www-sensitive" <code>canonical-domain</code>. It would be possible to use two different "www-sensitive" <code>canonical-domain</code>s though. This would look weird and I wouldn't recommend to allow this, but finally that's what the domain owner wants in this scenario: Two canonical domains, with and without www.
			:** Does this make more sense with a "www-neutral" <code>canonical-domain</code>? I don't think it does: While it doesn't look as weird it does the same, it assigns two domains, with and without www. However, there's a side effect here: greatfruitstore.example and www.greatfruitstore.example become impossible <code>canonical-domain</code> values if these sites don't share the same content (or else "half of the canonical domain" would be defunct or misleading).

			: It seems that for the advantage of making a rare case more elegantly possible "www-neutral" <code>canonical-domain</code>s could only be used when the www- and non-www version of the href-attribute both exist and share the same content.

			: So, although you are right that a "www-sensitive" <code>canonical-domain</code> doesn't satisfy all possible scenarios, I believe it works in more scenarios than a "www-neutral" <code>canonical-domain</code> would.

			: From keeping <code>canonical-domain</code> "www-sensitive" follows that <code>canonical-wwwnone</code> doesn't provide extra functionality and could be dropped (it could still be supported as a special case of <code>canonical-domain</code> for historical reasons if used somewhere but shouldn't be used in new webpages).

			I'm sorry these case explanations became so long. Might look complicated. Actually your proposal <code>canonical-domain</code> is simple yet powerful. Google webmaster tools show there's a need for this. I like this one very much. [[User:Ocolon\|Ocolon]] 00:48, 23 August 2010 (UTC)

Nick: /* canonical-wwwnone */ Replied.

2010-08-22T17:42:25Z

canonical-wwwnone: Replied.

← Older revision		Revision as of 17:42, 22 August 2010
Line 66:		Line 66:

	[[User:Nick\|Nick]], my impression is that your proposal <code>canonical-domain</code> already covers everything your proposal <code>canonical-wwwnone</code> achieves. Wouldn't it be better to concentrate on the more powerful <code>canonical-domain</code> and drop <code>canonical-wwwnone</code>? [[User:Ocolon\|Ocolon]] 09:40, 21 August 2010 (UTC)		[[User:Nick\|Nick]], my impression is that your proposal <code>canonical-domain</code> already covers everything your proposal <code>canonical-wwwnone</code> achieves. Wouldn't it be better to concentrate on the more powerful <code>canonical-domain</code> and drop <code>canonical-wwwnone</code>? [[User:Ocolon\|Ocolon]] 09:40, 21 August 2010 (UTC)

			=== Responses ===

			==== Error ====

			You're right about href; that's my stupid error. I corrected it.

			==== Usage conflict ====

			Since canonical-domain is for the case where someone owns widgetstore.example and bigfabulouswidgetstore.example and would rather everyone find the latter in search engine results, folding canonical-wwwnone into canonical-domain raises a question: Could there be a case (often enough) in which the site owner would '''not''' want a preference between the www and bare forms of bigfabulouswidgetstore.example? I understand that there are unusual but real cases in which an owner has separate sites for www and no-www.

			I assume there is a realistic although small frequency, so I'd leave the range of rel values in their hands, plus keep the clarity for page authors of there being separate rel values for somewhat different purposes. But if the case is too obscure and too rare, maybe it should be folded in. In that case, the multi-domain-name site owner will either not pick canonicality at all (unlikely except for amateurs) or will have to choose either bare or www when doing so.

			One possible use case would be measuring marketing success by comparing sales by what people typed, thus what advertising they saw. Getting people to say what ad they saw so often fails that companies use many department numbers, 800 phone numbers, domain names, and so on. Bare-or-www in a log might serve that same purpose.

			(I'm using the .example TLD per RFC 2606, akin to example.net, in case subdomains of the latter are considered a special case.)

			Thanks. [[User:Nick\|Nick]] 17:42, 22 August 2010 (UTC)

Ocolon: point at an error in the descriptions of canonical-wwwnone, propose dropping canonical-wwwnone in favor of the more powerful canonical-domain

2010-08-21T09:40:39Z

point at an error in the descriptions of canonical-wwwnone, propose dropping canonical-wwwnone in favor of the more powerful canonical-domain

← Older revision		Revision as of 09:40, 21 August 2010
Line 50:		Line 50:

	Thanks. [[User:Nick\|Nick]] 00:33, 8 October 2009 (UTC)		Thanks. [[User:Nick\|Nick]] 00:33, 8 October 2009 (UTC)

			== canonical-wwwnone ==

			=== Error in the description ===

			Currently it says:

			<pre>The rel value is the form preferred for indexing, e.g., rel="http://example.net".</pre>

			I am pretty sure this should be:

			<pre>The href value is the form preferred for indexing, e.g., href="http://example.net".</pre> [[User:Ocolon\|Ocolon]] 09:40, 21 August 2010 (UTC)

			=== Redundancy ===

			[[User:Nick\|Nick]], my impression is that your proposal <code>canonical-domain</code> already covers everything your proposal <code>canonical-wwwnone</code> achieves. Wouldn't it be better to concentrate on the more powerful <code>canonical-domain</code> and drop <code>canonical-wwwnone</code>? [[User:Ocolon\|Ocolon]] 09:40, 21 August 2010 (UTC)

Nick: /* On footnote, note, and jump */ new section

2009-10-08T00:33:47Z

On footnote, note, and jump: new section

← Older revision		Revision as of 00:33, 8 October 2009
Line 44:		Line 44:
	Thank you.		Thank you.
	[[User:Nick\|Nick]] 20:10, 20 September 2009 (UTC)		[[User:Nick\|Nick]] 20:10, 20 September 2009 (UTC)

			== On footnote, note, and jump ==

			The footnote and jump both seem useful if a browser opens an additional window so that the main text or prejump text, respectively, remains visible, especially useful for endnotes after long texts. This is analogous to the behavior for sidebar [http://www.w3.org/TR/html5/history.html#link-type-sidebar (HTML5, working draft of 8-25-09, section 6.12.3.16)]. To that end, I'm renaming this proposed keyword ''note'', as a more generic name, and adding ''footnote'' and ''endnote'' to the description. I don't know what a sidenote is and, while I can guess, I don't recall it being used or mentioned in literature, a local central public librarian doesn't remember ever seeing one, my OOo 3.0.0 spellchecker rejects it, and a callout isn't a sidenote, although I suppose this link pointing to a callout would be okay. While I'm taking ''sidenote'' out of the synonymy, which is only for legacy support (I gather it wasn't a past rel keyword), I'm still adding it to the description, in case, to preserve the original proposer's intent.

			Thanks. [[User:Nick\|Nick]] 00:33, 8 October 2009 (UTC)

Nick: /* On canonical-domain, canonical-wwwnone, and canonical-first */ new section

2009-09-20T20:10:55Z

On canonical-domain, canonical-wwwnone, and canonical-first: new section

← Older revision		Revision as of 20:10, 20 September 2009
Line 17:		Line 17:

	shortlink has also been proposed (on the blagosphere) as shorter and shorturl		shortlink has also been proposed (on the blagosphere) as shorter and shorturl

			== On canonical-domain, canonical-wwwnone, and canonical-first ==

			Responding to your summary on the last reversion:

			Two were analogous services, as noted, not the exact services. The concepts were discussed by Google and were justified there.

			For canonical-wwwnone, for the concept underlying it, Google says this at the linked page under "Set your preferred domain":
			"Setting your preferred domain tells Google which version of your site's URL (http://www.example.com or http://example.com) you prefer.
			"If you set your preferred domain as http://example.com, we'll treat links to http://www.example.com exactly the same as links to your preferred domain."

			Since Google supports this by requiring the site owner to tell Google through a tool apparently not on the website owner's site, I proposed a method apropos to all search engines that wish to implement it.

			For canonical-domain, while the same Google page supports only intradomain canonicalization, it does support that (see under "Specify the canonical link for each version of the page"). I extended their concept to interdomain canonicalization, because many institutions have multiple domains for identical content or the same website. An owner of one website with multiple domains who wants to do well in search engine results would likely prefer that all external inbound links point to one domain but can't ask everyone else to edit their links without risking links being deleted and a lowering in search results, and just asking everyone is a bunch of work. My proposal reduces the workload and eliminates that risk while raising site credibility that helps with positioning in search engine results.

			Examples of domains that probably share sites (although I didn't drill down to check beyond the home pages and didn't have the plugin to view the home page/s on the first pair): <http://esbnyc.com/> and <http://empirestatebuilding.com/>, which might redirect, and <http://www.networksolutions.com/> and <netsol.com>, as I typed it, which redirects.

			While redirection is an easy solution, the site owner might prefer to display a message to users of one domain and not the other as part of educating the general public about the preferred domain (as used to be the case at yaho.com (one "o")). In that case, canonical-domain would inform search engines who wish to implement it while allowing the site owner to educate the part of the public that types the wrong name. For example, in New York City the agency that intervenes for abused children is still widely known by initials that have been abolished for 40 years (I heard it in conversation on the 15th of this month).

			However, I do see one defect with my proposal. Where a rel link works, a rev link can usually be expected to work, and rev for canonical-domain could be used to steal traffic from a competitor or other site. So I will add that rev must be meaningless.

			I will do the same for canonical-wwwnone, since I understand that it's possible, albeit unusual, to have separate websites for www and bare forms of the same domain, depending on the host's architecture, which means it's possible, albeit very unlikely, that the two websites could be under separate managers, and perhaps separate owners, who bitterly compete. So I will add that rev must be meaningless for that keyword, too.

			For canonical-first, I did not cite Google. Because it is possible to have a canonical set of pages and one noncanonical page in situations where the keywords alternate and print wouldn't be technically adequate or semantically apt, and the canonical set of pages might not fully occupy a directory, it might be more convenient to have canonical-first as shorthand. That's easier because only one page needs coding rather than two or more. Because it is shorthand, however, it is more dispensable, if people would like to reject it. I'm putting it back for the time being, i.e., for decision, since it seems to have been removed on the basis of the Google position, but I hadn't asserted that Google supported it. I will also add that rev must be meaningless for this keyword, too.

			Thank you.
			[[User:Nick\|Nick]] 20:10, 20 September 2009 (UTC)

Sm: /* XFN noise */

2009-05-06T16:52:23Z

XFN noise

← Older revision		Revision as of 16:52, 6 May 2009
Line 12:		Line 12:

	Could XFN relations be separated? I'm under impression that they inflate the list.		Could XFN relations be separated? I'm under impression that they inflate the list.
			:I think that they should be removed, or moved to a microformat list where they would be named eg <code>xfn.friend</code>. I also want to emphasize that I dislike XFN as it implies to complex relation, that can be hard to resolve. For example "the maintaner of that document had that relation to the maintaner of the referenced document when the document was last edited/created" is not a good example of a relation. If we assume one knows the maintainer of the current document, how is one to know who the maintainer of the referenced document is? Someone could also be confused by the name of the relation and think that the current resource if a friend of the author…

	== Re: shortlink ==		== Re: shortlink ==

	shortlink has also been proposed (on the blagosphere) as shorter and shorturl		shortlink has also been proposed (on the blagosphere) as shorter and shorturl

Rtyuioiuytyui: New section: Re: shortlink

2009-04-14T14:57:30Z

New section: Re: shortlink

← Older revision		Revision as of 14:57, 14 April 2009
Line 12:		Line 12:

	Could XFN relations be separated? I'm under impression that they inflate the list.		Could XFN relations be separated? I'm under impression that they inflate the list.

			== Re: shortlink ==

			shortlink has also been proposed (on the blagosphere) as shorter and shorturl

Rtyuioiuytyui: New section: XFN noise

2009-04-14T14:55:55Z

New section: XFN noise

← Older revision		Revision as of 14:55, 14 April 2009
Line 8:		Line 8:

	--[[User:Hixie\|Hixie]] 23:40, 10 December 2007 (UTC)		--[[User:Hixie\|Hixie]] 23:40, 10 December 2007 (UTC)

			== XFN noise ==

			Could XFN relations be separated? I'm under impression that they inflate the list.

Hixie: New page: == Memorandum of understanding == * http://wiki.whatwg.org/wiki/RelExtensions This Web page and associated Web services, if any, are provided with the understanding that providing them i...

2007-12-10T23:40:41Z

New page: == Memorandum of understanding == * http://wiki.whatwg.org/wiki/RelExtensions This Web page and associated Web services, if any, are provided with the understanding that providing them i...

New page

== Memorandum of understanding ==

* http://wiki.whatwg.org/wiki/RelExtensions

This Web page and associated Web services, if any, are provided with the understanding that providing them is cheap and relatively reliable, and that the URIs for these resources will not change after HTML5's completion, unless circumstances outside of the administrator's control force such a change.

Organisations that believe these pages to be of vital importance are encouraged to put aside funds for the defence of this page should the need arise.

--[[User:Hixie|Hixie]] 23:40, 10 December 2007 (UTC)