Topik wawancara representatif

Wawancara Frontend: Bagaimana Anda menggunakan HTML Ruby Markup Extensions untuk anotasi multibahasa?

FrontendSulit
Tim Redaksi Offer.ccDipublikasikan Diperbarui

Pertanyaan

Rancang komponen konten untuk kana Jepang, Zhuyin Mandarin Tradisional, dan Pinyin. Bagaimana Anda menyusun markup ruby, mendukung anotasi berlapis, menangani pencarian dan penyalinan, menyediakan fallback saat CSS Ruby tidak tersedia, dan menilai risiko screen reader?

Konteks dan cakupan

Rancang komponen konten untuk kana Jepang, Zhuyin Mandarin Tradisional, dan Pinyin. Bagaimana Anda menyusun markup ruby, mendukung anotasi berlapis, menangani pencarian dan penyalinan, menyediakan fallback saat CSS Ruby tidak tersedia, dan menilai risiko screen reader?

W3C menerbitkan HTML Ruby Markup Extensions Candidate Recommendation Snapshot pada 4 Juni 2026. Dokumen ini merevisi struktur ruby pada HTML, memulihkan rb dan rtc sebagai elemen yang sesuai standar (conforming), dan mendefinisikan unit semantik untuk basis, anotasi, kontainer, serta beberapa level anotasi. Ini bukanlah komponen penerjemahan dan tidak menyelesaikan setiap strategi pengucapan screen reader; pisahkan markup semantik, tata letak, dan perilaku teknologi asistif.

Apa yang dievaluasi oleh pewawancara

Pewawancara menginginkan pemasangan basis-ke-anotasi yang terstruktur, pilihan beralasan antara markup interleaved dan tabular, serta penggunaan CSS Ruby Layout daripada memasukkan pengucapan ke dalam gambar. Bahas atribut bahasa, pencarian dan penyalinan, fallback rp, konsistensi SSR/hidrasi, keamanan XSS, dan batasan pengujian screen reader.

Pertanyaan klarifikasi sebelum menjawab

  • Apakah sumber konten menyediakan pasangan basis/anotasi, atau komponen harus membagi dan menghasilkannya sendiri?
  • Bisakah satu basis memiliki beberapa level bahasa atau anotasi, seperti Zhuyin dan Pinyin secara bersamaan?
  • Jika tata letak Ruby tidak tersedia, apakah produk harus menampilkan tanda kurung sebaris (inline), menyembunyikan anotasi, atau mempertahankan struktur mentahnya?
  • Apa yang harus dipertahankan oleh masing-masing fungsi pencarian, penyalinan papan klip, dan text-to-speech?
  • Apakah pengguna dapat mengirimkan konten, dan elemen HTML, atribut, URL, serta aturan CSP apa saja yang diizinkan?

Kerangka jawaban 30 detik

“Saya akan memodelkan rentang basis, rentang anotasi, bahasa, dan kebijakan presentasi, lalu menghasilkan ruby, rb, rt, rtc, dan rp yang semantik. Markup interleaved menangani pasangan sederhana; kontainer eksplisit atau markup tabular menangani anotasi multi-karakter dan berlapis tanpa bergantung pada pemasangan implisit. CSS mengontrol posisi Ruby dan gaya fallback; rp menyediakan konten sebaris yang terlihat saat tata letak Ruby tidak tersedia. Pencarian dan penyalinan mengikuti semantik produk dan diuji pada browser sebenarnya. Output screen reader diuji secara langsung alih-alih hanya diasumsikan dari spesifikasi. Konten pengguna disanitasi sebelum dirender.”

Pembahasan mendalam langkah demi langkah

1. Mendefinisikan model data anotasi

Setiap segmen berisi rentang basis, satu atau lebih rentang anotasi, tag bahasa, dan kebijakan presentasi. Bahasa Jepang mungkin menggunakan kana; Bahasa Mandarin Tradisional mungkin menggunakan Zhuyin atau Pinyin Latin. Satu basis dapat memiliki beberapa level rtc, tetapi level default harus dinyatakan secara eksplisit. Pisahkan model dari rendering agar aturan segmentasi tidak tersebar di seluruh komponen.

2. Memilih markup semantik

ruby adalah kontainer keseluruhan, rb adalah unit basis, rt adalah teks anotasi, rtc adalah kontainer anotasi, dan rp adalah presentasi fallback. Kasus sederhana dapat menggunakan unit basis implisit, tetapi pemasangan multi-karakter yang kompleks harus menggunakan rb eksplisit agar DOM, perilaku penyalinan, dan tata letak tetap dapat diprediksi.

3. Menangani pemasangan multi-karakter dan berlapis

Markup interleaved berfungsi untuk anotasi satu-ke-satu sederhana. Markup tabular mencantumkan beberapa unit rb diikuti oleh unit rt yang sesuai, yang lebih baik dalam merepresentasikan kata majemuk dan pembacaan berlapis. Kelompokkan elemen rt berturut-turut dengan rtc; tetapkan lang pada setiap lapisan bahasa. Jangan menempatkan pengucapan sebenarnya dalam pseudo-elemen CSS karena pencarian, penyalinan, dan teknologi asistif tidak dapat melihatnya secara andal.

html
<ruby lang="zh-TW">
  <rb>美</rb><rtc><rt>ㄇㄟˇ</rt></rtc>
  <rtc lang="zh-Latn"><rt>měi</rt></rtc>
</ruby>

4. Menggunakan CSS untuk peningkatan tata letak progresif

HTML menyediakan struktur; CSS Ruby Annotation Layout mengontrol ruby-position, ukuran font, tinggi baris, dan perataan. Nilai default harus mencegah anotasi menutupi teks basis dan harus mengizinkan pembesaran teks (zoom). Saat tata letak Ruby tidak tersedia, rp dapat menampilkan tanda kurung atau petunjuk sebaris lainnya; jangan sembunyikan semua teks anotasi dengan display: none.

5. Merancang pencarian, penyalinan, dan ekstraksi

Spesifikasi membahas interaksi pencarian dan penyalinan, namun implementasi tetap memerlukan pengujian di browser nyata. Tentukan apakah penyalinan berisi teks basis saja, basis beserta anotasi, atau ekspor terstruktur. Pencarian harus dapat menemukan basis dan anotasi tanpa kehilangan kata akibat anotasi yang menyela DOM. Indeks server dapat menyimpan field terstruktur; klien tidak boleh menyimpulkan pasangan menggunakan regex pada HTML yang dirender.

6. Menilai teknologi asistif dan internasionalisasi

Ruby dapat membantu anak-anak, penutur non-asli, dan orang dengan kesulitan membaca, tetapi screen reader mungkin menggunakan heuristik yang berbeda. Tetapkan nilai lang yang akurat, pertahankan urutan teks yang bermakna, dan uji screen reader, navigasi keyboard, zoom, serta kontras tinggi. Jangan mengklaim bahwa spesifikasi menyelesaikan masalah text-to-speech sepenuhnya; dokumentasikan perbedaan yang diketahui beserta fallback-nya.

7. Memverifikasi keamanan, performa, dan kompatibilitas

Sanitasi basis dan anotasi yang disediakan pengguna dengan allowlist elemen dan atribut; tolak skrip, atribut event, dan URL berbahaya. SSR dan hidrasi harus menggunakan algoritma pemasangan yang sama untuk mencegah kedipan anotasi atau perubahan urutan teks. Gunakan node terstruktur dan rendering bertahap (incremental) untuk dokumen panjang, simpan cache model data daripada HTML yang tidak aman, dan lakukan pengujian dengan WPT serta matriks browser.

Contoh jawaban berkualitas tinggi

Saya akan memodelkan rentang basis, level anotasi, bahasa, dan kebijakan presentasi sebelum menghasilkan markup ruby yang semantik. Pasangan sederhana dapat menggunakan struktur interleaved; anotasi multi-karakter dan berlapis menggunakan rb dan rtc eksplisit, dengan lang pada setiap lapisan bahasa. CSS Ruby Layout mengontrol posisi, ukuran, dan tinggi baris, sementara rp menyediakan fallback sebaris saat tata letak Ruby tidak tersedia. Penyalinan secara default mengambil teks basis, pencarian mengindeks basis dan anotasi, serta perilaku pastinya diuji pada browser nyata. Karena pembacaan suara pada teknologi asistif belum sepenuhnya diseragamkan oleh spesifikasi ini, saya akan menguji screen reader, keyboard, zoom, dan kontras tinggi serta mendokumentasikan perbedaannya. Input disanitasi, SSR dan klien menggunakan satu model data dan algoritma pemasangan yang sama, serta WPT ditambah matriks browser memverifikasi struktur, tata letak, pencarian, penyalinan, dan keamanan.

Kesalahan umum

  • Menampilkan pengucapan hanya dengan pseudo-elemen CSS → pencarian dan teknologi asistif kehilangan teks → gunakan markup Ruby semantik.
  • Mengodekan setiap karakter secara kaku (hard-coding) sebagai node interleaved → pembacaan majemuk dan berlapis menjadi rapuh → gunakan pemasangan terstruktur dan rtc.
  • Memperlakukan rp sebagai tanda baca wajib yang selalu terlihat → browser yang mendukung akan menampilkan konten duplikat → tampilkan hanya pada presentasi fallback.
  • Mengabaikan lang → pembacaan suara dan pemilihan font menjadi salah → beri tag pada lapisan basis dan anotasi secara akurat.
  • Menjanjikan urutan pembacaan screen reader yang identik → spesifikasi tidak mendefinisikan perilaku TTS yang lengkap → uji perangkat dan dokumentasikan perbedaannya.
  • Merender HTML pengguna secara langsung → injeksi skrip dapat terjadi → sanitasi elemen, atribut, dan URL.

Pertanyaan lanjutan dan jawabannya

Kapan sebaiknya Anda menggunakan rb daripada basis implisit?

Basis implisit cukup baik untuk anotasi satu lapis yang sederhana. Gunakan rb eksplisit untuk kata majemuk, markup tabular, atau aplikasi yang memerlukan DOM stabil untuk pemasangan, penyalinan, dan debugging.

Bagaimana jika satu basis memiliki kana dan romanisasi?

Gunakan beberapa lapisan rtc atau kontainer anotasi eksplisit dan tetapkan lang pada masing-masing lapisan. Produk harus memilih lapisan default dan kebijakan peralihan; CSS tidak boleh menentukan semantik.

Apa fallback saat tata letak Ruby tidak tersedia?

Pertahankan struktur teks dan gunakan rp untuk tanda kurung atau pemisah sebaris agar basis dan anotasi tetap terbaca. Jangan menyembunyikan konten atau menggantinya dengan gambar yang tidak dapat dipilih.

Bagaimana Anda mendefinisikan perilaku penyalinan?

Pilih teks basis, basis plus anotasi, atau ekspor terstruktur sesuai tujuan produk, lalu uji pada Chromium, Firefox, Safari, dan perangkat seluler. Urutan DOM tidak secara otomatis menghasilkan string yang diinginkan pengguna.

Bagaimana Anda menunjukkan bahwa anotasi tetap aksesibel?

Periksa tag bahasa, urutan fokus, zoom, pengoperasian keyboard, dan output screen reader pada mode tanpa anotasi, satu lapis, multi-lapis, dan fallback. Publikasikan perbedaan teknologi asistif yang diketahui.

Sumber publik

Pertanyaan terkait