Re: [link-relations] NEW APP DATA

[Ian Hickson <[e-mail]>]

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
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'