Re: Report on testing of the link relations registry

On Sun, Aug 22, 2010 at 2:07 AM, Ian Hickson <ian@hixie.ch> wrote:
> On Sun, 22 Aug 2010, Maciej Stachowiak wrote:
>> On Aug 21, 2010, at 8:26 PM, Ian Hickson wrote:
>> > On Sat, 21 Aug 2010, Maciej Stachowiak wrote:
>> >>
>> >> Are there any link relations that have an effect on both <a>/<area>
>> >> and on <link>, but not the same effect?
>> >
>> > In some cases "alternate", but for all practical purposes (and for the
>> > purposes of a registry) no, not as far as I know. I would recommend
>> > avoiding doing that, too, so we could indeed split it into orthogonal
>> > concerns: where the relation is conforming, what kind of relation it
>> > is, its synonyms, and the obvious stuff like name, description, and
>> > spec(s).

I also recommend avoiding having link relations have *different*
effects on <a>/<area> and <link>.


>> In that case, I'm not clear on why separate "effect on <a>/<area>" and
>> "effect on <link>" fields are required.

Agreed.


> In the current RelExtensions page, the "not allowed" state is treated as
> an effect. I don't mind how the information is structured, though, so long
> as it is all there.

In that case, I would prefer to have two columns:

"effect"

and

"allowed on"


This has a few advantages over the current "Effect on link" and
"Effect on a, area" split:

1. It encourages the same effect on all elements that the link
relation is allowed on.

2. The "allowed on" column can be simpler and perhaps automatically
used to extract validation/linting hints.

3. The "allowed on" column better allows for expressing other elements
(or vocabularies?) that may use rel.


Ian - do you have any objections to using "effect" and "allowed on"
rather than  "Effect on link" and "Effect on a, area"?

If not, I'll go ahead and add these columns to the microformats
existing-rel-values page accordingly.

Thanks,

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

Received on Wednesday, 1 September 2010 11:56:24 UTC