Standardize extension to content type mapping?
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
Línea de trabajo
Empieza por el issue de File API y el comportamiento de HTMLInputElement al que se hace referencia. Compara la asignación específica de la plataforma entre extensiones y tipos de contenido descrita para Chrome con las notas existentes sobre File API y HTML. Se consideraría terminado cuando exista una dirección de especificación resuelta, por ejemplo, decidir si se necesita una asignación estandarizada y definir su alcance.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
(This discussion could go here or HTML — which notes "Extensions tend to be ambiguous..." — but I'm guessing the right eyeballs will be here.)
When a File is minted via a drop operation or HTMLInputElement in Chrome, the content type is determined using platform-specific logic. e.g. on Windows the registry is used as is normal for the platform. There's also a small fallback list built into the browser. This causes behavior to differ for the same version of Chrome on the same OS depending on what applications are installed (e.g. .DOCX may be unknown if Office is not installed). Presumably this is also an interop issue across browsers on the same machine if different logic/lists are used is used.
Web applications should trust neither extensions nor content types. But should we attempt to standardize the behavior here in any way, e.g. an expected list of extension → type mappings, to avoid developer surprise?
I'm not strongly advocating for this, just wanted to kick off the discussion.
- Lenguaje dominante
- HTML
- Estrellas
- 118
- Forks
- 52
- Merge medio
- 9 d 16 h
- PR fusionados (30 d)
- 1
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de w3c/FileAPI
-
TPAC 2026 Status Report AbiertoTPAC2026
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Broken references in File API Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 62/100
-
Add accessibility section Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 30/100
Todos los issues de w3c/FileAPI
Issues similares
-
has_tail_capacity wraps and get_writable_raw_unchecked commits raw_len before the bounds check Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
stratum-mining/stratum#2404 ·
-
opensubtitlescom: moviehash never sent when opensubtitles (.org) is not in the provider list Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
Diaoul/subliminal#1382 ·
-
fix(errors): EHOSTUNREACH from a happy-eyeballs connect is reported as a resolver error (STAMP-80) Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 90/100
snapshot-labs/stamp#666 ·
-
fix(api): prevent leaderboard SSE heartbeat from starting after disconnect during initial load Abiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
GauravKarakoti/SecureFlow#1070 · 1 comentario ·
-
triage/confirmed
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
agentscope-ai/agentscope#2775 ·