इंटरनेट को आकार देने वाली HTML हैकिंग तकनीकें

 (tedium.co)
2 पॉइंट द्वारा GN⁺ 2023-12-03 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • शुरुआती वेब डेवलपर्स के लिए हर ब्राउज़र में standard implementation और flaws अलग-अलग होने के कारण, सिर्फ valid HTML/CSS से मनचाहा layout और behavior भरोसेमंद ढंग से सुनिश्चित करना मुश्किल था
  • Netscape 4, Internet Explorer 5/6/7, Safari/WebKit, Outlook जैसे environments ने CSS, PNG transparency, comments, selectors और email preview में browser-specific workaround code को जन्म दिया
  • HTML table layout, sIFR, Chrome Frame और responsive design ऐसे उदाहरण हैं जिनमें मूल इरादे से अलग combinations के जरिए design constraints और पुराने browser की समस्याओं को पार करने की कोशिश की गई
  • इन hacks में accessibility में गिरावट, non-standard code, Flash और plugins पर निर्भरता जैसी सीमाएँ थीं, लेकिन उस समय compatibility और visual presentation हासिल करने का ये व्यावहारिक तरीका था
  • web standards के आदर्श और वास्तविक इस्तेमाल के तरीके लगातार टकराते रहे, और developers व designers के बार-बार किए गए workarounds ने web design, email HTML और mobile対応 के तरीकों पर लंबे समय तक असर छोड़ा

ब्राउज़र flaws से बचने वाली CSS hacking

  • Netscape Navigator 4.0 का @import hack ऐसा तरीका था जिसमें Netscape द्वारा support न की जाने वाली CSS को जानबूझकर @import से load किया जाता था, ताकि वह browser advanced styles apply न कर सके
    • basic CSS को <link> से load किया जाता था, और ज्यादा advanced CSS को @import से अलग करके load करने की संरचना थी
    • CSS Cookbook ने इसे Netscape में काम न करने वाली CSS file को साथ में load कराने का effect बताया है
    • Netscape ने CSS के बजाय JSSS को push किया, और W3C द्वारा CSS चुनने के बाद 1997 की गर्मियों में Netscape 4 में CSS को जल्दबाजी में implement किया गया
    • Netscape 4 में JavaScript बंद करने पर CSS भी बंद हो जाने का side effect था
  • Internet Explorer 6 को target करने वाली CSS hacking में _width की तरह property के आगे underscore लगाकर सिर्फ IE6 से उस declaration को interpret करवाया जाता था
    • W3C के box model में width को border और padding को छोड़कर माना गया था, लेकिन Internet Explorer padding और border को अलग तरह से handle करता था, जिससे browsers के बीच layout differences बनते थे
    • उदाहरण width: 300px; _width: 320px; padding: 10px; जैसा था, जहाँ standard CSS में invalid declaration को IE6 के लिए correction value के रूप में इस्तेमाल किया जाता था
    • !important के बाद एक और exclamation mark जोड़कर IE7 और उससे नीचे में अलग behavior कराने जैसे IE-specific hacks भी थे

layout के लिए semantic structure को मोड़ना

  • HTML table layout एक प्रमुख hack था जिसमें असल में tabular data दिखाने के लिए बने <table> को visual page layout tool की तरह इस्तेमाल किया गया
    • David Siegel ने पारंपरिक designer के नजरिए से web को देखा, और इस परंपरा के विरुद्ध जाकर बेहतर दिखने वाली websites बनाने की कोशिश की कि HTML का visual result browser तय करता है
    • Creating Killer Web Sites में उन्होंने structural markup को bypass करने, images से two-dimensional layout बनाने, और tables आने पर columns में text डालने के तरीके पर चर्चा की
    • The History of the Web के Jay Hoffman ने बताया कि HTML/XML purists design और code structure के मिश्रण को बड़ा taboo मानते थे
    • table layout ने accessibility को नुकसान पहुँचाया और उसे ठीक करने में समय लगा, लेकिन इसने दिखाया कि developers web portals को visually compose कर सकते हैं
  • responsive design ने table layout की तरह existing technologies को नए तरीके से combine किया, लेकिन यह web standards के दायरे में screen size के अनुसार layout बदलने की method थी
    • 2000s के web design में 3 columns को page के bottom तक जारी रखने वाला “Holy Grail layout” CSS से implement करना बड़ा debate issue था
    • background images से fake columns बनाने जैसे कई workarounds थे, और बाद में CSS grid-based layout को support करने लगी
    • smartphones के फैलने के साथ existing 3-column layout का महत्व घटा, और अलग mobile website पर पैसे खर्च करने की स्थिति बन गई
    • Ethan Marcotte ने A List Apart के responsive web design article में media queries का उपयोग करके website layout को screen format के अनुसार fit करने का तरीका पेश किया
    • responsive design उस समय unfamiliar media queries का इस्तेमाल करने वाला hack जैसा दिखता था, लेकिन इसने web design को long term में बदल दिया

Internet Explorer era में images और comments के workarounds

  • AlphaImageLoader ने Internet Explorer 5 और 6 में PNG transparency सही से support न होने की समस्या को Microsoft-specific filter से bypass किया
    • Internet Explorer ने version 4 से PNG support किया था, लेकिन कई मामलों में सही render नहीं कर पाता था, खासकर IE5/IE6 में transparent PNG support न होना बड़ी समस्या थी
    • Perishable Press के Jeff Starr ने PNG fix for Internet Explorer में बताया कि उस समय के solutions को Microsoft के proprietary AlphaImageLoader transparency filter की जरूरत होती थी
    • उदाहरण में IE पर filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(...) apply किया जाता था, और non-IE browsers पर [class] selector से normal background image apply की जाती थी
    • इस तरह की छोटी feature gaps ने 2000s के अंत और 2010s की शुरुआत में developers को browser-specific hacks पर लगातार विचार करने के लिए मजबूर किया
  • Conditional Comments Microsoft द्वारा बनाया गया HTML comment extension था, जिससे IE version के आधार पर तय किया जा सके कि कोई specific HTML render होगा या नहीं
    • जब Internet Explorer ने websites implement करने के लिए बहुत ज्यादा hacks की मांग पैदा कर दी, तो Microsoft ने उन hacks को manage करने के लिए एक और hack introduce किया
    • मूल रूप से execution के लिए न बने HTML comments IE version conditions के अनुसार काम करने वाली structure में बदल गए
    • इसे पहली बार Internet Explorer 5 में introduce किया गया, और Windows के लिए Microsoft Outlook में complex email design के लिए आज भी कुछ मामलों में इसकी जरूरत पड़ती है
    • Jens Oliver Meiert ने 2007 के article में conditional comments की आलोचना की कि IE version support करते समय वे हर document या template के HTML को फिर से adjust करवाते हैं, जिससे structure और presentation के separation को नुकसान होता है
    • conditional comments IE9 के बाद हटा दिए गए, और JavaScript की conditional compilation को alternative method के रूप में इस्तेमाल किया जा सकता था

fonts, email और पुराने browsers के लिए non-standard combinations

  • sIFR(Scalable Inman Flash Replacement) JavaScript-based hack था, जिसमें web-safe fonts तक सीमित हुए बिना मनचाहा font दिखाने के लिए text को Flash embed से replace किया जाता था
    • Microsoft के Core Fonts for the Web ने सीमित web-safe fonts के इस्तेमाल को व्यवहार में encourage किया, और बाद में इसे बंद कर दिया गया
    • शुरुआती font replacement techniques images के इस्तेमाल से शुरू हुईं, लेकिन accessibility और presentation limitations थीं
    • Shaun Inman ने desired font को छोटी Adobe Flash file से replace करने का idea दिया, और Mike Davidson ने sIFR के जरिए fonts को जरूरत के अनुसार scale करने लायक बनाया
    • Davidson ने 2004 के sIFR release article में माना कि user द्वारा install न किए गए custom typeface deliver करने की समस्या अभी हल नहीं हुई थी
    • sIFR असली web fonts solution तक पहुँचने का intermediate step था, और Flash के mobile पर न पहुँच पाने के कारण लंबे समय तक नहीं टिक सका
  • preheader text hack में email client की preview line में अवांछित अगला body text जुड़ने से रोकने के लिए hidden characters और whitespace characters डाले जाते हैं
    • preheader वह छोटा text है जो email inbox में subject के बाद दिखता है, और email के subtitle की तरह काम करता है
    • email clients कभी-कभी HTML tags या unrelated body text को preview में खींच लाते हैं, इसलिए intended preheader और अगले text के बीच जबरन spacing insert की जाती है
    • Litmus द्वारा recommended example में display: none, max-height: 0px, overflow: hidden apply किए गए area में ͏, ‌,  ,  , ­ जैसे characters को बार-बार डालने का pattern था
  • Google Chrome Frame एक browser plugin था जो Internet Explorer के अंदर Chrome rendering engine इस्तेमाल कराता था, ताकि IE6-dependent environment में भी modern web features का उपयोग किया जा सके
    • कुछ enterprises मजबूत IT departments और IE6-based technologies पर निर्भरता के कारण latest browser पर जाना मुश्किल पाते थे
    • Google ने 2009 में Chrome Frame बनाया, जिससे पुराने Internet Explorer को modern engine मिला और developers को multiple versions बनाने या new features छोड़ने की जरूरत न पड़े
    • Chrome Frame retirement article के अनुसार उस समय कई users ऐसे browsers इस्तेमाल कर रहे थे जो latest features में पीछे थे
    • Google Wave और YouTube जैसे tools को HTML5 features की जरूरत थी, और IE6 support Google के लिए constraint था
    • Chrome Frame 5 साल तक market में रहा, और उस अवधि के बाद Chrome बहुत dominant browser बन गया

Safari/WebKit-specific support और web का वास्तविक evolution

  • WebKit-specific selector hack @supports (-webkit-appearance:none) {} की तरह specific browser-only CSS support का उपयोग करके सिर्फ WebKit family browsers पर CSS apply करने का तरीका है
    • Safari जब पहली बार आया, तो वह open source community में जड़ें रखने वाले engine पर आधारित था, और शुरुआत में HTML/CSS standards support मजबूत था
    • Apple Mail WebKit का उपयोग करता था, इसलिए email coding में इसे generally अच्छी तरह काम करने वाला environment माना जाता था
    • समय के साथ Safari release schedule Mac और iOS schedules से बँध गया, जिससे industry की तुलना में पीछे रहने की समस्या पैदा हुई
    • developers ने आलोचना की कि Apple bugs को ignore करता है या competitively disadvantageous features को delay करता है
    • Reddit के एक user ने Safari development complaint post में लिखा कि API implement करने पर भी उसमें बहुत bugs होते हैं या बाद में टूट जाता है
    • यह hack WebKit-based शुरू हुए शुरुआती Chrome versions में भी काम करता था
  • HTML का intent और real-world web usage काफी अलग हो गए, और designers व UI experts ने अजीब code के बावजूद internet पर visual presentation build किया
    • David Siegel की explanation के अनुसार standards bodies चाहती थीं कि HTML RSS की तरह final design से अधिक users और structure को महत्व देने वाले तरीके से काम करे
    • उसी दौर में आए Gopher जैसे protocols भी design impact कम रखने वाले तरीके से काम करते थे
    • लेकिन internet users की creativity और commercial internet की visual language पर निर्भरता के कारण वह philosophy mainstream नहीं बन सकी
    • email HTML में standard HTML/CSS से आसान transparent gradient handling भी मुश्किल है, और पुराने StackOverflow comment के HTML table glitch जैसे workarounds आज भी solution बन सकते हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-12-03
Hacker News की राय

  • लेआउट के लिए table का इस्तेमाल करना काफ़ी हद तक समझ में आता है
    लेकिन table के चलन से बाहर होने के बाद कुछ सालों तक लेआउट बनाने का मतलब बस float ही था। वह दौर ही असली उथल-पुथल भरा था, इसलिए उसका सूची से गायब होना हैरानी की बात है
    https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layou...
    “float प्रॉपर्टी, जिसे मूल रूप से text blocks के भीतर images को तैराने के लिए बनाया गया था, वेबपेज के multi-column layouts बनाने के सबसे आम टूल्स में से एक बन गई। flexbox और grid के आने के बाद अब यह फिर अपने मूल उद्देश्य पर लौट आई है”

    • जब float पहली बार आया था, तब मैंने एक computer repair साइट पूरी की पूरी FF में डेवलप की थी
      काम लगभग ख़त्म होने पर उसे IE में खोला तो पूरा डिज़ाइन बिखर गया, और target customers लगभग पक्का IE ही इस्तेमाल करने वाले थे, इसलिए आख़िरकार उसे table-based लेआउट में फिर से लिखना पड़ा। वह दुखभरा दिन था
    • शुरू से ही table-based layout को हैक कहना मुझे खटकता था
      table के हटने के बाद मैंने बहुत-सी frontend टीमों को “purists” के सिद्धांत बचाने के लिए float की कसरत में महीनों बर्बाद करते और कहीं ज़्यादा कम-समझ आने वाले webpages बनाते देखा, और वहीं से मैंने एक अहम सबक सीखा
      Joel Spolsky ने एक बेहतरीन लेख में ऐसे डेवलपर्स को Architecture Astronauts कहा था — ऐसे लोग जो यह भूल जाते हैं कि उनका काम कम-से-कम मेहनत में सही से चलने वाला software बनाना है। मुझे लगता है कि पहली EJB spec की बेतुकापन या Java के मज़ाक बन चुके AbstractFactoryBuilderConstructor जैसी चीज़ें भी उसी प्रवृत्ति की उपज थीं
      समय के साथ मैं ऐसी प्रवृत्ति को जल्दी पहचानकर उससे दूर रहने लगा
    • “कई साल तक float से लेआउट बनाना” faux columns के नाम से जाना जाता था, और साधारण 3-column layout भी इतना मुश्किल था कि उसे लेआउट का “holy grail” तक कहा जाता था
      https://en.wikipedia.org/wiki/Holy_grail_(web_design)#Faux_c...
    • W3Schools अभी भी जिसे यही कहता है, वह नया और आधुनिक clearfix hack
      .clearfix::after { content: ""; clear: both; display: table; }
      [1] https://www.w3schools.com/howto/howto_css_clearfix.asp
    • table और flexbox/grid के बीच का दौर कठिन था
      float नाज़ुक था और उसे ठीक से जमाना मुश्किल था, और बहुत-से लोग बस table पर लौट गए — और सच कहूँ तो उन्हें दोष भी नहीं दिया जा सकता था

  • क्या spacer.gif को कोई इज़्ज़त नहीं मिलती?
    HN में तो वह अब भी है, और हर page request में शामिल होता है
    https://news.ycombinator.com/s.gif

    • spacer image का ज़िक्र किए बिना table-based layout की बात पूरी नहीं होती

  • कुछ चीज़ें थीं जो मुझे पसंद थीं
    Faux columns से sidebar को देखने में इतना बढ़ा हुआ दिखाया जा सकता था कि वह main content जितना लंबा लगे: https://alistapart.com/article/fauxcolumns/
    इससे आगे बढ़कर 9-patch और 9 divs या 3x3 table के साथ हर axis पर background को repeat करके अपने हाथ से borders की नकल की जा सकती थी। CSS3 में border-image आने से थोड़ी मदद मिली, लेकिन इस तरह के border styles अब ज़्यादा चलन में नहीं हैं
    rounded borders भी 9-patch से बनाए जा सकते थे, और बहुत-से लोग generators से ऐसे कई elements वाला HTML बनाते थे जो rounded borders को simulate करे। यह लेख समझाता है: http://benogle.com/2009/04/29/css-round-corners.html आम तौर पर यह समझ थी कि extra markup bytes में images से बड़ा होता है, लेकिन round-trip requests कम हो जाती हैं और यह काफ़ी आसानी से किया जा सकता है

    • हमारी टीम ने 3x3 approach का इतना ज़्यादा इस्तेमाल किया कि उसके लिए एक component ही बना दिया
      वह ActionScript की दुनिया के थोड़ा ज़्यादा क़रीब था, लेकिन styling का विचार वही था, इसलिए हमने इस पर एक लेख भी लिखा: https://brajeshwar.com/2005/splice9-bitmap-window-resizer-co...
      एक और दिलचस्प चीज़ non-repeating background style patterns के लिए cicada principle का इस्तेमाल था
    • A List Apart खोला तो mobile पर header टूटा हुआ देखकर काफ़ी झटका लगा
      फिर भी, इतना समय बीतने के बाद भी यह अब तक साफ़-सुथरा दिखता है
    • rounded corners के लिए sliding doors technique का भी ज़िक्र होना चाहिए: https://alistapart.com/article/slidingdoors/
    • Faux columns अब भी हमारी मुख्य वेबसाइट में ज़िंदा हैं। उन्हें कुछ ज़्यादा आधुनिक से बदलने का समय कभी मिला ही नहीं ;)

  • यह बात अच्छी लगती है कि HN आज भी इनमें से एक का इस्तेमाल करता है: HTML table से layout बनाना
    थोड़ा गंभीर होकर देखें तो यह सूची अच्छी तरह दिखाती है कि standards के बिना development करने पर control information कई “किसी तरह चल जाने वाले” side channels में encode हो जाती है
    इस तरह की अव्यवस्था और टकराव की संभावना देखकर आज की W3C process को कभी-कभी जो तिरस्कार मिलता है, उसे फिर से सोचना पड़ता है। यह process standards-driven web technology evolution और browser-driven innovation को जोड़ती है, और दोनों को बारी-बारी से आगे बढ़ने या साथ-साथ चलने देती है
    इसका अक्सर मज़ाक उड़ाया जाता है, लेकिन इसे पहले के तरीकों की तुलना में ज़्यादा टिकाऊ और स्थिर तरीका भी माना जा सकता है
    सोचता हूँ, नए W3C-vendor nexus की आलोचना करने वालों में से कितने लोग वास्तव में उन उत्साहित दिनों में लौटना चाहेंगे, जिनकी याद ये “10 अजीब हैक्स” दिलाते हैं

    • यह standards की अनुपस्थिति से ज़्यादा ज़रूरी functionality की अनुपस्थिति का मामला है
      अगर जो काम आप करना चाहते हैं वह किसी feature के रूप में मौजूद नहीं है, तो आप उसे किसी न किसी creative तरीके से कर ही लेते हैं। Standards अगर इतने mature हो जाएँ कि वे संभावित ज़रूरतों को पकड़ ही न पाएँ, तो वे उल्टा rigidity पैदा करते हैं और ऐसी स्थिति बनती है। खासकर web में, जहाँ आपको ऐसे standards से बँधना पड़ता है जो आपकी ज़रूरत के मुताबिक हों भी सकते हैं और नहीं भी
      दूसरे क्षेत्रों में आमतौर पर विकल्प काफी होते हैं, इसलिए उनमें से कोई न कोई इतना flexible होता है कि काम हो जाए, और आप वही चुन लेते हैं
      अगर आपने research में लंबे समय तक काम किया है, तो आपको हैरानी होगी कि कितनी बार मनचाहा काम करने के लिए hacky technical approaches की ज़रूरत पड़ती है। बहुत से standards और feature sets business/consumer interactions और उनके आसपास के systems को ध्यान में रखकर बनते हैं, क्योंकि पैसा वहीं जाता है
    • दुर्भाग्य से आजकल W3C और TC39 पर Google का लगभग पूरा दबदबा है, और वह प्रक्रिया की परवाह लगभग सिर्फ औपचारिकता के स्तर पर करते हुए कई standards को आगे धकेलता है
      browser features पर निर्भर कई खिलाड़ी, जैसे वे TV vendors जो apps को WebKit या Chromium versions के अंदर चलाते हैं, standards committees में पूरी तरह चुप रहते हैं। इसलिए यह स्थिति वास्तव में Google, Apple और Mozilla की तीन-तरफ़ा रस्साकशी जितनी भी नहीं रह जाती
    • मज़ेदार है कि tables के “गायब हो जाने” के बाद उनकी जगह बड़े पैमाने पर Bootstrap ने ले ली
      नतीजा यह हुआ कि आपको div के अंदर tables मिलती हैं। बस वे 12-column वाली होती हैं
    • WHATWG ने web को non-profit हितों के लिए नहीं, बल्कि सिर्फ commercial interests के लिए आगे बढ़ाया है
      मैंने HTML 3.2 से सीखा था, इसलिए मुझे अच्छी तरह पता है कि IE और Netscape की वजह से कैसी Byzantine बेवकूफ़ियाँ करनी पड़ती थीं। लेकिन वह MS और Netscape की पसंद थी, और भले ही W3C की मौजूदगी ज़्यादा मज़बूत होती, इससे यह न तो तय होता और न ही संकेत मिलता कि MS और Netscape नए standards मानते
      फिर भी, आज की उस बेकार स्थिति से वह समय बेहतर था जिसमें एक विशाल कंपनी जो चाहे और बाकी web को उसका बोझ उठाना पड़े
      वाकई बहुत बेहतर था, है ना /s

  • मेरा “पसंदीदा” hack इसमें छूटा हुआ है। accessibility heading को -10000 position पर रखना, ताकि वह screen पर render न हो लेकिन screen reader उसे पढ़ सके

    • इसका एक काफ़ी मिलता-जुलता रूप आज भी आम है। क्योंकि हर स्थिति में ऐसा text जो दिखता नहीं लेकिन screen reader के लिए accessible हो उसे संभालने का अब भी कोई शानदार विकल्प नहीं है
      aria-label जैसी चीज़ों ने इस pattern के कुछ use cases को replace किया है, लेकिन सभी को नहीं
    • क्या यह अब भी काम करता है? या फिर ARIA इस्तेमाल करना चाहिए?

  • उस html5 shiv की बात नहीं है, जिसे सारे CSS से पहले डालकर browser quirks हटाए जाते थे
    https://paulirish.com/2011/the-history-of-the-html5-shiv/

    • reset, normalize जैसी चीज़ें भी छूट गईं

  • table cells को ठीक-ठाक बनाए रखने के लिए इस्तेमाल होने वाले transparent 1×1 pixel GIF के अच्छे पुराने दिन याद आ गए

    • “अच्छे पुराने दिन”? यह page जिसे आप अभी देख रहे हैं, वही भी इसका इस्तेमाल कर रहा है ;)
      https://news.ycombinator.com/item?id=38485665
    • पहले लोग बड़ी images को grid pattern में काटकर tables से पकड़े रखते थे
      अब याद भी नहीं कि ऐसा क्यों करते थे। क्या तेज़ loading के लिए था?

  • शुरुआती दौर की एक और चीज़ जोड़ें तो, non-breaking space character entity   का व्यापक इस्तेमाल था
    इसे container के अंदर text को दाएँ या बाएँ धकेलने के लिए इस्तेमाल किया जाता था, और जहाँ तक मुझे याद है, table cells को संभालकर रखने के लिए इसे 1x1 spacer GIF की तरह भी इस्तेमाल किया जाता था। कुछ pages पर सैकड़ों   होते थे, और यह margin या padding डालने के लगभग एक generic तरीके जैसा था

  • कभी-कभी समझ नहीं आता कि modern web developers CSS Grid और IE के मर जाने की वजह से बिगड़ गए हैं, या हम उस समय modern frameworks और build process की complexity न झेलने की वजह से बिगड़े हुए थे

    • शायद दोनों ही बात सही है
      लेकिन आजकल चीज़ें ज़्यादा आसान लगती हैं। तकनीकी रूप से modern frameworks और build process का इस्तेमाल ज़रूरी नहीं है, और सिर्फ modern CSS और JavaScript से ही ऐसे sites और apps आसानी से बनाए जा सकते हैं जो पहले काफ़ी complex होते थे
    • web development में एक अलग तरह की nuance है, कम-से-कम उन दूसरे क्षेत्रों की तुलना में जहाँ मैंने काम किया है
      industry ने पहिया बार-बार और ज़्यादा जटिल तरीके से फिर से बनाने की आदत डाल ली है
      सबसे plausible अंदाज़ा यह है कि web ऐसा क्षेत्र है जिसे नए developers या कम अनुभवी developers ज़्यादा चुनते हैं, और यह उसी का side effect है

  • क्या responsive design सच में hack है? Media queries शानदार हैं
    conditional logic को JavaScript में रखने के बजाय CSS में रखना बड़ी जीत है। खासकर जब आप server-side rendering चाहते हों

    • अलग-अलग media को support करने के लिए media queries का इस्तेमाल करना तो बिल्कुल सही use case लगता है
    • अगर आप वास्तव में जो जानना चाहते हैं उसे query नहीं कर रहे, बल्कि ऐसी चीज़ को query कर रहे हैं जिसका उससे सिर्फ संयोगवश correlation है, तब वह hack बन जाता है
    • यह hack नहीं है
      आप user agent की कई properties को query कर सकते हैं और नतीजे के आधार पर अलग CSS दे सकते हैं। इसे hack कहना अज्ञानता है, और responsive design बनाने के लिए यह ज़रूरी हिस्सा है