Bạn không cần JavaScript cho việc đó

 (htmhell.dev)
3 điểm bởi GN⁺ 2023-12-03 | 1 bình luận | Chia sẻ qua WhatsApp
  • Khi triển khai tính năng web, sẽ có lợi hơn nếu trước tiên cân nhắc các công nghệ ít mạnh hơn theo thứ tự HTML, CSS, rồi JavaScript để giảm lỗi tải và vấn đề về khả năng truy cập
  • JavaScript có thể điều khiển trực tiếp hành vi của trình duyệt, nhưng vì cần thêm tài nguyên và có khả năng phát sinh lỗi nên rất dễ loại trừ người dùng bàn phím và công nghệ hỗ trợ
  • Những tính năng trước đây cần JavaScript như công tắc checkbox, datalist, input type="color", details/summary, dialog giờ đây phần lớn đã có thể thực hiện bằng tính năng sẵn có của HTML/CSS
  • Các tính năng khai báo của HTML và CSS cho phép trình duyệt đảm nhiệm hành vi native, tùy chọn môi trường người dùng và hỗ trợ khả năng truy cập, nhờ đó cung cấp mặc định tốt hơn
  • Ngay cả khi cách triển khai JavaScript quen thuộc vẫn tiếp tục hoạt động, bạn vẫn nên định kỳ kiểm tra các lựa chọn thay thế HTML/CSS hiện đại, và khi thay đổi thì cần kiểm thử khả năng truy cập cùng lúc

Quy tắc đặc quyền tối thiểu

  • Quy tắc đặc quyền tối thiểu là nguyên tắc phát triển web khuyên chọn ngôn ngữ ít mạnh nhất nhưng vẫn đạt được mục tiêu
  • Trên web, nguyên tắc này thường được áp dụng bằng cách ưu tiên cân nhắc HTML trước CSS, và CSS trước JavaScript
  • JavaScript là công nghệ đa năng nhất trong ba công nghệ, nhưng cũng đi kèm nhiều gánh nặng hơn
    • Có thể bị hỏng
    • Có thể tải thất bại
    • Cần thêm tài nguyên để tải xuống, phân tích và thực thi
    • Dễ loại trừ người dùng bàn phím và người dùng công nghệ hỗ trợ
  • Khác với JavaScript mang tính mệnh lệnh, HTML và CSS hoạt động theo kiểu khai báo
    • Nhà phát triển cho trình duyệt biết mình muốn gì, còn cách triển khai sẽ do trình duyệt chọn
    • Trình duyệt có thể chọn cách xử lý hiệu quả hơn
  • Khi trình duyệt xử lý các tính năng HTML/CSS, điều đó có thể có lợi hơn về hiệu năng, hành vi native, phản hồi theo thiết lập người dùng và khả năng truy cập
    • Tuy vậy, khả năng truy cập không phải lúc nào cũng tự động được đảm bảo

Những tính năng trước đây cần JavaScript

  • Các nhà sản xuất trình duyệt và người viết đặc tả đã dần chuyển những tính năng từng cần JavaScript sang CSS và HTML trong vài năm qua
  • Web duy trì khả năng tương thích ngược, nên một cách triển khai đã học từ trước rất dễ ở lại trong hộp công cụ và được tái sử dụng lặp lại
  • Ngay cả khi bạn biết một tính năng nào đó cần JavaScript, thỉnh thoảng vẫn nên kiểm tra xem hiện tại có còn như vậy không để tạo ra website tốt hơn

Công tắc tùy biến tạo bằng checkbox

  • Công tắc tùy biến có thể được triển khai bằng checkbox mặc định và CSS thay vì div, trình xử lý onclick và trạng thái nội bộ
  • Khi đặt <input type="checkbox"> bên trong <label>, trình duyệt sẽ liên kết hai phần tử này
    • Nhấp vào bất kỳ đâu trên nhãn cũng sẽ bật/tắt checkbox
    • Không cần trình xử lý onclick riêng
  • appearance: none dừng việc trình duyệt render control form mặc định và cho phép tự tạo kiểu
    • Có thể trang trí chính input như nền của công tắc
    • Có thể dùng ::before làm chấm bên trong chuyển trạng thái
  • Pseudo-class :checked cho phép thay đổi màu nền và vị trí của ::before theo trạng thái đã chọn
  • Với người dùng bàn phím, cần có chỉ báo focus
    • Không nên ẩn focus bằng outline: none
    • :focus-visible có thể hiển thị vòng focus đẹp mắt chỉ khi tương tác bằng bàn phím
    • outline-offset cho phép điều chỉnh viền focus ra ngoài hoặc vào trong phần tử
  • input:focus { outline-color: transparent; } có thể làm viền trong suốt ở tình huống thông thường, nhưng trong chế độ tương phản cao sẽ lại hiển thị theo màu người dùng chọn
  • Có thể xem thêm về chế độ màu cưỡng bức tại forced colors explained

Tự động hoàn thành native với datalist

  • datalist là tính năng gợi ý tự động tích hợp sẵn trong trình duyệt, hiển thị danh sách tùy chọn khi người dùng nhập liệu
  • Cấu hình rất đơn giản
    • Đặt id và nhiều option trong phần tử datalist
    • Liên kết nó với datalist tương ứng bằng thuộc tính list của input
  • Khi người dùng nhập, trình duyệt sẽ hiển thị dropdown và tự động lọc các tùy chọn phù hợp với nội dung nhập
  • Vì đây là trường nhập liệu cơ bản, người dùng vẫn có thể nhập trực tiếp giá trị không có trong danh sách
  • Sau khi chọn trường nhập, có thể duyệt danh sách bằng phím mũi tên hoặc nhấp vào biểu tượng dropdown mà trình duyệt thêm vào để xem toàn bộ tùy chọn

Bộ chọn màu mặc định của input type="color"

  • Chỉ với một dòng <input type="color">, bạn có thể dùng bộ chọn màu native của trình duyệt
  • Nó có thể thay thế nhiều UI canvas và slider được tạo bằng JavaScript
  • Bộ chọn màu native của các trình duyệt Chromium cho phép chọn màu không chỉ trong trang mà còn ở bất kỳ đâu trên màn hình
  • Vì không phải mọi người dùng đều có thể sử dụng bộ chọn màu của trình duyệt, tốt hơn là nên cung cấp thêm cách chọn màu khác, chẳng hạn như nhập văn bản thông thường

Accordion với details và summary

  • Các phần tử details và summary cung cấp accordion thu gọn/mở rộng nội dung như một tính năng mặc định của trình duyệt
  • Hành vi mặc định rất đơn giản
    • Nội dung bên trong details, trừ summary, sẽ bị ẩn
    • Khi người dùng nhấp vào summary, phần nội dung còn lại sẽ được hiển thị
  • Thuộc tính open xác định trạng thái mở ban đầu
    • Đây không phải giá trị cố định sau khi người dùng tương tác; nếu người dùng mở hoặc đóng thì trạng thái sẽ thay đổi
  • Có thể tạo kiểu marker tam giác mặc định bằng summary::marker
    • Có thể thay nội dung bằng emoji hoặc thành phần khác tương tự
    • Có thể điều chỉnh màu nền, ảnh nền, cỡ chữ, v.v.
    • Nhiều thuộc tính CSS sẽ không hoạt động, và việc tạo kiểu theo kiểu đặt nó ở vị trí hoàn toàn khác thì bị hạn chế
  • Trên Safari cần pseudo-element ::-webkit-details-marker
  • Việc thay đổi nội dung marker có thể ảnh hưởng đến cách công nghệ hỗ trợ thông báo accordion, nên có thể tham khảo details/summary inconsistencies
  • summary có thể nhấp được, nhưng mặc định không hiện con trỏ pointer như liên kết và cũng không trông như nút, nên cần thêm trạng thái hover và focus để thể hiện khả năng nhấp

Modal với dialog

  • alert(), prompt(), confirm() có thể dùng để thông báo hoặc lấy xác nhận từ người dùng, nhưng chúng chặn main thread và khó tạo kiểu theo thiết kế
  • Nếu tự làm dialog thì việc xử lý khả năng truy cập sẽ trở nên phức tạp
    • Cần giữ focus bên trong dialog
    • Cần thông báo rằng đây là modal
    • Cần ngăn người dùng vô tình thoát ra ngoài
    • Có thể xung đột với widget có z-index rất cao
  • Phần tử dialog của trình duyệt cung cấp dialog native
  • Hiện tại vẫn cần JavaScript để mở dialog
    • Đã có thay đổi đang được tiến hành để mở mà không cần JavaScript, nhưng vẫn chưa được đặc tả hoặc triển khai đầy đủ
    • Có thể mở dialog bằng hàm showModal()
  • dialog mở trong top layer
    • Top layer là một lớp mới tách biệt khỏi HTML
    • Các phần tử trong lớp này luôn hiển thị phía trên, bất kể z-index hay việc lồng các stacking context
    • Có thể tham khảo giải thích khái niệm tại Top layer của MDN
  • dialog không cung cấp UI đóng mặc định, nên bạn phải tự thêm UI
    • Khi form method="dialog" được submit, trình duyệt sẽ đóng dialog
    • Nếu đặt value khác nhau cho hai nút submit, có thể dùng nó như một dialog xác nhận
    • Trong sự kiện close, có thể đọc dialog.returnValue để biết giá trị nút mà người dùng đã nhấn
    • Dữ liệu form bổ sung có thể đọc bằng FormData
  • dialog::backdrop là lớp nằm giữa dialog và phần còn lại của trang
    • Có thể làm tối hoặc làm mờ nền để hướng sự chú ý của người dùng vào dialog
    • Vì trình duyệt tự bố trí lớp này, bạn không cần tự xử lý cuộn trang, phần tử cố định hay thay đổi kích thước trình duyệt

Những tính năng có thể làm với ít JavaScript hơn

  • Còn nhiều tính năng khác có thể giảm dùng JavaScript
    • Cuộn mượt native với scroll-behavior: smooth
      • Nên kèm điều kiện chỉ dùng khi prefers-reduced-motion: no preference phù hợp
    • Carousel native với scroll-snap
    • Phần tử “in-view” với position: sticky
    • Container query
  • Trong tương lai cũng sẽ có thêm tính năng mới
    • Animation dựa trên cuộn
    • Bố cục Masonry với grid-template-rows: masonry mà không cần masonry.js
    • select có thể tạo kiểu hoàn toàn thông qua phần tử selectlist mới
    • Bộ chọn :has() có thể giảm một nhóm mã chọn phần tử bằng JavaScript
  • Có thể xem thêm nội dung liên quan trong video thuyết trình Stop Using JavaScript for That: Moving Features from JS to CSS and HTML.
  • Khi thay một cách triển khai hiện có đã được kiểm chứng bằng cách mới, đặc biệt cần kiểm thử khả năng truy cập để không loại trừ bất kỳ ai

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-12-03
Ý kiến trên Hacker News

  • Điểm bài viết này bỏ sót là lý do dùng JavaScript ở những chỗ như vậy là vì khả năng tương thích tốt hơn
    JavaScript mới có thể được transpile, nhưng polyfill cho các tính năng CSS hay HTML còn thiếu thì khó hơn nhiều, và trong một số trường hợp là không thể. Hơn nữa, các polyfill đó rốt cuộc cũng dùng JavaScript
    Ngay cả MDN cũng có nhiều cảnh báo với appearance, thậm chí appearance: none, rằng cần kiểm thử thật kỹ. Nếu chỉ hỗ trợ trình duyệt mới nhất thì có thể ít quan trọng hơn, nhưng các phiên bản Safari cũ tồn tại lâu hơn ta tưởng
    datalist không làm gì trên Firefox Android, và với tôi nó chỉ hiện như một ô nhập không có cả gợi ý
    Trình chọn màu thì hay, nhưng cực kỳ không chuẩn nên là vấn đề nghiêm trọng với phần lớn doanh nghiệp. Không chỉ nhà thiết kế phàn nàn, mà bộ phận hỗ trợ khách hàng cũng khó giúp người dùng hơn. Chromium còn cho phép lấy màu từ trang hoặc chọn màu tùy ý, nhưng Firefox Android chỉ cho khoảng cầu vồng, xám, đen trắng
    Bản thân bài viết cũng thừa nhận sự không nhất quán của details và dialog. Hy vọng một ngày nào đó các trình duyệt không hỗ trợ những tính năng này, hoặc không hỗ trợ nhất quán với nhau, sẽ không còn được dùng nữa; nhưng trong thời gian tới, có lẽ những phần tử này chỉ nên dùng trong các side project nơi có thể kiểm soát hoàn toàn trình duyệt được hỗ trợ

    • Tôi khó đồng ý với nhận định rằng trình chọn màu là không chuẩn
      Khi nhấn nút trên iPhone, trình chọn màu native thật của hệ thống sẽ hiện ra. Đó chính là control do OS cung cấp, xuất hiện trong nhiều ứng dụng, và tôi thích nó hơn hẳn so với thứ tự chế
    • Khả năng tương thích tốt hơn chỉ đúng khi giả định rằng mọi người dùng đều phải dùng JavaScript
      Tôi thích web không JavaScript hơn nhiều, và nó còn ảnh hưởng đến thời lượng pin laptop ở mức vài giờ. Một số trang không tương thích với kiểu đó nên chỉ render trang trắng, hoặc phàn nàn rằng cần JavaScript để hiển thị văn bản
      Ngược lại, Amazon còn có một bản sao trang thương mại điện tử không JavaScript, cho thấy ngay cả việc khổng lồ như vậy cũng có thể làm mà không cần JavaScript
    • Phần tử dialog giờ đã có phạm vi hỗ trợ khá sâu, và polyfill dành cho vài phần trăm người dùng Firefox hay Safari đời 2021 cũng đủ ổn
      Nếu làm modal thì tôi rất khuyến nghị, cải thiện về khả năng truy cập là rất tốt
    • Việc bộ phận hỗ trợ khách hàng khó giúp người dùng hơn là vấn đề lớn
      Ở công ty cũ chúng tôi đã chủ động thảo luận vấn đề này, và quyết định dùng triển khai bằng JS thay cho những thứ như datalist. Đặc biệt datalist thì đã thử, nhưng kết quả quá thiếu nhất quán nên phải bỏ
      Cuối cùng do sự không nhất quán giữa các trình duyệt, chúng tôi thậm chí đã ngừng hỗ trợ ngoài Chrome
    • Không. JavaScript khi lỗi thì lỗi hoàn toàn, đến mức chính nội dung cũng biến mất
      Các ví dụ HTML có thể trông sai trên trình duyệt cũ, nhưng nội dung thực vẫn còn đó. JS thì đơn giản là không có gì cả. Nó phá vỡ hoàn toàn khả năng truy cập
      Với HTML, trình đọc màn hình ít nhất còn có thể đọc được, nhưng nội dung tạo bằng JS lại ngăn điều đó. Khi JS không thể chạy JS, không polyfill hay JS nào khác có thể cứu JS. Nó phải “hoạt động” ngay từ đầu thì mới ổn cho khả năng truy cập, và trong trường hợp đó thì luận điểm ban đầu trở nên vô nghĩa

  • Tôi không biết Datalist, nhưng ít nhất trên Chrome Android có vẻ nó không hoạt động đúng
    Các tùy chọn có hiện trong vùng bàn phím nơi gợi ý tự động hoàn thành xuất hiện: https://imgur.com/a/Ecb4503
    Đây là lần đầu tôi thấy cách đó trong control biểu mẫu của UI web di động, và ngoài trường hợp ứng dụng tự động điền mật khẩu dùng cùng không gian này thì tôi chưa từng thấy
    Không tệ. Nó tốt hơn nhiều so với việc cuộn một dropdown JS tùy biến làm vụng về, nhưng tôi không chắc người dùng phổ thông sẽ tự tìm ra cách dùng nó. Vì vậy trên di động, tôi cho là về cơ bản không có hy vọng
    Trên Firefox Android thì hoàn toàn không được hỗ trợ: https://caniuse.com/?search=datalist

    • Các nhà làm trình duyệt, không thể cho phép style dropdown của datalist được sao?
      Tham khảo: https://adrianroselli.com/2023/06/under-engineered-comboboxe...
    • Đây là lý do những giải pháp kiểu này mất rất lâu mới được dùng rộng rãi
      JavaScript được chuẩn hóa khá tốt, còn HTML và CSS thì tương đối kém hơn
    • Tôi tò mò không biết thêm autocomplete="off" vào phần tử input có làm hành vi thay đổi không
      Dù sao thì để dùng datalist cho đúng cũng cần làm vậy. Nếu không, lịch sử các giá trị đã chọn sẽ bị thêm vào danh sách dropdown. Tôi quan sát thấy điều này trên Chromium
      Ngoài ra, trong một số tình huống như khi có giá trị mặc định được đặt, datalist vẫn cần JS. Tôi đã ghi lại các cách vòng tránh và ghi chú về hành vi đặc thù theo trình duyệt trong mã của website LibreOffice mới: https://git.libreoffice.org/infra/libreofficeorg/+/835a5cc59...
      Tin tốt là một lập trình viên Firefox dự định xem xét cải thiện hành vi của datalist, nên có thể danh sách sẽ hiển thị chỉ với một cú nhấp
    • Bạn có nhìn phía trên bàn phím không?
      Trường hợp của tôi thì các tùy chọn hiện ở vùng phía trên bàn phím, nơi thường hiển thị gợi ý từ
    • Việc tùy chọn datalist hiện bên trong bàn phím là thay đổi mới xuất hiện trong vài tháng gần đây
      Trước đây nó “bình thường”, nhưng có vẻ ai đó muốn thay đổi chỉ để thay đổi

  • Dùng cuộn mượt gốc bằng scroll-behavior: smooth thì làm ơn chỉ nên dùng có giới hạn
    Thực ra trong hầu hết trường hợp sử dụng, đây không phải ý hay và thường có tác dụng phụ không mong muốn
    Người ta nói có thể tạo carousel gốc bằng scroll-snap, nhưng carousel vẫn là một ý tưởng tệ nên phạm vi sử dụng chính đáng của scroll-snap cực kỳ hạn chế
    Các trang dùng hoạt ảnh dựa trên cuộn thường sẽ tốt hơn nếu bỏ nó đi

    • Trọng tâm của bài này không phải là chỉ thị phải dùng yếu tố thiết kế nào, mà là chỉ ra cách triển khai những thiết kế đó theo hướng thân thiện với người dùng hơn
      Cuộn mượt là ví dụ điển hình. API gốc cho phép người dùng dừng bất cứ lúc nào. Phần lớn cách triển khai bằng JS thì giật lag khủng khiếp và khiến người dùng khổ sở
      Bạn hoàn toàn có thể chỉ trích lựa chọn thiết kế, nhưng nếu không đưa ra lý do thực tế cho câu “carousel vẫn tệ” thì khó mà mong người khác lắng nghe
    • Tôi cũng ghét carousel
      Nhưng trang chủ Amazon dùng carousel rất nổi bật, và tôi biết Amazon A/B test các biến thể trang chủ rất quyết liệt. Vậy có khả năng carousel cho kết quả tốt trong thử nghiệm, và khá khó để nói nó thật sự “tệ” theo một nghĩa phổ quát, khách quan nào đó
    • Vì sao cuộn mượt gốc trong hầu hết trường hợp lại không phải ý hay?
      Thường thì ngay sau khi triển khai anchor kiểu mục lục, ít nhất tôi cũng thêm nó vào
    • Dù sao thì đúng là những thứ đó không cần JavaScript

  • Thật ngạc nhiên là đến năm 2023 mà chúng ta vẫn còn tranh cãi về form và UX thông thường khi người dùng nhập dữ liệu
    Chỉ cần nhìn các bình luận liên quan đến datalist và bộ chọn màu là thấy, tôi không hiểu vì sao đây vẫn chưa phải một lĩnh vực đã được giải quyết
    Trước đây từng có nỗ lực giải quyết một lần bằng XForms, nhưng nó không được triển khai trong trình duyệt
    Thay vào đó, gần như mọi framework component CSS/JS đều tự cung cấp một bộ phần tử form hạn chế với ngữ nghĩa khác nhau

    • Hệ quả của việc từ chối công nghệ XML là web bị định sẵn phải tái triển khai mãi những phiên bản tệ hại của các thứ XML từng cung cấp
      Có vẻ chúng ta sẽ phải tự triển khai các control UI cơ bản suốt đời
    • Chuyện này đã được giải quyết rồi. Cứ đưa vào React rồi sống tiếp là được
      Việc “chưa được giải quyết” chỉ trông như vậy vì một số người có nỗi ám ảnh kỳ lạ với việc tránh JavaScript nên cố nhồi nhét các phương án thay thế nửa vời
    • Form “đã được giải quyết” nghĩa là gì?
      Nếu bạn chịu dừng ở công nghệ cơ bản và nhàm chán thì nó đã được giải quyết rồi. Nhưng nếu cứ khăng khăng giải lại bằng React, rồi lại giải bằng React hooks, rồi giải lại vô tận, thì nó thành chưa được giải quyết
    • Vì CSRF, có vài việc con người làm được nhưng chúng ta thì không
      Ý định không phải thứ có thể được chương trình xác định, nên trong một số tình huống không thể có các tính năng hay ho
      Ở form phức tạp gần nhất tôi làm, tôi đã phải khiến sự kiện click kích hoạt việc submit form khá trực tiếp để trình duyệt cho phép
    • Form chưa được giải quyết vì ở đâu đó có người muốn gửi những thứ khác nhau bằng form
      Tôi chưa từng yêu cầu cách gửi màu sắc qua trang web

  • Nếu dùng details thay cho JavaScript, Ctrl+F có thể tìm kiếm bên trong nó và mở nó ra
    Accordion bằng JavaScript thì không mở được như vậy

    • Dùng hidden="until-found" thì accordion dựa trên JS hoặc nội dung ẩn khác cũng có thể làm được, nhưng tiếc là hiện giờ chỉ có trên trình duyệt dựa trên Chromium: https://developer.chrome.com/articles/hidden-until-found/
    • Có cách nào khác để ẩn nhưng vẫn cho phép tìm kiếm không?
    • Tôi vừa gặp vấn đề tương tự khi lướt qua tài liệu

  • Tôi đồng ý với phần lớn, nhưng chưa dùng dialog đủ nhiều nên không có ý kiến, còn datalist thì tôi cho là không phải lựa chọn hợp lệ nếu không phải công cụ nội bộ
    Nó xấu, những gì làm được bị hạn chế và cũng không tùy biến style được. Đây là vấn đề của phần lớn lập luận “cứ dùng chức năng tích hợp sẵn”. date picker cũng vậy
    Không chỉ giá trị mặc định không tốt, mà dù muốn đổi cũng không đổi được. Khi bạn đụng một trong vô số bức tường về thay đổi style hoặc hành vi, chẳng hạn muốn tuần bắt đầu từ thứ Hai cũng không được. Khi đó lựa chọn thường chỉ còn là thư viện thay thế hoàn toàn dùng JS
    Tôi ủng hộ dùng lựa chọn nhẹ hơn và cũng đồng ý với phân tầng HTML > CSS > JS, nhưng để có UI đẹp và đủ chức năng mong muốn, đôi khi JS là câu trả lời duy nhất

    • Khi triển khai hộp gợi ý tìm kiếm, tôi từng nghĩ datalist có thể hữu ích
      Nó hoạt động tốt cho đến thời điểm bạn muốn hiển thị các tùy chọn không bắt đầu đúng bằng nội dung đã nhập. Ví dụ nếu trong input có lỗi chính tả thì tùy chọn sẽ không hiện
      Không có cách nào buộc hiển thị tất cả mục, nên cuối cùng tôi chọn danh sách có thứ tự
    • Luôn đáng nhớ rằng cách mở rộng markup ngữ nghĩa tích hợp sẵn bằng JS là một hướng tiếp cận hướng tới tương lai
      Khi tôi bắt đầu làm web, thay đổi có thể mất tới 10 năm. IE6 cũng níu chân tất cả chúng ta, nhưng khi đó w3c cũng khá yếu. Giờ thì thay đổi nhanh hơn
      Năm sau, việc tùy biến style cho datalist có thể sẽ khả dụng không cần tiền tố trên ba trình duyệt lớn, nhưng nếu bị khóa vào giải pháp JS tùy chỉnh thì doanh nghiệp sẽ không trả chi phí xây dựng lại
      Nếu mở rộng tính năng gốc bằng JS, khi hỗ trợ đã đủ tốt, bạn có thể gỡ JS với chi phí thấp. Ở đâu control gốc chấp nhận được thì dùng ngay bây giờ, còn JS áp dụng như polyfill
    • Với ngày bắt đầu tuần hoặc input[type=date], phần lớn tùy chỉnh thường được đề xuất thực ra tốt hơn là không do lập trình viên kiểm soát
      Lịch phù hợp để hiển thị nên phụ thuộc vào locale. Nền tảng của người dùng đã có khả năng thiết lập và hiển thị theo cách mà người dùng nhiều khả năng sử dụng hiệu quả nhất
      Bộ chọn ngày của nền tảng tốt hơn thứ kỳ quặc tự làm

  • Nút chuyển đổi đó thật sự rất hay
    Có vẻ các lập trình viên meme frontend đang nổi giận với bài viết này, nhưng ý chính thì đúng. Tại sao lại làm quá nhiều trang web ngớ ngẩn bằng JS như vậy? Nếu mọi người chỉ tuân theo một chuẩn như HTML thì mọi thứ có thể nhất quán, và những thứ như khả năng truy cập hay dịch thuật cũng có thể được hỗ trợ dễ dàng
    Dạo này vào các trang web thì vì mọi thứ đều được tải động trong một trang duy nhất nên ngay cả nút quay lại cũng không hoạt động

    • Ngay cả khi mọi người tuân theo một chuẩn như HTML, các nhà sản xuất trình duyệt vẫn phải triển khai một cách nhất quán
      Và vẫn còn vấn đề “chờ mọi người cập nhật”: sau khi một tính năng mới được đưa vào, có thể mất nhiều năm cho đến khi nó được hỗ trợ đủ rộng để trở nên hữu ích
      Nhìn chung tôi đồng ý rằng có rất nhiều cách triển khai tệ và các cơ chế JavaScript phức tạp. Có khá nhiều giải pháp chuẩn hóa để duy trì chức năng quay lại ngay cả với nội dung động, và theo tôi biết các web framework phổ biến hỗ trợ mặc định
    • Họ thật sự đang nổi giận sao?
      Tôi đã đọc các bình luận hàng đầu nhưng không thấy mấy thứ có thể gọi là giận dữ, chỉ thấy mọi người nêu những điểm hợp lý về hỗ trợ trình duyệt

  • Đây đúng là một bước đi đúng hướng, nhưng CSS cũng là một công cụ khác mà những “artistes” theo cách nói của Philip Greenspun lạm dụng để tạo ra các trang khó đọc
    Tôi không phải người ủng hộ Gemini, nhưng về cơ bản mọi khía cạnh của layout và typography nên được trả lại cho trình duyệt và do người dùng kiểm soát. Các nhà thiết kế đã liên tục chứng minh rằng không thể tin tưởng giao việc đó cho họ

  • Tôi thích tinh thần của nó, công tắc cũng đẹp, và summary/details đôi khi cũng hữu ích
    Nhưng phần tử datalist gần như không phải lựa chọn thực tế cho các mục đích vượt ra ngoài đồ chơi hay prototype

  • Những thứ “không cần JS, chỉ CSS là đủ” mà tôi thích là sidebar drawer và carousel
    Thư viện component TailwindCSS tên DaisyUI cũng có các component dùng được ngay
    https://daisyui.com/components/drawer/
    https://daisyui.com/components/carousel/

    • Làm sao thông báo drawer cho screen reader?
      Drawer và các nội dung khác xuất hiện trên trang cần được thông báo, và bên cạnh đối tượng điều khiển phải có trạng thái aria-expanded
      Đây vẫn là một câu hỏi thật sự. Có thể có cách, hoặc các lập trình viên collectively cho rằng nó không quan trọng. Nhưng các kiểm toán viên có lẽ sẽ không đồng ý
    • Nhìn các framework kiểu này lúc đầu tôi luôn thấy kỳ vọng, nhưng giống như mọi framework khác tôi từng thử, DaisyUI cũng có nhiều vấn đề trên iOS Safari và các trình duyệt khác
      Có vẻ tác giả của các framework này đánh giá quá thấp lượng kiểm thử cần thiết để khiến chúng thực sự hoạt động trên nhiều trình duyệt
      Khi có nhiều component như vậy, lại còn hỗ trợ theme, thì cũng khó đảm bảo có thể sửa mà không phá các theme và ứng dụng hiện có
    • “Snap to [start|center|end]” trong components/carousel/ là lần đầu tôi thấy
      Rốt cuộc snap là gì và hoạt động thế nào? Màn hình của tôi không phản hồi với thao tác nhấn bằng ngón tay
      Tôi không nghĩ một kiểu tương tác chưa được biết đến là cơ sở tốt để khuyến nghị một thư viện phần tử UI