Γιατί το <div> Δεν Είναι Ποτέ η Σωστή Επιλογή για Button

Όλοι το έχουμε πάθει. Φτιάχνεις ένα component library και η σχεδίαση ζητάει ένα button. Όχι ένα τυπικό button—ένα ιδιαίτερο button. Με custom styling, ένα hover effect που τραβάει το μάτι, ίσως ένα gradient που αλλάζει όταν το πατάς.

Οπότε αρπάζεις ένα <div>, βάζεις λίγο CSS, και το αφήνεις να δουλέψει.

Στο Figma φαίνεται τέλειο. Δουλεύει μια χαρά στο demo σου. Και μετά ένας πραγματικός χρήστης προσπαθεί να κάνει tab μέσα από τη σελίδα, να στείλει μια φόρμα με το πληκτρολόγιο, ή να πλοηγηθεί με ένα screen reader—και εκεί αρχίζουν τα προβλήματα.

Το πρόβλημα δεν είναι το CSS σου. Το πρόβλημα είναι ότι ζήτησες από ένα <div> να κάνει μια δουλειά που δεν σχεδιάστηκε ποτέ να κάνει.

Το Div που Ήθελε να Γίνει Button

Αυτό που συμβαίνει συνήθως είναι το εξής: χρειάζεσαι ένα button που να δείχνει συγκεκριμένα. Φτιάχνεις ένα <div>, βάζεις class="btn", και το στυλάρεις μέχρι να ταιριάζει με το design. Φαίνεται υπέροχο. Αλλά μετά χρειάζεται να κάνει και τα πράγματα που κάνει ένα button.

Οπότε προσθέτεις ένα click handler. Μετά ένα hover state. Μετά ένα focus ring για τους χρήστες που χρησιμοποιούν πληκτρολόγιο. Μετά συνειδητοποιείς ότι τα Space και Enter δεν λειτουργούν, οπότε προσθέτεις keydown listeners. Το button πρέπει να είναι disabled κάποιες φορές, οπότε προσθέτεις μια κλάση .disabled που ελπίζεις να μπλοκάρει όλες τις σωστές αλληλεπιδράσεις. Κάπου εκεί μέσα, προσθέτεις και role="button" με tabindex="0" για να μην σε αγνοεί εντελώς το accessibility tooling.

Συγχαρητήρια. Έχεις φτιάξει ένα αντικείμενο σε σχήμα button που χρειάζεται περίπου 200 γραμμές JavaScript για να πλησιάσει αυτό που ο browser θα σου είχε δώσει δωρεάν.

Αυτό εννοούμε όταν μιλάμε για "πληρώνεις το ενοίκιο" κακών αρχιτεκτονικών αποφάσεων. Κάθε γραμμή workaround κώδικα είναι τόκος πάνω στην αρχική επιλογή να χρησιμοποιήσεις το λάθος element.

Το Άγραφο Συμβόλαιο

Υπάρχει κάτι που οι περισσότεροι developers δεν σκέφτονται ποτέ—μέχρι να το χάσουν. Τα native HTML elements έρχονται με ένα ολόκληρο "συμβόλαιο αλληλεπίδρασης".

Όταν χρησιμοποιείς ένα πραγματικό <button>, παίρνεις:

• Αυτόματο keyboard handling — Enter και Space λειτουργούν ακριβώς όπως περιμένουν οι χρήστες
• Σωστό focus management — Μπαίνει στη σειρά tab φυσικά, μπορεί να γίνει focus programmatically
• Disabled state — Μπλοκάρει κάθε αλληλεπίδραση, δεν γίνεται focus, ανακοινώνεται ως disabled
• Συμμετοχή σε forms — Στέλνει forms, σέβεται την validation, συμμετέχει στο form.reset()
• Accessibility semantics — Τα screen readers το ανακοινώνουν ως button χωρίς επιπλέον ARIA
• Platform conventions — Οι χρήστες ξέρουν ήδη πώς συμπεριφέρονται τα buttons γιατί τα buttons συμπεριφέρονται συνεπώς παντού

Με ένα <div> μεταμφιεσμένο σε button, παίρνεις... το CSS. Όλα τα υπόλοιπα είναι δική σου ευθύνη. Και ιδού το βρώμικο μυστικό: όσο προσεκτικός κι αν είσαι, η υλοποίησή σου θα είναι χειρότερη από αυτό που παρέχουν οι browsers. Οι browsers έχουν ολόκληρες ομάδες μηχανικών που βελτιστοποιούν αυτές τις συμπεριφορές σε διαφορετικές πλατφόρμες, edge cases, και assistive technologies. Η custom υλοποίησή σου έχει μόνο εσένα.

Η Πραγματική Ερώτηση Δεν Είναι "Μπορώ να το Στυλάρω;"

Εδώ είναι το σημείο όπου η συνεργασία design και engineering είτε διαπρέπει είτε δημιουργεί technical debt. Οι developers συχνά ερμηνεύουν το "semantic HTML" ως "δεχόμαστε τα άσχημα defaults του browser". Αυτό δεν είναι καθόλου αυτό που συζητάμε.

Η ερώτηση δεν είναι "μπορώ να το κάνω να δείχνει custom;" Μπορείς, οπωσδήποτε. Η ερώτηση είναι: "ποιες native συμπεριφορές πρέπει να επιβιώσουν μετά το styling;"

Ένα <button> μπορεί να έχει οποιαδήποτε οπτική μεταχείριση θέλεις. Μπορείς να αφαιρέσεις όλα τα default styles με appearance: none. Μπορείς να προσθέσεις gradients, shadows, animations, custom fonts—ό,τι ζητάει το design. Το interaction contract του browser δεν νοιάζεται πώς φαίνεται το button σου.

Αυτό που δεν μπορείς να κάνεις εύκολα με ένα <div> είναι να αναπαράγεις αυτό που σου δίνει ο browser αυτόματα. Οπότε διάλεξε τις μάχες σου: ξόδεψε την engineering προσπάθειά σου σε αυτό που κάνει το προϊόν σου μοναδικό, όχι στο να ξαναφτιάχνεις buttons.

Χτίζοντας για τον Πραγματικό Web

Οι χρήστες σου δεν χρησιμοποιούν το προϊόν σου σε κενό. Κάνουν tab ανάμεσα σε πεδία ενώ τα χέρια τους είναι στο πληκτρολόγιο. Χρησιμοποιούν voice control για να πλοηγηθούν. Μεγεθύνουν την οθόνη στο 300% γιατί αυτό τους βολεύει. Έχουν διαφορετικά browsers, διαφορετικά λειτουργικά συστήματα, διαφορετικές assistive technologies.

Το web platform σου δίνει ένα τεράστιο προβάδισμα με το semantic HTML. Τα native elements είναι accessible by default, keyboard-navigable by default, cross-platform by default. Όταν πολεμάς αυτή την υποδομή, δεν κάνεις απλά περισσότερη δουλειά στον εαυτό σου—δημιουργείς components που θα αποτυγχάνουν με υπονοούμενους τρόπους για πραγματικούς χρήστες.

Την επόμενη φορά που πας να αρπάξεις ένα <div> με role="button", ρώτα τον εαυτό σου: φτιάχνω κάτι που χρειάζεται πραγματικά custom υλοποίηση, ή απλά φοβάμαι το <button> tag; Γιατί η βαρετή λύση είναι συνήθως η σωστή. Και "ο browser το χειρίζεται σωστά" είναι feature, όχι limitation.

Το semantic web δεν αφορά το να ακολουθείς κανόνες. Αφορά το να χρησιμοποιείς τα εργαλεία που φτιάχτηκαν για τη δουλειά—και να ξοδεύεις την ενέργειά σου εκεί που πραγματικά έχει σημασία.