add option to advertise endpoint in <a> tag instead of <link>

[snarfed]

inspired by wordpress.com. background discussion: http://indiewebcamp.com/irc/2014-05-04/line/1399225703

thanks in advance, @sandeepshetty! cc @kylewm, @aaronpk, @barnabywalters

[pfefferle]

nice idea!

doesn't wordpress allow to add links at all? the html5 spec allows adding <link />s to the body if you add an item prop attribute btw.

[snarfed]

sadly no, wordpress.com doesn't allow <link>s at all: http://en.support.wordpress.com/code/#html-tags

[pfefferle]

never mind... adding a <a /> fallback isn't that bad.

[sandeepshetty]

Haven't touched WP in ages, but shouldn't adding the <link> tag be done in the theme or a plugin? What's the use case for doing this in posts, pages, and/or widgets where the restriction exists?

In general I'm ok with the idea of doing this with <a> tags, but have apprehensions in terms of complexity for parsers/clients?

Also, I don't like the idea of mentioning Wordpress limitations in the spec and if this is really required might prefer wording it differently.

[snarfed]

hey sandeep! thanks for the reply. this is wordpress.com, not self-hosted wordpress. wordpress.com doesn't allow custom themes or plugins.

examples are useful in specs, so i mentioned it as an example of the motivation. if you'd rather drop the wordpress.com mention, i'm ok with that.

...and discussion in irc seemed to agree that this wasn't too much of an additional imposition on parsers/clients. here's an example of a small modification to an existing client to support it: Ryuno-Ki/webmention-tools@f29879a

[sandeepshetty]

Ah, I missed the .com :)

We could make the change generic for silo's (no support for http headers or link tag).

This now also brings up the question of precedence. For example, if Wordpress.com decided to support webmention by publishing a link header and link tag, which might be different from the a tag published by the user, which one would take precedence? (the problem also exists between link header and link tag)

[sandeepshetty]

FYI, Pingback gives precedence to the (X-Pingback) header over the <link> element.

Maybe, Header > Link element > A element?

With the cited wordpress.com example, this might not be ideal as it will override the users preference and use the wordpress.com endpoint.

[sandeepshetty]

Hyperlinks created with the link element and its rel attribute apply to the whole page. This contrasts with the rel attribute of a and area elements, which indicates the type of a link whose context is given by the link's location within the document.

— http://www.w3.org/TR/html5/document-metadata.html#the-link-element

It looks like the spec might not allow this depending on how it's interpreted. For example how do you interpret an a element with the rel webmention in the footer/sidebar of the page that has a post.

@snarfed, @tantek, @aaronpk, @barnabywalters: What do you think? (See also previous 2 comments about precedence)

[snarfed]

all good points. thanks for bringing them up! I don't know that any of them rules this out entirely, but they're definitely worth thinking through.

Header > link > a makes sense to me. yes, in your example, WordPress.com would override individual users, but it's just a hypothetical, and I'm ok with a different ordering if we want.

I'm also personally ok with the slight skew from the letter of the law in the html spec.

my only real goal is to find a way for WordPress.com users to allow incoming webmentions. if we come up with a different idea that we prefer, I'd probably be fine with that too!

[tantek]

Agreed with headers > link > a.

Also agreed with not mentioning WordPress limitations by name in the spec - that kind of information quickly gets dated (and is a pain to maintain).

Re: the HTML5 spec re: - it's true that in the past (e.g. in microformats) we tried to scope to specific elements, but in practice that has not worked out (with the exception of rel=tag for a few years). We've dropped use of rel inside microformats and now only to apply to page level relationships (hence why the microformats2 parser spec puts them all into one document wide collection).

That part of the HTML5 spec is trying to say:

- always applies to the whole document - may apply to some context in the document, or the whole document.

Modern usage is now to only use <* rel> for the whole document. I should probably file a bug on the HTML spec (am in the W3C HTML WG).

[sandeepshetty]

Finally, I think the requirement to parse the a element for rel's by clients should be a MUST to ensure it is equivalent to the other methods.

So final mods are:

• Support for a element with rel="webmention" where there is no support for http headers or link element.
• Precedence is link header > link element > a element
• Clients MUST fallback to all of them when looking for rel="webmention"

I'll try to make these changes later today. Feel free to edit this PR if you get to it before me.

[snarfed]

done! i'm happy to defer to you all on specific language here. feel free to request changes or merge and make them afterward, either works for me.

[sandeepshetty]

Thanks @snarfed.