Re: [whatwg] Feed autodiscovery draft may be resurrected
On Mon, 5 Nov 2007, James M Snell wrote: The type attribute indicates the kind of document being referenced, link rel=service type=application/atomsvc+xml href=... / Because some clients (like windows live writer) support multiple protocols, we add a class=preferred to our service link to indicate which link the server prefers the client to use [1], link rel=service class=preferred type=application/atomsvc+xml href=... / Beyond that it's completely undefined... which, of course, is not a good thing. We need a standard or at least documented-and-commonly-used solution to this problem. [1] http://jcheng.wordpress.com/2007/10/16/how-wlw-speaks-atompub-part-1-autodiscovery/ Interesting. I recommend adding 'service' to the wiki extensions list: http://wiki.whatwg.org/wiki/RelExtensions ...with a link to a spec (it can be another page on that same wiki if you need somewhere to put it). I think 'service' is too new to really belong in the spec itself. I hope you don't mind. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML5 Edit Link Relation
On Mon, 5 Nov 2007, Martin Atkins wrote: James M Snell wrote: This is just off the top of my head so I'm certain that there are probably reasons why this wouldn't work, but could we not do something like, link rel=edit put delete patch href=http://example.org/foo; / Edit indicates the purpose of the link, put, delete and patch indicate methods (in addition to GET). That doesn't tell you what sort of stuff you are allowed to PUT to that URL, though. I'm not sure that HTML is really the place to tell you that it expects an Atom entry, but without it knowing that it supports PUT is not that useful either. However, I guess one could argue that there should be something that acts as the opposite of the type attribute: rather than the type that should result when you GET, instead indicate the type that you should PUT. Probably too tricky to be worth it, though: it'd probably need all of the capabilities of the HTTP Accept header to be useful, and it's questionable whether that much detail should be defined externally of the resource itself. It's an interesting idea, but as you say, I'm not sure we should do it immediately. It may be worth study for a future version though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about a way to disable referer headers for links
On 4 Nov 2007, at 12:40, Anne van Kesteren wrote: On Sat, 03 Nov 2007 18:27:50 +0100, Krzysztof ??elechowski [EMAIL PROTECTED] wrote: Dnia 03-11-2007, sob o godzinie 08:42 +, Ian Hickson napisa??(a): Ok, I've added a rel value similar to nofollow called noreferer that does this. While we are unable correct the spelling of referer, we certainly need not duplicate it for noreferrer. There must be some end to this self-humiliation. I think it's way better to stay consistent. Especially as the feature affects the Referer (sic) header. I too think Anne is right here — there are enough things that are inconsistent in the web already. Don't add another thing that requires me to think. I'll just make mistakes. A markup language should not require me to think — it should reflect logical structure. Importantly, outwith the structure, logic dictates contextual consistency (even if that goes against being consistent with other contexts). -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] several messages about a way to disable referer headers for links
While we are unable correct the spelling of referer, we certainly need not duplicate it for noreferrer. There must be some end to this self-humiliation. I think it's way better to stay consistent. Especially as the feature affects the Referer (sic) header. I too think Anne is right here... This may be one of those never been done, so can never happen things, but couldn't the spec as easily support both? It seems a bit silly that stuff should have to be spelled wrong to work. -- Charles
Re: [whatwg] several messages about a way to disable referer headers for links
While we are unable correct the spelling of referer, we certainly need not duplicate it for noreferrer. There must be some end to this self-humiliation. I think it's way better to stay consistent. Especially as the feature affects the Referer (sic) header. I too think Anne is right here... This may be one of those never been done, so can never happen things, but couldn't the spec as easily support both? It seems a bit silly that stuff should have to be spelled wrong to work. I'm really sorry to be diving into a trivial debate like this, but in our work on the Safari browser we've always treated the HTTP header field with the name Referer as the referrer header field and considered the misspelling part of the HTTP protocol, not to be propagated into other contexts. And as far as I can tell, standards other than HTTP have taken this tack too. For example, the document you can access from JavaScript has a referrer property, without the misspelling. I don't think that spelling the attribute noreferer is consistent. It should be noreferrer. -- Darin
