Front-end development: Libraries, frameworks και άλλα εργαλεία

H εποχή που με έναν απλό και ταπεινό text editor ξεκινάγαμε να γράφουμε από την αρχή τα πάντα έχει τελειώσει εδώ και πολύ καιρό. Πλέον για την δημιουργία ακόμα και του πιο απλού HTML template είναι σχεδόν υποχρεωτικό να χρησιμοποιήσουμε τουλάχιστον ένα CSS-reset καθώς και αρκετά javascript files, έτσι ώστε να προσθέσουμε συμβατότητα σε παλιότερους browsers, να ελέγξουμε τι υποστηρίζει ο κάθε browser κτλ κτλ. Παρακάτω περιγράφω τι διαδικασία, και φυσικά τα εργαλεία, libraries, scripts και snippets που χρησιμοποιώ σχεδόν σε κάθε νέο project, από το πιο μικρό μέχρι το πιο μεγάλο…

Markup

Ίσως το πιο εύκολο κομμάτι του puzzle. Μέχρι και πέρσι, συνήθως χρησιμοποιούσα ένα δικό μου template (βασισμένο σε Strict XHTML), ωστόσο μιας και προσπαθώ να το γυρίσω σε HTML5, πιάνω τον εαυτό μου να χρησιμοποιεί όλο και πιο συχνά το HTML5 boilerplate του Paul Irish. Το μόνο κακό που του βρίσκω είναι πως δεν μου φαίνεται και τόσο “boilerplate”, και συνήθως μου παίρνει αρκετή ώρα στο να διαγράφω αρχεία και κώδικα έτσι ώστε να το φέρω στα μέτρα μου. Σιγά-σιγά θέλω να φτιάξω και την δική μου λύση, ωστόσο μέχρι τότε το HTML5 boilerplate κάνει μια χαρά την δουλειά του.

CSS

Το πρώτο πράγμα που χρειάζομαι είναι ένα καλό CSS-reset. Αν η markup μου είναι HTML5, χρησιμοποιώ το HTML5 reset του HTML5 Doctor, αν όχι χρησιμοποιώ το παλιό καλό HTML reset του Eric Meyer . Πολλές φορές αν το project “βιάζεται”, χρησιμοποιώ και σαν βάση την τυπογραφία κάποιου έτοιμου CSS framework, συνήθως του Blueprint ή του HTML5 boilerplate. Τέλος, αν το project βιάζεται απελπιστικά ή θέλω κάποιο γρήγορο prototype εδώ και τώρα, χρησιμοποιώ και το grid system του Blueprint (είναι και το μόνο που έχω μάθει!). Τέλος, συνήθως περνάω και τα media queries του Andy Clarke αλλά και ένα print-only style που περιέχει όλη την βασική τυπογραφία για εκτύπωση, για να υπάρχουν (αργά ή γρήγορα θα χρειαστούν)…

Javascript

Και εφόσον κλείσαμε από markup και CSS το μόνο που μας μένει είναι η Javascript μας. Εάν το project έχει HTML5 markup, το html5shiv είναι το πρώτο “must” script που πρέπει να φορτώσουμε. Από εκεί και πέρα συνήθως περνάω το modernizr και το jQuery γιατί όλο και κάπου θα χρειαστούν. Τώρα τελευταία μου αρέσει πολύ σαν ιδέα και το selectivizr μιας και σε βοηθάει πολύ στο να κρατάς την markup σου ακόμα πιο καθαρή, ωστόσο μπορώ να ζήσω και χωρίς αυτό. Τέλος, υπάρχει πιθανότητα (πάντα ανάλογα το project και εάν ο πελάτης είναι περίεργος/φανατικός χρήστης IE) να χρησιμοποιήσω και το Respond.js, έτσι ώστε τα media queries να παίζουν και σε IE 6-7-8…

Αυτά τα λίγα σχετικά με το front-end κομμάτι των site. Όπως καταλαβαίνεται, ακόμα και μικρά projects μπορεί να θέλουν όλα τα παραπάνω και ακόμα περισσότερα για να στηθούν και να λειτουργήσουν όπως πρέπει. Τέλος αν κάποιος χρησιμοποιεί φανατικά κάποιο εργαλείο/library που δεν αναφέρω παραπάνω, ας αφήσει ένα σχόλιο έτσι ώστε το τεστάρουμε και εμείς…

HTML5 σκέψεις

Αυτό το καλοκαίρι το έριξα – όπως και πολλοί άλλοι φαντάζομαι – στην HTML5 η οποία έχει ήδη αρχίσει να κάνει δειλά-δειλά την εμφάνιση σε αρκετά sites, σε μικρότερο ή μεγαλύτερο βαθμό. Τα βιβλία που διάβασα ήταν το “HTML5 for web designers” του Jeremy Keith και το “Introducing HTML5” των Bruce Lawson και Remy Sharp. Καταρχάς όποιος σκέφτεται να αγοράσει κάποιο βιβλίο αυτήν την στιγμή, του προτείνω το δεύτερο (Introducing HTML5), μιας και το πρώτο με απογοήτευσε αρκετά για “A book apart” βιβλίο. Γενικότερα δεν θα το περιέγραφα καν ως βιβλίο, αλλά σαν μια γενική, θεωρητική εισαγωγή για το τι είναι η HTML5. Αντίθετα, το Introducing HTML5 με ξάφνιασε ευχάριστα τόσο με τα πολλά θέματα που καλύπτει όσο και με τον τρόπο που τα καλύπτει, μιας και δεν μένει μόνο στην θεωρία, αλλά προχωράει και στην πράξη (ρίξτε οπωσδήποτε και μια ματιά στα παραδείγματα του βιβλίου).

Μετά από αυτήν την μικρή εισαγωγή λοιπόν, και με την ελάχιστη εμπειρία που έχω στο θέμα, θέλω να καταγράψω κάποιες σκέψεις, προβληματισμούς, και γενικότερα να ξεκινήσω μια συζήτηση με τα πιο ανήσυχα μυαλά… Θα προσπαθήσω να είμαι σαφής και γρήγορος, έτσι ώστε να μην μπερδέψω  και να μην κουράσω. Επίσης σε αυτό το post γράφοντας HTML5 εννοώ και τα APIs ή τις τεχνολογίες οι οποίες δεν είναι μέρος του επίσημου HTML5 specification (είναι από μόνα τους ξεχωριστά specifications), ωστόσο θα χρησιμοποιηθούν κυρίως με αυτήν την markup και την ίδια περίοδο. Ας δούμε λοιπόν τι μας επιφυλάσσει το μέλλον, ε, το παρόν ήθελα να πω!

Markup

Ας ξεκινήσουμε με το πιο απλό μέρος της HTML5 – θεωρητικά πάντα – την markup και τα semantics. Τα semantics λοιπόν έχουν αλλάξει αρκετά και πλέον γίνεται ακόμα πιο δύσκολο το να γράψεις σημασιολογική markup. Παρακάτω περιγράφω αυτά που μου φάνηκαν πιο περίεργα, σημαντικά ή παράξενα!

  • Το outline – το οποίο δεν έχει υλοποιηθεί ακόμα από κανέναν browser (!!!) – αλλάζει τελείως τον νόημα των headings (h1-h6). Πλέον ένα h3 heading μπορεί να είναι πιο σημαντικό από ένα h1 heading! Στην ουσία στην HTML5 θα μπορούσαμε να είχαμε ένα και μοναδικό τύπο heading (h για παράδειγμα), ωστόσο υπάρχουν ακόμα έξι (h1-6) για compatibility θέματα. Μένει να δούμε πως θα επηρεάσει και το SEO αυτό το θέμα.
  • Τα sections και τα articles είναι αρκετά δύσκολα στην κατανόηση, μιας και το ένα μπορεί να υπάρχει μέσα στο άλλο αρκετές φορές! Θέλει αρκετή μελέτη έτσι ώστε να τα χρησιμοποιήσει κάποιος σωστά.
  • Τέλος είμαι πραγματικά περίεργος να δω πως θα φτιάξουν τους WYSIWYG web editors (Dreamweaver για παράδειγμα) έτσι ώστε να γράφουν semantic HTML5. Παλιότερα τα πράγματα ήταν πανεύκολα, απλά πετούσαν παντού ένα div και το θέμα τελείωνε, τώρα τι λύση θα βρουν άραγε;

Φόρμες (forms)

Οι φόρμες επιτέλους δεν θα σπάνε τα νεύρα σε αυτούς που τις φτιάχνουν. Μερικά attributes στην markup μας και θα αφήνουμε τον browser να κάνει όλη την “βρόμικη” δουλειά. Οι περισσότεροι browsers υποστηρίζουν λίγα πράγματα προς το παρόν (ο πιο ολοκληρωμένος browser στο θέμα είναι ο Opera) ωστόσο σιγά-σιγά θα τον φτάσουν και οι υπόλοιποι.

  • Πολύ έξυπνο compatibility μιας και όλες οι φόρμες εμφανίζονται σαν απλά text inputs σε παλιότερους browsers που δεν καταλαβαίνουν τα νέα HTML5 attributes.
  • Δυστυχώς θα γράφουμε για πολύ καιρό ακόμα Javascript validation scripts (ιδιαίτερα στην Ελλάδα, με τους αρχαιοελληνικούς browsers που κυκλοφορούν)!
  • Πρέπει οπωσδήποτε να υπάρξει μια επίσημη γραμμή για το πως θα εμφανίζονται/φαίνονται τα διάφορα widgets (πχ. επιλογή ημερομηνίας) και τα λάθη (validation errors), καθώς και για το πως θα διαγράφουμε αυτά τα default browser styles, γιατί προβλέπω να γίνεται χαμός σε αυτό το θέμα.
  • Ακόμα λιγότερη Javascript χάρις τα autofocus, placeholder, autocomplete και required attributes.
  • Το pattern attribute απλά τα σπάει! Ελέγχει κατευθείαν στον browser το regular expression που έχει δηλωθεί στο pattern!

Video και Audio

Εδώ πέρα τα πράγματα ξεκίνησαν καλά και απλά, αλλά μια (τραγική;) παράληψη στο specification έκανε τα εύκολα δύσκολα! Όπως όλοι ξέρουμε ο κάθε κατασκευαστής browser αποφάσισε (ή θα αποφασίσει) να υποστηρίξει τον video codec που τον συμφέρει.

  • Χρησιμοποιώντας πολλαπλά source elements μπορούμε να φορτώσουμε πολλά διαφορετικά φορμάτ. Πολύ χρήσιμο για την κατάσταση που θα επικρατήσει.
  • Χρησιμοποιώντας το video element με codec Ogg Theora (.ogg), H.264 (mp4) και webM (βασισμένο στον VP8 codec της Google), είμαστε καλυμμένοι στους μοντέρνους browsers, ωστόσο 3 διαφορετικές κωδικοποιήσεις είναι πολλές για το ίδιο video.
  • Και μην ξεχνάτε πως πρέπει να το κωδικοποιήσουμε και σε Flash video για να παίζει σε παλιότερους browsers!
  • Στο audio τα πράγματα είναι αρκετά πιο απλά, μιας και με ένα mp3 έχουμε τελειώσει.
  • Στα θετικά είναι πως το API του video και audio tag είναι ακριβώς το ίδιο (αν θυμάμαι καλά το audio element έχει κανα-δυο λιγότερες methods και attributes – όπως πχ. width και height).

Canvas

Με το Canvas API μπορείς να κάνεις πραγματικά τρελά πράγματα, ωστόσο το θέμα accessibility είναι τεράστιο! Στην ουσία ότι “ζωγραφίζεται” πάνω στον καμβά, δεν μπορεί να διαβαστεί από screen readers. Είναι δηλαδή (προς το παρόν) ένα καθαρά οπτικό (visual) element/API, χωρίς μάλιστα να έχει προβλεφθεί κάποια εναλλακτική λύση για την προβολή περιεχομένου (όπως στο video tag για παράδειγμα)!

Client-side Data storage

Και εδώ δεν γνώριζα αρκετά πράγματα. Οι 2 σοβαρές τεχνολογίες ονομάζονται Web Storage και Web SQL Database (υπάρχει και μια τρίτη από την Mozilla η οποία μάλλον θα σβήσει – δεν θυμάμαι καν το όνομα της), με αρκετή υποστήριξη από τους browsers.

  • Το Web Storage είναι κάτι σαν cookies on steroids. Επίσης η τεχνολογία υποστηρίζετε από όλους (!!!) τους μοντέρνους browsers.
  • H Web SQL υποστηρίζεται σε Opera, Chrome και Safari ενώ η SQL μηχανή που χρησιμοποιούν είναι η SQLite (δεν γνωρίζω εάν το αναφέρει πουθενά το specification, ωστόσο αυτή την έκδοση SQL έχουν οι παραπάνω browsers).
  • Και πάλι θα συνεχίσουμε να γράφουμε για πολύ καιρό cookies για να υποστηρίξουμε τους παλιότερους browsers (fallback κώδικας).

Offline Application Caching

Μια τεχνολογία που δεν είχα ιδέα πως λειτουργούσε, η οποία αν και εντυπωσιακή για κάποιο λόγο δεν μου αρέσει ο τρόπος λειτουργίας της (ωστόσο θα ενθουσιάσει αυτούς που ασχολούνται με web servers, .htaccess files κτλ.). Πολύ απλά δηλώνουμε σε ένα “μανιφέστο” ποια αρχεία θέλουμε να cachαριστούν (αλήθεια πως θα το μεταφράζατε αυτό;) στον browser, έτσι ώστε το site/web app μας να συνεχίζει να λειτουργεί ακόμα και εάν πάψει να λειτουργεί η σύνδεση μας.

  • Η χρήση είναι σχετικά απλή, απλά δημιουργούμε ένα .manifest αρχείο στο οποίο αναφέρουμε τα αρχεία που θέλουμε να cashaρηστούν, και το δηλώνουμε στην markup μας (<html manifest="demo.manifest">). Για κάποιο λόγο ωστόσο δεν μου αρέσει αυτός ο τρόπος λειτουργίας… Με κάνει να αισθάνομαι κάπως έξω από τα νερά μου, μιας και όπως εξήγησα και πιο πάνω μοιάζει πιο πολύ με την δημιουργία κάποιου .htaccess αρχείου, κάτι που δεν κάνει συχνά κάποιος web designer (ή έστω front-end developer).

Geolocation

Ένα από τα πιο εύκολα και αγαπημένα μου χαρακτηριστικά. Το Geolocation API δεν είναι μέρος της HTML5, ωστόσο το αναφέρω για τους λόγους που εξήγησα στην εισαγωγή. Είναι σχετικά απλό (με 2 methods έχετε καθαρίσει – getCurrentPosition και watchPosition), και πιστεύω πως όλο και περισσότερα sites θα το χρησιμοποιούν για να μας δείχνουν πιο “ντόπια” προϊόντα, διαφημίσεις, νέα, προσφορές, κτλ. κτλ. Με λίγα λόγια, “θα φορεθεί πολύ”…

Web Messaging API, Web Workers API και Web Sockets API

Τα παραπάνω APIs τα αναφέρω και τα 3 μαζί μιας και είναι φτιαγμένα για καθαρά Web εφαρμογές (δεν είναι ούτε και αυτά μέρος της HTML5). Με τα παραπάνω APIs μας δίνονται οι παρακάτω δυνατότητες:

  • Το Web Messanging υποστηρίζεται από πολλούς browsers (και IE) και μας επιτρέπει να κάνουμε διάφορα ωραία, όπως να στέλνουμε μηνύματα σε άλλα domains κτλ. Φανταστείτε το κάτι σαν AJAX on steroids και αυτό.
  • Χρησιμοποιώντας Web Workers μπορούμε να κάνουμε την web εφαρμογή μας να τρέχει την Javascript σε διαφορετικά threads! Από μια γρήγορη ματιά που έριξα, η λογική είναι αρκετά πολύπλοκη και πιστεύω πως αυτήν την στιγμή είναι πολύ κακό για το τίποτα, ωστόσο οφείλω να ομολογήσω πως σε μια πολύπλοκη web εφαρμογή (φανταστείτε κάτι σε Photoshop στο web) μπορεί να κάνει τρελή διαφορά (πχ. να χρησιμοποιεί ένα φίλτρο, και ενώ ο web worker κάνει τους υπολογισμούς του, ο χρήστης να συνεχίζει να χρησιμοποιεί την εφαρμογή, χωρίς αυτή να φαίνεται σαν να έχει κολλήσει).
  • Τα Web Sockets ανοίγουν μια αμφίδρομη επικοινωνία μεταξύ του server και του client χρησιμοποιώντας τον browser σαν “μεσάζοντα”. Αρκετά βολικό και χρήσιμο…
Αυτές είναι οι πρώτες εντυπώσεις/σκέψεις μου για την HTML και όλα τα άλλα ωραία καλούδια που έρχονται μαζί της. Έχετε στο μυαλό σας πως  υπολογίζουν πως η HTML5 θα είναι 100% ολοκληρωμένη (σε browser επίπεδο τουλάχιστον) γύρω στο 2020 (!!!) ωστόσο δεν χάνουμε τίποτα με το να χρησιμοποιούμε και να μαθαίνουμε τα νέα χαρακτηριστικά της. Πολλά από αυτά άλλωστε υποστηρίζονται και από τους σημερινούς μοντέρνους browsers ενώ λογικά με την έλευση του IE9 θα δούμε ακόμα πιο πολλές HTML5-based εφαρμογές. Μην φοβάστε λοιπόν να την χρησιμοποιήσετε εδώ και τώρα, απλή HTML είναι άλλωστε 😉 Τα υπόλοιπα τα λέμε στα σχόλια!

Base tag, ή αλλιώς το client-side debuging tag

Είναι αρκετές οι φορές όπου κάποιος συνάδελφος ή φίλος, μου στέλνει ένα url προς κάποια σελίδα με την γνωστή ατάκα – “Γιατί δεν παίζει;”. Συνήθως η δομή της σελίδας είναι αρκετά πολύπλοκη με πολλά elements και διάφορα πραγματάκια να γίνονται εδώ και εκεί… Φυσικά το πρώτο πράγμα που ζητάω είναι πρόσβαση στα αρχεία, ωστόσο πολλές φορές αυτό δεν είναι εφικτό.

Έχω βρει εναλλακτική λύση όμως! Η δεύτερη καλύτερη λύση είναι η χρήση του base tag. Το μόνο που έχετε να κάνετε είναι να αντιγράψετε την markup από το site που θέλετε (copy-paste του source code), και μετά να προσθέσετε το παρακάτω tag στο head μέρος της markup σας.

<base href="http://domain.com" />

Με αυτόν τον πολύ απλό τρόπο, δηλώνουμε στην markup πoιο url είναι η προεπιλογή μας για όλα τα links της σελίδας μας! Έτσι μπορούμε να δούμε και να επεξεργαστούμε την στατική σελίδα που μόλις κατεβάσαμε, με όλα τα stylesheets και javascripts να παίζουν κανονικότατα, και από εκεί και πέρα να προσθέσουμε ότι θέλουμε χρησιμοποιώντας inline CSS ή Javascript (για test/development καταστάσεις μόνο 😉 ). Πολύ βολικό έτσι;

Γράψτε HTML5 χρησιμοποιώντας XHTML…

Πολλοί είναι αυτοί που παραπονιούνται πως ενώ θέλουν να χρησιμοποιήσουν την καινούργια markup (HTML5), και όλα τα ωραία semantics που περιέχει, δυστυχώς είναι ακόμα κάπως νωρίς για μια τέτοια αλλαγή, ιδιαίτερα σε μεγάλα sites. Ευτυχώς για όλους εμάς όμως, κάποιοι άνθρωποι είναι ιδιαίτερα δημιουργικοί και βρήκαν μια πολύ εύκολη και πρακτική λύση. Χρησιμοποιώντας απλά την υπάρχον XHTML μαζί με κάποιες συγκεκριμένες και προκαθορισμένες κλάσεις, μπορούμε να προσφέρουμε τα semantics της HTML5 στην (X)HTML μας. Το μόνο που χρειάζεται να κάνετε, είναι να προσθέσετε στα elements σας κάποιες κλάσεις όπως article, section, header κτλ.

Ακολουθώντας τους παραπάνω κανόνες λοιπόν, αν και συνεχίζουμε να γράφουμε την παλιά, καλή και δοκιμασμένη XHTML, κερδίζουμε δύο πράγματα: Πρώτον μαθαίνουμε να σκεφτόμαστε και να χρησιμοποιούμε την HTML5, η οποία έχει αρκετές διαφορές και ιδιαιτερότητες από την (X)HTML. Τέλος, το δεύτερο και πιο σημαντικό είναι πως το site μας θα είναι κατά 99% έτοιμο (σε markup επίπεδο τουλάχιστον) όταν αποφασίσουμε να το αναβαθμίσουμε σε πραγματική HTML5. Το μόνο που θα χρειαστεί να κάνουμε, είναι να αντικαταστήσουμε τα παλιομοδίτικα divs με τα καινούργια πιο semantic elements.

Προσωπικά θα προσπαθήσω να εισάγω αυτό τον τρόπο συγγραφής markup σε καινούργια projects, μιας και μόνο κερδισμένος μπορώ να βγω από αυτήν την διαδικασία. Όσοι ενδιαφέρεστε και θέλετε να ξεκινήσετε, ρίξτε μια ματιά στα παραπάνω links τα οποία περιέχουν τις πιο τεχνικές λεπτομέρειες.

Styling HTML5 elements

Όσοι έχετε δοκιμάσει να παίξετε με την HTML5 θα έχετε πέσει σε διάφορες παραξενιές της. Χτες έπεσα σε μία από αυτές που μου έφαγε πολύ χρόνο, ενώ μου προκαλεσε και εντύπωση το γεγονός πως πολλά HTML5 άρθρα και posts δεν αναφέροντε στο συγκεκριμένο πρόβλημα όσο ξεκάθαρα θα έπρεπε (μέχρι και το Google με απογοήτευσε στις αναζητήσεις μου).

Το πρόβλημα που είχα, ήταν πως ενώ η HTML5 markup μου ήταν σωστή (και valid), elements όπως header, section, footer και aside, δεν καταλάβαιναν τους styling κανόνες που τους έβαζα! Οι μοντέρνοι και HTML5-ready browsers έδειχναν να μην κάνουν σωστό rendering τα καινούργια elements (ο Firefox και ο Chrome τουλάχιστον, αν και έχω την αίσθηση πως και οι υπόλοιποι θα έχουν ανάλογα προβλήματα). Η λύση τελικά είναι πανεύκολη, απλά δίνουμε στα καινούργια elements display:block.

header, section, footer, aside, nav, article, figure { display: block; }

Από ότι κατάλαβα για κάποιο περίεργο λόγο, οι browsers κάνουν τα παραπάνω στοιχεία rendering ως inline elements, οπότε με τον παραπάνω απλό κανόνα καθαρίσαμε. Μπορεί έχασα ένα ολόκληρο απόγευμα, ωστόσο πιστεύω πως άξιζε τον χρόνο. Άλωστε μόνο έτσι μαθαίνεις…

Εύκολα στην υλοποίηση accessibility tips : Χρησιμοποιήστε (σωστά) labels στις φόρμες σας.

Ένα πανεύκολο και πολύ απλό στην υλοποίηση accessibility tip που δυστυχώς δεν το συντάω συχνά σε ελληνικά site. Τα πράγματα είναι εξαιρετικά απλά σε αυτό το θέμα. Ο μοναδικός σκοπός του label (ετικέτα) element είναι να “συνδέεται” και να περιγράφει όσο καλύτερα μπορεί ένα και μοναδικό form control, όπως για παράδειγμα checkbox, radio button, text input κτλ. (εκτός από τα buttons φυσικά). Αντιθέτως, κάθε form control μπορεί “συνδεθεί” με πολλά label elements, έτσι ώστε να παρουσιάσει μηνύματα βοήθειας, λάθους κτλ. Οι δύο παρακάτω τρόποι κάνουν σωστή χρήση του label element. Προσωπικά προτιμώ τον πρώτο γιατί σου αφήνει περισσότερα περιθώρια ελευθερίας τόσο σε markup όσο και σε styling επίπεδο…

<label for="name">Όνομα:</label>
<input id="name" name="name" type="text" />

<label>Όνομα:
<input id="name" name="name" type="text" />
</label>

Τα accessibility οφέλη που παίρνουμε είναι πως τα παραπάνω labels ενεργοποιούν κατευθείαν τα controls που περιγράφουν, κάτι πολύ σημαντικό για την ευκολότερη συμπλήρωση φορμών. Πολλά controls είναι μικρά, δυσδιάκριτα και δύσκολα στο να επιλεχθούν (ειδικά τα radio buttons), οπότε επιλέγοντας το κείμενο της ετικέτας μας (label) επιλέγουμε αυτόματα και το ανάλογο control. Τέλος ας μην ξεχνάμε πως βοηθάμε πολύ και τους χρήστες text browser και screen readers…

Εύκολα στην υλοποίηση accessibility tips : Χρησιμοποιήστε option groups στις φόρμες σας.

Ένα πανεύκολο tip που θα ωφελήσει όλες τις κατηγορίες χρηστών σας και θα κάνει τις φόρμες σας ομορφότερες αλλά και ευκολότερες στο να συμπληρωθούν. Εάν λοιπόν έχετε κάποιο select element  με πολλά option elements, καλό θα ήταν να τα κατηγοριοποιήσετε χρησιμοποιώντας τα option groups.

Η χρήση τους είναι εξαιρετικά απλή, απλά ονομάζεται το group δίνοντας του ένα όνομα (label) και στην συνέχεια του προσθέτεται τα option elements που θέλετε. Ρίξτε μια ματιά παρακάτω και προσπαθήστε να το χρησιμοποιήσετε την επόμενη φορά που θα έχετε μια λίστα με πολλές επιλογές…

<label for="bestepisode">Διάλεξε το καλύτερο επεισόδιο τριλογίας!</label>
<select name="bestepisode" id="bestepisode">
<optgroup label="Star Wars">
<option value="starwars4">The Star Wars</option>
<option value="starwars5">The Empire Strikes Back</option>
<option value="starwars6">Return of the Jedi</option>
</optgroup>
<optgroup label="Indiana Jones">
<option value="ij1">Raiders of the Lost Ark</option>
<option value="ij2">The Temple of Doom</option>
<option value="ij3">The Last Crusade</option>
</optgroup>
<optgroup label="Matrix">
<option value="matrix1">The Matrix</option>
<option value="matrix2">The Matrix Reloaded</option>
<option value="matrix3">The Matrix Revolutions</option>
</optgroup>
</select>

Kαλοπιστικά γραφικά vs γραφικά περιεχομένου

Σε αυτό το μικρό postακι θα προσπαθήσω να εξηγήσω την διαφορά των συγκεκριμένων γραφικών/images καθώς και πως πρέπει να εμφανίζονται στην markup μας (με τι attributes κτλ.). Για κάποιον λόγο αυτή η απλή διαφορά δεν γίνεται αμέσως αντιληπτή, ιδιαίτερα στους  νέους του χώρου, οπότε ας ξεκαθαρίσουμε λίγο τα πράγματα.

Η λύση είναι απλούστατη και θέμα θέμα απλής λογικής. Όποιο γραφικό είναι μέρος του περιεχομένου, όπως πχ. μια φωτογραφία, ένα διάγραμμα, κτλ., πρέπει να παρουσιάζεται με το HTML img tag και να περιέχει – εκτός φυσικά από το src attribute – και ένα περιγραφικό alt attribute. Αντιθέτως τα γραφικά που δεν είναι μέρος του περιεχομένου, δεν θα πρέπει να υπάρχουν καθόλου στην markup μας (ως img tags)! Τα συγκεκριμένα γραφικά θα πρέπει να παρουσιάζονται είτε μέσω CSS, είτε μέσω DOM injection χρησιμοποιώντας κάποια Javascript library. Εάν φυσικά τα πράγματα δεν γίνονται αλλιώς (δεν μπορούμε να κάνουμε και μαγικά σε μερικές περιπτώσεις), τότε μπορούμε να προσθέσουμε τα συγκεκριμένα γραφικά με img tags τα οποία θα έχουν κενή την alt attribute τους (<img src="logo.jpg" alt="" />). Εύκολο έτσι;

Εύκολα στην υλοποίηση accessibility tips : Οδηγείστε τους χρήστες screen readers / text browsers κατευθείαν στο περιεχόμενο ή όπου αλλού θέλετε.

Ένα πανεύκολο στην υλοποίηση accessibility feature, που θα βοηθήσει αφάνταστα τους screen readers και τους χρήστες που χρησιμοποιούν text-browsers. Το μόνο που πρέπει να κάνετε είναι στην αρχή κάθε document, να προσθέσετε τα links που θα οδηγούν τον χρήστη κατευθείαν στο σημείο που έχετε ορίσει. Έτσι για παράδειγμα, σε αυτό το site, το πρώτο πράγμα που “εμφανίζεται” στην markup μου είναι μια λίστα με αυτά τα links (μέσα σε ένα div).

<div id="accessibilitylinks">
<ul>
<li><a title="Go to content" href="#content">Skip to content</a></li>
<li><a title="Go to main navigation" href="#navigation">Skip to main navigation</a></li>
<li><a title="Go to Search form" href="#search">Skip to Search form</a></li>
</ul>
</div>

Με τον παραπάνω κώδικα, οι χρήστες screen reader μπορούν πολύ εύκολα – στην κυριολεξία με ένα κλικ – να μετακινηθούν στο περιεχόμενο της σελίδας μου, στο navigation ή στην search form. Φυσικά μπορούμε να εφαρμόσουμε και όλους τους γνωστούς styling κανόνες στην λίστα έτσι ώστε να την διαμορφώσουμε όπως θέλουμε. Καλό θα είναι εάν θέλουμε να την κρύψουμε, να μην χρησιμοποιήσουμε τον κανόνα display:none αλλά να την κρύψουμε με κάποιο άλλο τρόπο (πχ. absolute position), και αυτό γιατί πολλοί screen readers/text browsers δεν διαβάζουν τα elements με display:none. Για παράδειγμα, εγώ κρύβω την συγκεκριμένη λίστα links με τον παρακάτω κώδικα:

#accessibilitylinks {
position:absolute;
top:-1000px;
}

Είναι πραγματικά το πιο εύκολο αλλά και πρακτικό usability χαρακτηριστικό που μπορείτε να έχετε στην σελίδα σας!

Εύκολα στην υλοποίηση accessibility tips : Extra navigation για text browsers / screen readers (και όχι μόνο)

Η αλήθεια είναι πως όσο καλός και ενημερωμένος να είσαι στο χώρο του web, πάντα υπάρχει κάτι καινούργιο να μάθεις. Επειδή λοιπόν και εγώ πρόσφατα (πριν από έναν χρόνο για την ακρίβεια, αλλά ας μείνουμε στο πρόσφατα), ανακάλυψα μερικά ενδιαφέροντα και πολύ εύκολα στην υλοποίηση accessibility tips, θα τα παρουσιάσω σε αυτή την μίνι σειρά post.

Οι περισσότεροι γνωρίζετε το link element που βάζουμε στο head κομμάτι του κώδικα μας, και δηλώνει πως το εν λόγω document έχει κάποια σχέση (relationship – rel) με κάποιο άλλο document ή πηγή. Ο πιο κλασικός τρόπος χρήσης του είναι η εισαγωγή κάποιου εξωτερικού stylesheet (CSS), όπως για παράδειγμα :

<link rel="stylesheet" href="default.css" type="text/css" media="screen" />

Αυτό που δεν γνωρίζουν οι περισσότεροι, είναι πως με το εν λόγω element μπορούμε να προσφέρουμε επιπλέον navigation χαρακτηριστικά στους χρήστες screen readers, text browsers αλλά και σε κάποιους κανονικούς browsers (όπως Opera) οι οποίοι αρχίζουν να υποστηρίζουν και αυτήν την ιδιότητα του link element. Μερικά παραδείγματα και τρόπους χρήσης του μπορείτε να δείτε παρακάτω :

<link rel="home" title="Home" href="http://www.tsevdos.com/" />
<link rel="prev" title="Title of previous page" href="http://www.tsevdos.com/</code><code>previous-page" />
<link rel="next" title="Title of next page" href="http://www.tsevdos.com/</code><code>next-page" />

Όπως βλέπεται η χρήση του είναι πανεύκολη και τα πλεονεκτήματα αρκετά, έτσι ώστε να το χρησιμοποιήσουμε.

Τέλος το συγκεκριμένο tag μπορεί να χρησιμοποιηθεί και για άλλους σκοπούς, όπως για παράδειγμα στο να ενημερώσει τις μηχανές αναζήτησης εάν το περιεχόμενο της σελίδας μας υπάρχει και σε άλλες γλώσσες ή σε άλλη μορφή. Παρακάτω μπορείτε να βρείτε τα ανάλογα παραδείγματα, ωστόσο δεν θα σταθώ πολύ σε αυτά μιας και θέλω στο συγκεκριμένο post να συγκεντρωθώ κυρίως στο θέμα προσβασημότητας/accessibility. Όπως και να έχει ρίξτε οπωσδήποτε μια πιο λεπτομερή ματιά στο link element και δεν θα χάσετε.

<link lang="fr" title="La documentation en Fran&ccedil;ais" type="text/html" rel="alternate" hreflang="fr" href="http://someplace.com/manual/french.html">
<link media="print" title="The manual in postscript" type="application/postscript" rel="alternate" href="http://someplace.com/manual/postscript.ps">
<link rel="Start" title="The first page of the manual" type="text/html" href="http://someplace.com/manual/start.html">

Μείνετε συντονισμένοι και για τα επόμενα!