Apple giới thiệu thuộc tính CSS riêng tư để thêm hiệu ứng Liquid Glass vào nội dung web

(alastair.is)

4 điểm bởi GN⁺ 2025-09-16 | 5 bình luận | Chia sẻ qua WhatsApp

Apple đã bổ sung thuộc tính CSS riêng tư -apple-visual-effect có thể dùng trong iOS 26
Thuộc tính này cho phép áp dụng các hiệu ứng thiết kế mới như Liquid Glass và vật liệu blur tiêu chuẩn cho cả nội dung web
Tính năng này không được bật mặc định trong trình duyệt Safari hoặc WKWebView
Để dùng trong WKWebView, cần bật thiết lập riêng tư useSystemAppearance, nhưng việc thay đổi nó khiến rất khó được App Store phê duyệt
Có vẻ tính năng này chủ yếu được Apple sử dụng nội bộ, và các nhà phát triển thông thường hiện chưa thể tận dụng

Tổng quan

Tác giả thường xem GitHub ChangeLog của WebKit như một thú vui để dự đoán các bản cập nhật iOS sắp tới
Gần đây, ngay sau WWDC, tác giả phát hiện một Pull Request trên WebKit có tiêu đề “[Materials] Rename 'hosted blur' materials to reference 'glass'”
Liquid Glass được nhấn mạnh tại WWDC 2025 là thay đổi lớn nhất về giao diện người dùng (UI) kể từ iOS 7
Trước đây đây là thay đổi thiết kế chỉ áp dụng cho UI native, nhưng PR lần này gợi ý mối liên hệ với web view

Thuộc tính CSS riêng tư của Apple

PR cho thấy Apple đã đưa vào một thuộc tính CSS riêng tư tên là -apple-visual-effect
Thông qua thuộc tính này, trên iOS 26 có thể áp dụng hiệu ứng Liquid Glass (ví dụ: -apple-system-glass-material)
Trên mọi phiên bản, cũng có thể dùng vật liệu blur tiêu chuẩn (-apple-system-blur-material-thin v.v.)
Các vật liệu này cũng được nhắc đến trong hướng dẫn thiết kế chính thức

Khả năng áp dụng thực tế

Ngay cả khi thử chỉnh sửa CSS trong Safari để áp dụng, nó vẫn không hoạt động trên web
Trong các ứng dụng dựa trên WKWebView, tính năng này cũng bị tắt theo mặc định
Chỉ khi đổi giá trị useSystemAppearance trong WKPreferences thành true thì nó mới hoạt động, nhưng bản thân thiết lập này là riêng tư nên không thể dùng qua con đường chính thức

Nếu bật giá trị đó bằng cách không chính thức rồi áp dụng CSS như bên dưới, có thể thấy hiệu ứng

.toolbar {  
  border-radius: 50%;  
  -apple-visual-effect: -apple-system-glass-material;  
  height: 75px;  
  width: 450px;  
}

Ví dụ CSS và áp dụng có điều kiện

Apple đã biến hiệu ứng này thành một thuộc tính CSS, giúp đơn giản hóa việc chỉ định các quy tắc khác nhau tùy theo khả năng hỗ trợ

Ví dụ, có thể dùng truy vấn @supports để chỉ áp dụng -apple-visual-effect trên các thiết bị được hỗ trợ

.toolbar {  
  border-radius: 50%;  
  height: 75px;  
  width: 450px;  
  background: rgba(204, 204, 204, 0.7);  
}  

@supports (-apple-visual-effect: -apple-system-glass-material) {  
  background: transparent;  
  -apple-visual-effect: -apple-system-glass-material  
}

Ý nghĩa và giới hạn

Đây là một tính năng mà nhà phát triển thông thường không thể sử dụng, trừ nội bộ Apple
Tuy nhiên, nó cũng cho thấy một gợi ý về việc vì sao webview trong ứng dụng thường có tiếng xấu
Một webview được tích hợp mượt mà đến mức người dùng không nhận ra sự tồn tại của nó thì ít khi để lộ vấn đề
Việc Apple phát triển tính năng này gián tiếp cho thấy hãng đang thực sự dùng nó trong các dịch vụ hoặc ứng dụng của mình
Có khả năng trong đời sống hằng ngày, người dùng đang vô thức trải nghiệm UI dựa trên webview

5 bình luận

ahwjdekf 2025-09-18

Nên phớt lờ mấy thứ vô lý thế này và đừng ai dùng cả

coremaker 2025-09-17

Khi Apple khai tử Flash, mọi người đã hoan hô vì lợi ích các bên khi đó trùng khớp,
nhưng thật trớ trêu khi lựa chọn hiện tại lại khiến tôi cảm thấy đây là quyết định phớt lờ hệ sinh thái hiện có.

Đây là sự tái sinh của IE sao?

spp00 2025-09-18

Từ sau thời IE, với các lập trình viên frontend thì vị trí kiểu IE không phải Chrome mà là Safari. Vì Safari mà dân frontend phải mua Mac đắt tiền. Có những trường hợp Chrome và Firefox đều chạy được nhưng riêng Safari thì không được hoặc hiển thị kỳ quặc.

GN⁺ 2025-09-16

Ý kiến trên Hacker News

Việc chỉ cung cấp các tính năng của hệ điều hành (OS) cho ứng dụng của chính mình rõ ràng là một hành vi cản trở cạnh tranh. Đây là ví dụ điển hình của việc tận dụng vị thế thống lĩnh trong thị trường điện thoại và hệ điều hành để chỉ cho phép ứng dụng của mình dùng một tính năng trên thị trường ứng dụng mà đối thủ không được phép dùng
- Ban đầu tôi muốn tức giận với Apple, nhưng rồi lại không thấy như vậy. Chỉ cần đọc tài liệu WinAPI cũng sẽ thấy vô số tham số ghi là "reserved". Các nhà phát triển hệ điều hành thường tạo ra tính năng chỉ để dùng nội bộ. Lần này chỉ là một cải tiến UI nên tôi không nghĩ nhất thiết phải giữ riêng tư, nhưng có lẽ Apple để nó ở dạng không công khai vì không muốn tiếp tục phải duy trì nó
- Có phải mọi thuộc tính CSS phi tiêu chuẩn đều là “phản cạnh tranh” không? Tôi tự hỏi liệu -webkit-tap-highlight-color của Google cũng phải bị chỉ trích tương tự hay không. Lập luận đó thực chất là muốn cấm luôn việc tạo ra các thuộc tính CSS độc quyền, và với tôi thì nhận định như vậy là hơi phóng đại
- Tôi không chắc đây có thực sự là một "hành vi phản cạnh tranh rõ ràng" theo nghĩa pháp lý hay không. Ở Mỹ, các luật cạnh tranh áp dụng là Sherman Act và Clayton Act. Hành vi này không nằm trong danh sách các "vi phạm đương nhiên (per se)" được liệt kê trong các luật đó, nên nhiều khả năng sẽ áp dụng "nguyên tắc cân nhắc hợp lý (rule of reason)". Trong trường hợp đó, chỉ khi hành vi này trực tiếp gây hại cho cạnh tranh, không mang lại lợi ích tích cực đáng kể và không có phương án thay thế ít hạn chế hơn thì mới được công nhận. Rất khó chứng minh rằng một thuộc tính CSS thực sự gây thiệt hại gì cho cạnh tranh, hơn nữa nếu ai muốn thì hoàn toàn có thể tự tạo CSS “liquid glass” mà chẳng ai ngăn cản, nên tôi nghĩ lập luận này khó đứng vững
- Tôi tò mò không biết bạn nghĩ sao về những trường hợp còn hạn chế hơn nhiều như phần cứng máy tính. Ví dụ, máy chơi game console yêu cầu mọi đoạn mã phải có chữ ký mã hóa, và bên thứ ba không thể phân phối bất kỳ phần mềm nào nếu không có sự cho phép của nhà sản xuất
- Nếu coi việc làm cho chữ trong UI khó đọc hơn là một lợi thế cạnh tranh thì cũng có thể nhìn theo hướng đó
Tôi thích “đại lý thuyết về webview trong ứng dụng của Alastair”: lý do chính khiến webview trong ứng dụng mang tiếng xấu là vì những webview được tích hợp tốt thì người dùng thậm chí không nhận ra chúng tồn tại
- Có sự khác biệt rất lớn giữa người từng thật sự triển khai webview và người chỉ nghe nói rằng cứ bọc web app trong native app là xong. Phần lớn mọi người thuộc nhóm thứ hai
- Có lẽ vì thế mà tính năng này được đưa vào. Bình thường, cách rẻ nhất để kiểm tra xem một ứng dụng có dùng bộ công cụ UI của bên thứ ba hay không là đổi theme hệ thống rồi xem ứng dụng có theo kịp việc đổi theme hoặc thay đổi màu sắc/tỷ lệ hay không. Có lẽ ngay cả một số ứng dụng do Apple cung cấp cũng không phản ánh theme đúng cách nên cuối cùng họ mới tạo ra thuộc tính CSS không công khai này. Trong khi đó, một số nhà cung cấp OS khác tránh phải quản lý nhiều toolkit dang dở bằng cách loại bỏ luôn khả năng điều khiển theme
- Nếu ai đó có thể nêu được dù chỉ một ứng dụng webview tích hợp hoàn hảo thì tôi sẽ công nhận. Người dùng trung bình có thể không nhận ra, nhưng nếu thật sự có thì chắc chắn trên Hacker News đã từng được nhắc đến ít nhất một lần. Kiểu như mỗi khi tranh luận về webview lại có người phản bác rằng “nhưng app Foo cũng làm bằng webview đó, và nó chạy rất ổn mà”
- Cảm giác giống như câu “Tóc giả lúc nào cũng trông giả. Tôi chưa từng thấy bộ tóc giả nào trông thật cả”
Mọi người nói “chắc chắn tính năng này được tạo ra vì Apple cần dùng”, nhưng không ai biết nó được dùng ở đâu. Nếu đoán thì có lẽ là phần cài đặt iCloud (bên trong app Cài đặt) hoặc các trang tài khoản trong App Store/Music/TV (chạm vào biểu tượng hồ sơ ở góc trên bên phải). Những trang này phần lớn là các webview ẩn cố gắng trông như native. Manh mối là nếu nhấn giữ lâu thì sẽ hiện bản xem trước trang web cho liên kết ``. Hướng dẫn người dùng trong app Tips cũng có thể là một ứng viên. Đó là nơi tôi sẽ kiểm tra đầu tiên
Điều thú vị là mọi người đoán rằng "Apple sẽ dùng nó ở đâu đó", nhưng thực tế chúng ta thậm chí không nhận ra nó đang được dùng ở đâu. Hóa ra chúng ta thường xuyên gặp webview trên iOS hằng ngày mà hoàn toàn không ý thức được
- Đặc biệt là app Cài đặt, nhất là phần tài khoản hoặc iCloud, tôi thường nghi là webview. Có thể đoán từ những khác biệt nhỏ như việc biểu tượng hiện ra chậm hơn khi tải
- App Store dường như cũng dùng webview rất nhiều
- Tôi biết Mail và Calendar cũng dùng webview khá nhiều
- Tôi nghĩ Apple.com cũng sẽ dùng nó. Tương tự cách trước đây họ dùng backdrop-filter cho hiệu ứng làm mờ nền trên iOS
- Apple Music có vẻ cũng dùng webview khá nhiều
Phát hiện rất hay. UI kính mới của Apple bị chỉ trích nhiều, nhưng cá nhân tôi lại thích nó. Nó khiến OS có cảm giác như lại có cá tính riêng, thoát khỏi vẻ đơn điệu và nhạt nhẽo. Các vùng có thể bấm cũng dễ nhận ra hơn và có thể phân biệt trực quan giữa nút bấm với văn bản thường. Tôi xem đây là một thay đổi đáng hoan nghênh. Không chỉ vì “hoài niệm” mà còn vì đây thực sự là thay đổi hữu ích. Tôi đã cài iOS 26 Beta sớm để thử nghiệm website, và dù có một vài vấn đề nhỏ, nhìn chung hướng đi này khiến OS có nhiều cá tính hơn là điều tích cực. Người dùng phổ thông cũng sẽ thích thôi
- Tôi thích hiệu ứng kính và yếu tố thẩm mỹ, nhưng về mặt chức năng thì ở nhiều ứng dụng nó lại bất tiện hơn trước. Những nút từng dễ tiếp cận nay bị giấu dưới menu và khó tìm hơn
- Theo tôi, nhìn rộng ra thì công chúng phổ thông sẽ không thích thay đổi này. Những người nghĩ rằng “hệ điều hành phải có cá tính” như thế này chỉ là thiểu số đam mê công nghệ. Đa số xem OS chỉ là một “phương tiện” để làm việc gì đó, nên những thay đổi thị giác kiểu này thường không mang nhiều ý nghĩa hơn mức gây chú ý nhất thời. Đặc biệt, phần tôi khó chịu nhất trong thiết kế liquid glass là thanh tab dưới mới. Apple Music là ví dụ tệ nhất. Số lần chạm để dùng giao diện Search tăng thêm một bước, và ngay cả sau khi bấm vào Search Box thì vẫn phải bấm thêm lần nữa mới hiện bàn phím. Ngoài ra, mọi tương tác đều bị thêm các hoạt ảnh phức tạp và chậm. Ví dụ khi chuyển từ Home sang Library, tab sẽ phồng lên như bong bóng phía trên thanh tab rồi lấp lánh di chuyển, trông chỉ rối mắt chứ không giúp ích gì. Các thiết lập trợ năng như Reduce Transparency hay Reduce Motion lại không áp dụng cho những hoạt ảnh này. Trên thực tế, gần đây nhiều ứng dụng mặc định của Apple quên áp dụng hoặc áp dụng rất sơ sài các tùy chọn trợ năng. Ví dụ, khi bật Reduce Motion thì một số hoạt ảnh như bấm vào album sẽ được đơn giản hóa, nhưng thao tác vuốt sang trái hay các hành động khác vẫn còn hoạt ảnh quá mức. Apple Podcasts và iMessage cũng tương tự. Còn Reduce Transparency thì trong một số app, thay vì chỉ giảm độ trong suốt, họ lại đổ toàn bộ nền thành màu đen (#000000). Những trường hợp như vậy xuất hiện đầy rẫy khắp iOS. Chỉ còn vài ngày trước khi phát hành mà các nơi như dropdown hay nút bàn phím bị vô hiệu hóa vẫn chưa phản ánh các tùy chọn trợ năng
- Câu “có thể nhìn ra kích thước vùng bấm và nút khác rõ với văn bản” thật ra không phải là một tiêu chuẩn cao
- Cá nhân tôi thuộc phe “thiết kế này thật sự kinh khủng”. Tôi không hiểu Apple đang nghĩ gì
Có lẽ Apple hiện vẫn chưa muốn bất kỳ ai dùng tính năng này. Sau khi OS mới được công bố, nhiều nhà phát triển có thể sẽ áp dụng ngay lập tức, nên có thể Apple muốn chốt cách sử dụng nội bộ trước khi công khai. Cũng phải nói là trong chủ đề này đang có một số lời chỉ trích vô căn cứ từ vài phía. Hiện vẫn chưa biết bên nào đúng
Mệnh đề “vì Apple định dùng nó” thực ra không phải lúc nào cũng đúng. Trong phần mềm thật tế có vô số đoạn mã và tính năng không bao giờ được dùng đến. Hướng phát triển thay đổi nhiều lần, nên có thể một thuộc tính CSS được thêm ở giai đoạn thứ 2 nhưng đến giai đoạn thứ 4 thì bị loại bỏ hoàn toàn
Tôi thật lòng hy vọng liquid jelly sẽ không trở thành xu hướng
- Dù thích hay ghét liquid glass, sự chuyển dịch mô hình từ “chrome của UI bao quanh nội dung ứng dụng” sang “UI đè lên trên nội dung” là một thay đổi mang tính hướng tới tương lai. Nó cũng rất hợp với AR, và cho phép tách biệt UI với nội dung theo nhiều kích thước màn hình khác nhau. Bản triển khai lần này có cả ưu lẫn nhược điểm, nhưng cách tiếp cận này sẽ được dùng rộng rãi hơn trong tương lai. Mô hình UI overlay cũng không nhất thiết phải trong suốt. Nó có thể mờ đục nhưng vẫn theo kiểu nổi phía trên
- Thế hệ trẻ đang bị ám ảnh bởi nỗi hoài niệm với thẩm mỹ thời Aero/Glass. Vì Apple đã áp dụng nên khả năng cao nó sẽ trở thành xu hướng. Trong toàn ngành, cứ Apple làm gì là mọi người lại đua nhau làm theo
- Cá nhân tôi chỉ mong họ bỏ hiệu ứng bounce/jiggle đi. Nó rung lắc và nhún nhảy quá mức, khiến cảm giác kính ban đầu thành ra giống một khối thạch blob hơn
- Tôi cũng thuộc phe không muốn nó thành mốt, nhưng thành thật mà nói, tôi nghĩ hễ Apple làm là rồi ai cũng sẽ bắt chước thôi
- Nó đã là xu hướng rồi
Có người nói phải bật thiết lập useSystemAppearance trong WKPreferences, nhưng vì đây là API riêng tư nên ứng dụng sẽ không được App Store phê duyệt. Tôi tò mò không biết điều đó có đúng không. Tôi không quá rành phát triển iOS, nhưng có nhớ từng xem một video giải nén một app tạo hiệu ứng động cho widget trên màn hình chính bằng cách dùng nhiều API nội bộ khác nhau
- Mấy thứ đó sẽ không qua được vòng kiểm duyệt App Store
- Bạn đang nói đến video này phải không?
Đây là trào lưu xấu xí nhất tôi từng thấy kể từ thời góc bo tròn và padding quá rộng. Mong nó biến mất càng sớm càng tốt

addons 2025-09-17

Đừng nói nhảm nữa, lo cho khả năng tương thích của Safari cho tử tế đi.