Standardize extension to content type mapping?
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 25/100
Hướng nghiên cứu
Bắt đầu với issue về File API và hành vi của HTMLInputElement được tham chiếu. So sánh ánh xạ phần mở rộng sang loại nội dung dành riêng cho nền tảng được mô tả cho Chrome với các ghi chú hiện có về File API và HTML. Công việc được xem là hoàn tất khi đã xác định được hướng đặc tả, chẳng hạn như quyết định liệu có cần một ánh xạ được chuẩn hóa hay không và xác định phạm vi của nó.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
(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.
- Ngôn ngữ chính
- HTML
- Star
- 118
- Fork
- 52
- Merge trung bình
- 9 ngày 16 giờ
- Pull request đã merge (30 ngày)
- 1
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của w3c/FileAPI
-
TPAC 2026 Status Report Đang mởTPAC2026
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
-
Broken references in File API Đang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 62/100
-
Add accessibility section Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 30/100
Issue tương tự
-
has_tail_capacity wraps and get_writable_raw_unchecked commits raw_len before the bounds check Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
stratum-mining/stratum#2404 ·
-
opensubtitlescom: moviehash never sent when opensubtitles (.org) is not in the provider list Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
Diaoul/subliminal#1382 ·
-
fix(errors): EHOSTUNREACH from a happy-eyeballs connect is reported as a resolver error (STAMP-80) Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 90/100
snapshot-labs/stamp#666 ·
-
fix(api): prevent leaderboard SSE heartbeat from starting after disconnect during initial load Đang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
GauravKarakoti/SecureFlow#1070 · 1 bình luận ·
-
triage/confirmed
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
agentscope-ai/agentscope#2775 ·