[Bug 21894] Do not define @longdesc as a hyperlink. Instead, define it as a link analogous to @cite.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21894

--- Comment #4 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> ---
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.)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Saturday, 18 May 2013 02:45:47 UTC