[Bug 21439] The MAY w.r.t. treating invalid longdesc URLs as text, is harmful. Remove the harm - or remove the MAY.

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

Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #11 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> ---
(In reply to comment #10)
> The may statement in the conformance requirements has been removed.

Right. But as is, the descriptions blurs things, I feel. (But feel free to
suggest we handle this as a separate bug.)

> Since it is true that a common mistake is to include the description
> directly in the attribute, the repair example and the informative statement
> about it are still there, based on the "heirarchy of needs" principle - it
> is more important to help users than authors...

Yea. But even if every second longdesc was text, still, as long as @longdesc is
supposed to be a URL container, then everyone should be able to expect that, by
*default*, user ageents seek to resolve it as a URL [1] before eventually
seeking to consume it as text. Agree? (Note: by default.)

Note, in that regard, that the URL standard, which HTML 5.1 refers to,
considers spaces inside a URL as valid,[3] (see bug 21897). But note as well
that what the URL standard says about *failure*, might come us to resuce:[2]

   ]]Parsing (provided it does not return _failure_) and
     serializing a URL will turn it into an absolute URL.[[

PROPOSAL:

* In the examples and informative statement’s, replace the references
  to '(in)valid URL' with references to 'failure' to parse URL.
* E.g. instead of this:
  //Tries to repair errors where the longdesc isn't a URI
  Say this:
  //Tries to repair where URL parsing of longdesc leads to failure
* And e.g. instead of 
  (validURL(i.longdesc)) { //assumes some URL validating function
   Say this:
  (failureURL(i.longdesc)) { //some URL parsing failure function

JUSTIFICATIONS ETC:

* A JavaScript could probably pre-check (without following it) the
  url for failure, and thus prepare it for repair.
* Note that URL standard, for the @href attribute requires the
  user agent to 'try more', even beyond failure.[4] And thus,
  thus, compared with @href, the 'read as text' level would be
  lower.
* More aggressive fixing should be left to user’s configuration
  of preferences etc.

Personally, I think that the requiremetn that the URL must failure, is such a
high bar that the risk of loosing the URL becomes very low. Probably, so low
that much content that is text, would go pass/parse (sic) as URLs.

[1]
http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#resolving-urls
[2] http://url.spec.whatwg.org/#concept-parsed-url
[3] http://url.spec.whatwg.org/#url-code-points
[4] http://url.spec.whatwg.org/#dom-url-href

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

Received on Thursday, 2 May 2013 02:23:55 UTC