Could <input type=url> accept domains?

HTML
1

A domain (e.g., “wicg․io”) is not a valid URL string. In order to be valid, it needs the “https://” part.

When people type into the browser’s URL bar, they leave out the “https://” part and only type the domain. The browser than fills in this part, so that the input becomes a valid URL string.

So, browsers can turn a domain into a valid URL string. I assume they’re very good at this, and that this algorithm is the same between different browsers.

Could this functionality be exposed to <input type=url> somehow? So that the user can type a domain, and then the browser converts it into a valid URL string. Alternatively, there could be an <input type=domain> element.

This would be useful when asking users to enter their personal website, their favorite social network, their preferred search engine, and so on. Users know what domains are. When yo ask them to enter Twitter’s website address, they know to type “twitter․com”.

But the “https://” part is a problem. Users shouldn’t be expected to type that part when entering a website’s address. This means that <input type=url>, which requires it, is unsuitable for domains. It’s only suitable for copy-pasting full URLs from somewhere.

Website can use <input type=text> for domains, but then there is no built-in URL validation.

The only thing that is preventing <input type=url> from being suitable for domains is the “https://” part. I wish websites could just tell the browser to assume HTTPS. If the input is a domain, stick “https://” to the front and validate that.

3 Likes
2

seems a duplicate of Validate mime type for input type=url

3

Sounds like this is an ask for a built-in browser validator for an input field, which seems like a good idea. Curious if there are any downsides.

1 Like
4

But a domain is not a media type.

5

But a domain is not a media type.

Right, but a part of same flow of URL validation. Whether it is a full or partial domain name by RegEx, DNS lookup for domain existence, or presence of the resource by issuing the OPTION http request to validate, or assuring the remote resource size is sane for given device/connection,… all together fits into generic validation flow.

Going further it is also a part of form submission flow as part of Declarative Web Application proposals set.

If we look from prospective of multiple validators on same type of input field, we need to have validation rules

  • not conflicting
  • order explicitly defined
  • future-extendable without conflicts

Here we discussing just two mutually exclusive validations: domain name and content-type. I am envisioning at least a dozen similar proposals. Perhaps it is a time to write a generic declarative validation rule which would fit this and other proposals in compatible way?

6

Can’t browsers convert domains to URL strings and validate them without performing requests?

7

Can’t browsers convert domains to URL strings and validate them without performing requests?

yes, and there is no need for <input type="url"> expanding, the pattern attribute is sufficient. There is a thread on current state of this approach.

But a server side validation is also a good pattern :stuck_out_tongue_winking_eye:. Why you wanted to allow a fake domain in general and missing resource as well?

8

The pattern attribute does not prevent browsers from invalidating values that don’t start with “https://”.

9

The pattern attribute does not prevent browsers from invalidating values that don’t start with “https://”.

Right, and pattern validation does not trigger before the URL validator is passed. fiddle

As an option type=url has to check pattern first and skip the remaining check after passing. But it would not inject the prefix into value.

From another side, should the value to be treated in same way as URL API validator, like in <a href=url>?

I do not think so. Without protocol the domain would be counted as a path, obviously not intentional.

Summarizing, the omission of protocol in <input type=URL> makes it ambiguous.

What is realistic, is to ask vendors to alter the UI and hide the protocol when not in focus.

image
image1526×108 12.3 KB
and reveal when focused:
image
image1434×91 13 KB

As a second thought, this behavior can be done by CSS, not sure how reliable would be to compute the protocol shift behind of container. PoC fiddle

10

Why?

<input type=url> only accepts absolute URLs, not paths, so a value like “wicg․io” could only be interpreted as a domain.

11

See the URL spec on how the URL without protocol treated. Hint: as a relative path.