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 attributes that take exactly one URL (for example a@href or img@src), leading or trailing whitespace should be allowed in the attribute value. It will be safely stripped, and will not have any interoperability impact, nor will it do anything other than what the author expects. msn.com is an example of a site with this error: http://www.w3.org/html/wg/wiki/index.php?title=HTML5_Authoring_Conformance_Study#msn.com
(a) It is possible that multiple URLs would be allowed in the future. (b) I wouldn't count on the results being as expected; sometimes the spaces are converted to %20, and I wouldn't count on these being safely stripped at the end. (At the beginning, maybe.)
(In reply to comment #1) > (a) It is possible that multiple URLs would be allowed in the future. If there are attributes where that is the case, and where allowing leading or trailing whitespace would conflict with that eventual goal, then it would be reasonable to exempt them from this request. I do not expect <img src> or <a href> will ever be converted to take a space-separated list of URLs. For one thing, it would be incompatible with the way UAs process spaces in the middle of a URL currently. > (b) I wouldn't count on the results being as expected; sometimes the spaces > are converted to %20, and I wouldn't count on these being safely stripped at > the end. (At the beginning, maybe.) Are there any UAs or HTML content processors in which this actually happens for leading or trailing whitespace in an href or src attribute? If so, that would be a reasonable basis to reject this request.
I remember having problems, but cannot duplicate them now. I believe the situation was URLs launched from MS-Word, but using Opera (rather than MSIE) as my default browser, and the URLs were on an intranet to which I no longer have access. Trying to re-create, Opera does indeed strip " ", but not %20 -- so I suspect the problem was that something else was doing an URL-encode on the string. (This was a perfectly reasonable thing to do, given the number of embedded spaces in some of those URLs.) If the encoder first stripped the ends that would be OK, but I wouldn't count on homegrown tools actually doing that, even if does become standard. Should browsers autocorrect by stripping even an explicitly encoded percent-20? If not, I would prefer to keep at least explicitly-quoted attributes as-is.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: Concurred with original reporter's comments.
Checked in as WHATWG revision r4992. Check-in comment: Allow spaces around URLs in most attributes (not itemtype or xmlns). Require that UAs strip spaces around <input type=url value> URLs. http://html5.org/tools/web-apps-tracker?from=4991&to=4992