W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > July 2011

[Bug 13173] WF2: <input type="url"> should accept URLs with protocol omitted

From: <bugzilla@jessica.w3.org>
Date: Mon, 11 Jul 2011 19:23:51 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QgM59-0001G5-I3@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13173

--- Comment #20 from Marat Tanalin <mtanalin@yandex.ru> 2011-07-11 19:23:50 UTC ---
(In reply to comment #19)
> > Yes, for example, web-developer may show dynamic JS-tip like "You have not
> > entered a protocol, so "http://" is currenly assumed".
> 
> Why would you want to show the user that?  Are there existing applications that
> show such tooltips, or other evidence of author demand?  In what specific
> real-world case would such a tooltip help the user?

For example, URL in web-interface (this may be "URL" field in bugzilla's
bug-reporting form) is allowed to not be http one ("http://example.com",
"https://example.com", "ftp://example.com" are all valid URLs), but http is
default (since most often used) protocol in the interface and therefore is
allowed to be omitted (URL can be just "example.com"). Not all users make a
distinction between "https://example.com" and "http://example.com", so a tip
that clarifies this difference is quite likely to be present in usable
interface.

> > Web-developer should exactly know what is entered into form field just for
> > flexibility without any browser's disservice such as unauthorized
> > transformation of user input.
> 
> If you want complete flexibility, again, use <input type=text>.

When _complete_ flexibility is needed, then <input type="text"> is of course
most suitable. But if we need to just free user from typing redundant protocol
(while still dealing with URL as a whole and native URL validation in
particular), then _semantic_ <input type="url"> element (that semantically
_means_ that string is URL) is more suitable.

All we need here is to make protocol optional. No another changes or additions
to browser's behavior and/or UI are needed. Very simple to describe in the
spec, and very easy to implement.

There are no form fields types which values are transformed by browser before
submit, and there is no need for <input type="url"> to be different.

But again, even if browsers will add "http://" if protocol is omitted in user
input, then we at least could begin using <input type="url"> in real world
without harm for usability. Will browsers add "http://" before submit or not,
this is quite secondary thing.

Additionally, I personally would prefer that, if browsers will autoadd
"http://", then this would be added only to _data_ before its sending, _not_
inserted into field itself immediately after, say, the field blurring.

> If the browser only ever submits a valid absolute URL, the author can just
> output it into <a href=> without worrying about anything except XSS.

No, author (well, _good_ author) do not. Browser validation at all does not
guarantee that data sent to server is actually valid (and does not prevent XSS
in particular) --just because a hacker can send invalid data directly to server
with not use of browser at all. Input data should be validated on server-side
ANYWAY.

Purpose of browser validation is ONLY to make USER experience better by
providing _fast_ validation messages without need for page reload. Browser
validation is NOT a security measure at all, considering contrary is mistake.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 11 July 2011 19:23:52 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:13 UTC