Google Chrome : Μια πιο τεχνολογική ματιά

Δοκίμασα και εγώ τον νέο open-source browser της Google, τον Chrome, και προσωπικά με εντυπωσίασε! Ακόμα και στην beta έκδοση, ο Chrome είναι πάρα πολύ γρήγορος, κάτι που έπρεπε να δω με τα ίδια μου τα μάτια, μιας και δεν πιστεύω ποτέ ούτε τα fanboys, ούτε τις υπερβολές των επίσημων κατασκευαστών. Δεν θα μπω στο τρυπάκι του να (αντι)γράψω για μια ακόμα φορά τα χαρακτηριστικά του, τα οποία είναι πραγματικά πολλά και αξιόλογα (δείτε και τα video που τα παρουσιάζουν, είναι πολύ μικρά και αξιόλογα), ωστόσο θα σταθώ σε μερικά σημεία που θα απασχολήσουν στο μέλλον τους πιο έμπειρους χρήστες και επαγγελματίες.

Το πρώτο και σημαντικότερο είναι πως ο Chrome χρησιμοποιεί το Webkit για μηχανή rendering. Προς το παρών η Google δηλώνει πως όποιο site εμφανίζεται σωστά σε Safari (ο οποίος στηρίζεται και αυτός στο Webkit) θα εμφανίζεται σωστά και στον Chrome. Με λίγα λόγια αυτήν την στιγμή οι δύο browsers έχουν κατά κάποιον τρόπο “συμβατή” version του Webkit, ωστόσο κανείς δεν ξέρει εάν η Google ή η Apple θα κρατήσουν αυτήν την συμβατότητα…

Το δεύτερο σημαντικό στοιχείο του browser είναι η ολοκαίνουργια Javascript engine που χρησιμοποιεί, η V8! Πραγματικά δείχνει πολύ γρήγορη, ενώ περνάει και με 100% επιτυχία το ACID2 test (στο 3 θέλει λίγο δουλειά ακόμα). Γενικά πιστεύω πως η αγορά χρειαζόταν μια καινούργια και γρήγορη Javascript engine, ενώ το γεγονός ότι και αυτή είναι open source την κάνει ακόμα πιο σημαντική.

Ένα άλλο σημείο που κάνει τον Chrome να ξεχωρίζει από τους άλλους browsers, είναι η ενσωμάτωση του Google Gears μέσα στον ίδιο τον browser (δεν χρειάζεται να εγκαταστήσετε κάποιο plug in). Αυτό αλλάζει πολλά δεδομένα για τους developers που θέλουν να αναπτύξουν εφαρμογές με επιπλέον δυνατότητες, πέρα από τις κλασικές τεχνολογίες. Μιλάμε για φοβερές δυνατότητες όπως local server μέσα στον browser (ο browser με λίγα λόγια θα είναι και client και server !!!), local database/SQLite και πολλά άλλα καλούδια!!! Σκεφτείτε πόσα επιπλέον features μπορεί να αποκτήσει οποιοδήποτε site/web application, γνωρίζοντας πως οι χρήστες του χρησιμοποιούν τον συγκεκριμένο browser!

Αν και δεν σχολιάστηκε όσο θα έπρεπε, ο Chrome χτυπάει, και μάλιστα πολύ δυνατά, άλλο ένα προϊόν της Mozilla – πέρα του Firefox – το Mozilla Prism (είχα γράψει και παλιότερα γι αυτό). Με μία κίνηση λοιπόν μπορείτε να δημιουργήσετε application shortcuts (έτσι τα ονομάζει τουλάχιστον), τα οποία με την βοήθεια του browser και των χαρακτηριστικών του (Gears, κτλ.) μπορούν να λειτουργήσουν σαν RIA εφαρμογές! Ακριβώς ότι κάνει το Prism με την Gecko rendering engine, μόνο που όλα γίνονται πιο εύκολα και γρήγορα!

Τέλος, για εμάς τους developers, ο Chrome διαθέτει 2 πολύ ενδιαφέροντα εγαλειάκια, το Web Inspector και το JavaScript Debugger (έχω την αίσθηση πως είναι τα κλασικά web tools έρχονται με το Webkit), αλλά τίποτα παραπάνω προς το παρόν (ξεχάστε το Firebug δηλαδή)… Είναι πολύ νωρίς ακόμα για να ζητάω add-ons, ιδιαίτερα τέτοιου επιπέδου, ωστόσο έχω την αίσθηση πως θα φτιαχτούν γρήγορα πολλά και ποιοτικά add-ons για τον browser. Μην ξεχνάτε πως τα πάντα είναι open source! Τα πιο ανήσυχα μυαλά μπορούν να ρίξουν και μια ματιά στο επίσημο FAQ των web developers το οποίο θα τους λύσει αρκετές απορίες για τον browser και τις παραξενιές του.

Μετά από μία ολόκληρη μέρα με τον Chrome λοιπόν, δηλώνω fan του στο κομμάτι του browsing, ωστόσο μερικά add-on του Firefox (Firebug, FireShot, Web Developer Bar, Delicious Bookmarks και διάφορα άλλα μικρότερης σημασίας), με αναγκάζουν να κρατάω τον Firefox ως default browser. Θα περιμένω λοιπόν ακόμα να δω τι add ons θα δημιουργηθούν για τον νέο browser, και θα ξανασκεφτώ σοβαρά το θέμα switching, ωστόσο εάν ψάχνεται έναν γρήγορο browser μόνο για surfing, κατεβάστε και χρησιμοποιήστε άφοβα τον Chrome!

Η Microsoft ξανασκέφτεται τo version targeting στον IE8

Επιτέλους η Microsoft δείχνει να ακούει την web κοινότητα, και ανακοινώνει στο επίσημο blog του ΙΕ8 πως η default rendering engine του καινούργιου Explorer θα είναι η νέα web-standard compliant rendering engine (και όχι αυτή του IE7)! Φυσικά έχει επικρατήσει πανικός σε όλα τα web design blogs μιας και το θέμα version targeting έδειχνε να έχει κλείσει, αλλά ευτυχώς για όλους εμάς κάποιοι το ξανασκέφτηκαν… Η παραπάνω επίσημη ανακοίνωση σημαίνει πως :

  • Οι web designers/developers δεν θα χρειάζεται να προσθέσουν το γνωστό meta element για να χρησιμοποιηθεί η καινούργια και πολλά υποσχόμενη rendering μηχανή του IE8. Σε αυτό το σημείο να υπενθυμίσω πως η rendering engine του ΙΕ8 έχει περάσει και το γνωστό Aicd 2 test που σημαίνει πως ο IE8 θα είναι πραγματικά web-standards compliant!!!
  • Οι web designers/developers που θα θέλουν να χρησιμοποιήσουν την παλιότερη μηχανή rendering του IE7, θα πρέπει να προσθέσουν στον head section του site τους το γνωστό πλέον meta element. Ακριβώς αυτήν την άποψη είχα από την αρχή στο όλο θέμα, και πραγματικά απορώ γιατί δεν το σκέφτηκαν νωρίτερα!!!

Προσωπικά είμαι 100% σύμφωνος με την εξέλιξη της υπόθεσης και πραγματικά χαίρομαι που η Microsoft ξανασκέφτηκε το όλο θέμα. Μόνο καλό στον χώρο του internet μπορεί να κάνει αυτή η κίνηση μιας και ο διασημότερος browser θα είναι επιτέλους, και για πρώτη φορά, web-standards compliant! Η Microsoft μας χρωστούσε εδώ και καιρό έναν αξιόλογο web browser και επιτέλους θα τον έχουμε!

Internet Explorer 8 και version targeting : Το μεγάλο λάθος της Microsoft

Και ενώ τα νέα που είχαμε στην διάθεση μας σχετικά με την νέα έκδοση του Internet Explorer ήταν παραπάνω από καλά, όπως την (σχεδόν) πλήρης υποστήριξη των web standards καθώς και το γεγονός ότι πέρασε με απόλυτη επιτυχία το ACID 2 test, ξαφνικά η Microsoft κάνει κατά την γνώμη μου την χειρότερη κίνηση στο να εκμεταλλευτεί πλήρως όλα τα παραπάνω και να ξεπλύνει το κακό όνομα που έχει ο browser της! Ο λόγος είναι το λεγόμενο version targeting που θα χρησιμοποιήσει η εταιρεία στον Internet Explorer 8 το οποίο και βρίσκω πραγματικά ανούσιο και δεν καταλαβαίνω γιατί αποφασίστηκε ένας τέτοιος μηχανισμός επιλογής rendering μηχανής στον νέο browser και όχι κάτι πιο απλό και κατανοητό (και για τον απλό χρήστη και για τον developer). Στο A List Apart έχουν δημοσιευθεί δύο πολύ ενδιαφέροντα άρθρα πάνω στο θέμα, με το ένα να τίθεται υπέρ και το άλλο κατά του version targeting, με τίτλους “Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8” και “From Switches to Targets: A Standardista’s Journey“, τα οποία και συστήνω σε όλους τους web designers/developers.

Γιατί πιστεύω πως η Microsoft κάνει λάθος λοιπόν. Έχουμε και λέμε, η Microsoft μετά από πολλά χρόνια καταφέρνει να φτιάξει επιτέλους έναν πολύ αξιόλογο browser (Internet Explorer 8), ο οποίος και περνάει το διάσημο ACID 2 test, πράγμα που σημαίνει πως η rendering μηχανή του ανταποκρίνεται σωστά (ή έστω με πολύ μεγάλη ακρίβεια) στα web standards. Το λάθος της εταιρείας λοιπόν είναι πως αντί να χρησιμοποιήσει σαν default την καινούργια, web standards compliant rendering engine στον Internet Explorer 8, αποφασίζει να δώσει 3 rendering modes στον browser, ανάλογα με τον κώδικα που βρίσκει σε κάθε σελίδα, και πιο συγκεκριμένα :

  • Quirks mode” όπου θα χρησιμοποιείτε σε σελίδες με μη web standard κώδικα και θα είναι συμβατός με παλιό και μη ενημερωμένο περιεχόμενο.
  • Standards mode” όπου θα συμπεριφέρεται σαν το standards mode του Internet Explorer 7. Έτσι τα site με valid code θα γίνονται render όπως ακριβώς γίνονται στον Internet Explorer 7 και όχι με την καινούργια web standards compliant rendering engine του Internet Explorer 8!
  • Εάν θέλετε να χρησιμοποιήσετε την καινούργια web standards compliant rendering engine του Internet Explorer 8 θα πρέπει να χρησιμοποιήσετε ένα <meta> element!

To meta element που θα πρέπει να χρησιμοποιηθεί παρουσιάζεται στον είναι το παρακάτω code snippet,

<meta HTTP-equiv="X-UA-Compatible" content="IE=8">

με δυνατότητα επέκτασης και σε άλλους browsers και versions ως :

<meta HTTP-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4">

Και που είναι το πρόβλημα τώρα, θα αναρωτιέστε πολλοί. Τα πρόβλημα που βλέπω εγώ (και όχι μόνο) είναι το εξής. Γιατί θα πρέπει ο οποιοσδήποτε web designer/developer να δημιουργήσει ένα meta element για να χρησιμοποιήσει την καινούργια rendering μηχανή του ΙΕ8 σε valid κώδικα? – Αλλιώς όπως αναφέρω παραπάνω η default rendering engine που θα χρησιμοποιηθεί είναι αυτή του IE7! Καταλαβαίνω (σε αντίθεση με πιο σκληροπυρηνικούς) τον λόγο ύπαρξης ενός “Quirks mode” για την προβολή παλιού και μη valid περιεχομένου, αλλά από εκεί και πέρα η default rendering μηχανή σε valid σελίδες θα έπρεπε να είναι η καινούργια (αυτή του ΙΕ8) και όχι αυτή του ΙΕ7! Είναι σαν μια αναβάθμιση που στην ουσία για να χρησιμοποιήσει κάποιος θα πρέπει να κάνει κάποιο hack! Στην χειρότερη περίπτωση, εάν θέλανε τόσο πολύ να μην χαλάσουν κάποια site που λειτουργούν μια χαρά αυτήν την στιγμή σε ΙΕ7, ας κάνανε το αντίθετο, δηλαδή να δημιουργούσαν ένα meta element το οποίο θα ανάγκαζε τον IE8 να συμπεριφερόταν σαν ΙΕ7 (και όχι το αντίθετο)! Πραγματικά δεν μπορώ να καταλάβω γιατί η Microsoft πνίγεται σε μια κουταλιά νερό σε τέτοια θέματα. Θες να βγάλεις τον browser σου και να υποστηρίζεις όλες τις προηγούμενες και κακές υλοποιήσεις του, πολύ ωραία, κάντο, αλλά κάντο έξυπνα και προπαντός χωρίς να πηγαίνεις πίσω το καινούργιο προϊόν σου! Η πρόοδος έχει πάντα ένα μικρό κόστος και στην συγκεκριμένη περίπτωση θα ήταν πάρα πολύ μικρό σε σχέση με το γενικότερο κέρδος που θα είχε και από την web κοινότητα και από την development κοινότητα! Τέλος δεν μπορώ να καταλάβω γιατί εφόσον θέλει να υποστηρίξει τα κακογραμμένα sites που έχουν φτιαχτεί 5 και 10 χρόνια πριν, γιατί δεν κάνει ευκολότερη την ζωή και των χρηστών τέτοιων site αλλά και των developers, δίνοντας την επιλογή στον browser της να διαλέξει rendering μηχανή (μέσα από κάποιο μενού ας πούμε – όπως κάνουμε πχ. με το μενού encoding) ή έστω να επιτρέψει την εγκατάσταση διαφορετικών εκδόσεων του browser της στο ίδιο σύστημα!

Προσωπικά πιστεύω πως η Microsoft πνίγηκε σε μια κουταλιά νερό και χάλασε άδοξα τις πάρα πολύ καλές εντυπώσεις που είχε κερδίσει ο καινούργιος Explorer. Τώρα πόσο θα επηρεάσει αυτή η απόφαση εμάς τους developers, ο χρόνος θα δείξει… Άποψη μου είναι πως έκανε το απλό, πολύπλοκο, χωρίς κανέναν ιδιαίτερο λόγο.

HTML e-mails και πως πρέπει να σχεδιάζονται

Αν και έχουν γίνει αρκετά βήματα μπροστά στο θέμα HTML e-mails/newsletters, όπως το Email Standards Project (όπως έχω αναφέρει και σε παλιότερο post), τα πράγματα για τους developers παραμένουν άσχημα, μιας και οι mail clients εκτός από από πολλοί, έχουν μείνει και αρκετά πίσω στο θέμα rendering HTML περιεχομένου. Οι περισσότεροι, για λόγους ασφαλείας κυρίως, κόβουν πολλά χαρακτηριστικά όπως Javascript, CSS και πολλές φορές ακόμα και εικόνες, οπότε η κατάσταση είναι δύσκολο να ελεγχθεί από τον developer/designer που έχει αναλάβει την δημιουργία του περιεχομένου! Επιπλέον πρόβλημα είναι και η ύπαρξη on-line αλλά και off-line (desktop) mail clients, όπου ο καθένας ακολουθεί τους δικούς του κανόνες στο τι θα κάνει render και με ποιον τρόπο! Το παρακάτω άρθρο θα προσπαθήσει να δώσει συμβουλές αλλά και να προβάλει τεχνικές έτσι ώστε να σχεδιάζετε καλύτερα και πιο συμβατά HTML mails.

Το πρώτο πράγμα που πρέπει να ασπαστείται είναι η inline CSS! Αν και στο web design η inline CSS θεωρείτε τόσο κακή πρακτική όσο και τα παλιομοδίτικα font tags, στην περίπτωση των HTML mails η inline CSS είναι το μόνο είδος CSS που λειτουργεί στους περισσότερους clients! Έτσι εάν θέλετε να χρησιμοποιήσετε σε κάποιο span element Arial font, σε γκρι χρώμα και bold, ο κανόνας που πρέπει να γράψετε (inline) είναι ο εξής :


Span element με Arial font, γκρι χρώμα και bold!

Από εκεί και πέρα προσπαθήστε να χρησιμοποιήσετε τις βασικές CSS properties οι οποίες υποστηρίζονται στους περισσότερους clients, και αποφύγετε τις πιο σπάνιες (όπως πχ list-style-image). Παρακάτω συγκέντρωσα μία λίστα η οποία εξηγεί τι εννοώ γράφοντας βασικές properties. Την λίστα την έφτιαξα μετά από μελέτη ενός καταπληκτικού άρθρου πάνω στο θέμα το οποίο έχει κάνει ολόκληρη μελέτη για το ποιες CSS properties υποστηρίζονται και ποιες όχι (γράφτηκε το 2006, αλλά υπάρχει και το 2007 review).

  • color
  • background-color
  • border
  • font-family
  • font-size
  • font-style
  • font-variant
  • font-weight
  • letter-spacing
  • line-height
  • margin
  • padding
  • text-align
  • text-decoration
  • text-transform

Κάποιοι παρατηρητικοί θα είδαν πως στις παραπάνω CSS properties δεν αναφέρω πουθενά positioning properties. Ο λόγος είναι πολύ απλός, για HTML e-mail (και μόνο για τον συγκεκριμένο λόγο) η καλύτερη λύση είναι να χρησιμοποιήσετε tables! Το ξέρω πως σε αυτό το blog γράφω πάντα κατά των tables και υποστηρίζω τις μοντέρνες web design τεχνικές, αλλά στην συγκεκριμένη περίπτωση όλα αυτά απλά δεν ισχύουν! Χρησιμοποιήστε tables λοιπόν και μάλιστα αποφύγετε τα πολλά tables μέσα σε tables (γνωστά και ως nested tables). Ένα απλό table-based layout, με λίγα rows και columns είναι το ιδανικότερο, μετά με την εισαγωγή κάποιων βασικών styles στο περιεχόμενο (content) του πίνακα και ακολουθώντας τις παραπάνω συμβουλές, μπορείτε εύκολα να δημιουργήσετε ένα πολύ ευανάγνωστο και εντυπωσιακό HTML e-mail/newsletter.

Άλλο ένα σημαντικό λάθος, που το κάνουν ακόμα και μεγάλες εταιρείες, είναι η αλόγιστη χρήση γραφικών (images) και το ακόμα χειρότερο, η χρήση γραφικών για την προβολή περιεχομένου (content). Ο λόγος που δεν πρέπει να χρησιμοποιούμε πολλά γραφικά, είναι πως πολλοί mail clients (on-line και off-line) δεν αφήνουν τα γραφικά να “περάσουν”, με αποτέλεσμα να μην εμφανίζονται! Όπως καταλαβαίνεται τα πράγματα γίνονται ακόμα χειρότερα εάν τα γραφικά περιέχουν και μέρος του περιεχόμενου μας, όπως για παράδειγμα κείμενο, γραφήματα κτλ. Καλό θα είναι το κείμενο (τίτλοι, παράγραφοι, κτλ.) να είναι κείμενο, και όχι γραφικά με περίεργα Photoshop fonts, γιατί εκτός από το κίνδυνο να μην τα δουν ποτέ οι παραλήπτες, υπάρχει και μεγάλο accessibility πρόβλημα όταν κάποιος θέλει να κάνει copy κάποιο κομμάτι του κειμένου σας!

Τέλος κάντε όσα πιο πολλά τεστ μπορείτε! Και για να γίνω πιο συγκεκριμένος εξετάστε τα HTML mails τουλάχιστον σε :

Αυτά τα βασικά και πιο τεχνικά πράγματα για τα HTML e-mails (προς το παρόν). Ελπίζω να με διαβάζουν και κάποιοι που δημιουργούν τέτοια mails, γιατί όπως πάντα η κατάσταση στην Ελλάδα είναι πάλι αρκετά πίσω από τον μέσο όρο, οπότε όσοι πιστοί νοιάζεστε, διορθώστε όσο μπορείτε την κατάσταση!

Το WebKit είναι η πρώτη rendering engine που υποστιρίζει client-side database αποθήκευση!

Πραγματικά δεν μπορώ να καταλάβω γιατί αυτή η είδηση δεν πήρε τις διαστάσεις που θα έπρεπε, μιας και την θεωρώ εξαιρετικά σημαντική, τόσο για την εξέλιξη του internet όσο και των εφαρμογών του! Το WebKit λοιπόν, η μηχανή rendering που κρύβεται πίσω από πολλούς browsers, όπως Safari και Konqueror, είναι πρώτη μηχανή rendering που θα υποστηρίξει HTML5 client-side database αποθήκευση. Αυτό με πολύ απλά λόγια σημαίνει πως οι browsers που βασίζονται στο WebKit, θα έχουν την δυνατότητα database αποθήκευσης στην client-side (browser) μεριά! Το συγκεκριμένο feature θα δώσει άπειρες επιπλέον δυνατότητες και προοπτικές στους developers οι οποίοι θα έχουν στην διάθεση τους ένα ακόμη χαρακτηριστικό, που μέχρι τώρα δεν υπήρχε και φυσικά περιόριζε πολύ το web σαν πλατφόρμα εφαρμογών. Όπως όλα δείχνουν οι browser θα εξελιχθούν στην μία και μοναδική εφαρμογή που θα χρειάζεται ο μέσος χρήστης, μιας και σιγά-σιγά μετατρέπονται σε υπέρ-API για όλες τις κατηγορίες εφαρμογών.

Είμαι περίεργος να δω την απάντηση της Mozilla με την Gecko rendering engine, καθώς και της Opera στο εν λόγω θέμα (η Microsoft προβλέπω να αργεί πολύ ακόμα). Το μόνο που εύχομαι είναι να ακολουθήσουν όλοι τα επίσημα standards έτσι ώστε να μην έχουμε browser-wars 2!