Đáp lại, CSS nguyên tử ủng hộ các tên lớp ngữ nghĩa được phê bình. Trong khi điều này khiến tôi suy nghĩ, tâm trí của tôi hầu như không thay đổi
Ở đây tôi sẽ giải thích tại sao lại như vậy và giải quyết một số câu trả lời
1. “Ngữ nghĩa là một từ gây hiểu lầm”
Trong Hiểu ngữ nghĩa, Léonie Watson nói rằng ngữ nghĩa có nghĩa là
“mã nhằm phản ánh cấu trúc và ý nghĩa. ”
Đây là lý do tại sao "trình bao bọc" là ngữ nghĩa. Đó là một yếu tố bao bọc một yếu tố khác, luôn luôn. Cho dù CSS xóa các “cột” nổi trên màn hình lớn hay xếp chúng trên màn hình nhỏ, nó luôn là một trình bao bọc
Do đó, một khi HTML được viết, nó không cần phải thay đổi. Trường hợp như một lớp red
hoặc clearfix
không phải là ngữ nghĩa — ít nhất là không phải trong ngữ cảnh của HTML
Trong ngữ cảnh của HTML, một tên lớp ngữ nghĩa mô tả nó là gì, không phải nó trông như thế nào hoặc nó hoạt động như thế nào
2. “Các lớp ngữ nghĩa tạo ra các trang web tải chậm”
Tôi đã xây dựng nhiều trang web. Chúng không bao giờ chậm vì chúng tôi đã sử dụng tên lớp ngữ nghĩa. Một ví dụ gần đây về điều này là một trang web thương mại điện tử hoàn toàn tùy chỉnh, cầu kỳ và phản hồi nhanh với tổng dung lượng chỉ 48kb
Nó không chậm và tôi không chú ý nhiều đến hiệu suất CSS. Chúng tôi có thể tiết kiệm được một số tiền nhưng 48kb CSS hiện tại không gây hại cho bất kỳ ai
Về mặt lý thuyết, nếu bạn chỉ có thể sử dụng các lớp được xác định trước, thì việc đảm bảo giao diện người dùng nhất quán sẽ dễ dàng hơn. Điều này có ý nghĩa vì nó giới hạn những gì nhà phát triển có thể sử dụng. Nhưng không có gì ngăn cản ai đó thêm một lớp dưới cùng mới hoặc sử dụng sai lớp
Có lẽ có cơ hội để tạo một công cụ trái ngược với quy ước đặt tên cho công cụ này?
4. Phân tích hiệu suất CSS một cách riêng biệt
Khía cạnh nổi tiếng nhất của CSS nguyên tử là nó dẫn đến một dấu chân CSS nhỏ giúp tăng tốc thời gian vẽ lần đầu tiên. Vấn đề là điểm này luôn được thảo luận một cách cô lập khiến điểm bán hàng này tốt nhất là gây hiểu lầm
Thứ nhất, kích thước của HTML tăng lên rất nhiều. Hãy nhớ rằng CSS có thể lưu vào bộ nhớ cache và phục vụ toàn bộ trang web giống như trang tôi đã đề cập trước đó. HTML là duy nhất, năng động và thường được cá nhân hóa. Nó không thể được lưu vào bộ nhớ cache
Thứ hai, lượng CSS được lưu, ngay cả với các cơ sở mã lớn, sẽ tương đối nhỏ. Mặc dù có thể có các trang web có mười trigabyte CSS, nhưng chúng không chỉ hiếm mà còn có các giải pháp cho vấn đề này
Cuối cùng, kích thước của CSS không phải là chỉ báo hiệu suất duy nhất. Những người khác cần được xem xét một cách toàn diện
5. Các lớp nguyên tử khó đọc
Tên lớp nguyên tử thường được viết tắt. Chữ viết tắt khó đọc. Họ phải được hiểu và lập bản đồ tinh thần. Chúng ta nên cố gắng làm rõ ràng hơn là ngắn gọn
Ví dụ, 'blk' có nghĩa là gì? . Đó là văn bản màu đen hoặc nền đen
Chúng ta có thể sử dụng các tên dài dòng dễ đọc hơn, nhưng điều này làm cho HTML lớn hơn và làm giảm hiệu suất — đó là lý do đầu tiên cho việc viết tắt
Và nó không phải là về việc lưu các lần gõ phím - trình soạn thảo văn bản có tính năng tự động hoàn thành cho việc này
6. CSS nguyên tử tái tạo CSS trong HTML
CSS nguyên tử tạo lại các cấu trúc tương tự được tìm thấy trong CSS để sử dụng các lớp trong HTML. CSS được thiết kế để tạo kiểu
Thật lãng phí khi tạo lại một quy ước cho HTML khuyến khích các nhà phát triển sử dụng sai công cụ cho công việc
7. Dù sao chúng ta cũng cần tên lớp ngữ nghĩa
Để viết các bài kiểm tra chức năng và nâng cao trang web bằng JavaScript, chúng tôi sẽ cần các lớp ngữ nghĩa. Vì vậy, sẽ có sự kết hợp của các lớp dành riêng cho những thứ khác nhau
Mã không nhất quán rất khó giải thích và nếu có hai cách để làm điều gì đó, chắc chắn chúng sẽ bị lẫn lộn
8. CSS ngữ nghĩa không vi phạm 'Đừng lặp lại chính mình' DRY
Cố gắng sử dụng lại quy tắc CSS cũng giống như cố gắng sử dụng lại một biến trên các đối tượng Javascript khác nhau. Đơn giản là nó không vi phạm DRY. CSS đã tóm tắt tất cả các quy tắc cho chúng tôi để chúng tôi có thể chỉ định những gì chúng tôi muốn khi chúng tôi muốn
9. Tên lớp ngữ nghĩa dễ xóa hơn
Dễ dàng xóa một thành phần được xác định ngữ nghĩa vì CSS liên quan được kết nối rõ ràng
Trong khi CSS nguyên tử được đan xen giữa vô số phần tử khiến mã khó bị xóa
Trước khi xóa CSS liên quan, bạn cần xem xét từng lớp trên mọi thành phần trong thành phần, để xác định xem nó có được sử dụng ở nơi khác không. Chỉ sau đó bạn mới có thể quyết định xem bạn có thể xóa nó không
Code tốt dễ xóa vì không ăn nhập với nhau
10. CSS nguyên tử là một mẫu chống thiết kế đáp ứng
Như Ben Frain đã nói trong Atomic CSS là một Responsive Design Anti Pattern 'việc thực hiện các thay đổi rất cụ thể tại các điểm ngắt nhất định và buộc chúng vào một lớp phải được thêm vào HTML có vẻ phức tạp không cần thiết. ’
Anh ấy tiếp tục nói rằng 'bạn chắc chắn sẽ kết thúc với một loạt các lớp trong biểu định kiểu của mình đã lỗi thời. ' Tôi đồng ý
11. Khó hơn để tạo kiểu cho các lớp giả
Đối với mỗi phong cách bạn muốn thay đổi, bạn cần một tên lớp tương đương, dài dòng, khó đọc. Ví dụ .red-text-when-hover
hoặc .black-bg-when-focus
Nếu các kiểu cần thay đổi ở các điểm dừng khác nhau, điều đó thậm chí còn khó hơn. Ví dụ .red-text-when-hover-on-large-screens
12. Khó hơn để tạo kiểu dựa trên trạng thái
Xem xét một giỏ có trạng thái trống. Mỗi phong cách khác nhau do trạng thái cần có lớp riêng
13. Javascript hiện cũng cần quản lý các kiểu
JavaScript phải thay đổi một số lớp để đáp ứng với sự thay đổi trạng thái
Ví dụ: giả sử chúng ta có HTML sau
Khi người dùng nhấp vào
JavaScript cần đảm bảo đường viền trở nên dày 2px và có màu xanh lam
Tại đây, bạn cần thêm [và có thể xóa] một số khai báo kiểu bằng JavaScript. Có nghĩa là Javascript cũng phải “nhận biết phong cách”
14. Khó tạo kiểu hơn dựa trên hướng đọc
Như David Mark đã nói trên Twitter, 'luôn luôn, "kéo sang trái" chứa float. ngay trong cấu hình RTL. Đó là một manh mối về lý do tại sao nó không có ý nghĩa. ’
15. Khó tăng cường hơn
Nếu chúng tôi muốn sử dụng @supports
, chúng tôi sẽ cần một
0
16. Khó thay đổi cơ chế bố cục hơn
Như Ben Frain đã nói trong cùng một bài báo 'giả sử […] chúng tôi thay đổi sản phẩm của mình […] từ bố cục dựa trên float sang bố cục dựa trên Flexbox. Bây giờ chúng tôi có gấp đôi gánh nặng bảo trì. ’
17. Khó khắc phục sự cố Internet Explorer hơn
Đôi khi chúng tôi thêm CSS có điều kiện để sửa lỗi Internet Explorer. Chúng tôi không thể nhắm mục tiêu tên lớp nguyên tử để làm điều này
18. Các lớp nguyên tử gây hiểu lầm và dư thừa
Ví dụ:
1 được sử dụng để xóa các phần tử con nổi. Tuy nhiên, ở màn hình nhỏ, các con được xếp chồng lên nhau chứ không nổi. Điều này gây hiểu lầm cho các nhà phát triển và dư thừa cho người dùng
19. Mọi phần tử đều cần các lớp
Với CSS nguyên tử, mọi phần tử đều cần một số lớp. Nhưng đôi khi chúng ta không cần thêm hook, vì chúng ta có thể làm điều này.
0 hoặc cái này.
1
Ngoài ra, ví dụ, Markdown buộc chúng ta phải định kiểu các phần tử thông qua một tổ tiên chung với tên lớp ngữ nghĩa
20. Nó làm cho thanh tra ồn ào
Thật khó để tìm ra nơi một thành phần bắt đầu và kết thúc bởi vì không có gì để phân định nó trong HTML. Nội dung bị xáo trộn và thanh tra có nhiều dòng mã hơn để xem xét
21. Thật khó để tìm thấy HTML
Thật khó để tìm kiếm cơ sở mã cho một phần tử cụ thể vì tên lớp nguyên tử không phải là duy nhất cho các phần tử cụ thể. Mặc dù cấu trúc tệp tốt và tạo khuôn mẫu giúp ích, nhưng việc phải dựa vào nó không phải là lý tưởng
22. “Chuyển đổi giữa HTML và CSS rất khó”
Trong tất cả những việc mà các nhà phát triển phải làm, việc nhấn CMD+TAB hầu như không tốn nhiều công sức. Và trên thực tế, cách duy nhất để bạn không phải chuyển sang tệp CSS [hoặc tài liệu] là ghi nhớ mọi tên lớp có sẵn
Có thể sử dụng lại CSS trong các dự án là một ý tưởng hay nếu các trang web của bạn trông giống nhau. Nhưng hầu hết các trang web được gắn thương hiệu duy nhất để trông khác biệt
24. Thật khó để tạo chủ đề CSS
Khi tôi nghiên cứu giải pháp nhãn trắng cho một số trang web thương mại điện tử, đó là HTML được sử dụng lại chứ không phải CSS. Đó là bởi vì HTML tương tự, không phải CSS
25. “Các lớp ngữ nghĩa dài hơn các tên lớp nguyên tử”
Đây là một đoạn CSS nguyên tử điển hình từ một trang web có kiểu dáng cơ bản
Tôi chưa bao giờ thấy một tên lớp ngữ nghĩa gần như thế này
Tóm lược
Trong nhiều trường hợp, CSS nguyên tử sẽ giảm kích thước tệp CSS của bạn. Đó là điều được mong đợi. Giống như nếu tôi quyết định nội tuyến tất cả các kiểu, tôi sẽ mong đợi kích thước của tệp CSS bằng 0
Vấn đề là điều này giới thiệu các vấn đề khác không nên bỏ qua. Hiệu suất chỉ là một vấn đề khi nó trở thành một vấn đề. Có thể có nhiều yếu tố để xem xét
Tôi không nói rằng hãy chờ đợi khi có vấn đề xảy ra, nhưng tôi không nói rằng chúng ta nên loại bỏ các kỹ thuật đã được thử nghiệm, thử nghiệm và áp dụng công nghệ như CSS ngữ nghĩa.
Có nhiều cách khác để làm cho trang web tải nhanh hơn liên quan đến CSS. Ví dụ: chúng tôi không phải tải toàn bộ CSS của trang web cùng một lúc. Chúng tôi có thể tải dần dần CSS và bộ đệm dành riêng cho từng trang
Tập trung vào CSS không nhất thiết là nơi năng lượng của chúng ta được sử dụng tốt nhất. Có lẽ trang có quá nhiều thứ. Có lẽ thiết kế trực quan là lãng phí và không mang lại lợi ích cho người dùng. Bạn có thể đang sử dụng một khung, CSS hoặc cách khác mà bạn không cần
Nói chung, việc phải điều hướng theo cách của chúng tôi thông qua tất cả các sự đánh đổi để loại bỏ một số CSS, điều này làm tăng đáng kể kích thước của HTML, chỉ là đánh đổi một vấn đề cho một số vấn đề lớn hơn khác
Trong hầu hết các trường hợp, chúng ta sẽ cần các lớp ngữ nghĩa để thực hiện công việc bất kể. Chúng tôi cũng có thể sử dụng chúng cho CSS
Đăng ký nhận bản tin của tôi
Tham gia cùng hơn 5000 người đăng ký nhận các bài viết mới nhất của tôi qua email về thiết kế dựa trên nền tảng cơ bản, tránh sự phức tạp và phù hợp với mọi người