[link-relations] rel="longdesc"

Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> Thu, 12 August 2010 04:43 UTC

Return-Path: <xn--mlform-iua@xn--mlform-iua.no>
X-Original-To: link-relations@core3.amsl.com
Delivered-To: link-relations@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B24D73A68E0 for <link-relations@core3.amsl.com>; Wed, 11 Aug 2010 21:43:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.463
X-Spam-Level:
X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_20=-0.74]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9o-Gg-tWhea for <link-relations@core3.amsl.com>; Wed, 11 Aug 2010 21:43:28 -0700 (PDT)
Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.248.54]) by core3.amsl.com (Postfix) with ESMTP id B0C0E3A6767 for <link-relations@ietf.org>; Wed, 11 Aug 2010 21:43:28 -0700 (PDT)
Received: from cm-84.208.110.159.getinternet.no ([84.208.110.159] helo=[10.0.1.3]) by smtp.domeneshop.no with esmtpa (Exim 4.71) (envelope-from <xn--mlform-iua@xn--mlform-iua.no>) id 1OjPe7-0002H0-Pd for link-relations@ietf.org; Thu, 12 Aug 2010 06:44:03 +0200
Date: Thu, 12 Aug 2010 06:44:03 +0200
From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
To: link-relations@ietf.org
Message-ID: <20100812064403354963.8375d0b7@xn--mlform-iua.no>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Organization: =?iso-8859-1?Q?M=E5lform.no?=
X-Mailer: GyazMail version 1.5.9
Subject: [link-relations] rel="longdesc"
X-BeenThere: link-relations@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <link-relations.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/link-relations>, <mailto:link-relations-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/link-relations>
List-Post: <mailto:link-relations@ietf.org>
List-Help: <mailto:link-relations-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/link-relations>, <mailto:link-relations-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Aug 2010 04:43:29 -0000

Hi! I consider registering "longdesc" as a link relation. What is the 
best way forward for something like that?

Longdesc is the name of a link attribute of <img>, <frame> and <iframe> 
in HTML4. Yesterdady, the HTML5 working group issued a decision which 
precludes longdesc from being valid in HTML5 documents. That decision 
may change, of course.  However, an idea to replace it with <a 
rel="longdesc" href=* ><img alt=* src=* /></a> was presented to the 
HTMLwg at an earlier stage. And I would like to continue with that 
idea. Such a solution could also possibly broaden/generalize the 
concept so that other elements than <img> (e.g. <object>) could be 
staffed with longdesc links.

HTML4 describes longdesc as follows {my notes are within curly 
parenthesis, the rest is quotes}:

* link to long description (complements alt) {IMG}
* link to long description (complements title) {iframe/frame}
* This attribute specifies a link to a long description of the image. 
This description should supplement the short description provided using 
the alt attribute. When the image has an associated image map, this 
attribute should provide information about the image map's contents. 
This is particularly important for server-side image maps. Since an IMG 
element may be within the content of an A element, the user agent's 
mechanism in the user interface for accessing the "longdesc" resource 
of the former must be different than the mechanism for accessing the 
href resource of the latter. {img}
* This attribute specifies a link to a long description of the frame. 
This description should supplement the short description provided using 
the title attribute, and may be particularly useful for non-visual user 
agents. {iframe/frame}
* {the content of a longdesc is URI.}

A prelimnary registration form:

   o  Application Name: ???
   o  Description: a link from an object with a short (that is: basic) 
description to a resource containing a longer (that is: supplementary) 
description of the same object
   o  Default Value: ???
   o  Notes: This link relation is connected to accessibility use 
cases. The user should be able to expect that the long description 
resource is accessible. The purpose is to implement the semantics of 
the longdesc link attribute of HTML4 as a "normal" link with a longdesc 
relationship. The longdesc link is expected to be programmatically 
associated with short description, so that the user - if wanted - can 
jump directly from the short description at hand, to the long 
description.

I expect that it will take some time before I can eventually complete 
this project - so there is no need to rush an answer, I think. However, 
I would like to get some input on how it could be solved and if there 
are some principle issues which needs to be solved.
-- 
leif halvard silli