Theo tôi, thiết kế select
chức năng trong CSS cụ thể hóa là một lý do khá tốt để không sử dụng nó.
Bạn phải khởi tạo phần tử được chọn với material_select()
, như @ littleguy23 đã đề cập. Nếu bạn không, hộp chọn thậm chí không được hiển thị! Trong một ứng dụng jQuery kiểu cũ, tôi có thể khởi tạo nó trong hàm sẵn sàng tài liệu. Đoán xem, tôi và nhiều người khác đang sử dụng jQuery những ngày này, cũng như chúng tôi không khởi chạy ứng dụng của mình trong tài liệu sẵn sàng hook.
Các lựa chọn được tạo động . Điều gì sẽ xảy ra nếu tôi đang tạo các lựa chọn động, chẳng hạn như xảy ra trong một khuôn khổ như Ember tạo ra các chế độ xem nhanh chóng? Tôi phải thêm logic trong mỗi chế độ xem để khởi tạo hộp chọn mỗi khi một chế độ xem được tạo hoặc viết một mixin chế độ xem để xử lý điều đó cho tôi. Và còn tệ hơn thế nữa: khi chế độ xem được tạo và theo thuật ngữ Ember didInsertElement
được gọi, ràng buộc với danh sách tùy chọn cho hộp chọn có thể chưa được giải quyết, vì vậy tôi cần logic đặc biệt quan sát danh sách tùy chọn để đợi cho đến khi nó được điền trước khi thực hiện cuộc gọi đến material_select
. Nếu các tùy chọn thay đổi, như họ có thể dễ dàng, material_select
không có ý tưởng về điều đó và không cập nhật menu thả xuống. Tôi có thể gọi material_select
lại khi các tùy chọn thay đổi, nhưng có vẻ như không có gì (bị bỏ qua).
Nói cách khác, có vẻ như giả định thiết kế đằng sau việc hiện thực hóa các hộp chọn của CSS là chúng đều ở đó khi tải trang và giá trị của chúng không bao giờ thay đổi.
Thực hiện . Từ quan điểm thẩm mỹ, tôi cũng không ủng hộ cách thực hiện CSS thực hiện các trình đơn thả xuống của nó, đó là tạo ra một tập hợp các phần tử bóng song song ở một nơi khác trong DOM. Được cho là, các lựa chọn thay thế như select2 cũng làm được điều tương tự và có thể không có cách nào khác để đạt được một số hiệu ứng hình ảnh (thực sự?). Tuy nhiên, đối với tôi, khi tôi kiểm tra một phần tử, tôi muốn nhìn thấy phần tử đó, chứ không phải một phiên bản bóng mờ nào đó ở một nơi khác mà ai đó đã tạo ra một cách kỳ diệu.
Khi Ember giảm chế độ xem, tôi không chắc rằng việc hiện thực hóa CSS sẽ làm giảm các phần tử bóng mà nó đã tạo ra. Trên thực tế, tôi sẽ khá ngạc nhiên nếu nó xảy ra. Nếu lý thuyết của tôi là đúng, khi các lượt xem được tạo ra và bị chia nhỏ, DOM của bạn cuối cùng sẽ bị ô nhiễm với hàng tá tập hợp các trình đơn thả xuống bóng tối không được kết nối với bất kỳ thứ gì. Điều này không chỉ áp dụng cho Ember mà bất kỳ khung công tác front-end OPA dựa trên MVC / khuôn mẫu nào khác.
Ràng buộc . Tôi cũng không thể tìm ra cách lấy giá trị được chọn trong hộp thoại để liên kết trở lại với bất kỳ thứ gì hữu ích trong một khuôn khổ như Ember gọi các hộp chọn thông qua một {{view 'Ember.Select' value=country}}
giao diện loại. Nói cách khác, khi một cái gì đó được chọn, country
sẽ không được cập nhật. Đây là một kẻ phá vỡ thỏa thuận.
Sóng . Nhân tiện, các vấn đề tương tự cũng áp dụng cho hiệu ứng "sóng" trên các nút. Bạn phải khởi tạo nó mỗi khi một nút được tạo. Cá nhân tôi không quan tâm đến hiệu ứng sóng, và không hiểu tất cả những rắc rối là gì, nhưng nếu bạn muốn có sóng, hãy lưu ý rằng bạn sẽ dành phần lớn thời gian còn lại của cuộc đời mình để lo lắng về cách khởi tạo mọi nút khi nó được tạo.
Tôi đánh giá cao nỗ lực của những người thực hiện CSS, và có một số hiệu ứng hình ảnh đẹp mắt ở đó, nhưng nó quá lớn và có quá nhiều điểm nhấn như trên nên không thể sử dụng được. Bây giờ tôi đang có kế hoạch tách CSS cụ thể hóa từ ứng dụng của mình và quay lại Bootstrap hoặc một lớp trên Suit CSS. Các công cụ của bạn sẽ giúp cuộc sống của bạn dễ dàng hơn chứ không phải khó khăn hơn.
<select class="browser-default">