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