यदि आप शून्य से एक बटन बनाना चाहते हैं, तो आपको पहले ब्रह्मांड बनाना होगा
आज के वेब पर शून्य से एक साधारण-सी चीज़, जैसे बटन, फिर से बनाना यह दिखाता है कि native HTML controls कितना व्यवहार, accessibility, और cross-device nuance पहले से प्रदान करते हैं — और उन विवरणों को गलत करना कितना आसान है। टिप्पणीकार बहस करते हैं कि richer native widgets (जैसे एक वास्तविक combobox) दशकों से क्यों ठहरे हुए हैं, और इसके लिए browser politics, Web Components जैसे awkward standards, तथा “document” HTML और app-like interfaces के बीच तनाव को जिम्मेदार ठहराते हैं। Accessibility एक वास्तविक तकनीकी और नैतिक चिंता के साथ-साथ एक कानूनी minefield के रूप में उभरती है, जहाँ कुछ लोग मानते हैं कि AI और smarter tooling जल्द ही इस जटिलता का बड़ा हिस्सा संभाल लेंगे, जबकि अन्य चेतावनी देते हैं कि इसे opaque agents पर छोड़ना usability, privacy, और reliability को और खराब कर सकता है.
व्यंग्य, बटन, और पहुंच-योग्यता की जटिलता
- बहुत से लोग इस लेख को व्यंग्यात्मक ढंग से प्रस्तुत किए जाने के बावजूद सटीक मानते हैं: सही तरीके से एक बटन को फिर से बनाना आश्चर्यजनक रूप से कठिन है।
- कुछ पाठकों ने इसे शिक्षाप्रद पाया, क्योंकि वे फ्रेमवर्क्स पर निर्भर रहे थे और कई पहुंच-योग्यता संबंधी चिंताओं के बारे में नहीं जानते थे।
- अन्य लोग नोट करते हैं कि उदाहरण कोड में अभी भी बग हैं (जैसे, गलत pointer/mouse-up लॉजिक), जो इस बात को और मजबूत करता है कि इसे “सही” तरीके से करना मुश्किल है।
मूल HTML बनाम कस्टम कंपोनेंट्स और गायब विजेट्स
- कई लोगों का तर्क है कि जटिल विजेट्स (जैसे server-side filtering वाले comboboxes) केवल native HTML के साथ करना कठिन या असंभव है, जिससे डेवलपर्स कस्टम implementations की ओर बढ़ते हैं।
<input>+<datalist>को combobox का आंशिक समाधान बताया जाता है, लेकिन dynamic/efficient updating और समृद्ध व्यवहार में अभी भी कमियाँ हैं।- इस बात को लेकर निराशा है कि HTML में अभी भी कई उच्च-स्तरीय विजेट्स नहीं हैं, जो native toolkits में दशकों पहले मौजूद थे।
ब्राउज़र विक्रेता, मानक, और ठहराव
- कुछ लोग HTML-native, JavaScript-free components पर धीमी प्रगति के लिए सभी प्रमुख ब्राउज़रों को दोष देते हैं।
- अन्य लोग यह कहे जाने का विरोध करते हैं कि Apple अकेले प्रगति रोक रहा है, और Open UI जैसे standards तथा गति बनाम सुरक्षा की अलग-अलग philosophies की ओर इशारा करते हैं।
- Safari का built-ins को extend करने का समर्थन न करना (जैसे
class MyButton extends HTMLButtonElement) चर्चा में आता है; आलोचकों का कहना है कि यह हल्की customization की बजाय पूरी re‑implementation को मजबूर करता है।
वेब बनाम “semantic web” और एप्लिकेशन की ज़रूरतें
- टिप्पणीकार document-centric “semantic web” और अत्यधिक interactive web applications के बीच अंतर करते हैं।
- Business और UX requirements अक्सर native form controls से मिलने वाली चीज़ों से अलग होती हैं; केवल native elements के साथ उन अपेक्षाओं को पूरा करना अव्यावहारिक या बहुत महंगा माना जाता है।
UI और accessibility पर AI का प्रभाव
- एक पक्ष का दावा है कि AI अब scratch से जटिल, accessible components और tests बनाना बहुत आसान कर देता है, जिससे “button को फिर से मत बनाओ” वाला तर्क कमजोर पड़ता है।
- दूसरे लोग जवाब देते हैं कि AI सामान्य गलतियाँ दोहराता है (जैसे navigation के लिए buttons का गलत उपयोग), अपने आप सभी edge cases को नहीं कवर करता, और code bloat को बढ़ावा दे सकता है।
- कुछ लोग मौजूदा apps में accessibility जोड़ने के लिए LLMs से मदद लेने के अच्छे अनुभव साझा करते हैं; अन्य लोग चिंता जताते हैं कि “shitty code” पर प्रशिक्षित models खराब patterns को फैलाएँगे।
पहुंच-योग्यता अनुपालन, मुकदमे, और “racket” संबंधी चिंताएँ
- एक कहानी साझा की जाती है जिसमें accessibility lawsuit के कारण महंगे, काफी हद तक सतही बदलाव हुए और “compliance” subscriptions चलती रहीं।
- इस पर बहस है कि क्या भविष्य के AI screen readers/agents कड़े technical compliance को कम प्रासंगिक बना देंगे, या कानून और प्रोत्साहन वर्तमान प्रणाली को बनाए रखेंगे।