बस button का उपयोग करें

 (gomakethings.com)
10 पॉइंट द्वारा GN⁺ 2025-11-02 | 7 टिप्पणियां | WhatsApp पर शेयर करें
  • वेब इंटरफ़ेस में की जगह का उपयोग करना accessibility और functionality दोनों के लिहाज़ से सही विकल्प है
  • `` को screen reader interactive element के रूप में नहीं पहचानते, और यह keyboard focus या Enter, Spacebar इनपुट पर भी प्रतिक्रिया नहीं देता
  • [role="button"] या [tabindex="0"] attributes जोड़ने पर भी focus order की गड़बड़ी और keyboard event handling की समस्या बनी रहती है
  • इन समस्याओं को हल करने के लिए कई event listeners और conditional statements जोड़ना अनावश्यक जटिलता पैदा करता है
  • `` accessibility, focus, और keyboard input handling की सुविधाएँ डिफ़ॉल्ट रूप से देता है, इसलिए यह सरल और standard समाधान है

गलत तरीका: `` से button बनाना

  • React या HTMX उपयोगकर्ताओं के बीच `` के रूप में modal खोलने जैसी interactions लागू करने के उदाहरण बहुत मिलते हैं
    • उदाहरण कोड: 
      Open Modal
  • इस तरीके की समस्याएँ
    • screen reader इस element को interactive element के रूप में नहीं पहचानते
    • keyboard से focus ले जाना संभव नहीं होता
    • केवल click event चलता है, Enter या Spacebar इनपुट पर प्रतिक्रिया नहीं होती

accessibility “ठीक” करने की कोशिशों की सीमाएँ

  • [role="button"] attribute जोड़ने से screen reader पहचान की समस्या तो हल हो जाती है, लेकिन focusability और keyboard input handling की समस्या फिर भी बनी रहती है
  • [tabindex="0"] जोड़कर focus संभव बनाया जा सकता है, लेकिन focus order बिगड़ने या अप्रत्याशित रूप से focus move होने का जोखिम रहता है
  • keyboard input को संभालने के लिए keydown event को global (document) पर register करना पड़ता है, और Enter या ' ' (space) key को detect करके focused element को ढूँढकर चलाना पड़ता है 
    document.addEventListener('keydown', (event) => {
  if (event.key !== 'Enter' && event.key !== ' ') return;
  const notRealBtn = document.activeElement.closest('[onclick]');
  if (!notRealBtn) return;
  // 실행 코드
});
  • नतीजे में, `` जो सुविधाएँ डिफ़ॉल्ट रूप से देता है, उन्हीं को जटिल तरीके से दोबारा लागू किया जाता है

`` द्वारा दी जाने वाली डिफ़ॉल्ट सुविधाएँ

  • `` element अपने आप निम्नलिखित को support करता है
    • implicit role ([role="button"])
    • automatic focusability
    • focus की स्थिति में Enter और Spacebar इनपुट पर click event trigger होना
  • यही behavior में लागू करने के लिए **कई attributes और scripts की ज़रूरत** पड़ती है, जबकि से यह एक ही लाइन में हो जाता है 
    Open Modal

निष्कर्ष: सादगी ही सबसे अच्छा विकल्प है

  • `` accessibility standards को पूरा करते हुए code की मात्रा कम करने का सबसे सरल तरीका है
  • अनावश्यक event handling या attributes जोड़े बिना standard HTML elements का उपयोग करना maintenance और efficiency दोनों के लिए बेहतर है
  • “जितने आलसी developer होंगे, उन्हें उतना ही सही element इस्तेमाल करना चाहिए” — यह संदेश अनावश्यक जटिलता से बचने और built-in features का उपयोग करने वाली development आदतों के महत्व पर ज़ोर देता है

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

7 टिप्पणियां

 
come2mecome 2025-11-04

बहुत अच्छा लेख है। इसके मुख्य संदेश को "HTML tag का अर्थपूर्ण तरीके से इस्तेमाल करें." के रूप में संक्षेपित किया जा सकता है। अगर div (या किसी अन्य) tag से click event दिया जाता है, तो मुझे लगता है कि यह उस पुराने दौर से बिल्कुल अलग नहीं है जब layout table tag से बनाया जाता था।
 
carnoxen 2025-11-11

बिलकुल, aria-* attributes डालने से बात ज़्यादा साफ़ हो सकती है, लेकिन इतनी मेहनत करने से बेहतर है कि सीधे सही tag इस्तेमाल कर लो हाहाहा
 
roxie 2025-11-06

यादें ताज़ा हो गईं हाहा
 
nemorize 2025-11-02

button का इस्तेमाल करें

background, border, outline, appearance, -webkit-appearance, cursor
ओवरराइड करनी पड़ने वाली default stylesheet बहुत ज़्यादा हैं, रोना आता है
 
rtyu1120 2025-11-03

इसीलिए CSS Reset होता है।
 
carnoxen 2025-11-02

हमारे देश की सरकारी वेबसाइटों में `` का बहुत इस्तेमाल होता है...
 
GN⁺ 2025-11-02
Hacker News राय

  • मेरी शिकायतों में से एक यह है कि वेबसाइटें नेविगेशन को onclick handler से लागू करती हैं बस `` tag का इस्तेमाल करें, तो नया tab खोलना, accessibility devices के साथ integration, right-click menu आदि सब अपने-आप सही काम करते हैं अगर यह नेविगेशन है, तो JavaScript soup की जगह link का इस्तेमाल करना चाहिए

    • पिछले कुछ वर्षों में इस तरह के implementation बढ़े हैं शायद framework के प्रभाव या लापरवाही की वजह से फिर भी पारंपरिक तरीका UX के लिहाज़ से लगभग हमेशा बेहतर होता है जो लोग `` tag को replace करना चाहते हैं, उन्हें थोड़ा असुविधा होनी ही चाहिए
    • मुझे लगता है समस्या यह है कि React से शुरुआत करने वाले developers ने HTML की बुनियादी अवधारणाएँ सीखे बिना सीधे “मज़ेदार चीज़ों” पर छलांग लगा दी ऐसे लोग गलत pattern बनाते हैं और बाद के developers वही जैसा-का-तैसा follow करते हैं `` को button की तरह सजाने की ज़रूरत मुझे बहुत कम पड़ी है
    • JS-based scrolling भी खत्म होनी चाहिए मैं अक्सर mouse के middle button से scroll करता हूँ, और बहुत-सी sites इसे तोड़ देती हैं
    • यह बात सुनकर Microsoft Office 365 का link checker याद आता है left-click करने पर safety check page खुलता है, लेकिन middle-click करने पर सीधे चला जाता है
    • हाल ही में जिस React project में मैंने हिस्सा लिया, उसमें भी सारा नेविगेशन onClick से किया गया है जो elements असल में link हैं, उन्हें भी click handler से संभाला जा रहा है, जो मेरी समझ से बाहर है

  • ज़्यादातर buttons में type="button" साफ़-साफ़ लिखना चाहिए default value submit होती है, इसलिए form के अंदर होने पर वह अपने-आप submit हो जाता है शायद कुछ developers यह नहीं जानते, इसलिए `` का इस्तेमाल करते हैं

    • मुझे लगता है OP की लंबी पोस्ट में यह मुख्य जानकारी छूट गई default type वाला button अजीब तरह से व्यवहार करता है और कभी-कभी JS handler को bypass भी कर देता है
    • default दरअसल के बराबर है और अलग है
    • मैंने भी यह बात खुद अनुभव करके सीखी
    • इस्तेमाल करने से `type="submit"` वाली समस्या से बचा जा सकता है शुरू से खाली होता है, इसलिए ज़रूरत की functionality ही जोड़ी जाती है, और बाद में बदलना भी आसान होता है वहीं `` का default behavior समझने के लिए documentation देखनी पड़ती है आख़िरकार यह explicit control vs built-in features के बीच चुनाव का मामला है

  • अच्छा होता अगर लेख को “जिस काम के लिए HTML element बना है, उसी काम के लिए उसका इस्तेमाल करें” इस दिशा में और बढ़ाया जाता कई SPA developers को HTML elements का semantics ठीक से पता नहीं होता, इसलिए वे हर बार पहिया फिर से बना देते हैं

    • अच्छा होता अगर elements को थोड़ा ज़्यादा styling-friendly बनाया गया होता उदाहरण के लिए default date picker इतना बदसूरत होता है कि लोग उसे JS-based चीज़ से replace कर देते हैं
    • “platform का जैसा है वैसा इस्तेमाल करो” यह बात HTML5 के बाद frontend में बार-बार कही जाती रही है, लेकिन अभी तक हर जगह नहीं पहुँची
    • हक़ीक़त में ज़्यादातर developers HTML elements के बारे में लगभग कुछ नहीं जानते और एक DIV से सब हल करने की कोशिश करते हैं
    • लगभग 2010 के आसपास browsers में button styling अलग-अलग होती थी, इसलिए उन्हें खुद बनाना पड़ता था इसी वजह से custom button आने की पृष्ठभूमि बनी

  • आजकल ऐसी पीढ़ी आ गई है जो clickable area ढूँढने के लिए स्क्रीन पर इधर-उधर दबाती फिरती है 10 साल पहले किसी ने link drag को text selection से ज़्यादा अहम बना दिया, और अब text select करना लगभग नामुमकिन हो गया है इसे ठीक करने के लिए शायद browser fork करना पड़े

    • मुझे link को drag करके background tab में खोलने की आदत है Alt (या Option) key दबाने पर link के अंदर का text select किया जा सकता है
    • iOS में phone number copy करने की कोशिश करो और वह अपने-आप call कर दे, यह भी वैसी ही चिढ़ाने वाली चीज़ है यह सच में अनचाहा behavior है
    • non-selectable text पागल कर देता है macOS की TextSniper app से area select करके OCR के ज़रिए text copy किया जा सकता है इसकी वजह से Google Analytics भी थोड़ा इस्तेमाल लायक हो जाता है
    • मैं भी अक्सर link के अंदर के कुछ text को select करना चाहता हूँ और असफल हो जाता हूँ इस तरह की समस्या का ज़्यादा बार ज़िक्र होना चाहिए
    • link text selection के लिए browser extension भी है पहले उसका नाम Select Like A Boss था, अब Drag-Select Link Text है

  • Chrome की default stylesheet में button {align-items: flex-start} होने की वजह से मैं flexbox sizing bug में काफ़ी देर तक उलझा रहा फिर भी मैं जहाँ तक संभव हो सही HTML elements का इस्तेमाल करने की कोशिश करता हूँ, लेकिन छोटे side projects में कभी-कभी `` ज़्यादा आसान लगता है

    • appearance: none property button styling reset करने में काम आती है मैं .unbuttonify class बनाता हूँ ताकि वह button की तरह काम करे लेकिन दिखे अलग तरह से
    • मैं यह ज़ोर देकर कहना चाहता हूँ कि frontend developers को CSS की बुनियाद पता होनी चाहिए

  • जहाँ तक हो सके, elements का इस्तेमाल उनके मूल उद्देश्य के अनुसार करना चाहिए

  • button को लेकर मेरी दो शिकायतें हैं एक तो यह कि आपको वैसे भी styling फिर से करनी पड़ती है, दूसरी यह चेतावनी कि buttons को nest नहीं किया जा सकता व्यवहार में यह काफ़ी बार सामने आ जाता है

  • LLM अक्सर ऐसे गलत patterns generate करते हैं वे browser की built-in functionality को नज़रअंदाज़ करके चीज़ों को बेवजह जटिल बना देते हैं मैं अक्सर Claude से कहता हूँ कि ऐसे code को simplify करे TypeScript में भी error handling को अजीब बनाने की प्रवृत्ति होती है

    • LLM की code लिखने की क्षमता शानदार है, लेकिन software engineering की समझ कमज़ोर है
    • token prediction की प्रकृति के कारण, LLM ज़्यादा जटिल patterns को अधिक बार चुनते हैं

  • मैं जहाँ तक संभव हो default रूप से button का इस्तेमाल करता हूँ लेकिन अगर चीज़ को असल में link की तरह काम करना है, तो `` tag इस्तेमाल करता हूँ

    • अगर URL बदलता है तो वह link है, नहीं बदलता तो button
    • “वेब ऐप के भीतर नेविगेट करने वाला hyperlink” है, तो वह `` tag है

  • मैं सोच रहा था कि आखिर `` इस्तेमाल करने की राय आती ही क्यों है

    • शायद इसलिए कि `` अजीब visual customization के लिए ज़्यादा सुविधाजनक है और इसी वजह से वह न button जैसा दिखता है, न button जैसा काम करता है
    • उदाहरण के लिए TV Tropes जैसी sites लंबी सूची को “folder” की तरह collapse/expand करती थीं, और इसे `` से लागू किया गया था
    • सबसे आम वजह यह है कि लोग default button styling को override करने की झंझट नहीं चाहते