Apple ने वेब कंटेंट में Liquid Glass इफ़ेक्ट जोड़ने के लिए एक प्राइवेट CSS प्रॉपर्टी पेश की

(alastair.is)

4 पॉइंट द्वारा GN⁺ 2025-09-16 | 5 टिप्पणियां | WhatsApp पर शेयर करें

Apple ने iOS 26 में इस्तेमाल की जा सकने वाली प्राइवेट CSS प्रॉपर्टी -apple-visual-effect जोड़ी है
यह प्रॉपर्टी Liquid Glass और स्टैंडर्ड blur material जैसे नए डिज़ाइन इफ़ेक्ट्स को वेब कंटेंट पर भी लागू करने देती है
यह फीचर Safari ब्राउज़र या WKWebView में डिफ़ॉल्ट रूप से सक्षम नहीं है
WKWebView में इसका उपयोग करने के लिए useSystemAppearance नाम की एक प्राइवेट सेटिंग चालू करनी पड़ती है, और इसे बदलने पर App Store अनुमोदन पाना मुश्किल हो जाता है
यह फीचर मुख्य रूप से Apple के भीतर आंतरिक उपयोग के लिए दिखता है, इसलिए सामान्य डेवलपर्स अभी इसका उपयोग नहीं कर सकते

अवलोकन

लेखक शौक के तौर पर WebKit के GitHub ChangeLog को अक्सर देखते हैं और iOS के अगले अपडेट का अनुमान लगाते हैं
हाल ही में WWDC के तुरंत बाद WebKit में “[Materials] Rename 'hosted blur' materials to reference 'glass'” नाम का Pull Request चढ़ा हुआ देखा गया
2025 WWDC में ज़ोर देकर दिखाया गया Liquid Glass iOS 7 के बाद का सबसे बड़ा user interface (UI) बदलाव है
पहले यह डिज़ाइन बदलाव सिर्फ native UI पर लागू होता था, लेकिन इस PR ने web view के साथ इसके संबंध का संकेत दिया

Apple की प्राइवेट CSS प्रॉपर्टी

PR से पता चला कि Apple ने -apple-visual-effect नाम की एक प्राइवेट CSS प्रॉपर्टी पेश की है
इस प्रॉपर्टी के ज़रिए iOS 26 में Liquid Glass इफ़ेक्ट (जैसे -apple-system-glass-material) लागू किया जा सकता है
सभी versions में स्टैंडर्ड blur material (-apple-system-blur-material-thin आदि) का उपयोग भी संभव है
आधिकारिक design guide में भी ऐसे materials का उल्लेख है

वास्तविक उपयोग की संभावना

Safari में CSS एडिट करके लागू करने की कोशिश करने पर भी, यह वेब पर काम नहीं करता
WKWebView-आधारित apps में भी यह डिफ़ॉल्ट रूप से disabled है
इसे चलाने के लिए WKPreferences के useSystemAppearance मान को true करना पड़ता है, लेकिन यह सेटिंग खुद प्राइवेट है, इसलिए आधिकारिक तरीके से इसका उपयोग संभव नहीं है
अनौपचारिक तरीके से हैक कर इस मान को सक्षम करने के बाद नीचे जैसा CSS लागू करने पर इफ़ेक्ट देखा जा सकता है
```
.toolbar {  
  border-radius: 50%;  
  -apple-visual-effect: -apple-system-glass-material;  
  height: 75px;  
  width: 450px;  
}  
```

CSS उदाहरण और शर्त आधारित उपयोग

Apple ने इस इफ़ेक्ट को CSS प्रॉपर्टी के रूप में बनाया है, ताकि support उपलब्ध होने पर अलग-अलग rules आसानी से तय किए जा सकें

उदाहरण के लिए @supports query का उपयोग करके, सिर्फ supported devices पर -apple-visual-effect लागू किया जा सकता है

.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  
}

महत्व और सीमाएँ

Apple के आंतरिक उपयोग को छोड़ दें तो यह सामान्य डेवलपर्स के लिए उपलब्ध फीचर नहीं है
लेकिन इससे यह समझने का एक संकेत मिलता है कि ऐप के भीतर webview की छवि अक्सर खराब क्यों होती है
जो webview बहुत seamless तरीके से अच्छी तरह integrated होते हैं, उनके अस्तित्व का उपयोगकर्ता को अक्सर पता ही नहीं चलता, इसलिए समस्याएँ सामने आने की संभावना कम रहती है
Apple ने इसे विकसित किया है, यह अप्रत्यक्ष रूप से संकेत देता है कि कंपनी इसे अपनी सेवाओं या apps में वास्तव में इस्तेमाल कर रही है
संभव है कि रोज़मर्रा के इस्तेमाल में आप अनजाने में webview-आधारित UI का अनुभव कर रहे हों

5 टिप्पणियां

ahwjdekf 2025-09-18

ऐसी बकवास चीज़ को नज़रअंदाज़ करना चाहिए और किसी को भी इसका इस्तेमाल नहीं करना चाहिए

coremaker 2025-09-17

जब Apple ने Flash को खत्म किया था, तो हित मेल खाने की वजह से मैंने भी उसका स्वागत किया था।
लेकिन अब ऐसा लगना विडंबनापूर्ण है कि उसकी मौजूदा पसंदें मौजूदा ecosystem की अनदेखी करने वाला फैसला हैं।

क्या यह IE की वापसी है?

spp00 2025-09-18

IE के बाद, frontend developers के नज़रिए से IE वाली पोज़िशन Chrome की नहीं बल्कि Safari की थी। Safari की वजह से frontend developers को महंगा Mac खरीदना पड़ता है। Chrome और Firefox में सब चल जाता है, लेकिन कई बार सिर्फ Safari में या तो काम नहीं करता या अजीब तरह से दिखता है।

GN⁺ 2025-09-16

Hacker News टिप्पणियाँ

OS फ़ीचर्स को सिर्फ़ अपने ऐप्स के लिए उपलब्ध कराना साफ़ तौर पर प्रतिस्पर्धा-विरोधी प्रैक्टिस है। फ़ोन और OS मार्केट में अपनी प्रभुत्वशाली स्थिति का इस्तेमाल करके ऐप मार्केट में ऐसे फ़ीचर्स केवल खुद इस्तेमाल करना, जिन्हें प्रतिस्पर्धियों को अनुमति नहीं है, इसका स्पष्ट उदाहरण है
- मूल रूप से मैं Apple पर गुस्सा होना चाहता था, लेकिन वैसा महसूस नहीं होता। सिर्फ़ WinAPI docs पढ़ लें तो "reserved" parameters बहुत मिलते हैं। OS developers अक्सर ऐसे फ़ीचर्स बनाते हैं जिनका मकसद सिर्फ़ internal use होता है। इस बार यह सिर्फ़ एक UI सुधार है, इसलिए इसे private रखने की खास ज़रूरत नहीं लगती, लेकिन शायद Apple इसे लगातार maintain नहीं करना चाहता, इसलिए private रखा है
- क्या सभी non-standard CSS properties “प्रतिस्पर्धा-विरोधी” हैं? Google की “-webkit-tap-highlight-color” को भी क्या उसी तरह दोषी ठहराया जाना चाहिए? यह तर्क तो proprietary CSS properties बनाने की पूरी प्रथा पर रोक लगाने जैसा है, और मुझे यह दावा बढ़ा-चढ़ा हुआ लगता है
- क़ानूनी अर्थ में यह सचमुच "स्पष्ट प्रतिस्पर्धा-विरोधी आचरण" है या नहीं, यह पक्का नहीं है। अमेरिका में Sherman Act और Clayton Act जैसे antitrust laws लागू होंगे। इन क़ानूनों में सूचीबद्ध "per se" violations में यह शामिल नहीं है, इसलिए यहाँ "rule of reason" लागू होगा। उस स्थिति में तभी माना जाएगा जब यह आचरण सीधे प्रतिस्पर्धा को नुकसान पहुँचाता हो, और इसके कोई ख़ास सकारात्मक प्रभाव या कम restrictive alternatives न हों। यह साबित करना मुश्किल है कि इस CSS property से वास्तव में प्रतिस्पर्धा को क्या नुकसान होता है, और अगर कोई चाहे तो “liquid glass” CSS खुद भी बना सकता है, कोई रोक नहीं रहा, इसलिए इसे लागू करना कठिन लगता है
- मैं जानना चाहूँगा कि इससे कहीं ज़्यादा restrictive मामलों, जैसे कंप्यूटर हार्डवेयर, के बारे में क्या सोचा जाए। उदाहरण के लिए video game consoles में सारा code cryptographically signed होना चाहिए, और निर्माता की अनुमति के बिना third parties कोई software distribute नहीं कर सकते
- अगर UI text को पढ़ना मुश्किल बना देना प्रतिस्पर्धात्मक बढ़त माना जाए, तो शायद हाँ
“Alastair की in-app webview grand theory” मुझे पसंद आई: in-app webviews की बदनामी का मुख्य कारण यह है कि जो webview सच में अच्छी तरह integrated हो, उसे users नोटिस ही नहीं करते
- जिन लोगों ने सच में webview implement किया है और जिन लोगों ने सिर्फ़ यह सुना है कि web app को native app में wrap करके ship कर देना काफ़ी है, उनके बीच बड़ा फ़र्क है। ज़्यादातर लोग दूसरे समूह में आते हैं
- शायद यही वजह है कि यह फ़ीचर लाया गया। आम तौर पर यह जाँचने का सस्ता तरीका कि कोई app third-party UI toolkit इस्तेमाल कर रहा है या नहीं, system theme बदलकर देखना है कि app theme या color/scale changes के साथ ठीक से adapt करता है या नहीं। Apple के अपने कुछ apps भी themes को ठीक से reflect नहीं करते होंगे, इसलिए आख़िरकार private CSS property बनानी पड़ी होगी। वहीं कुछ दूसरे OS vendors theme control functionality ही हटा देते हैं ताकि कई अधूरे toolkits को manage करने की समस्या से बचा जा सके
- अगर कोई कम-से-कम एक भी ऐसा webview app बता दे जो पूरी तरह perfectly integrated हो, तो मैं मान लूँगा। average users शायद नोटिस न करें, लेकिन अगर सच में ऐसा कोई होता, तो Hacker News पर उसका ज़िक्र कभी न कभी ज़रूर हुआ होता। webview बहस हर बार “लेकिन Foo app भी webview से बना है, और वह तो पूरी तरह बढ़िया चलता है” जैसे counterexample के रूप में सामने आता
- यह कुछ ऐसा है जैसे कहना, “विग हमेशा नकली दिखती है। मैंने कभी सच में असली जैसी दिखने वाली विग नहीं देखी”
लोग कहते हैं, “Apple खुद ज़रूर इस्तेमाल करेगा, तभी यह फ़ीचर बना,” लेकिन यह किसी को नहीं पता कि कहाँ। अंदाज़ा लगाया जाए तो शायद iCloud settings (Settings app के भीतर) या App Store/Music/TV apps के account pages (ऊपर दाईं ओर profile icon tap) में। ये pages ज़्यादातर ऐसे छिपे हुए webviews हैं जो native जैसे दिखने की कोशिश करते हैं। लंबा press करने पर links के लिए webpage preview आना इसका एक संकेत है। Tips app का user guide भी उम्मीदवार हो सकता है। यह ऐसी जगह है जहाँ मैं पहले जाँच करूँगा
यह दिलचस्प है कि लोग अनुमान लगाते हैं कि "Apple इसे कहीं इस्तेमाल करेगा", लेकिन हम यह पहचान भी नहीं पाए कि वास्तव में कहाँ इस्तेमाल हो रहा है। हम रोज़मर्रा में iOS पर webviews का सामना करते रहे, और हमें ज़रा भी एहसास नहीं हुआ
- खासकर Settings app में, और विशेष रूप से account या iCloud वाले हिस्सों में, मुझे अक्सर शक होता है कि वहाँ webview है। loading के दौरान icons थोड़ा देर से दिखते हैं जैसी छोटी बातों से ऐसा अंदाज़ा लगता है
- App Store app भी webviews का काफ़ी ज़्यादा इस्तेमाल करता लगता है
- मेरी जानकारी में Mail और Calendar apps भी webviews का काफ़ी इस्तेमाल करते हैं
- मुझे लगता है Apple.com पर भी यह आने वाला है। जैसे पहले iOS में background blur effect के लिए backdrop-filter इस्तेमाल हुआ था, उसी तरह
- Apple Music भी काफ़ी हद तक webviews का इस्तेमाल करता लगता है
बढ़िया खोज है। Apple के नए glass UI की बहुत आलोचना हो रही है, लेकिन मुझे उल्टा यह पसंद है। लगता है जैसे OS में फिर से कुछ असली personality आ गई हो, और वह monotone, फीका एहसास कम हुआ हो। clickable areas भी ज़्यादा साफ़ दिखते हैं और buttons को सामान्य text से visually अलग पहचानना आसान हो जाता है। मुझे यह स्वागतयोग्य बदलाव लगता है। सिर्फ़ “nostalgia” की वजह से नहीं, बल्कि सच में practical बदलाव है। मैं iOS 26 Beta पहले से install करके websites test कर रहा हूँ; कुछ छोटी issues हैं, लेकिन overall OS को ज़्यादा personality देने की दिशा अच्छी लगती है। आम users को भी यह पसंद आएगा
- मुझे glass effect और aesthetics पसंद हैं, लेकिन कई apps में functionality के लिहाज़ से चीज़ें पहले से ज़्यादा असुविधाजनक हो गई हैं। जो buttons पहले आसानी से मिलते थे, वे menus के नीचे छिप गए हैं और उन्हें ढूँढना मुश्किल हो गया है
- मेरे हिसाब से व्यापक तौर पर आम जनता इस बदलाव को पसंद नहीं करेगी। “OS में personality होनी चाहिए” ऐसा सोचने वाले लोग सिर्फ़ कुछ tech enthusiasts हैं। ज़्यादातर लोग OS को सिर्फ़ काम कराने के एक ‘माध्यम’ की तरह देखते हैं, इसलिए ऐसे visual changes अक्सर दिलचस्पी से आगे कोई मायने नहीं रखते। खासकर liquid glass design में मेरी सबसे बड़ी शिकायत नया bottom tab bar है। Apple Music इसमें सबसे खराब है। Search interface इस्तेमाल करने के लिए एक extra click बढ़ गया है, और Search Box पर click करने के बाद भी keyboard लाने के लिए अलग से दबाना पड़ता है। फिर हर interaction में complex और slow animations जोड़ दिए गए हैं। उदाहरण के लिए Home से Library जाते समय tab bar के ऊपर bubble की तरह tab बड़ा होकर चमकता-सा move करता है; यह सिर्फ़ distracting है, मददगार नहीं। Reduce Transparency या Reduce Motion जैसी accessibility settings इन animations पर लागू नहीं होतीं। हाल के समय में Apple के कई default apps accessibility options लागू करना भूल जाते हैं, या बहुत अधूरा लागू करते हैं। उदाहरण के लिए Reduce Motion on करने पर album click जैसी कुछ animations सरल हो जाती हैं, लेकिन left swipe या दूसरे actions में फिर भी animation बहुत ज़्यादा रहता है। Apple Podcasts और iMessage में भी यही हालत है। Reduce Transparency कुछ apps में transparency कम करने के बजाय हर background को काला (#000000) कर देता है। iOS भर में ऐसे उदाहरण बहुत हैं। release में कुछ ही दिन बचे होने पर भी dropdowns, disabled keyboard buttons जैसी जगहों पर accessibility options reflect नहीं हो रहे
- “click target का size visually पता चल जाता है और buttons text से साफ़ अलग दिखते हैं” — सच कहूँ तो यह कोई बहुत ऊँचा मानक नहीं है
- निजी तौर पर मैं “यह design वाकई भयानक है” वाले पक्ष में हूँ। Apple क्या सोच रहा था, समझ नहीं आता
शायद Apple अभी चाहता ही हो कि कोई और इस फ़ीचर का इस्तेमाल न करे। नए OS announcement के बाद बहुत से developers इसे तुरंत अपनाने की कोशिश कर सकते हैं, इसलिए हो सकता है Apple public करने से पहले internal use पक्का करना चाहता हो। यह भी सच है कि इस thread में कुछ बेबुनियाद आरोप भी लगाए जा रहे हैं। अभी यह कहना मुश्किल है कि सही कौन है
“क्योंकि Apple इस्तेमाल करेगा, इसलिए यह बनाया गया” — यह बात हमेशा सही नहीं होती। असली software में इस्तेमाल न होने वाला code और features बहुत बड़ी मात्रा में मौजूद रहते हैं। development direction कई बार बदलती रहती है, इसलिए दूसरे चरण में जो CSS property जोड़ी गई हो, वह चौथे चरण तक पूरी तरह गायब भी हो सकती है
मैं सच में उम्मीद करता हूँ कि liquid jelly trend न बने
- liquid glass पसंद हो या नापसंद, “UI chrome app content को घेरता है” से “UI content के ऊपर overlay होता है” तक का paradigm shift भविष्य-दर्शी है। यह AR के साथ भी अच्छी तरह मेल खाता है, और अलग-अलग screen sizes में UI और content को अलग समझने में मदद करता है। इस implementation के अपने फायदे-नुकसान हैं, लेकिन यह approach आगे और व्यापक हो सकती है। Overlay UI model का transparent होना ज़रूरी नहीं; opaque लेकिन floating form भी हो सकता है
- युवा पीढ़ी Aero/Glass दौर की aesthetics के लिए nostalgia में डूबी हुई है। और क्योंकि Apple ने इसे अपनाया है, इसके trend बनने की संभावना ज़्यादा है। industry में कुल मिलाकर Apple जो करता है, वही follow करने का माहौल रहता है
- निजी तौर पर अगर bounce/jiggle effect हटा दिया जाए तो मुझे अच्छा लगेगा। यह ज़रूरत से ज़्यादा हिलता-डुलता है, और असली glass feel के बजाय jelly जैसे blob की तरह दिखता है
- मैं भी नहीं चाहता कि यह trend बने, लेकिन सच कहूँ तो Apple अगर करता है, तो आख़िरकार सब उसका अनुसरण करेंगे
- यह पहले से trend में है
कहा जा रहा है कि WKPreferences में useSystemAppearance setting on करनी पड़ती है, लेकिन यह private है, इसलिए App Store approval नहीं मिलेगा। क्या यह सच है, जानना चाहता हूँ। मैं iOS development का विशेषज्ञ नहीं हूँ, लेकिन मुझे याद है कि मैंने एक वीडियो देखा था जिसमें किसी app को decompile करके दिखाया गया था कि वह कई internal APIs का इस्तेमाल करके homescreen widgets को animate बनाता है
- ऐसी चीज़ें App Store review पास नहीं कर पातीं
- क्या आप इस वीडियो की बात कर रहे हैं?
rounded corners और wide padding के बाद यह सबसे बदसूरत trend है जो मैंने देखा है। उम्मीद है यह जल्दी से जल्दी गायब हो जाए

addons 2025-09-17

बकवास छोड़ो और Safari compatibility को ही ठीक से संभालो।