In short: because Sir Tim said so, and the rest of the world agreed.

“In fact, couldn’t we make a rule that whatever is the first character after the “href=” is the delimiter”

We could, but there already is such a rule, so why bother?

“Allowing spaces and flexible delimiters would let us express URL’s in ways humans can more easily understand.”

As I said in my previous comment, allowing spaces at the cost of adding delimiters peels off a layer of complexity at the cost of adding another one. It is not clear to me how that is a win. The only reason I can think of is that “regular” people more easily understand the rule Always Use Delimiters than they understand Never Use Spaces. The reason for that would be that most people use MS Windows, which allows (but not obligates) delimiters, and allows spaces.

Unfortunately, delimiters in Windows are only really useful when you are working with the command line interface, and I think that a) only a small subset of Windows users use the CLI, and b) the sort of people who use the CLI are typically computer savvy people who are capable of remembering a rule Never Use Spaces.

Perhaps what you really meant was: why can’t I type in “coca cola” in my address bar and go to the Coca Cola website? The answer to that is that that depends on your web browser.

BTW, as Glenn Fleishman notes, ‘they’ are working on domain names that allow international characters, and the big challenge for browser makers and browser users alike is that this opens the door for spoofs. This goes for spaces too: in some contexts, they differ little from underscores. If both are allowed in domain names, this makes it harder to detect spoofs. That’s not the fault of spaces, but it shows that using a small set of allowed characters makes it easier to detect spoofs.

(My expectation: a huge number of characters will be added to the set that is currently allowed for domain names, and browser makers and users will have to get used to a world where phishing is easier.)

“Allowing spaces and flexible delimiters would let us express URL’s in ways humans can more easily understand. After all, should Web pathnames be harder to read than Windows pathnames?”

Can I get paid for every hour of work that the easy-to-read Windows pathnames have cost me?

If all weblinks were associative queries there wouldn’t be a problem. Rather than linking to benandjerries.com you’d link to google.com?s=ben%20and%20jerries. As it is, already a lot of people use their Google input field instead of their address bar to get places. But sometimes you just want a specific document; having the least amount of ambiguity helps in such cases.

(Isn’t the plural of URL URLs, by the way? Just curious — I am not a native speaker of English.)

No, it’s annoying. I’d rather it left the damn things alone. I could select and drop ‘em on the tab bar if I wanted to open ‘em.

And wouldn’t the “first character after ‘href=’ is the delimiter” rule fix that for email clients anyway?

The other thing is that changing the basic specifications of the internet and web is practically impossible beccause of all the existing investment. Same reason why we still use QWERTY keyboards.

http://www.lumberjacks%20exchange.com/call%20me%20%22Carla%22.html

And, what Glenn said above – though that relates to non ASCII characters.

Right now, ICANN is dealing with the fact that despite the Internet being “international,” 10,000s of characters/ideograms/etc in most non-Roman languages cannot be represented. Browsers allow the use of hundreds of characters in domain names by using something called punycode, that rewrites certain characters into a special 26-Roman-plus-hyphen-plus-numerals format that DNS servers can interpret and that registrars must conform with.

So you have multiple plumbing challenges. Were you to want the space character to be legal in the domain name part of a URI, then you need to be part of the ICANN process and make sure that it gets in there. Otherwise, you’d have to use special browser extensions to do weird mapping and such on the browser side and only browsers with that extension (or browsers that adopt the approach) would handle that.

On the local side of the URI, after the domain name, you can use a whole slew of characters; your browser will encode them. But the Web server has to interpret them correctly. It’s possible to name local files with quotation marks and spaces in them (depending on platform), and the browser can encode that information into a path that can then be read.