W3C home > Mailing lists > Public > public-html@w3.org > August 2010

Re: link relation metadata considerations, also ACTION-186

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 26 Aug 2010 13:47:46 +0200
Message-ID: <4C765462.8010303@gmx.de>
To: "public-html@w3.org" <public-html@w3.org>
Hi there,

more data relating to ACTION-186, due today...

- Bugzilla entry on bookmark not being allowed on <link>: 
<http://www.w3.org/Bugs/Public/show_bug.cgi?id=10412>; rejected by the 
author

- Separate mailing thread where the proposal to refactor the application 
metadata was repeated: 
<http://lists.w3.org/Archives/Public/public-html/2010Aug/0232.html>; no 
Bugzilla issue was raised yet because I was hoping for the discussion on 
the mailing list to get somewhere.

Best regards, Julian

On 21.08.2010 19:36, Julian Reschke wrote:
> Unfortunately, I haven't seen any feedback on this.
>
> ...adding some more thoughts before adding issues to BugZilla. See below:
>
>> OK, here we go.
>>
>> Let's have a look at <http://dev.w3.org/html5/spec/links.html#linkTypes>.
>>
>> Observations:
>>
>> a) There are link types not allowed on <link>.
>>
>> b) There are link types not allowed on <a>/<area>.
>>
>> c) *When* a link type is allowed on both, the "effect" is the same for
>> both.
>>
>>
>> Questions I'd like this Working Group to consider:
>>
>> 1) What's the use case for link relations not allowed on <link>?
>>
>> Right now, there are four:
>>
>> bookmark: the only reason this *currently* doesn't make sense page-wide
>> is because the definition was changed from what HTML4 said.
>>
>> external, nofollow, noreferrer: no idea why they would be disallowed.
>
> I'll add individual bugs "bookmark" and "external". I already did so for
> "nofollow" and "noreferrer" four weeks ago
> (<http://www.w3.org/Bugs/Public/show_bug.cgi?id=10172>, rejected by the
> editor, thus will be added to the issue tracker soonish).
>
>> 2) If there are currently no cases where the "effect" on a link would
>> depend on whether it's <link> or <a>/<area>... maybe this distinction is
>> meaningless, and a better categorization would be:
>>
>> i) what the effect is on links in general (no matter where they appear),
>> and
>>
>> ii) where they are allowed (in that if they are not a conformance
>> checker would complain).
>
> For i) I can think of two approaches:
>
> a) define "link relation classes" as proposed in HTML5 ("hyperlink",
> "external resource", "annotation"), and add this as one application data
> field to the link registry.
>
> It's pretty clear how this could be used in general: a "hyperlink" (or
> "link?") is just a link with no additional properties relevant for
> general processing. An "external resource" is something a link-following
> processor would want to follow when archiving a resource, or saving it
> for offline use.
>
> An "annotation" isn't a *real* link relation, as the information only
> augments the link it's on. Validators could use this information to flag
> links that *only* have an annotation (this applies to HTML <link>
> element, the <atom:link) element, and the Link: HTTP header field, for
> instance).
>
> I think this looks good if we're sure that there aren't any classes we
> need to add in the future.
>
> b) Thus, maybe flags would make more sense: "required" (-> "external
> resource") and "annotation" (a link needs a non-annotation relation to
> be complete).
>
> With this approach we'd need two flags, but they'd be binary.
>
> For ii) (the conformance-on-certain-elements question) I'm still not
> convinced that this information needs to go into the generic registry;
> and I'm also not convinced that not having the data in the generic link
> registry would mean it's not useful for HTML; it just would be *less*
> useful. *If* we add this information it really should be orthogonal to
> the link relation *classification*; otherwise the information would be
> *only* be useful for HTML, and I hope we can agree that this would be
> sub-optimal.
>
>> ...
>
> Best regards, Julian
>
>
Received on Thursday, 26 August 2010 11:48:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 August 2010 11:48:29 GMT