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 17:13:52 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QgK3M-0001vD-AX@jessica.w3.org>

Aryeh Gregor <Simetrical+w3cbug@gmail.com> changed:

           What    |Removed                     |Added
  Status Whiteboard|                            |Hixie: see comment 1,
                   |                            |comment 7

--- Comment #19 from Aryeh Gregor <Simetrical+w3cbug@gmail.com> 2011-07-11 17:13:50 UTC ---
(In reply to comment #14)
> 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?

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

There's always a tradeoff between flexibility and utility.  If we make a
feature handle more use-cases, it will become less suited to each use-case it
does handle.  <input type=url> is meant to be useful for a limited range of
specific use-cases, not a general-purpose tool for handling any possible kind
of URL input for any conceivable purpose.  It's meant to handle 80% of
use-cases well, not all use-cases passably.  If you want complete flexibility,
again, use <input type=text>.

So requests that input types should be more flexible on general principle miss
the point.  You need to give very specific real-world use-cases if you expect
to get changes made.  "Real-world" here means not just conceivable or
theoretical, it means use-cases where it's clear (preferably provable) that a
significant percentage of authors would want the functionality.

(In reply to comment #15)
> (In reply to comment #13)
> > More specifically?
> If you do not know that the user typed, you can't tell him/her what was wrong.

That's not "specific".  I'm asking for specific real-world use-cases.  That
means preferably actual existing websites that accept URL input and would be
able to switch to <input type=url> except for this problem.  Failing that, you
need to at least sketch a specific scenario and argue convincingly that it's
likely to be common, even if you can't find actual occurrences.

> Not true. <a href> takes a references, not a what the HTML spec calls a "URL".
> So, yes, it will absolutely work with something like "foo.html", and thus this
> input type doesn't help at all for inserting hrefs.

<input type=url> is of course not useful for the general case of inserting <a
href=>.  It's intended for typical cases where you're supposed to enter a URL
in a form, like "Home page" in a profile.  The user might enter "example.com",
expecting it to work the same as "http://example.com".

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.  If the
browser submits "example.com" when the user enters that, you don't want to
output <a href=example.com>, since it will have a totally incorrect effect. 
Thus you'll need to add URL manipulation logic into your application, which is
the kind of complexity this input types are supposed to remove.

(Of course, you still have to deal with untransformed user input for the near
term anyway, when old browsers are still around.  But we should be planning for
the future here.  Eventually, authors should be able to escape input to avoid
XSS and not have to worry about other invalidity on the server side. 
"Eventually" could be soon in the presence of JS shims.)

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 17:13:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:55 UTC