This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In the discussion regarding invalid content of @longdesc, we sometimes seem to assume that user agents somehow hide the longdesc link if the longdesc content is invalid. For example, if the longdesc URL is the empty string. However, this does not seem to match reality. For instance, in iCab, the mouse pointer will change to indicate presence of longdesc even when the @longdesc URL is the empty string. And, if one tries to open such an invalid longdesc URL (using the contextual menu), then - as the URL is the empty string, the only result is that the current page is opened in a new window (or in a new tab). Such an experience can be quite confusing - e.g. for someone that doesn't know what @longdesc is good for. PROPOSAL: When the longdesc is the empty string, then let the spec encourage user agents to inform the user that the longdesc is invalid. This could be done for instance by announcing "invalid longdesc link". Or it could be done by presenting some kind of dummy text: "Sorry. This URL was invalid." Anything that can help the user understand that this did not work as intended. This could be done e.g. by defining a default data URI. This data URI - or some equivalent that the vendor picks - will then, when the user atempts to follow the empty longdesc URL, be rendered in place of today’s behavior. ANALOGY/PRESEDENCE: If the @src URL of an img element is empty, then (at least some) user agents render a special icon (usually containing a question markj) that informs the user that the image is lacking. 1. CONTRA ANALOGY/PRESEDENCE: a) If one control-clicks on an image, the user agents usually offers to open the link in a new window/tab. This is very similar to how longdesc URLs often open in a new window/tab. But, if the @src URL is the empty string, then all that happens is that the current page opens in a new window/tab. And so: Why not handle an emtpy @longdesc URL the same way as such an empty @src URL? b) to render dummy content when @longdesc is empty, would not reflect the tru URL that the empty string reflects. It would instead be like some kind of filter that is applied when opening longdesc URLs wher the longdesc value is the empty string. 2. PRO ANALOGY/PRESEDENCE: To this is could be replied that a) why not implement the same behavior for empty @src URL as well? b) for empty @src, users know in advance that image is lacking. It is harder to to know that @longdesc is empty. c) what's wrong with applying a filter? c) we should create the best user experience d) in the case of images, then the user knows what he expectes to see - the image, and no being able to see it should not confuse the user if the user already didn't see it since the URL was empty. Besides, an empty @src URL is an edge case. Sure, an empty @longdesc is also an edge case, in a way. But unlike @src, it suffers from the problem that users, including authors, often don't know what to expect. As a final argument, if the empsty string caused such a default data URI with some explainative stuff to be opened, then it would become very simple for authors to test how longdesc works.
Another argument in favor of this solution is that it seems like an incremental improvement. No one looses any content due to this change.
UPDATED PROPOSAL, based on implementation research: (1) Rather than presenting any message, empty longdesc URLs should simply be ignored by implementations. That is: Empty longdesc URLs should simply not be presented to the user at all. (2) Implementations which already do ignore empty longdesc URLs: * Opera’s native built-in longdesc feature. * Longdesk [with -k] 0.2 Firefox addon by Anthony [1] * Longdesc [with -c] 0.8 Firefox addon by Patrick H. Lauke [2] * Next iCab version. (Developer confirmation received today.) (The above implementations are the only ones I have tested with regard to this issue.) [1] https://addons.mozilla.org/en-US/firefox/addon/longdesk/ [2] https://addons.mozilla.org/en-US/firefox/addon/longdesc/
After an exchange with the iCab developer, I think that empty longdesc should be ignored *even* if the document has a <base href="someOtherPage"/>. See bug 21781.
Leif, it would be helpful to understand the content of your discussion with the iCab guys - and even more helpful to have their comments on the list directly. Since a blank longdesc is technically a URL, the behaviour you are requesting would be a wilful violation of HTML, something I am reluctant to do without some very clear justification. While in the normal case we can expect a blank link to be an error, it is well known that a lot of longdesc is still done badly. I think we are in an analagous position to alt 15 or so years ago, when it seemed to be used more often for attempted SEO than as a text alternative. A site might actually use server-side magic to provide something useful, as the current set of specifications has allowed for over two decades, although I don't know of any such case and would not be surprised if we didn't find one. My inclination is to wontfix this, but I think we should have further discussion first.
(In reply to comment #4) > Leif, it would be helpful to understand the content of your discussion with > the iCab guys - and even more helpful to have their comments on the list > directly. > > Since a blank longdesc is technically a URL, the behaviour you are > requesting would be a wilful violation of HTML, something I am reluctant to > do without some very clear justification. d'uh. But not a "valid *non*empty* URL". There was a reason for putting that in the spec. > A site might actually use server-side magic to provide something useful, as > the current set of specifications has allowed for over two decades, although > I don't know of any such case and would not be surprised if we didn't find > one. And this spec was written to clarify that it isn't a valid way of providing longdesc. > My inclination is to wontfix this, but I think we should have further > discussion first. I'm still inclined to wontfix this, beyond noting that there is a dependence on the bugs about whether a user agent must present longdesc, or can ignore invalid values, etc.
I am reluctant to conclude that the proposal *does* break URL standards. Relevant things to check: * How parsers (should) parse URLs inside @src attributes * How parsers (should) parse URLs inside @cite attributes
I asked a question on WhatWG, whether the related @src attribute should be ignored when empty, or if e.g. base url does apply http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-May/039486.html
(In reply to comment #7) > I asked a question on WhatWG, whether the related @src attribute should be > ignored when empty, or if e.g. base url does apply > > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-May/039486.html The initial result from asking the WHATwg mailing list was positive, from my point of view: Empty @src URL strings are ignored: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-May/039488.html http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-May/039490.html I asked some follow-up questions: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-May/039491.html
Filed bug 21896 about the @cite attribute to require non-empty URL and to ignore @cite if the url is empty.
We're not defining a user experience for error cases.