This seems to add complication for no real benefit.

The Task Force resolved to close the bug wontfix on 2013-05-16

(In reply to comment #1)
> This seems to add complication for no real benefit.
> 
> The Task Force resolved to close the bug wontfix on 2013-05-16

I am constantly told that ‘the task force decided’ so and so. That information feels like some kind of pressure. I would like to hear technical or otherwise sound arguments that I can accept or not.

The benefit of resolving this bug should be obvious. Namely: it brings the language of this HTML5 extension in line with the language of the HTML5 specification.

My understanding is that the ultimate goal is to, at some point, make this spec part of the HTML5 (or HTML 5.1 or HTML6) specification. To ease that transition, it would be an advantage to use the same language as HTML5 uses.

Otherwise, it is unclear to me, whether you, at that point, would like redefine HTML5/HTML51/HTML6’s definition of hyperlink.

(In reply to comment #2)
> (In reply to comment #1)
> > This seems to add complication for no real benefit.
> > 
> > The Task Force resolved to close the bug wontfix on 2013-05-16
> 
> I am constantly told that ‘the task force decided’ so and so. That
> information feels like some kind of pressure.

There is no intent to use this as pressure. The HTML Accessibility Task Force produces this specification on behalf of the HTML and PF working groups, and so that is where decisions are made on issues and bugs.

> I would like to hear technical or otherwise sound arguments
> that I can accept or not.

The minutes of all meetings are public. The discussion in this case was in the email thread starting at  The argument was that this change is an unnecesasry complication - longdesc is an actual link, that goes to a URL. The cite attribute was not defined that way in HTML4 (probably a mistake at the time).

> The benefit of resolving this bug should be obvious. Namely: it brings the
> language of this HTML5 extension in line with the language of the HTML5
> specification.

The bug did not show why the language was not already in line with the specification, and in particular with the 

> My understanding is that the ultimate goal is to, at some point, make this
> spec part of the HTML5 (or HTML 5.1 or HTML6) specification. To ease that
> transition, it would be an advantage to use the same language as HTML5 uses.

It is undecided whether this spec will proceed to Recommendation alone, or as part of an HTML specification. That is stated explicitly in the section "Status of this document".

The specification refers to the HTML specification to define what a hyperlink is, and what a URL is. The algorithm for "following a link" as specified in HTML can be followed with the information in this specification.

If the specification is integrated into the HTML specification, then yes, part of the work of integration may well involve extending the definitions provided to include a "longdesc" type of link, and noting that a longdesc attribute can also create a link. But until such a decision is made, that is a hypothetical problem that is part of the editorial work of integrating two specifications.
 
> Otherwise, it is unclear to me, whether you, at that point, would like
> redefine HTML5/HTML51/HTML6’s definition of hyperlink.

It doesn't seem necessary to do so.

Obviously, the hyperlink defined here is not a "link defined by an a or area element". However, the definitions of hyperlinks and following hyperlinks are sufficient for the purposes of the specification.

Executive summary: 

By ‘algorithm for "following a link"’, I am going to assume that you referred to section 4.12.3 about ‘Following hyperlinks’: http://www.w3.org/TR/html5/links.html#following-hyperlinks  Since you clearly expect UAs to use that algorithm, would it not be a good idea to delete the current reference to 'hyperlink', and instead insert an explicit link to that algorithm? (Though, since that algorithm assumes @href, you must also add a ‘caveat note’ about replacing @href with @longdesc before running the algorithm.)

(In reply to comment #3)
> (In reply to comment #2)

Thanks for the info on the TF/PF’s involvement. 

> The discussion in this case was in
> the email thread starting at  

Something disappeared after the ’at’ word.

> The argument was that this change is an
> unnecesasry complication - longdesc is an actual link, that goes to a URL.
> The cite attribute was not defined that way in HTML4 (probably a mistake at
> the time).

First, I of course support (what I assume is) the motivation behind the current wording: To stress that longdesc is a link - and not a 'long variant' of @alt. But by reading HTML5, the most prosaic definition of ‘hyperlink’ that one could come up with, would be to say that it is an element with a href attribute. This is evident from HTML5’s algorithm for following hyperlinks: http://www.w3.org/TR/html5/links.html#following-hyperlinks

However, because 'hyperlenk' probably is understood much more generally by 'laymen', there  are important conceptual reasons to avoid 'hyperlink' about the longdesc URL - and these conceptual reasons that were present already in HTML4.

Namely: Hyperlinks are interactive content. And HTML5 have special rules for where interactive content can occur - including that interactive content cannot be nested inside other interactive content. By contrast, @longdesc can occur even inside hyperlinks. And a longdesc doesn't turn an image into an interactive element - per the way HTML5 sees it. HTML4 even went so far as to say that longdesc links should be opened in a manner *different* from the way hyperlinks are opened, precisely because it should be possible to follow them even when they were nested inside hyperlinks.

Therefore, I believe that in order to avoid that someone mixes the two concepts (and thus e.g. starts believing that one cannot add a longdesc to an <img> element if the <img> element is child of a <a> element), the term 'hyperlink' a a definition of what the longdesc URL is, should be avoided even if the Image Description Spec never becomes included in the HTML5 spec.

More so, when HTML5 is clear about the fact that the URL of a hyperlink always is to be found in a @href attribute, one really cannot point to HTML5’s definition of hyperlinks for definition of what the longdesc URL is.

When it comes to @cite: @cite does not - whether in HTML4 or in HTML5 - turn the blockquote element or q element into 'interactive content' (in the HTML5 spec’s understanding of the word - http://www.w3.org/TR/html5/dom.html#interactive-content-0). And neither does the longdesc spec suggest that <img> becomes interactive content when @longdesc is present.  And while HTML4 was silent on accessing @cite, then HTML5 says that UAs may allow readers to access the URI it contains. And HTML5 also does not prohibit that <q cite> or <blockquote cite> or <ins cite> or <del cite> are children of interactive content.

And thus, longdesc and cite obviously has many similirities. In iCab, the @cite and the @longdesc are even accessed the same way!

>  The argument was that this change is an
> unnecesasry complication - longdesc is an actual link, that goes to a URL.
> The cite attribute was not defined that way in HTML4 (probably a mistake at
> the time).

I’ve made the point that it is (hyper) link myself, so it is not impossible to understand the argument.

> > The benefit of resolving this bug should be obvious. Namely: it brings the
> > language of this HTML5 extension in line with the language of the HTML5
> > specification.
> 
> The bug did not show why the language was not already in line with the
> specification, and in particular with the 

[Something fell out of your reply after the ‘the’ word.]

I tried to show why it is not in line with HTML5 - citing myself: "HTML 5.1 section 4.12 Links defines 'link' as a concept related to <a>/<area>". Yes, I pointed to HTML 5.1 there. But HTML 5.0 says the same: http://www.w3.org/TR/html5/links.html#introduction-3

Also, relevant is that HTML5 *does* define @cite, including that it defines that UAs may allow users to "allow users to follow such citation links". But despite saying that UAs should ”allow users to follow such citation links”, HTML5 does not define  <blockquote> or <q>  - or the very @cite attribute - as hyperlinks.

{I get the feeling that I repeat myself, but I hope that I just hear an echo of some old thoughts …}

> > My understanding is that the ultimate goal is to, at some point, make this
> > spec part of the HTML5 (or HTML 5.1 or HTML6) specification. To ease that
> > transition, it would be an advantage to use the same language as HTML5 uses.
> 
> It is undecided whether this spec will proceed to Recommendation alone, or
> as part of an HTML specification. That is stated explicitly in the section
> "Status of this document".

Sure. But I am in favor of increasing the chances of inclusion by keeping this extension as much as possible as a spec that can be 'dropped in', without affecting the rest of HTML5.

> The specification refers to the HTML specification to define what a
> hyperlink is, and what a URL is. The algorithm for "following a link" as
> specified in HTML can be followed with the information in this specification.

SHORT REPLY: By ‘algorithm for "following a link"’, I am going to assume that you referred to section 4.12.3 about ‘Following hyperlinks’: http://www.w3.org/TR/html5/links.html#following-hyperlinks  Would it not be a good idea to explicitly point to that algorithm if you expect UAs to use it?

LONGER REPLY: Well, the hyperlinks algorithm starts: ‘the user agent must resolve the URL given by the href attribute’. As there is no @href in the img element. So the algorithm does not apply … ! Another issue is (not for me, but perhaps for you) that the ‘Following a hyperlink’ algorithm is not *silent* with regard to what should happen if resolving the URL fails.

For hyperlinks, then, if resolving was successful, the UA must 'navigate a browsing context to the resulting absolute URL'. But if unsuccessful, “the user agent may report the error to the user in a user-agent-specific manner, may navigate to an error page to report the error, or may ignore the error and do nothing.” 

Note in particular that there is *no room* (or at least, it is very, very small) for repair of the URL (in case the author filled the @href with text instead of a URL). By contrast, you have insisted on being silent on what should happen if resolving the URL fails. There is no such silence with regard to hyperlinks.

For instance, the resolving (http://www.w3.org/TR/html5/infrastructure.html#resolve-a-url) also includes the sub-step parsing (http://www.w3.org/TR/html5/infrastructure.html#parse-a-url) which includes several willful violations of RFC 3986, including that space characters are added to the unreserved production (unreserved production: http://tools.ietf.org/html/rfc3986#section-2.3 ), which means that the following longdesc attribute would *resolve* just fine: 

   longdesc="This is an image of my mum and dad"

PROPOSAL: First and foremost I stand by that you should not refer to @longdesc as a ‘hyperlink’. (See comment #0 for possible alternative wordings - but the name is not important to me, as long as you avoid 'hyperlink'.) 

But secondly, you could say something like this, somewhere in the spec:

   ]] To obtain/access/open[*] an image description, user agents should use the algorithm for following hyperlink except that they should replace the @href attribute with the @longdesc attribute.[[ 

[*] HTMl5 says 'obtain' about @cite. Me, I like the word 'open'.

Of course, if you would like to explicitly be silent about what to do in case of errors … then you would have to edit the algorithm even more than simply replace @href with @longdesc.

> If the specification is integrated into the HTML specification, then yes,
> part of the work of integration may well involve extending the definitions
> provided to include a "longdesc" type of link, and noting that a longdesc
> attribute can also create a link. But until such a decision is made, that is
> a hypothetical problem that is part of the editorial work of integrating two
> specifications.

Please note that the most important integration preparation was not the wording 'description link'. (Hey, why not call it a 'image description link'…) The most important integration preporatory step would be to *avoid* the word 'hyperlink' as a definiton of what the longdesc attribute is.

> > Otherwise, it is unclear to me, whether you, at that point, would like
> > redefine HTML5/HTML51/HTML6’s definition of hyperlink.
> 
> It doesn't seem necessary to do so.
> 
> Obviously, the hyperlink defined here is not a "link defined by an a or area
> element". However, the definitions of hyperlinks and following hyperlinks
> are sufficient for the purposes of the specification.

As I said above, I think that an explicit link to HTML5, section 4.12.3 (‘Following hyperlinks’), with some additional words about how that algorithm must be amended before being applied to longdesc, would be a good idea.

The only thing I wanna add w.r.t. <a> and <area> vs @longdesc, is that HTML5 says about <a>/<area> (and less clearly about <link>) each ‘represents’ a hyperlink. Thus, it is their **main function** to be links. By contrast, both @cite and @longdesc are just enriching features of their respective elements. E.g. <blockquote> ‘represents a section that is quoted from another source’. And the img element represents an image.  (Btw, in it is also an important, subtle detail that an a/area elemnet *is* not a link, they just *represent* a hyperlink.)

I don't see the issue with the current spec, 

the spec [1] says:

"The longdesc attribute must contain a valid non-empty URL potentially surrounded by spaces. The URL is a hyperlink to a description of the image"

the linked definition of hyperlink says

"These are links to other resources that are generally exposed to the user by the user agent so that the user can cause the user agent to navigate to those resources, e.g. to visit them in a browser or download them."

which is what I would expect and hope user agents do with the URL contained in the longdesc attribute.

[1] https://dvcs.w3.org/hg/html-proposals/raw-file/tip/longdesc1/longdesc.html#longdesc

(In reply to comment #5)

> which is what I would expect and hope user agents do with the URL contained
> in the longdesc attribute.

To say that user agents should treat longdesc "*like* a hyperlink", and define how far that alikening goes, should be OK. In fact, something like that was what I suggested in comment #4. 

However, the word 'hyperlink' has *surprisingly* many connotations with regard to user experience. E.g. we don’t expect anchor element links to be treated in 'special ways' when it comes to what happens when users activate them. By contrast, users have much less control on how to open longdesc URLs (in part because because it is supposed to be avaible also when img is child of an <a>) and on what happens when one does open them (one cannot control whether it opens in same tab/window or in another tab/window) - all this seem to be much more rigid for longdesc compared to hyperlinks.

Perhaps the current text could be changed to this:

]]
The URL MUST point to a description of the image that its parent img element represents. User agents are expected to allow longdesc URLs to be followed in a fashion similar to how they <a href="HTML5spec/links.html#following-hyperlinks">follow hyperlinks</a>, but with the restriction that the interface to follow the link MUST be acccessible also in case the IMG is child of an anchor element.

<p class="note">
The longdesc attribute does not turn the img into interactive content, per HTML5’s definition, and an img with the longdesc attribute set is thus permitted to be the child of an <a> element.</p>

<p class="note">It is common, but not required, that the user interface to follow the longdesc URL is one that works whether the img is or isn’t a child of a hyperlnk.</p>

<p class="note">It is quite common, but not required, that the longdesc URL opens in a browsing context (typically tab or window) that is parallel to the current browsing context.</p>
[[

(In fact, it surprises me to discover that section 3.0.3 on User Agents currently says nothing about access to longdesc when img is child of an anchor element ....)

(In reply to comment #6)
> (In reply to comment #5)
> 
> > which is what I would expect and hope user agents do with the URL contained
> > in the longdesc attribute.
> 
> To say that user agents should treat longdesc "*like* a hyperlink", and
> define how far that alikening goes, should be OK. In fact, something like
> that was what I suggested in comment #4. 
> 
> However, the word 'hyperlink' has *surprisingly* many connotations with
> regard to user experience. E.g. we don’t expect anchor element links to be
> treated in 'special ways' when it comes to what happens when users activate
> them. By contrast, users have much less control on how to open longdesc URLs
> (in part because because it is supposed to be avaible also when img is child
> of an <a>) and on what happens when one does open them (one cannot control
> whether it opens in same tab/window or in another tab/window) - all this
> seem to be much more rigid for longdesc compared to hyperlinks.

Actually, some links are hard to control in most implementations, such as when they are typed as download. Thia is an implementation question that I think the spec properly does not seek to constrain.

> Perhaps the current text could be changed to this:
> 
> ]]
> The URL MUST point to a description of the image that its parent img element
> represents. User agents are expected to allow longdesc URLs to be followed
> in a fashion similar to how they <a
> href="HTML5spec/links.html#following-hyperlinks">follow hyperlinks</a>, but
> with the restriction that the interface to follow the link MUST be
> acccessible also in case the IMG is child of an anchor element.
> 
> <p class="note">
> The longdesc attribute does not turn the img into interactive content, per
> HTML5’s definition, and an img with the longdesc attribute set is thus
> permitted to be the child of an <a> element.</p>
> 
> <p class="note">It is common, but not required, that the user interface to
> follow the longdesc URL is one that works whether the img is or isn’t a
> child of a hyperlnk.</p>

That would conflict with the above statement and the requirement to be able to use the thing when the img is a child of a link.

> <p class="note">It is quite common, but not required, that the longdesc URL
> opens in a browsing context (typically tab or window) that is parallel to
> the current browsing context.</p>

I don't see why this should be there. It doesn't add anything...

> [[
> 
> (In fact, it surprises me to discover that section 3.0.3 on User Agents
> currently says nothing about access to longdesc when img is child of an
> anchor element ....)

Nor when it is a child or not of any other element. It requires that the user can get the description, and that accessibility APIs can.

(In reply to comment #7)

>That would conflict with the above statement and the requirement to be able to
>use the thing when the img is a child of a link.

FWIW: I meant to say that it is common that it is a *single* metod that works under all circumstances. (As opposed to one method when it isn’t the child of a hyperlink, and a second method when it is a child of a hyperlink.)

>Nor when it is a child or not of any other element. It requires that the user
>can get the description, and that accessibility APIs can.

OK. I accept your argument.

However, HTML5 prohibits nesting of hyperlinks. Thus, your argument actually only serves to prove that, per HTML5, @longdesc is not a hyperlink. HTML5’s definition of hyperlinks can therefore not be used as definition of what the longdesc URL is.

To really focus on the *bug* - and leave the solution completely up to you, I hereby withdraw all proposals w.r.t. *how* you shold fix this bug.

I propose to fix this by explicitly noting that we are "wilfully violating" the core HTML spec on this point, thereby overriding it. "Plan-2014" explicitly acknowledges that extensions specs may do this.

(This change will appear in a new Editor's draft soon for review)

(In reply to comment #9)
> I propose to fix this by explicitly noting that we are "wilfully violating"
> the core HTML spec on this point, thereby overriding it. "Plan-2014"
> explicitly acknowledges that extensions specs may do this.
>
>(This change will appear in a new Editor's draft soon for review)

If done the right way, then I think that’s something that can be both elegant and work well.

Supposedly, you would  then define longdesc as a hyperlink - without referring to HTML5’s definition. And in the note/sentence where you refer to the wilfull violation, *there* you will point to HTML5’s defintion.

Added notes in the abstract and definition of longdesc clarifying that we are indeed extending the semantics of a hyperlink.