Re: New HTML attribute: "rels"

Since rel can already take multiple values, it may be clear that rels
is meant for a different purpose. But which alternative name would you
suggest for a rels-like attribute?

I agree that a special-purpose attribute would be easier to implement,
and am also interested to hear what others think about this. An
Internet-Draft is of course intended for review and discussion.

If the special-purpose route were to be taken, I would likely prefer
rel-signature to simply signature. I don't like the idea that every
link relation could map to an HTML attribute. Using rels or a rel-
attribute prefix, anybody could take any existing or new link relation
and use it in the way that I would like "signature" to be used, and
this would establish a clear precedent.

On Tue, Dec 8, 2015 at 6:20 PM, Martin Janecke <w3.org@prlbr.com> wrote:
> On 08.12.15 18:00, Sean B. Palmer wrote:
>> The HTML attribute set is added to more conservatively than the link
>> relation set.
>
> Still your proposal encompasses to add to the attribute set, not to the
> link relation set. ;)
>
>
>> You may think of a specialised signature attribute as
>> being a parallel to:
>>
>>   <link stylesheet="style.css">
>>
>> Instead of:
>>
>>   <link rel="stylesheet" href="style.css">
>>
>> The former is a design pattern which is avoided in HTML.
>
> I think I understand your analogy, but I have to disagree. The former
> design pattern is ubiquitous in HTML. There are more than a handful of
> global attributes that can be added to every HTML element, e.g.
>
> |  <h1 id="…" lang="…" dir="…" class="…" style="…" title="…">…</h1>
>
> and many elements have additional attributes defined that can be added, e.g.
>
> |  <a href="…">
> |  <img src="…" alt="…">
> |  <input type="…" value="…">
> |  <td colspan="…">
>
> Additionally, I think that the suggested
>
> |  rels="signature software.tar.gz.sig"
>
> does not really follow the design pattern of
>
> |  <link rel="stylesheet" href="style.css">
>
> . I also feel that the name rels is confusingly similar to rel. rels
> sounds like the plural of rel, so it might seem that rels should be used
> when you want to define multiple rel values. Of course that’s not the
> case. Multiple rel values are added correctly as follows
>
> |  <a rel="nofollow license">
>
> which leads me to another concern: Compare the previous example with
>
> |  <a rels="signature sigfile">
>
> Both of these examples are very similar, but they are supposed to be
> interpreted quite differently. "nofollow license" is an enumeration of
> values, while "signature sigfile" is an assignment of a value to a key.
> So, what looks like the same pattern is really different and I think
> this can lead to unnecessary errors.
>
> My last concern would be that sometimes there is whitespace in filenames
> which could cause extra problems when the filename appears in an
> attribute value where whitespace is used as a delimiter. I know about
> percent-encoding, but still I think that we should avoid such likely
> points of failure if possible.
>
>
>> One alternative which does have an existing parallel is a
>> rel-signature attribute, like the data-* attributes. Unlike the data-*
>> attributes, however, rel- would not be intended for user extension, so
>> this aspect does not have a parallel.
>
> I agree.
>
> In conclusion I think a special-purpose attribute (e.g.
> signature="sigfile") would be less complicated to implement by user
> agents and less prone to errors than the rels proposal. I also think
> that a special attribute would better fit to your proposal for a
> mechanism for cryptographic resource verification – in the sense that
> the introduction of a general purpose rels attribute transcends the
> topic of cryptographic resource verification so far that I would
> consider it to be an almost independent proposal.
>
> Of course, that’s just my opinion. I’d be interested to read what others
> think.
>
> Thanks
> Martin



-- 
Sean B. Palmer, http://inamidst.com/sbp/

Received on Tuesday, 8 December 2015 18:31:48 UTC