Anda Tidak Membutuhkan JavaScript untuk Itu

 (htmhell.dev)
3 poin oleh GN⁺ 2023-12-03 | 1 komentar | Bagikan ke WhatsApp
  • Untuk mengimplementasikan fitur web, meninjau teknologi yang kurang kuat terlebih dahulu—dengan urutan HTML, CSS, lalu JavaScript—lebih menguntungkan untuk mengurangi kegagalan pemuatan dan masalah aksesibilitas
  • JavaScript dapat mengontrol perilaku browser secara langsung, tetapi karena membutuhkan resource tambahan dan memiliki kemungkinan error, ia mudah mengecualikan pengguna keyboard dan teknologi bantu
  • Fitur seperti switch checkbox, datalist, input type="color", details/summary, dan dialog yang dulu membutuhkan JavaScript kini sebagian besar bisa dibuat dengan fitur bawaan HTML/CSS
  • Fitur deklaratif HTML dan CSS memungkinkan browser menangani perilaku native, pengaturan lingkungan pengguna, dan respons aksesibilitas, sehingga dapat menyediakan default yang lebih baik
  • Meski implementasi JavaScript yang sudah familier tetap berjalan, periksa alternatif HTML/CSS terbaru secara berkala, dan saat menggantinya lakukan juga pengujian aksesibilitas

Aturan hak istimewa minimum

  • Aturan hak istimewa minimum adalah prinsip pengembangan web yang menyarankan memilih bahasa yang paling kurang kuat namun tetap dapat mencapai tujuan
  • Di web, ini biasanya diterapkan dengan mempertimbangkan HTML sebelum CSS, dan CSS sebelum JavaScript
  • JavaScript adalah yang paling serbaguna di antara ketiga teknologi itu, tetapi bebannya juga paling besar
    • Bisa rusak
    • Bisa gagal dimuat
    • Membutuhkan resource tambahan untuk diunduh, diparsing, dan dieksekusi
    • Mudah mengecualikan pengguna keyboard dan pengguna teknologi bantu
  • Berbeda dari JavaScript imperatif, HTML dan CSS bekerja secara deklaratif
    • Developer memberi tahu browser apa yang diinginkan, dan browser memilih cara implementasinya
    • Browser dapat memilih cara pemrosesan yang lebih efisien
  • Ketika browser menangani fitur HTML/CSS, hal ini bisa menguntungkan dari sisi performa, perilaku native, dukungan pengaturan lingkungan pengguna, dan aksesibilitas
    • Namun aksesibilitas tidak selalu otomatis terjamin

Fitur-fitur yang dulu membutuhkan JavaScript

  • Pembuat browser dan penulis spesifikasi telah memindahkan fitur-fitur yang hingga beberapa tahun lalu membutuhkan JavaScript ke CSS dan HTML
  • Web mempertahankan kompatibilitas mundur, sehingga cara implementasi yang pernah dipelajari cenderung tetap ada di toolbox dan digunakan berulang kali
  • Meski Anda tahu suatu fitur membutuhkan JavaScript, sesekali memeriksa apakah hal itu masih benar dapat membantu membuat situs web yang lebih baik

Switch kustom yang dibuat dengan checkbox

  • Switch kustom dapat diimplementasikan dengan checkbox bawaan dan CSS, alih-alih div, handler onclick, dan state internal
  • Jika memasukkan <input type="checkbox"> ke dalam <label>, browser akan menghubungkan keduanya
    • Mengklik bagian mana pun dari label akan men-toggle checkbox
    • Tidak perlu handler onclick terpisah
  • appearance: none menghentikan rendering kontrol form bawaan browser dan memungkinkan Anda men-styling-nya sendiri
    • input itu sendiri dapat dihias seperti latar switch
    • ::before dapat digunakan sebagai titik internal yang di-toggle
  • Pseudo-class :checked dapat mengubah warna latar dan posisi ::before sesuai status checked
  • Untuk pengguna keyboard, indikator fokus diperlukan
    • Menyembunyikan fokus dengan outline: none bukan cara yang baik
    • :focus-visible dapat menampilkan ring fokus yang terlihat bagus hanya saat interaksi keyboard
    • outline-offset dapat menyesuaikan garis fokus ke luar atau ke dalam elemen
  • input:focus { outline-color: transparent; } membuat garis fokus transparan dalam situasi normal, dan dalam mode kontras tinggi dapat membuatnya terlihat kembali dengan warna pilihan pengguna
  • Mode warna paksa dapat dibaca lebih lanjut di forced colors explained

Autocomplete native dengan datalist

  • datalist adalah fitur saran otomatis bawaan browser yang menampilkan daftar opsi saat pengguna mengetik
  • Susunannya sederhana
    • Masukkan id dan beberapa option ke elemen datalist
    • Hubungkan dengan datalist tersebut melalui atribut list pada input
  • Saat pengguna mengetik, browser menampilkan dropdown dan otomatis memfilter opsi sesuai isi input
  • Karena ini adalah field input biasa, pengguna juga dapat mengetik nilai yang tidak ada dalam daftar
  • Setelah memilih field input, pengguna dapat menelusuri daftar dengan tombol panah, atau mengeklik ikon dropdown yang ditambahkan browser untuk melihat semua opsi

Color picker bawaan input type="color"

  • Dengan satu baris <input type="color">, Anda dapat menggunakan color picker native browser
  • Ini dapat menggantikan banyak UI canvas dan slider yang dibuat dengan JavaScript
  • Color picker native di browser Chromium dapat memilih warna tidak hanya di dalam situs, tetapi juga dari mana saja di layar
  • Karena tidak semua pengguna dapat memakai color picker browser, sebaiknya sediakan juga cara lain untuk memilih warna, seperti input teks biasa

Accordion dengan details dan summary

  • Elemen details dan summary menyediakan accordion untuk melipat dan membuka konten sebagai fitur bawaan browser
  • Perilaku dasarnya sederhana
    • Konten di dalam details, kecuali summary, disembunyikan
    • Saat pengguna mengklik summary, konten lainnya ditampilkan
  • Atribut open menentukan kondisi terbuka di awal
    • Ini bukan nilai yang tetap setelah interaksi pengguna; status berubah saat pengguna membuka dan menutupnya
  • Marker segitiga bawaan dapat di-styling dengan summary::marker
    • Kontennya dapat diganti dengan emoji dan sejenisnya
    • Warna latar, gambar latar, ukuran font, dan lainnya dapat disesuaikan
    • Banyak properti CSS tidak berfungsi, dan styling seperti menempatkannya di posisi yang sama sekali berbeda memiliki keterbatasan
  • Di Safari, pseudo-element ::-webkit-details-marker diperlukan
  • Perubahan konten marker dapat memengaruhi cara teknologi bantu mengumumkan accordion, jadi Anda dapat merujuk ke details/summary inconsistencies
  • summary dapat diklik, tetapi secara default tidak menampilkan kursor pointer seperti link maupun terlihat seperti tombol, sehingga perlu menambahkan status hover dan focus agar terlihat bisa diklik

Modal dengan dialog

  • alert(), prompt(), dan confirm() dapat memberi tahu atau meminta konfirmasi kepada pengguna, tetapi mengunci main thread dan sulit di-styling agar sesuai desain
  • Jika membuat dialog sendiri, penanganan aksesibilitas menjadi rumit
    • Fokus harus tetap berada di dalam dialog
    • Harus memberi tahu bahwa ini modal
    • Harus mencegah pengguna keluar secara tidak sengaja
    • Dapat berbenturan dengan widget yang memiliki z-index sangat tinggi
  • Elemen dialog browser menyediakan dialog native
  • Saat ini JavaScript diperlukan untuk membuka dialog
    • Perubahan untuk membukanya tanpa JavaScript sedang berjalan, tetapi belum sepenuhnya dispesifikasikan atau diimplementasikan
    • Dialog dapat dibuka dengan fungsi showModal()
  • dialog dibuka di top layer
    • Top layer adalah layer baru yang terpisah dari HTML
    • Elemen di layer ini selalu ditampilkan di atas, terlepas dari z-index dan tumpukan stacking context
    • Untuk penjelasan konsepnya, lihat Top layer di MDN
  • dialog tidak menyediakan UI penutup bawaan, sehingga Anda harus memasukkan UI sendiri
    • Saat form method="dialog" disubmit, browser menutup dialog
    • Jika dua tombol submit diberi value berbeda, ini dapat digunakan seperti dialog konfirmasi
    • Pada event close, Anda dapat membaca dialog.returnValue untuk memeriksa nilai tombol yang ditekan pengguna
    • Data form tambahan dapat dibaca dengan FormData
  • dialog::backdrop adalah layer di antara dialog dan bagian halaman lainnya
    • Ini dapat menggelapkan atau memburamkan latar belakang untuk mengarahkan perhatian pengguna ke dialog
    • Karena browser yang menempatkannya, Anda tidak perlu menangani sendiri scrolling, elemen fixed, atau perubahan ukuran browser

Fitur yang bisa dibuat dengan lebih sedikit JavaScript

  • Ada lebih banyak fitur yang dapat mengurangi JavaScript
    • Smooth scrolling native dengan scroll-behavior: smooth
      • Dengan syarat hanya digunakan saat prefers-reduced-motion: no preference cocok
    • Carousel native dengan scroll-snap
    • Elemen “in-view” dengan position: sticky
    • Container query
  • Ada juga fitur yang akan ditambahkan ke depan
    • Animasi berbasis scroll
    • Layout Masonry dengan grid-template-rows: masonry tanpa masonry.js
    • select yang dapat di-styling sepenuhnya melalui elemen baru selectlist
    • Selector :has() yang dapat mengurangi satu kategori kode seleksi JavaScript
  • Konten terkait dapat dilihat lebih lanjut dalam video presentasi Stop Using JavaScript for That: Moving Features from JS to CSS and HTML.
  • Saat mengganti implementasi yang sudah teruji dengan cara baru, uji aksesibilitas secara khusus agar tidak ada siapa pun yang tereksklusi

Bacaan terkait

1 komentar

 
GN⁺ 2023-12-03
Komentar Hacker News

  • Hal yang terlewat dari tulisan ini adalah alasan memakai JavaScript di tempat seperti ini justru karena kompatibilitasnya lebih baik
    JavaScript baru bisa ditranspilasi, tetapi mem-polifill fitur CSS atau HTML yang belum ada jauh lebih sulit, dan dalam beberapa kasus tidak mungkin. Lagi pula, polifill itu pada akhirnya juga memakai JavaScript
    appearance bahkan di MDN pun disertai banyak peringatan untuk menguji dengan sangat teliti, termasuk appearance: none. Ini mungkin kurang penting jika hanya mendukung browser modern, tetapi versi Safari lama ternyata bertahan lebih lama dari dugaan
    datalist tidak melakukan apa pun di Firefox Android, dan bagi saya hanya terlihat seperti kotak input tanpa saran apa pun
    Pemilih warna memang keren, tetapi sangat tidak standar sehingga bisa fatal bagi kebanyakan bisnis. Bukan cuma desainer yang akan mengeluh; tim dukungan pelanggan juga jadi sulit membantu pengguna. Chromium bahkan memberi fitur memilih dari halaman atau mengambil warna acak, sedangkan Firefox Android hanya memberi pelangi, abu-abu, dan hitam-putih semacam itu
    Tulisan itu sendiri juga mengakui ketidakkonsistenan details dan dialog. Semoga suatu hari browser yang tidak mendukung fitur seperti ini, atau mendukungnya secara tidak konsisten, tidak lagi dipakai, tetapi untuk sementara elemen-elemen ini tampaknya hanya cocok untuk side project yang bisa sepenuhnya mengendalikan browser yang didukung

    • Sulit setuju dengan pernyataan bahwa pemilih warna itu tidak standar
      Di iPhone, saat tombol ditekan, yang muncul adalah pemilih warna native sistem yang sesungguhnya. Itu kontrol yang memang disediakan OS dan terlihat di berbagai aplikasi, dan saya jauh lebih menyukainya daripada yang dibuat kustom
    • Bahwa kompatibilitasnya lebih baik hanya benar jika diasumsikan semua pengguna harus memakai JavaScript
      Saya jauh lebih suka web tanpa JavaScript, dan dampaknya pada daya tahan baterai laptop bisa sampai hitungan jam. Ada situs yang tidak kompatibel dengan ini lalu hanya merender halaman kosong atau mengeluh bahwa JavaScript diperlukan untuk menampilkan teks
      Sementara itu Amazon juga punya salinan situs e-commerce tanpa JavaScript, yang menunjukkan bahwa pekerjaan sebesar itu pun bisa dilakukan tanpa JavaScript
    • Elemen dialog sekarang sudah punya cakupan dukungan yang cukup dalam, dan polifill untuk beberapa persen pengguna yang masih memakai Firefox atau Safari era 2021 sudah cukup layak
      Kalau membuat modal, sangat direkomendasikan, dan peningkatan aksesibilitasnya luar biasa
    • Bahwa tim dukungan pelanggan jadi sulit membantu pengguna itu memang besar
      Di tempat kerja lama saya, kami membahas masalah ini secara serius dan memutuskan memakai implementasi JS alih-alih hal seperti datalist. Khusus datalist, kami sempat mencobanya tetapi hasilnya terlalu tidak konsisten sehingga harus ditinggalkan
      Pada akhirnya, karena ketidakkonsistenan antar-browser, kami bahkan menghentikan dukungan selain untuk Chrome
    • Tidak. JavaScript itu kalau gagal, gagalnya total sampai kontennya sendiri hilang
      Contoh HTML mungkin tampilannya salah di browser lama, tetapi konten sebenarnya tetap ada. Kalau JS, ya tidak ada apa-apa. Ini benar-benar merusak aksesibilitas
      Dengan HTML, screen reader setidaknya masih bisa membacanya, tetapi konten yang dibuat dengan JS malah menghalangi itu. Saat JS tidak bisa menjalankan JS, tidak ada polifill atau JS lain yang bisa menyelamatkan JS. Ia harus “berfungsi” sejak awal agar aman bagi aksesibilitas, dan kalau begitu poin awal perdebatan jadi tidak bermakna

  • Saya sebelumnya tidak tahu soal Datalist, tetapi setidaknya di Chrome Android tampaknya tidak berfungsi dengan baik
    Opsinya memang muncul di area keyboard tempat saran autocomplete ditampilkan: https://imgur.com/a/Ecb4503
    Saya belum pernah melihat pendekatan seperti itu pada kontrol form di UI web mobile, kecuali saat aplikasi autocomplete kata sandi memakai area yang sama
    Tidak buruk. Jauh lebih baik daripada menggulir dropdown JS kustom yang dibuat asal-asalan dengan canggung, tetapi saya tidak yakin pengguna biasa akan tahu cara memakainya. Jadi menurut saya di mobile ini praktis tidak punya harapan
    Di Firefox Android malah sama sekali tidak didukung: https://caniuse.com/?search=datalist

    • Para pembuat browser, apa tidak bisa memberi styling untuk dropdown datalist?
      Referensi: https://adrianroselli.com/2023/06/under-engineered-comboboxe...
    • Inilah alasan solusi seperti ini butuh waktu lama untuk benar-benar mapan
      JavaScript sudah cukup terstandarisasi dengan baik, sedangkan HTML dan CSS relatif belum sebaik itu
    • Saya penasaran apakah menambahkan autocomplete="off" pada elemen input akan mengubah perilakunya
      Bagaimanapun juga, itu memang diperlukan agar datalist bisa dipakai dengan benar. Kalau tidak, riwayat nilai yang pernah dipilih akan ditambahkan ke daftar dropdown. Saya mengamati ini di Chromium
      Selain itu, dalam beberapa situasi seperti saat nilai default sudah ditetapkan, datalist juga tetap memerlukan JS. Solusi sementara dan catatan perilaku khas per browser saya rangkum dalam kode situs web baru LibreOffice: https://git.libreoffice.org/infra/libreofficeorg/+/835a5cc59...
      Kabar baiknya, pengembang Firefox berencana meninjau perbaikan perilaku datalist, jadi mungkin nantinya daftar bisa ditampilkan hanya dengan satu klik
    • Sudah lihat bagian di atas keyboard?
      Di saya, opsinya biasanya muncul di area atas keyboard tempat saran kata ditampilkan
    • Munculnya opsi datalist di dalam keyboard itu perubahan yang baru terjadi dalam beberapa bulan terakhir
      Dulu “normal”, tetapi rasanya seseorang hanya ingin mengubahnya demi mengubah saja

  • Penggunaan scroll-behavior: smooth untuk scrolling halus native sebaiknya benar-benar dibatasi
    Ternyata ini bukan ide yang bagus untuk sebagian besar kasus penggunaan, dan sering menimbulkan efek samping yang tidak diinginkan
    Orang bilang scroll-snap bisa dipakai untuk membuat carousel native, tetapi carousel tetap ide yang buruk, jadi ruang penggunaan scroll-snap yang benar-benar sah juga sangat terbatas
    Halaman yang memakai animasi berbasis scroll biasanya justru akan lebih baik kalau itu dihapus

    • Inti tulisan ini bukan menyuruh orang memakai elemen desain tertentu, melainkan menunjukkan cara mengimplementasikan desain seperti itu dengan lebih ramah pengguna
      Scrolling halus adalah contoh yang bagus. API native memungkinkan pengguna menghentikannya kapan saja. Sebagian besar implementasi JS tersendat parah dan bikin pengguna menderita
      Kita bebas mengkritik pilihan desain, tetapi tanpa menjelaskan alasan nyata mengapa “carousel tetap buruk”, sulit berharap orang mau mendengarkan
    • Saya juga benci carousel
      Tapi halaman depan Amazon memakai carousel dengan sangat mencolok, dan setahu saya Amazon melakukan A/B testing variasi halaman depan tanpa ampun. Kalau begitu, mungkin saja carousel menunjukkan hasil yang bagus dalam pengujian, sehingga agak sulit mengatakan itu benar-benar “buruk” dalam arti yang universal dan objektif
    • Mengapa scrolling halus native bukan ide bagus dalam kebanyakan kasus?
      Biasanya saya tetap menambahkannya setidaknya segera setelah membuat anchor bergaya daftar isi
    • Bagaimanapun juga, hal-hal seperti itu memang tidak memerlukan JavaScript

  • Mengejutkan bahwa pada 2023 kita masih saja berdebat soal form dan UX umum untuk input data pengguna
    Cukup lihat komentar tentang datalist dan pemilih warna; sulit dipahami mengapa ini masih belum menjadi area yang selesai
    Dulu ada upaya untuk menyelesaikan semuanya sekaligus lewat XForms, tetapi itu tidak pernah diimplementasikan di browser
    Sebagai gantinya, hampir semua framework komponen CSS/JS masing-masing menyediakan kumpulan elemen form terbatas dengan semantik yang berbeda-beda

    • Akibat menolak teknologi XML, web ditakdirkan untuk terus-menerus mengimplementasikan ulang versi buruk dari apa yang sebenarnya sudah diberikan XML
      Sepertinya kita akan menghabiskan hidup dengan membuat sendiri kontrol UI dasar
    • Itu sebenarnya sudah selesai. Tinggal masukkan ke React dan lanjutkan hidup
      Kesan bahwa ini “belum selesai” hanya muncul karena sebagian orang punya obsesi aneh untuk menghindari JavaScript lalu memaksakan alternatif setengah matang
    • Apa maksudnya form itu “sudah selesai”?
      Kalau kita mau bertahan pada teknologi yang membosankan dan dasar, sebenarnya itu sudah selesai. Tetapi kalau kita keras kepala ingin menyelesaikannya lagi dengan React, lalu lagi dengan React hooks, dan terus mengulang tanpa akhir, ya jadinya memang tidak pernah selesai
    • Karena CSRF, ada beberapa hal yang secara manusia bisa dilakukan tetapi tidak bisa kita lakukan
      Niat tidak bisa ditentukan secara terprogram, jadi dalam situasi tertentu kita tidak bisa punya fitur yang keren
      Pada form kompleks terakhir yang saya kerjakan, saya harus membuat event klik memicu submit form dengan cukup langsung agar browser mau mengizinkannya
    • Form belum selesai karena di suatu tempat selalu ada orang yang ingin mengirimkan hal yang berbeda lewat form
      Saya sendiri tidak pernah meminta cara mengirim warna melalui halaman web

  • Jika memakai details alih-alih JavaScript, Ctrl+F bisa mencari isinya dan membukanya
    Accordion berbasis JavaScript tidak bisa dibuka seperti itu

    • Dengan hidden="until-found", hal ini juga bisa dilakukan pada accordion berbasis JS atau konten tersembunyi lain, tetapi sayangnya saat ini hanya ada di browser berbasis Chromium: https://developer.chrome.com/articles/hidden-until-found/
    • Adakah cara lain untuk menyembunyikan sesuatu sambil tetap mengizinkan pencarian?
    • Saya baru saja mengalami masalah serupa saat menelusuri dokumen

  • Saya setuju dengan sebagian besar isinya, tetapi belum cukup memakai dialog untuk punya pendapat, dan menurut saya datalist bukan pilihan yang layak kecuali untuk alat internal
    Tampilannya jelek, kemampuannya terbatas, dan juga tidak bisa di-style. Inilah masalah dengan sebagian besar argumen “pakai saja fitur bawaan”. date picker juga sama
    Bukan cuma default-nya kurang bagus, tetapi saat ingin mengubahnya pun tidak bisa. Begitu menabrak salah satu dari sekian banyak batas dalam styling atau perubahan perilaku—misalnya ingin minggu dimulai dari Senin—itu tidak bisa. Lalu pilihannya biasanya tinggal pustaka pengganti total berbasis JS
    Saya mendukung penggunaan opsi yang lebih ringan dan setuju dengan hierarki HTML > CSS > JS, tetapi kadang JS adalah satu-satunya jawaban jika kita ingin UI yang bagus sekaligus fitur yang diinginkan

    • Saat membuat kotak saran pencarian, saya sempat berpikir datalist mungkin membantu
      Itu bekerja baik sampai muncul kebutuhan untuk menampilkan opsi yang tidak benar-benar diawali oleh input pengguna. Misalnya, kalau input mengandung typo, opsinya tidak akan muncul
      Karena tidak ada cara untuk memaksa semua item tetap ditampilkan, saya akhirnya memilih daftar berurutan
    • Selalu layak diingat bahwa pendekatan memperluas markup semantik bawaan dengan JS adalah pendekatan yang lebih tahan masa depan
      Saat saya mulai mengembangkan web, perubahan bisa memakan waktu sampai 10 tahun. IE6 memang menahan kita semua, tetapi saat itu w3c juga cukup tidak berdaya. Sekarang perubahan terjadi lebih cepat
      Tahun depan mungkin saja styling datalist tanpa prefiks akan tersedia di tiga browser utama, tetapi kalau kita sudah terikat pada solusi JS kustom, bisnis belum tentu mau membayar biaya pembangunan ulang
      Jika kita memperluas fitur native dengan JS, kita bisa menghapus JS itu dengan biaya rendah saat dukungannya sudah cukup. Gunakan kontrol native sekarang jika sudah memadai, lalu terapkan JS seperti polyfill
    • Untuk hari awal minggu atau input[type=date], sebagian besar kustomisasi yang sering diusulkan justru lebih baik tidak berada di bawah kendali pengembang
      Kalender yang tepat untuk ditampilkan seharusnya bergantung pada locale. Platform pengguna sudah punya kemampuan untuk mengatur dan menampilkannya dengan cara yang kemungkinan paling efektif bagi pengguna
      Pemilih tanggal milik platform lebih baik daripada sesuatu aneh buatan sendiri

  • Tombol toggle itu memang bagus
    Tulisan ini tampaknya membuat para pengembang frontend pecinta meme marah, tetapi poin utamanya benar. Mengapa begitu banyak situs bodoh dibuat dengan JS? Jika orang-orang cukup mengikuti satu standar seperti HTML, semuanya bisa konsisten, dan hal-hal seperti aksesibilitas atau terjemahan juga bisa lebih mudah diselaraskan
    Kalau masuk ke situs-situs sekarang, semuanya dimuat secara dinamis dalam satu halaman sampai-sampai tombol kembali pun tidak berfungsi

    • Sekalipun orang-orang mengikuti satu standar seperti HTML, para pembuat browser juga harus mengimplementasikannya secara konsisten
      Dan tetap ada masalah “menunggu orang memperbarui”, karena setelah fitur baru diperkenalkan bisa butuh waktu bertahun-tahun sampai dukungannya cukup luas untuk benar-benar berguna
      Saya pada umumnya setuju bahwa ada banyak implementasi buruk dan perangkat JavaScript yang rumit. Untuk konten dinamis pun sudah ada cukup banyak solusi terstandar untuk mempertahankan fungsi kembali, dan setahu saya framework web populer mendukungnya secara bawaan
    • Benarkah mereka sedang marah?
      Saya sudah membaca komentar-komentar teratas, tetapi tidak banyak yang bisa disebut kemarahan; yang terlihat hanya orang-orang yang mengemukakan poin valid soal dukungan browser

  • Ini memang satu langkah ke arah yang benar, tetapi CSS juga merupakan alat lain yang disalahgunakan oleh para “artistes” seperti kata Philip Greenspun untuk membuat halaman yang sulit dibaca
    Saya bukan pendukung Gemini, tetapi pada dasarnya semua aspek tata letak dan tipografi seharusnya dikembalikan ke browser dan dikendalikan oleh pengguna. Para desainer sudah tanpa henti menunjukkan bahwa mereka tidak bisa dipercaya untuk urusan itu

  • Saya suka maksudnya, switch-nya juga keren, dan summary/details juga kadang berguna
    Tetapi elemen datalist hampir bukan pilihan yang realistis untuk penggunaan di luar mainan atau prototipe

  • Hal-hal “cukup dengan CSS tanpa JS” yang saya sukai adalah sidebar drawer dan carousel
    Di DaisyUI, pustaka komponen TailwindCSS, juga ada komponen siap pakai
    https://daisyui.com/components/drawer/
    https://daisyui.com/components/carousel/

    • Bagaimana cara memberi tahu screen reader tentang drawer?
      Drawer dan konten lain yang muncul di halaman harus diumumkan, dan status aria-expanded harus ada di samping kontrol targetnya
      Ini masih pertanyaan nyata. Mungkin ada caranya, atau mungkin para pengembang secara kolektif menganggapnya tidak penting. Para auditor mungkin tidak akan setuju
    • Setiap kali melihat framework seperti ini saya selalu bersemangat pada awalnya, tetapi seperti semua framework lain yang pernah saya uji, DaisyUI juga punya berbagai masalah di iOS Safari dan browser lain
      Tampaknya para penulis framework seperti ini sangat meremehkan seberapa banyak pengujian yang diperlukan agar benar-benar bekerja lintas browser
      Komponennya sebanyak itu, ditambah lagi bisa diberi tema, sehingga sulit memastikan apakah perbaikannya bisa dilakukan tanpa merusak tema dan aplikasi yang sudah ada
    • “Snap to [start|center|end]” di components/carousel/ baru pertama kali saya lihat
      Sebenarnya apa itu snap dan bagaimana cara kerjanya? Layar saya tidak merespons klik jari
      Saya rasa cara interaksi yang tidak dikenal bukan alasan yang baik untuk merekomendasikan pustaka elemen UI