[Bug 21566] User agents must present longdesc through normal interfaces.

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

--- Comment #12 from Charles McCathieNevile <chaals@yandex-team.ru> ---
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #8)
> 
> > > * URL should be non-empty
> > 
> > This is already required in the spec. 
> 
> As this bug blocks bug 21778, the answer is no, it’s not (at least not for
> the copy of the spec that I hitherto has seen).

It is in the current editor's draft -
<https://dvcs.w3.org/hg/html-proposals/raw-file/default/longdesc1/longdesc.html>
- and will be in subsequent drafts unless there is a resolution to do
otherwise.

"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 that
its parent img element represents." - the second requirement for authors and
conformance checkers. That is repeated in the IDL.

> Btw, note the difference in our approaches: 
> You drew up a condition for when UAs *must* “present longdesc”:
> 
> >>> making the statement apply to valid longdescs
> 
> Whereas I drew up conditions for when UAs must *not* “present longdesc”:
> 
> >> if the value is the empty string, or if the URL is so malformed that
> >> it causes parsing failure

Yes, I understand that.

> It follows that your approach allows an empty longdesc to be presented.

Yes. It allows any nonsense to be presented. While that is not an optimal
implementation strategy, it seems reasonable to allow it to conform to the
specification. Indeed, as far as I know nearly all implementations today do
this (at least until I add the detect-and-repair heuristic to my extension...)

> (Or to quote what you said below: it “should conform (although it is
> recognized as not being the best quality of implementation)”.) Whereas
> my approach would not allow empty longdesc to be presented. (To be
> accurate, your approach makes it conforming whether the UA hides or
> presents an empty longdesc - placing the more responsibility on
> authors, which seems to me to be against the usual priority of
> constituencies.)
> 
> >> What do you think, Charles? Would you lilke to have even stricter
> >> condidtions for making the longdesc accessible to the user? 
> > 
> > No.
> 
> I’ll just note that your ‘when longdesc is valid’ condition would permit UAs
> to hide (or eventually instead ‘repair’) many more URLs than the negative
> conditions I suggested above would allow.

Probably, but I don't understand whether you think there is an implication in
that fact. As I see it, that is a fine thing, since it allows implementations
to be smarter and more innovative.

> > The agreement of the TF at this stage was to close this bug as
> > suggested. The following points were brought up in the discussion:
> >
> > 1. If user agents do present *everything* as if it were a valid URL,
> > that should conform (although it is recognised as not being the best
> > quality of implementation)
> 
> Agree, except when it comes to empty longdesc: Please discern - as I tried
> in comment #8 - between 'valid longdesc (value)' and 'valid URL'.

OK. That comes down to the precise wording that I use to try and implement the
resolution. I'll attempt to ensure that I get the distinction clear.

> The empty string is an valid URL, but it is an *invalid longdesc*.

Indeed.

> Should it really be conforming for UAs to present longdesc whenever
> it is empty?

Yes.
1. Prescribing error correction is fine when you have a good sense of what the
errors are and what the best corection should be, but I don't think we are at
that stage yet.
2. This is what implementations *do*, so we are paving cowpaths.
3. Conforming is not the same as good, and there is no reason to imply it is.
We can stsate explicitly that it might not be helpful, but I am trying to keep
the spec short for now.

> As told in bug 21778, I don't see why.


> > 2. We don't know enough about what to do when things are not working out to
> > be prescriptive, so we should leave this open while we learn from
> > implementation experience.
> 
> Since you use the wording ‘not working out’, and since we can expect a URL
> that includes a space to be working out (since both the URL standard and UAs
> have ways to work with them), this definition sounds *pretty* close to what
> I said (when I referred to URL parsing failure). Because, after all, there
> is nothing in the above statement which permits UAs to to assume that a URL
> that contains one or more space, should not be opened/followed/presented by
> the user agent.

Yes there is. If it has spaces, it is not valid.

> > 3. Where the URL is valid, it needs to be made available to the user.
> 
> Again, this means that UAs must present empty longdescs to the user (since
> empty longdescs would constitute a valid URLs). I suggest adding the
> condition 'and non-empty'. If it did att the condition 'and non-empty', then
> it would be an agreeable statement.

Indeed. I agree that I was imprecise, and will be more careful of that (as well
as ensuring the spec is).

> > We could dig into allowing the UA to test whether the URL resolves to a
> > valid long description,
> 
> I agree 100% that it would be best to not dig into that.
> 
> > Actually, the Web Apps group has a URL spec as a deliverable,
> 
> Thanks for the heads up.
> 
> > Fielding, Dürst, Suignard, McCahill… than the part-spec by Anne, and
> > something with spaces in it will not be a valid URL even if the spec defines
> > a way to work with it.
> 
> My apologies to him and to you - as well as to those guys you mention - for
> having spread *false information* regarding whether spaces are valid in
> Anne’s URL standard. Anne’s URL standard does *not* allow spaces in URLs -
> but it does define how to work with them

Right. I expect to do likewise.

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

Received on Monday, 6 May 2013 02:51:30 UTC