Fold common MIME types article into MIME types

[Josh-Cena]

Fix #6956

[github-actions]

Preview URLs (9 pages)

• /en-US/docs/Glossary/Lossy_compression
• /en-US/docs/Glossary/MIME_type
• /en-US/docs/Web/API/DataTransferItem/type
• /en-US/docs/Web/API/Window/showOpenFilePicker
• /en-US/docs/Web/API/Window/showSaveFilePicker
• /en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URLs
• /en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types
• /en-US/docs/Web/HTTP/Resources_and_URIs
• /en-US/docs/Web/Manifest/file_handlers

Flaws (3)

Note! 6 documents with no flaws that don't need to be listed. 🎉

URL: /en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URLs
Title: Data URLs
Flaw count: 1

• macros:
  • Wrong xref macro used (consider changing which macro you use). Error processing path /en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types

---

URL: /en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types
Title: MIME types (IANA media types)
Flaw count: 1

• macros:
  • Wrong xref macro used (consider changing which macro you use). Error processing path /en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types

---

URL: /en-US/docs/Web/HTTP/Resources_and_URIs
Title: Resources and URIs
Flaw count: 1

• macros:
  • Wrong xref macro used (consider changing which macro you use). Error processing path /en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types

External URLs (6)

URL: /en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types
Title: MIME types (IANA media types)

• https://datatracker.ietf.org/doc/html/rfc7303 (1 time) (Note! This may be a new URL 👀)
• https://en.wikipedia.org/wiki/7-Zip (1 time) (Note! This may be a new URL 👀)
• https://en.wikipedia.org/wiki/AbiWord (1 time) (Note! This may be a new URL 👀)
• https://www.adobe.com/acrobat/about-adobe-pdf.html (1 time) (Note! This may be a new URL 👀)

---

URL: /en-US/docs/Glossary/MIME_type
Title: MIME type

• https://en.wikipedia.org/wiki/Internet_media_type (1 time)
• https://www.iana.org/assignments/media-types/media-types.xhtml (1 time)

(comment last updated: 2024-07-23 14:24:31)

[bsmth]

Not all of these are binary, we could move H3 section "Binary data types" after this table and it would make more sense, IMO. Something like this:

## Important MIME types for Web developers

This table lists the most common MIME types with corresponding document types, ordered by their common extensions.

{table}

### Binary data types

What do you think?

[Josh-Cena]

@bsmth: this page calls application/* "binary type". I'm open to another name.

[hamishwillee]

FWIW I would name this application data types and explain that application just means "binary types associated with applications, that aren't grouped in the more specific types.

FWIW @bsmth I think this merging a very good thing - we should do it.

EDIT note, I've changed this comment a few times. The problem here is that the list isn't very interesting and that the application mime type is a catch all. So it would be nice to have it further down as a "by the way", here are some other things of interest. We could still do that, but put in own heading and cross reference.

[Josh-Cena]

I'm not sure I understand what change you are suggesting @hamishwillee. Are you saying we should move the table down to a new section at the end of "Important MIME types for Web developers", but keep the "Application data types" content here, or we should move "Application data types" down, after all other data types, because this is a catch-all and is the least interesting? I tried both but the flow got more awkward, particularly because it should probably still go before multipart/, and application/ vs. text/ is a common topic so they should be introduced side-by-side.

[hamishwillee]

Yes

1. Keep the top level "Application data types" content where it is (the text before the table).
   • Rename that heading to application data types or similar (from "Binary")
   • Text might need a little massaging - you'd point to the other application types in the table, which has moved ...
2. Table moves, as you say, to a new section before multpart (it is a discrete types).
   • "Important MIME types for Web developers" works for me.
   • or "Other Important ..." or "Common MIME Types for Web Developers" - any variant.
   • Again, you may need a few words to note that these are application types.

Sorry I was confusing - I haven't experimented with the flow as you have so that's what I'm seeing without having actually tried it.

[Josh-Cena]

The current tree is:

• Important MIME types for Web developers
  • Application data types (already edited, per your suggestion)
    • A list of a few explanation-worthy types
    • This table
  • Text types
    • text/html
    • text/css
    • text/javascript
  • Image types
    • A list
  • Audio and video types
    • A list
  • multipart/form-data

Are you suggesting I should move the table before multipart/form-data, so it becomes:

• Important MIME types for Web developers
  • Application data types
    • A list of a few explanation-worthy types
  • Text types
    • text/html
    • text/css
    • text/javascript
  • Image types
    • A list
  • Audio and video types
    • A list
  • Other application data types
    • The table
  • multipart/form-data

? Note that currently, the whole "Application data types" section is new and what's there used to be notes inlined in the giant table. Splitting them is a bit awkward because there's really no reason to document application/zip separately from the other application types, just because there's more to talk about it.

The following may be slightly better:

• Important MIME types for Web developers
  • Text types
    • text/html
    • text/css
    • text/javascript
  • Image types
    • A list
  • Audio and video types
    • A list
  • Application data types
    • A list of a few explanation-worthy types
    • This table
  • multipart/form-data

[hamishwillee]

Are you suggesting I should move the table before multipart/form-data, so it becomes:

Yes.
Though I would probably name the "Other application data types" heading "Other common MIME types" (and possibly explain that they are mostly application types).

Your suggestion might be better - it's the sort of thing that I wouldn't be sure of until trying it. But without seeing it, I prefer mine.

[bsmth]

OK, thank you both for sharing. If we're going ahead with removing the page, my gut feeling that the table is 'useful' means I would prefer the current tree where the table is higher up:

Important MIME types for Web developers
    Application data types
        A list of a few explanation-worthy types
        This table
    Text types
        text/html
        text/css
        text/javascript
    Image types
        A list
    Audio and video types
        A list
    multipart/form-data

[bsmth]

I've come back to this PR a few times since looking at it first, and I'm -1 on removing the files/en-us/web/http/basics_of_http/mime_types/common_types/index.md page. There is a lot of traffic to it (more than the files/en-us/web/http/basics_of_http/mime_types/index.md page), so it appears this table is popular in a standalone form. We can consider how to reduce duplication of information, but this format looks like it's working well:

• overview page
• table as a reference

[Josh-Cena]

@bsmth The problem is:

• Both pages have a list of MIME types and one is a strict subset of another
• Both contain substantial information so you really have to read both pages to get the whole picture, despite them talking about the exact same thing
• I don't get the traffic argument. No information is lost. Everyone who's previously looking at the table can now find the same information in the root page, but with more explanations.

If you wish, think about it as merging the root page into the table page (i.e. keep the table page that everyone likes, but add more information to it from another lesser known page), and then moving the table page to the root (another move that increases the discoverability of the table page).

[github-actions]

This pull request has merge conflicts that must be resolved before it can be merged.

[Josh-Cena]

@bsmth What do you think? Benefits of this PR:

• Colocated list of MIME types and explanations
• More links and more explanations, because it's terribly hard to do complex things in a Markdown table
• Deduplicated information

The popularity just comes from the fact that the table contains a lot of keyword hits so it's more discoverable. That doesn't mean it's useful by itself. After this change, the main page would also have the equal number of keyword hits while being far more readable.

[bsmth]

The popularity just comes from the fact that the table contains a lot of keyword hits so it's more discoverable. That doesn't mean it's useful by itself.

It's hard to tell, honestly, but I see your point. My rationale to keep it is that I've been looking at this page we're flagging for deletion as a 'cheat sheet'. We could apply these changes (which are thoughtful, btw) and keep an eye on the page feedback at some point down the road. How does that sound?

[bsmth]

Note for us; we'd have to update https://github.com/mdn/yari/blob/main/kumascript/macros/HTTPSidebar.ejs

"Introduction to MIME types" might be up for renaming.

Maybe we can use "Media types (MIME types)" instead: https://www.iana.org/assignments/media-types/media-types.xhtml

Media Types (formerly known as MIME types)

clearing the stale review

[Josh-Cena]

@bsmth and @hamishwillee I've moved the table down. Please let me know what you think.

[hamishwillee]

FWIW I think the structure with the table split out is much better.

Reading through https://pr34269.content.dev.mdn.mozit.cloud/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types I do find it a little repetitive that we talk about each of the discrete types, then we expand on them in the important types for web developers section. I think we could merge these if we want and make this quite a lot more succint.
I don't think I'd block on that though.

What does need to happen is the sidebar fix - #34269 (comment)

@bsmth I consider myself a bit of a "fly by" reviewer on this - so I'm expecting you to merge this. If you want me to be a proper reviewer let me know

[caugner]

The removed page has significantly more page views and users than the remaining one, so I have concerns with removing this page.

[Josh-Cena]

@caugner I have just had the same discussions with @bsmth above: "page views" is not a good indicator of the relative utility of a page. I can make a page that contains every buzzword a developer might google for but everything is a link to another page. This would make this page come up in every search but it just leads to more jumps. Instead of making cheatsheets, why not just talk about it while we introduce each thing? I don't get why deleting a page is such a big deal when I'm not removing any information and everything's still discoverable. If you believe someone has bookmarked the previous page then they can still use the current page and look for what they need.

[LeoMcA]

Instead of making cheatsheets, why not just talk about it while we introduce each thing?

Because a cheat sheet serves an entirely different purpose to explanatory documentation: a cheat sheet is for quick knowledge reminders, rather than fully learning about a topic.

I would be furious if https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_expressions/Cheatsheet was deleted because the information is duplicated elsewhere: the page's utility lies in having minimal prose, maximum information density.

I don't get why deleting a page is such a big deal when I'm not removing any information and everything's still discoverable.

Splitting up and burying the list of mime types amongst prose makes this information less discoverable for a certain use case.

Consider the user story: as a developer mid-flow, I know what mime types are, but have just forgotten the proper one for a json response is (is it text/json or is it application/json? crap, let's go to MDN to figure it out). Which page would you prefer to scroll or search through to try and find this information?

The additions to the mime types overview page look fantastic, but I don't think they require deleting the common mime types page. There's utility in duplicated content. Ideally the cheat sheet would link to the relevant prose-filled section of the overview page too. I can't imagine keeping the two pages in sync is a huge maintenance burden given how rare mime type additions which are relevant to web developers are.

And if page views for the common mime types page disappear into nothingness (or a large proportion navigate immediately to the mime types overview page) then we know that not many users are using it as a cheat sheet, and it's safe to delete it. As it stands, we're making big assumptions.

[Josh-Cena]

I'm not an HTTP maintainer and I don't want to spend my time fighting for its doc structure. If people don't think the merge is worthwhile, I'll record that as the opinion and close both this PR and the linked issue since the issue is essentially asking for the merge which gets rejected. Without the merge, there's not much to take away from the PR, although the Yari PR can proceed independently because it's also fixing the titles.