New "URL" content area?

[Josh-Cena]

We don't have a central place for documenting how browsers handle URLs:

• Text fragments lives outside of everything else
• URL fragments that represent element IDs are undocumented (I think)
• data: lives in HTTP/Basics_of_HTTP/Data_URLs
• blob: is "documented" in API/URL/createObjectURL_static (one page links there; other pages link to API/Blob which makes even less sense)
• javascript: is entirely undocumented: Content suggestion: javascript pseudo-protocol identifier content#7143, despite its many interesting behaviors
• sms:, mailto:, et al. only get a passing reference on the <a> page

The fragment affects navigation behavior, while the different schemes affect many things, including link targets, fetch, import etc. The URL API exposes the syntax of URLs, such as resolving relative references (mdn/content#33455), but not the semantics like what should happen when fetching a javascript: URI. Moreover, I think it's just "wrong" to put things like resource URI concepts under the HTTP docs, because HTTP is just a protocol, and is not the whole network. Therefore it doesn't seem right to put docs about browsers' handling of URLs anywhere. Maybe we should consider a new "URL" area under Web/?

[bsmth]

I was originally thinking HTTP would be a good place for this but:

I think it's just "wrong" to put things like resource URI concepts under the HTTP docs, because HTTP is just a protocol, and is not the whole network

This is a good point, and there's plenty of other ways to use URIs, and it would be good for ftp, mailto (like you mentioned), ldap, websockets and more. So I would add a +1 for this section.

[hamishwillee]

Note, concrete PR work on this in mdn/content#35202

FYI @wbamberg . I have not formed an opinion on this yet.

My first reactions were negative

• is it "big" enough to justify its own references section:
  
• Where do I most think about URLs - HTTP, fetch (API).
• The fact that it can be found in ftp, ldap, mailto is a bit irrelevant since we talk very little about these. Even if we did, I still think I'd expect to go to HTTP to find information about URLs.
• I do think all things about construction of URLs and what makes them tick should be together.

Kind of feel like this is in the middle - not sure it is better, but maybe no worse either.

EDIT, I do kind of like the way the schemes are exposed in mdn/content#35202 (comment) but you could have this under a top level structure under HTTP and group their. So the question is, "is this better for navigability/discoverability"?

[Josh-Cena]

is it "big" enough to justify its own references section:

We have many other smaller "sections" not put into this navbar: security, PWA, opensearch... even XML has its own thing!

Where do I most think about URLs - HTTP, fetch (API).

That's right, and HTML too, since <a> hrefs are more or less their own thing, and don't forget import in JS which carries over its own behavior w.r.t. resolution and fetching. Therefore we have so many cross-cutting concerns that we have to find somewhere to document the similarities and differences in a central place.

The fact that it can be found in ftp, ldap, mailto is a bit irrelevant since we talk very little about these. Even if we did, I still think I'd expect to go to HTTP to find information about URLs.

But none of those can be used in HTTP, so it's wrong to put them there. In fact you can't even use data: in an HTTP request, so we are already wrong.

[hamishwillee]

These are all good arguments. So perhaps I just expect it in HTTP because that is where it is now. I'd be interested in what Will has to say.

[wbamberg]

I think @Josh-Cena 's comments about URL handling crossing over lots of different areas of MDN makes total sense. I guess the only thing I have to say is that it would be nice to design a complete coherent IA for MDN, rather than doing it in bits and pieces like this.

[Josh-Cena]

The new area has been created and the first PR for new docs in this area has been merged: mdn/content#35599 without this new area, there's pretty much nowhere we could document javascript: URLs!