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

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

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

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

It follows that your approach allows an empty longdesc to be presented. (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.

> 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'. The empty string
is an valid URL, but it is an *invalid longdesc*. Should it really be
conforming for UAs to present longdesc whenever it is empty? 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.

> 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.

> 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

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

Received on Sunday, 5 May 2013 03:40:20 UTC