Re: New HTML attribute: "rels"

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

Received on Tuesday, 8 December 2015 18:21:23 UTC