Miriam Suzanne là một tác giả, nghệ sĩ và nhà phát triển web tại Denver, Colorado. Cô hiện đang nghiên cứu các thông số kỹ thuật thú vị của CSS như Truy vấn vùng chứa và Lớp tầng.
Bài đăng này là một phần của Designcember. Một sự kiện thiết kế web do web.dev mang đến cho bạn.
Miriam Suzanne là một tác giả, nghệ sĩ và nhà phát triển web ở Denver, Colorado. Cô là đồng sáng lập của OddBird (một công ty quảng cáo trên web), người viết nội dung cho CSS Tricks, thành viên nhóm cốt lõi Sass và Chuyên gia được mời của W3C trong Nhóm làm việc CSS. Gần đây, cô ấy tập trung vào việc phát triển các tính năng CSS mới như Lớp tầng, Truy vấn vùng chứa và Phạm vi. Khi không có mạng, Miriam là một tiểu thuyết gia, nhà soạn kịch và nhạc sĩ đã xuất bản. Chúng ta đã nói về công việc của cô ấy với Sass và CSS.
Rachel: Lần đầu tiên tôi biết về sản phẩm của bạn là nhờ khung lưới Susy của bạn. Điều gì khiến bạn tạo ra sản phẩm đó?
Miriam: Năm 2008, bố cục trên web là một trải nghiệm rất khác. Các nhà phát triển đã chuyển từ bố cục bảng sang các lưới nổi có ngữ nghĩa hơn (nhưng vẫn đột phá). Đã có sự phát triển vượt bậc của các "khung lưới" có một kích thước phù hợp với tất cả 12 cột – cung cấp một lưới được xác định trước (thường là tĩnh) với một tập hợp các lớp CSS được xác định trước. Nếu cần có tính năng tuỳ chỉnh khác, bạn đã có thể tuỳ chỉnh. Rõ ràng là các trang web cần tăng tốc độ phản hồi, nhưng truy vấn đa phương tiện vẫn chưa có sẵn và có rất nhiều vấn đề về khả năng tương thích với trình duyệt liên quan đến quảng cáo linh hoạt.
Tôi đã sử dụng cách tiếp cận Hệ thống CSS của Natalie Downe. Phương pháp này rất thông minh trong việc phản hồi cả kích thước phông chữ và kích thước khung nhìn, nhưng tôi đã thất vọng vì tất cả các vụ tấn công trình duyệt và toán học lặp đi lặp lại bắt buộc. Cùng lúc đó, Sass bắt đầu được chú ý và lựa chọn này hoàn toàn phù hợp với nhu cầu của tôi. Bản nháp đầu tiên của Susy rất đơn giản: chỉ cần một vài kiểu kết hợp để giải toán và thêm những mẹo tôi cần. Mục tiêu là tối thiểu và chỉ đưa ra mã thiết yếu. Các lưới hoàn toàn có thể tuỳ chỉnh mà không cần bất kỳ lớp nào được xác định trước.
Rachel: Anh đã chuyển đổi từ làm việc với một bộ tiền xử lý CSS sang làm việc về các thông số của CSS như thế nào? Bạn có nghĩ rằng làm việc trên bộ tiền xử lý là một nền tảng tốt để viết thông số kỹ thuật không?
Miriam: Theo kinh nghiệm của tôi, có rất nhiều điểm trùng lặp và tôi vẫn rất tích cực ủng hộ cả hai khía cạnh đó. Nhưng tôi cho rằng điều đó phần lớn nhờ vào nhóm Sass nói riêng, do Natalie Weizenbaum dẫn đầu. Họ có một tầm nhìn rất dài hạn — cố gắng phát triển các công cụ tích hợp suôn sẻ với các tiêu chuẩn web đang phát triển. Vượt ra ngoài phạm vi "tư duy nhất định" và tạo dựng tính linh hoạt lâu dài là điều cần thiết khi bạn suy nghĩ về tương lai của các tiêu chuẩn web cốt lõi.
Làm cách nào để chúng ta xây dựng các công cụ vừa đáp ứng nhu cầu và phương pháp tiếp cận đa dạng của nhà phát triển, trong khi vẫn khuyến khích và hỗ trợ khả năng tiếp cận cũng như các yếu tố quan trọng khác?
Rachel: Chúng tôi đã có nhiều tính năng trong CSS nhằm thay thế cơ bản chức năng vốn có của Sass. Có lý do chính đáng để tiếp tục sử dụng những thứ như Sass không?
Miriam: Đúng vậy, đối với một số người, nhưng không có câu trả lời chung nào ở đây. Hãy xem các biến làm ví dụ. Biến Sass có phạm vi từ vựng và được biên dịch trên máy chủ, với các cấu trúc dữ liệu được sắp xếp như danh sách và đối tượng, thao tác màu, v.v. Điều này rất phù hợp để thiết kế logic hệ thống không cần chạy trong trình duyệt.
Các biến CSS có một số điểm trùng lặp, chúng cũng có thể lưu trữ các giá trị, nhưng chúng cung cấp một tập hợp hoàn toàn khác gồm các điểm mạnh và điểm yếu dựa trên tầng. Sass không thể xử lý các thuộc tính tuỳ chỉnh và CSS thực sự không thể xử lý dữ liệu có cấu trúc. Cả hai đều hữu ích và đều có tác dụng mạnh mẽ, tuy nhiên nhu cầu cụ thể của bạn có thể khác nhau.
Tôi nghĩ sẽ thật tuyệt khi mọi người có thể loại bỏ các công cụ mà họ không cần nữa. Một số dự án có thể không yêu cầu cả biến phía máy chủ và phía máy khách. Tuyệt vời! Tuy nhiên, quá đơn giản để cho rằng chúng giống hệt nhau và một đơn giản sẽ thay thế cái còn lại. Sẽ luôn có trường hợp sử dụng để một số logic thiết kế xảy ra ở phía máy chủ và một số xảy ra ở phía máy khách – ngay cả khi chúng ta đến thời điểm mà các ngôn ngữ cung cấp các tính năng về cơ bản giống nhau. Bộ phận tiền xử lý sẽ luôn đồng hành cùng chúng tôi trong thời gian dài.
Rachel: Có điều gì khiến bạn ngạc nhiên khi tham gia nhiều hơn vào công việc xây dựng các tiêu chuẩn, hoặc bất cứ điều gì mà bạn nghĩ rằng mọi người thường có thể không biết về quy trình này không?
Miriam: Trước khi bắt đầu tham gia, quy trình tiêu chuẩn giống như một chiếc hộp đen bí ẩn và diệu kỳ, khiến tôi không rõ mình có thể mong đợi điều gì. Tôi sợ rằng mình có thể không có đủ kiến thức về nội bộ trình duyệt để đóng góp, nhưng thực tế là họ không cần thêm kỹ sư trình duyệt. Họ cần có thêm nhiều nhà phát triển và nhà thiết kế đang xây dựng các trang web và ứng dụng trong môi trường hoang dã.
Tôi ngạc nhiên khi nhận thấy rằng rất ít người có liên quan chủ yếu tập trung vào các tiêu chuẩn, nhưng cũng rất ít người trong số đó chủ yếu phát triển hoặc thiết kế trang web. W3C được tạo thành từ các "tình nguyện viên" từ các tổ chức thành viên (thường được các tổ chức đó trả tiền, nhưng không phải là công việc chính của họ) và phí thành viên không hề rẻ. Điều đó sẽ khiến người tham gia bị lệch khỏi các nhà thiết kế và nhà phát triển thường ngày, đặc biệt là những người trong chúng ta đang làm công việc khách hàng tại các công ty nhỏ hoặc làm việc tự do. Nếu tôi không tìm được nguồn vốn bên ngoài cho công việc đó, thì vai trò Chuyên gia được mời của tôi sẽ là tình nguyện viên hoàn toàn, một sở thích đắt đỏ.
Trên thực tế, quá trình này diễn ra khá cởi mở và công khai, đồng thời cần có sự tham gia của nhà phát triển. Tuy nhiên, luôn có quá nhiều cuộc trò chuyện diễn ra cùng một lúc nên bạn khó có thể tìm ra được văn bản phù hợp. Đặc biệt nếu đó không phải là công việc thường ngày.
Rachel: Truy vấn vùng chứa là giải pháp tối ưu của nhiều nhà phát triển web trong nhiều năm. Tôi rất hài lòng về kết quả mà chúng tôi đạt được. Có vẻ như rất nhiều người đang nghĩ về lợi ích của truy vấn vùng chứa, vậy bạn có cảm thấy chúng cũng có tiềm năng khai thác khả năng sáng tạo hơn không?
Miriam: Chắc chắn rồi, mặc dù tôi không coi những công cụ đó là hoàn toàn riêng biệt. Tất cả chúng ta đều có thời gian hạn chế và chúng ta đều cố gắng viết mã có khả năng bảo trì và hiệu suất cao. Khi điều gì đó khó thực hiện trên thực tế, chúng ta sẽ ít có khả năng sáng tạo với những gì có thể.
Tuy nhiên, ngành công nghiệp web hiện đang chịu sự chi phối của các doanh nghiệp lớn. Do đó, những mối quan tâm kinh doanh đó luôn được phát sóng nhiều hơn các nghệ sĩ web. Và tôi cho rằng chúng ta sẽ mất rất nhiều nếu bỏ qua tính sáng tạo trên web trong vai trò một trường hợp sử dụng chính của các tính năng. Tôi rất vui khi thấy một số nghệ sĩ CSS biểu diễn nguyên mẫu truy vấn vùng chứa. Jhey Tompkins đã xây dựng một bản minh hoạ có tính tương tác và thông minh đặc biệt thông minh về các màn hình venetian của CSS để bình luận về meme cũ chống CSS. Tôi nghĩ rằng còn nhiều điều khác để khám phá trong lĩnh vực đó và tôi rất nóng lòng được thấy những ý tưởng khác của mọi người.
Cuộc trò chuyện cũng tập trung vào các truy vấn dựa trên kích thước, là trường hợp sử dụng ban đầu, nhưng tôi rất vui được thấy mọi người làm gì với truy vấn kiểu–khả năng viết các kiểu có điều kiện dựa trên giá trị của thuộc tính hoặc biến CSS. Đây là một tính năng cực kỳ mạnh mẽ và cho đến nay hầu như vẫn chưa được khám phá. Tôi nghĩ điều đó sẽ mở ra nhiều cơ hội sáng tạo hơn nữa!
Rachel: Có điều gì mà chúng tôi chưa thể làm (hoặc có phương pháp sắp tới) trong CSS mà bạn nghĩ là sẽ hữu ích không?
Miriam: Tôi rất hào hứng về một số thông số kỹ thuật khác mà tôi đang phát triển. Các lớp tầng sẽ giúp tác giả có nhiều quyền kiểm soát hơn đối với các vấn đề cụ thể và Phạm vi sẽ giúp nhắm mục tiêu bộ chọn chính xác hơn. Nhưng cả hai đều là vấn đề tổng quan về kiến trúc. Nghệ sĩ trong tôi hào hứng hơn với những tính năng như bật/tắt CSS, một cách khai báo để tạo kiểu tương tác hoặc vùng chứa "dòng thời gian", cho phép chúng tôi chuyển đổi suôn sẻ các giá trị giữa các điểm ngắt nội dung nghe nhìn hoặc vùng chứa. Điều này có ý nghĩa rất thiết thực đối với kiểu chữ thích ứng, nhưng cũng mở ra rất nhiều cơ hội sáng tạo cho nghệ thuật và ảnh động thích ứng.
Rachel: Hiện tại có ai đang thực hiện công việc thực sự thú vị, thú vị hoặc sáng tạo trên web không?
Miriam: Ồ, tôi thậm chí còn không chắc phải trả lời câu hỏi đó như thế nào, có rất nhiều người đang làm công việc sáng tạo trong các lĩnh vực khác nhau như vậy. Có rất nhiều tiêu chuẩn thú vị đang được hoàn thiện từ cả CSSWG và Open-UI, bao gồm cả một số công việc của bạn về việc phân mảnh. Nhưng tôi thường tìm thấy nguồn cảm hứng nhiều nhất từ các nghệ sĩ web và cách mọi người sử dụng các công cụ này vào quá trình sản xuất theo những cách không liên quan trực tiếp đến hoạt động thương mại. Những người như Jhey, Lynn Fisher hoặc Yuan Chuan hay nhiều người khác đang bứt phá khỏi những giới hạn mà công nghệ web có thể thực hiện theo cách trực quan và tương tác. Ngay cả những người làm công việc nhiều hơn dựa trên kinh doanh cũng có thể học được nhiều từ kỹ thuật nghệ thuật của họ.
Tôi cũng trân trọng nghệ thuật web mang tính khái niệm hơn của những người như Ben giữ nguyên, người luôn thúc đẩy chúng ta xem xét lại những gì chúng ta muốn trên web và cụ thể là mạng xã hội. Hãy xem ví dụ về minus.social mới.
Rachel: Hãy theo dõi công việc của Miriam về Dịch vụ so sánh giá (CSS) tại css.oddbird.net và tìm hiểu những hoạt động khác của cô thông qua trang web miriam.codes và Twitter @TerribleMia.