@@ -2932,8 +2932,9 @@ Always define a corresponding MIME type and extend existing APIs to support this
2932
2932
for any new data format.
2933
2933
2934
2934
There are cases when a new capability on the web involves adding a new data format.
2935
- This can be an image, video, audio, or any other type of data that a browser is expected
2936
- to ingest. New formats should have a standardized MIME type, which is strictly validated.
2935
+ This can be an image, video, audio, text, or any other type of data that a browser is
2936
+ expected to ingest. Use a strictly validated standardized MIME type for new formats.
2937
+ New formats containing text should only support UTF-8 encoded text.
2937
2938
2938
2939
While legacy media formats do not always have strict enforcement for MIME types (and
2939
2940
sometimes rely on peeking at headers, to workaround this), this is mostly for legacy
@@ -2946,8 +2947,8 @@ they are safelisted in both ingress (e.g. decoding from a ReadableStream) and eg
2946
2947
For example. if you are to add an image format to the web platform, first add a new MIME
2947
2948
type for the format. After this, you would naturally add a decoder (and presumably an
2948
2949
encoder) for said image format to support decoding in HTMLImageElements. On top of this,
2949
- you are also expected to add support to egress points such as HTMLCanvasElement.toBlob()
2950
- and HTMLCanvasElement.toDataURL().
2950
+ you are also expected to add support to egress points such as ` HTMLCanvasElement.toBlob()`
2951
+ and ` HTMLCanvasElement.toDataURL()` .
2951
2952
2952
2953
For legacy reasons browsers support MIME type sniffing, but we do not recommend extending
2953
2954
the [pattern matching algorithm] (https://mimesniff.spec.whatwg.org/#image-type-pattern-matching-algorithm),
0 commit comments