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