Houdini: Phát triển Sôi động nhất trong CSS mà bạn chưa từng thấy

Đã bao giờ bạn muốn sử dụng một tính năng CSS đặc biệt nhưng đã làm không phải vì nó không được hỗ trợ đầy đủ trong tất cả các trình duyệt ? Hoặc tệ hơn, nó đã được hỗ trợ trong tất cả các trình duyệt, nhưng sự hỗ trợ là lỗi, không phù hợp hoặc thậm chí hoàn toàn không tương thích? Nếu điều này xảy ra với bạn – và tôi đặt cược nó đã – sau đó bạn nên quan tâm đến Houdini .

Houdini là một lực lượng đặc nhiệm của W3C mới mà mục tiêu cuối cùng là để làm cho vấn đề này đi xa mãi mãi. Họ có kế hoạch để làm điều đó bằng cách giới thiệu một bộ mới của API sẽ, lần đầu tiên, cung cấp cho các nhà phát triển sức mạnh để mở rộng CSS riêng của mình, và những công cụ để móc vào kiểu dáng và bố trí quy trình của công cụ rendering của trình duyệt . Nhưng điều đó có nghĩa là, cụ thể nó thậm chí còn là một ý tưởng tốt? Và làm thế nào nó sẽ giúp chúng tôi phát triển xây dựng các trang web hiện nay và trong tương lai?

Trong bài viết này, tôi sẽ cố gắng trả lời những câu hỏi này. Nhưng trước khi tôi làm, điều quan trọng là để làm cho nó rõ ràng các vấn đề hiện nay và tại sao có như vậy một nhu cầu thay đổi. sau đó tôi sẽ nói cụ thể hơn về cách Houdini sẽ giải quyết những vấn đề này và liệt kê một số tính năng thú vị hơn đang được phát triển. Cuối cùng, tôi sẽ cung cấp một số điều cụ thể chúng tôi như các nhà phát triển web có thể làm hôm nay để giúp làm cho Houdini thành hiện thực.

Vấn đề gì Houdini Đang cố gắng để giải quyết?

Bất cứ lúc nào tôi viết một bài hoặc xây dựng một bản demo một số tính năng CSS mới, chắc chắn một người nào đó ý kiến hoặc trên Twitter sẽ nói điều gì đó giống như, “Điều này là tuyệt vời! Quá xấu, chúng tôi sẽ không thể sử dụng nó cho thêm 10 năm nữa.” Như gây phiền và phá hoại, tôi hiểu được. Trong quá khứ, nó đã đề xuất tính năng để đạt được áp dụng rộng rãi. Và lý do là, trong suốt lịch sử của trang web, cách duy nhất để có được một tính năng mới được thêm vào CSS là phải đi qua quá trình tiêu chuẩn.

Trong khi tôi đã hoàn toàn không có gì chống lại quá trình tiêu chuẩn, không thể phủ nhận nó có thể mất một thời gian dài! Ví dụ, flexbox lần đầu tiên được đề xuất vào năm 2009, và các nhà phát triển vẫn còn phàn nàn rằng họ không thể sử dụng nó ngày nay do thiếu sự hỗ trợ trình duyệt. Cấp bách, vấn đề này đang dần đi xa bởi vì hầu như tất cả các trình duyệt hiện đại bây giờ cập nhật tự động; nhưng ngay cả với các trình duyệt hiện đại, sẽ luôn có một độ trễ giữa các đề xuất và sẵn sàng nói chung của một tính năng. Điều thú vị là, đây không phải là 1 trường hợp trong tất cả các lĩnh vực của web. Hãy xem xét mọi thứ đã được làm việc như thế nào gần đây trong JavaScript:

Trong kịch bản này, thời gian giữa một ý tưởng và nhận được để sử dụng nó trong sản xuất đôi khi có thể là một vấn đề của nhiều ngày. Ý tôi là, tôi đã sử dụng các async / chờ đợi chức năng trong sản xuất, và tính năng đó đã không được thực hiện ngay cả trong một trình duyệt duy nhất! Bạn cũng có thể thấy một sự khác biệt rất lớn của hai cộng đồng này. Trong cộng đồng JavaScript, bạn đọc bài viết trong đó mọi người phàn nàn rằng mọi thứ đang chuyển động quá nhanh. Trong CSS, mặt khác, bạn nghe người ta than thở sự vô ích của việc học bất cứ điều gì mới, vì bao lâu nó sẽ được trước khi họ thực sự có thể sử dụng nó.

VÌ VẬY, TẠI SAO KHÔNG CHÚNG TÔI VIẾT THEME GỬI POLYFILLS CSS?

Đầu tiên, viết nhiều polyfills CSS có vẻ như câu trả lời. Với polyfills tốt, CSS có thể di chuyển nhanh như JavaScript, phải không? Đáng buồn thay, nó không phải là đơn giản. Polyfilling CSS là vô cùng khó khăn, và trong hầu hết trường hợp, không thể làm trong một cách mà không hoàn toàn hủy bỏ hiệu suất.

JavaScript là một ngôn ngữ năng động, có nghĩa là bạn có thể sử dụng JavaScript để polyfill JavaScript. Và bởi vì nó rất năng động, nó có khả năng mở rất rộng. CSS, mặt khác, có thể hiếm khi được sử dụng để polyfill CSS. Trong một số trường hợp, bạn có thể transpile CSS thành CSS trong một bước xây dựng ( PostCSS hiện điều này); nhưng nếu bạn muốn polyfill bất cứ điều gì mà phụ thuộc vào cấu trúc của DOM hoặc bố trí hoặc vị trí của một nguyên tố, sau đó bạn sẽ phải chạy logic phía máy khách của polyfill của bạn. Thật không may, trình duyệt không thực hiện điều này dễ dàng. Biểu đồ dưới đây cho phép một phác thảo cơ bản về cách trình duyệt của bạn đi từ nhận được một tài liệu HTML để hiển thị điểm ảnh trên màn hình. Các bước màu xanh trong show nơi JavaScript có sức mạnh để kiểm soát các kết quả:

Các hình ảnh là khá ảm đạm. Là một nhà phát triển, bạn đã không kiểm soát làm thế nào trình duyệt phân tích cú pháp HTML và CSS và biến nó thành các DOM và mô hình đối tượng CSS (CSSOM). Bạn không có quyền kiểm soát các tầng. Bạn không có quyền kiểm soát như thế nào trình duyệt lựa chọn để đặt ra các phần tử trong DOM hoặc làm thế nào nó vẽ những yếu tố trực quan trên màn hình. Và bạn không thể kiểm soát những gì các compositor làm.

Chỉ một phần duy nhất của quá trình này bạn có thể truy cập vào là DOM. Các CSSOM có phần mở; Tuy nhiên, để trích dẫn trang web của Houdini, đó là “underspecified, không phù hợp trên các trình duyệt, và thiếu tính năng quan trọng.”

Ví dụ, các CSSOM trong các trình duyệt hiện nay sẽ không cho bạn biết các quy tắc cho style sheets chéo nguồn gốc, và nó sẽ chỉ đơn giản là loại bỏ bất kỳ quy tắc CSS hoặc khai báo nó không hiểu, điều đó có nghĩa rằng nếu bạn muốn polyfill một tính năng trong trình duyệt không hỗ trợ nó, bạn không thể sử dụng CSSOM. Thay vào đó, bạn phải đi qua DOM, tìm <style> và / hoặc <link rel = “stylesheet”> thẻ, có CSS mình, phân tích nó, viết lại nó và sau đó thêm nó trở lại vào DOM. Tất nhiên, việc cập nhật các DOM thường có nghĩa là trình duyệt có để sau đó đi qua các thác toàn bộ, bố trí, vẽ và composite bước trên một lần nữa.

Trong khi phải hoàn toàn rerender một trang có thể không có vẻ là lớn về hiệu suất (đặc biệt là đối với một số các trang web), xem xét tần suất này có khả năng có thể xảy ra. Nếu logic polyfill của bạn cần phải chạy để đáp ứng với những thứ như sự kiện di chuyển, thay đổi kích thước cửa sổ, di chuyển chuột, sự kiện bàn phím – thực sự bất cứ lúc nào bất cứ điều gì ở tất cả các thay đổi – khi đó mọi thứ sẽ được chú ý, thậm chí đôi khi cripplingly, chậm. Điều này được thậm chí còn tồi tệ hơn khi bạn nhận ra rằng hầu hết polyfills CSS ra có ngày hôm nay bao gồm phân tích cú pháp CSS riêng của họ và logic thác riêng của họ. Và bởi vì phân tích và các tầng thực sự là những điều rất phức tạp, những polyfills thường hoặc quá lớn hoặc quá lỗi. Để tóm tắt tất cả mọi thứ tôi chỉ nói ngắn gọn hơn: Nếu bạn muốn trình duyệt để làm một cái gì đó khác với những gì nó nghĩ rằng đó là nghĩa vụ phải làm (cho CSS bạn đã cho nó), sau đó bạn phải tìm ra một cách để giả mạo bằng cách cập nhật và sửa đổi DOM. Bạn không có quyền truy cập vào các bước khác trong các rendering pipeline.

NHƯNG SAO TÔI LUÔN MUỐN SỬA ĐỔI RENDERING ENGINE CỦA TRÌNH DUYỆT?

Điều này, với tôi, là câu hỏi quan trọng nhất để trả lời toàn bộ bài viết này. Vì vậy, nếu bạn đã lướt game cho đến giờ, đọc phần này từ từ và cẩn thận!

Sau khi nhìn vào phần cuối cùng, tôi chắc chắn rằng một số bạn đang nghĩ, “Tôi không cần điều này! Tôi chỉ cần xây dựng các trang web bình thường. Tôi không cố gắng để hack vào internals của trình duyệt hoặc xây dựng một cái gì đó siêu lạ mắt, thử nghiệm hoặc gay cấn “.

Nếu bạn đang nghĩ rằng, sau đó tôi bắt buộc yêu cầu bạn phải bước trở lại trong một giây và thực sự kiểm tra các công nghệ mà bạn đã sử dụng để xây dựng các trang web trong những năm qua. Muốn truy cập và móc vào quá trình tạo của trình duyệt không chỉ là về building fancy demo – nó cho các nhà phát triển và các tác giả frameworks để làm hai việc chính:

• để bình thường hóa sự khác biệt giữa các trình duyệt,
• để p hát minh hay polyfill tính năng mới để người dùng có thể sử dụng chúng.

Nếu bạn đã từng sử dụng một thư viện JavaScript như jQuery, thì bạn đã được hưởng lợi từ khả năng này! Trong thực tế, đây là một trong những điểm sellings chính của hầu hết tất cả các thư viện front-end và frameworks ngày nay. Năm phổ biến nhất JavaScript và DOM kho trên GitHub – AngularJS, D3, jQuery, React và Ember – tất cả làm rất nhiều công việc để bình thường hóa sự khác biệt giữa các trình duyệt để bạn không cần phải suy nghĩ về nó. Mỗi phơi bày một API đơn, và nó chỉ hoạt động. Bây giờ, nghĩ về CSS và tất cả các vấn đề cross-browser. Ngay cả khung CSS như Bootstrap và Foundation tương thích cross-browser không thực sự bình thường hóa các lỗi cross-browser – họ chỉ cần tránh cho họ. Và lỗi trình duyệt chéo trong CSS không chỉ là một điều của quá khứ. Thậm chí ngày nay, với module bố trí mới như flexbox , chúng ta phải đối mặt với nhiều sự không tương thích giữa các trình duyệt . Điểm mấu chốt là, tưởng tượng cuộc sống của bạn sẽ đẹp hơn vì có thể sử dụng bất kỳ CSS nào và biết chắc chắn nó sẽ làm việc, giống hệt nhau, ở mọi trình duyệt. Và suy nghĩ về tất cả các tính năng mới, bạn đọc của bài viết trong blog hoặc nghe về tại các hội nghị và các buổi họp – những thứ như lưới CSS , CSS snap point và định vị dính . Hãy tưởng tượng nếu bạn có thể sử dụng tất cả trong số họ hiện nay và trong một cách đó mạnh như các tính năng CSS. Và điều bạn cần làm là lấy mã từ GitHub.

Đây là ước mơ của Houdini. Đây là tương lai bắt buộc đang cố gắng để làm cho tốt. Vì vậy, ngay cả khi bạn không bao giờ có kế hoạch viết một polyfill CSS hoặc phát triển một tính năng thử nghiệm, bạn có thể muốn người khác để có làm vậy – bởi vì một khi những polyfills tồn tại, tất cả mọi người được hưởng lợi từ chúng.

ITZone via Gramy.vn