Re: [link-relations] NEW APP DATA

Ian Hickson <> Mon, 09 August 2010 17:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12BD528C11D for <>; Mon, 9 Aug 2010 10:50:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.468
X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 96YAciaLr4Ea for <>; Mon, 9 Aug 2010 10:50:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B774A3A6867 for <>; Mon, 9 Aug 2010 10:50:16 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id DADB368C06B; Mon, 9 Aug 2010 10:50:50 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=date:from:to:cc :subject:in-reply-to:message-id:references:mime-version: content-type; q=dns;; b=3YQeGH9xZaxGYMckWOipOrmmyjJIu mJ04r0RwOyG7hu5mGsCLBkhlvdNdgW8TGMn0D9fL4bjnBi3BGRNz7ir0FHQfqtvr enqXD6//BTtt9bCpbXu1aTubUpVX6wCpgy/gCeHFSY70/fStKiS07g47nlk3bjmb KeTLItaQoYHog4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version: content-type;; bh=sNGDsxyLmawm2fBDiI9Am53B7qU=; b=QMp auF1r+zotLgPWzJeLrBIP9JPDE7aUafavtI128nFcEOc3Kmhye8wa2SZcPG9p5gK P3GdZYZf2gsmjpSRvSPQ/u1Fdb+krahc86dQMOJCZQ0xKZqNCkFruxNm+yATrwFO hkiE1TDwpmjDOfK4KlarPmFmJVatd2YCgFHvAT9M=
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id CC9A868C065; Mon, 9 Aug 2010 10:50:50 -0700 (PDT)
Date: Mon, 09 Aug 2010 17:50:50 +0000
From: Ian Hickson <>
To: Julian Reschke <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <>
Content-Language: en-GB-hixie
Content-Style-Type: text/css
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Subject: Re: [link-relations] NEW APP DATA
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Aug 2010 17:50:18 -0000

On Mon, 9 Aug 2010, Julian Reschke wrote:
> > 
> > The purpose of those flags is to define conformance for HTML.
> Yes. I'm not convinced that it's a good idea to move this into the IANA 
> registry

Nor am I, but that is what the registry was designed to do.

> nor am I convinced that the individual flags and their defaults make 
> sense.

Ok... Do I have to convince you for the fields to be registered?

> > Relations can be updated to define how they work with HTML by using 
> > the process described in the Web Linking spec.
> Do you think it's necessary to do so? Be default, I'd expect any link 
> relation that we have to be usable with <link> by default. It would be 
> very useful to understand why this wouldn't be the case.

It's certainly not the case that any link relation is relevant anywhere. 
Suppose someone designed a link relation whose purpose was to identify a 
resource that should be notified any time an API call was made on an 
HTMLDocument object. That presumably wouldn't make any sense in an Atom 
feed. Similarly, consider "edit" or "edit-media". While they may be 
well-defined in the context of Atom, they certainly are not defined to a 
level that is clear enough for it to make sense to use them in an HTML 
document, so we wouldn't want to have an author accidentally use them 
(especially if they were just using them because they thought they could 
make up new relations and just accidentally clashed with the Atom ones).

> > An example of a relation that we would not want to allow is 
> > rel=stylesheet on<area>, which we would want to disallow because it 
> > has no effect and is therefore likely an authoring mistake. Similarly, 
> > we wouldn't want
> (Side note: when did <area> acquire @rel???)

As part of the WHATWG's rationalisation of HTML features a few years ago 
we made all elements that could create hyperlinks be consistently defined 
(as much as we can given legacy, anyway).

> Are you confident that <a> and <area> always have the same requirements?

They currently do. If that changes, we'll update the registries. Who knows 
what the future holds.

> > rel=noreferrer to be allowed on <link> because it's not a link 
> > relation, it's a link annotation, and <link> doesn't create hyperlinks 
> > without a relation that creates one. Each keyword would have to be 
> > taken on a case- by-case basis.
> I can see that noreferrer being the only link relation on a <link> is 
> meaningless, but that doesn't mean it needs to be disallowed; there 
> could be other rel values present, after all.

If something is meaningless, the author benefits from being informed of 
this, since it is unlikely to be his intent. That's what conformance 
checkers, and thus conformance definitions, are for.

> > Regarding the final parenthetical, I believe the templates fit what is 
> > described in the Web Linking spec.
> It does, this is an oversight in the spec. So we'd have to figure out 
> unique names upon registration.

I'm just trying to do what the spec says here.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'