Cộng đồng nổi bật: Miriam Suzanne

Miriam Suzanne là một tác giả, nghệ sĩ và nhà phát triển web ở Denver, Colorado. Cô hiện đang làm việc trên các thông số kỹ thuật CSS thú vị như Container Queries và Cascade Layers.

Bài đăng này thuộc Designcember. Một sự kiện tôn vinh thiết kế web do web.dev tổ chức.

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), cây bút cho CSS Tricks, thành viên của nhóm Sass và là chuyên gia được mời của W3C trong Nhóm công tá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ư Cascade Layers, Container Queries và Scope. Ngoài đời, Miriam là một tiểu thuyết gia, nhà viết kịch và nhạc sĩ đã xuất bản sách. Chúng tôi đã trò chuyện về công việc của cô với Sass và CSS.

Miriam trên sân khấu, đang mỉm cười và được chiếu sáng bằng đèn rọi.
Thông tin ghi nhận tác giả ảnh From the Hip Photo

Rachel: Tôi biết đến công việc của bạn lần đầu tiên là nhờ vào khung lưới Susy. Điều gì đã khiến bạn tạo ra khung lưới đó?

Miriam: Năm 2008, bố cục trên web mang đến 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 bố cục lưới linh hoạt (nhưng vẫn còn nhiều điểm bất cập). Có một sự bùng nổ về "khung lưới" 12 cột phù hợp với mọi kích thước – cung cấp một lưới xác định trước (thường là tĩnh) với một tập hợp các lớp CSS xác định trước. Nếu cần thứ gì đó có thể tuỳ chỉnh nhiều hơn, bạn sẽ phải tự làm. Rõ ràng là các trang web cần phải trở nên linh hoạt hơn, nhưng truy vấn nội dung nghe nhìn vẫn chưa có sẵn và có rất nhiều vấn đề về khả năng tương thích của trình duyệt liên quan đến các thành phần nổi linh hoạt.

Tôi đã sử dụng phương pháp Hệ thống CSS của Natalie Downe. Phương pháp này rất thông minh khi phản hồi cả kích thước phông chữ và khung nhìn, nhưng tôi cảm thấy khó chịu vì tất cả các phép toán lặp đi lặp lại và các thủ thuật trình duyệt cần thiết. Đồng thời, Sass bắt đầu được chú ý và 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ó một vài mixin để tính toán và thêm các đoạn mã tôi cần. Mục tiêu là giảm 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ó bất kỳ lớp học nào được xác định trước.

Rachel: Làm cách nào mà bạn chuyển từ việc làm việc trên một trình tiền xử lý CSS sang làm việc trên các quy cách CSS? Bạn có nghĩ rằng việc làm việc trên trình tiền xử lý là một nền tảng tốt để viết quy cách 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 ranh giới đó. Nhưng tôi nghĩ điều đó phần lớn là nhờ nhóm Sass, đặc biệt là Natalie Weizenbaum. Nhóm này 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 các tiêu chuẩn web đang phát triển. Việc vượt qua các giải pháp "dựa trên ý kiến" chung chung và xây dựng tính linh hoạt lâu dài là điều cần thiết khi bạn nghĩ về tương lai của các tiêu chuẩn cốt lõi trên web.

Chúng tôi có thể xây dựng những công cụ tôn trọng sự đa dạng về nhu cầu và phương pháp của nhà phát triển, đồng thời vẫn khuyến khích và tạo điều kiện cho khả năng tiếp cận cũng như những yếu tố quan trọng khác như thế nào?

Rachel: Chúng tôi có một loạt các tính năng mới trong CSS, về cơ bản sẽ thay thế những chức năng vốn là một phần của Sass. Có lý do chính đáng nào để vẫn sử dụng một thứ như Sass không?

Miriam: Có, đối với một số người, nhưng không có câu trả lời chung cho câu hỏi này. Hãy lấy biến làm ví dụ. Các biến Sass được phân loại theo 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ó tổ chức như danh sách và đối tượng, thao tác màu, v.v. Điều này rất phù hợp với logic hệ thống thiết kế 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 bộ điểm mạnh và điểm yếu hoàn toàn khác dựa trên tầng. Sass không thể xử lý các thuộc tính tuỳ chỉnh và CSS không thể xử lý dữ liệu có cấu trúc. Cả hai đều hữu ích và mạnh mẽ, nhưng nhu cầu cụ thể của bạn có thể khác nhau.

Tôi cho rằng việc mọi người có thể loại bỏ những công cụ không còn cần thiết là điều tuyệt vời, 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. Tuyệt vời! Nhưng sẽ quá đơn giản nếu cho rằng điều đó có nghĩa là chúng giống hệt nhau và một chỉ đơn giản là thay thế cho cái kia. Luôn có những trường hợp sử dụng mà một số logic thiết kế diễn ra ở phía máy chủ và một số logic diễn ra ở phía máy khách – ngay cả khi các ngôn ngữ cung cấp về cơ bản là các tính năng giống nhau. Các đơn vị xử lý trước sẽ đồng hành với chúng tôi trong thời gian dài.

Rachel: Có điều gì khiến bạn ngạc nhiên khi bạn tham gia nhiều hơn vào việc tạo ra các tiêu chuẩn, hoặc 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 tham gia, tôi cảm thấy quy trình tiêu chuẩn giống như một hộp đen bí ẩn và kỳ diệu, và tôi không biết mình nên mong đợi điều gì. Tôi lo 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 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.

Tôi rất ngạc nhiên khi nhận thấy rằng rất ít người tham gia 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ố 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 được các tổ chức đó trả lương, 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 đó khiến những người tham gia không phải là nhà thiết kế và nhà phát triển thông thường, đặc biệt là những người làm việc với khách hàng tại các công ty quảng cáo nhỏ hoặc làm việc tự do. Vai trò Chuyên gia được mời của tôi hoàn toàn là tình nguyện, một thú vui tốn kém, nếu tôi không tìm được nguồn tài trợ bên ngoài cho công việc đó.

Trên thực tế, quy trình này 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, vì có quá nhiều cuộc trò chuyện diễn ra cùng lúc, nên bạn có thể khó tìm được vị trí của mình. Đặc biệt là nếu đó không phải là công việc chính của bạn.

Rachel: Container queries (truy vấn vùng chứa) là mục tiêu mà nhiều nhà phát triển web đã hướng đến trong nhiều năm. Tôi rất vui vì chúng tôi sẽ có những tính năng này. Tôi cảm thấy nhiều người đang nghĩ về tính hữu ích của truy vấn vùng chứa. Bạn có cảm thấy chúng có tiềm năng mở ra nhiều 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 điều đó là hoàn toàn tách biệt. Tất cả chúng ta đều có thời gian hạn chế và đang cố gắng viết mã có thể duy trì và hoạt động hiệu quả. Khi một việc gì đó khó thực hiện, 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 đang bị chi phối bởi lợi ích của các tập đoàn lớn, vì vậy, những mối lo ngại về kinh doanh đó luôn được đề cập nhiều hơn so với các nghệ sĩ web. Tôi nghĩ chúng ta sẽ bỏ lỡ nhiều điều nếu bỏ qua khả năng sáng tạo trên web như một trường hợp sử dụng chính cho các tính năng. Tôi rất vui khi thấy một số người làm nghệ thuật CSS đang thử nghiệm nguyên mẫu truy vấn vùng chứa. Jhey Tompkins đã tạo một bản minh hoạ đặc biệt thông minh và có tính tương tác về CSS venetian blinds (CSS rèm cửa sổ) như một lời bình luận về meme cũ chống CSS. Tôi nghĩ còn rất nhiều điều để khám phá trong không gian đó và tôi rất nóng lòng muốn xem mọi người sẽ nghĩ ra những nội dung gì khác.

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, vì đây là trường hợp sử dụng ban đầu, nhưng tôi rất vui khi thấy mọi người làm gì với các truy vấn về kiểu – khả năng viết các kiểu có điều kiện dựa trên giá trị của một 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 vẫn chưa được khám phá hết. Tôi nghĩ rằng việc này sẽ mở ra nhiều cơ hội sáng tạo hơn nữa!

Rachel: Bạn có nghĩ rằng có điều gì mà chúng ta không thể làm (hoặc sắp có cách để làm) trong CSS nhưng 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. Các lớp xếp tầng sẽ giúp tác giả kiểm soát tốt hơn các vấn đề về tính cụ thể và Scope sẽ giúp nhắm đến bộ chọn chính xác hơn. Nhưng cả hai đều là những vấn đề về kiến trúc cấp cao. Tôi là một nghệ sĩ nên rất hào hứng với những thứ như nút bật/tắt CSS, một cách khai báo để tạo kiểu tương tác hoặc "dòng thời gian" của vùng chứa, cho phép chúng ta chuyển đổi mượt mà 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 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òn có những ai đang làm những việc thực sự thú vị, vui vẻ hoặc sáng tạo trên web?

Miriam: Ồ, tôi thậm chí không biết phải trả lời câu hỏi đó như thế nào, có rất nhiều người làm công việc sáng tạo ở nhiều lĩnh vực khác nhau. Cả CSSWG và Open-UI đều đang tiến hành nhiều công việc thú vị về tiêu chuẩn, 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 lớn nhất từ các nghệ sĩ trên web và cách mọi người sử dụng những công cụ này trong quá trình sản xuất, theo những cách không liên quan trực tiếp đến thương mại. Những người như Jhey, Lynn Fisher, Yuan Chuan hoặc nhiều người khác đang nỗ lực mở rộng giới hạn của những gì công nghệ web có thể làm về mặt hình ảnh và tương tác. Ngay cả những người làm công việc thiên về kinh doanh hơn cũng có thể học được nhiều điều từ kỹ thuật nghệ thuật của họ.

Tôi cũng đánh giá cao những tác phẩm nghệ thuật trên web mang tính khái niệm hơn của những người như Ben Grosser. Ông liên tục thúc đẩy chúng ta xem xét lại những gì chúng ta muốn từ web, đặc biệt là mạng xã hội. Ví dụ: hãy xem minus.social mới của anh ấy.

Rachel: Theo dõi công việc của Miriam về CSS tại css.oddbird.net và tìm hiểu những việc khác mà cô ấy đang làm thông qua trang web miriam.codes và Twitter @TerribleMia.