Il faut voir cette vidéo sur Vimeo (parce que je sais qu’elle passe à la télé mais je suis sûr que ça n’a rien à voir)!
Quoi de mieux qu’une publicité qui s’intègre parfaitement avec son support ? Je n’en dis pas plus : allez absolument voir la vidéo Honda Insight sur Vimeo.
Here & There propose une carte particulière de Manhattan :
L’évolution 3D vers 2D se fait progressivement, sur une courbe visuelle. On me dit qu’un GPS serait une super idée. En effet!
Qui a dit « Où est mon skate ? » ?
Un gars de Brooklyn voulait savoir jusqu’où il pouvait aller en 15 minutes en partant de chez lui. Et puis en 30min, 1h, 2h…
triptrop NYC est une carte colorée de New York où les distances sont représentées par une couleur, rouge pour le plus proche, violet pour le plus éloigné, et tout l’éventail de couleurs entre les deux. Les trajets se font par métro.
Imaginons que je veuille aller du Guggenheim au Flatiron. Ca me prendrait environ 30 min.
Encore une belle utilisation de l’API de Google Maps. Il y a d’ailleurs des infos locales disponibles. A quand la même chose pour Paris ?
3 mai 2009
Nyle « Let The Beat Build » from Nyle on Vimeo.
Une vidéo de grande qualité, dans sa conception et sa réalisation. Je suis étonné par la qualité du son (enregistré directement). Les prises de son ont du se faire à plusieurs endroits, puis masterisé après. Et j’ai bien aimé la phrase « I don’t need a sample, I’ve got a girl with a banjo ».
4 mai 2009
The do’s and don’ts of modern web design regroupe les bonnes pratiques (do’s) et les mauvaises pratiques (don’ts) en web design. A chaque fois, un lien est fourni vers un article expliquant pourquoi c’est une bonne ou mauvaise pratique.
Dans les do’s on trouve par exemple :
Il faut dire qu’en l’occurence le conseil « Mix and match Classes » contredit un peu le « Write good class and id names » parce qu’il crée une classe « bordered » (bouh pas bien). Mais dans l’ensemble ça reste cohérent.
Dans les don’ts (à éviter donc) on a par exemple :
Le site aurait du rajouter « oublier de faire un lien sur le logo du site »!
6 mai 2009
Je me suis posé la question de savoir combien était divisé mon temps pendant que j’intégrais. J’ai divisé en 5 parties ce temps (peut-être en oubliant des parties) et évalué grossièrement leur répartition. Je suis arrivé à ce graphique :
Je code toujours en XHTML 1.0 Strict, et ça m’a évité pas mal de problème de Quirksmode je me rends compte. J’utilise au maximum les balises sémantiques <p>,<ul>,<label>,<hn>,<strong>… mais je suis de moins en moins réticent à multiplier les <div> et <span>. D’un côté, c’est cool d’éviter la divite, c’est joli, c’est léger. Mais en pratique, et surtout pour les gros sites, il faut être très spécifique quant aux styles à appliquer à certains éléments. Donc je rajoute une ou deux div par ci par là pour améliorer ma productivité et surtout la flexibilité du code. Ca facilite grandement la différenciation. Et ça permet surtout de prévoir d’eventuelles évolutions de fonctionnalités, et avoir une approche plus modulaire.
A force de prôner la séparation HTML (contenu) / CSS (mise en page), on a peur de modifier le HTML, comme si c’était devenu interdit voire impossible. Je me dis que les développeurs ne sont pas bien méchants et que l’on peut leur demander des modifs HTML, avoir plusieurs classes sur un même élément au lieu de répéter son code CSS pour pas grand chose (voir plus bas).
C’est évidemment très lié au HTML utilisé. Depuis quelques temps, je me suis fait un fichier reset.css qui utilise le Reset CSS de Yahoo! . Par contre, ce n’est pas un fichier que j’importe à chaque fois mais un code que je copie-colle en créant ma CSS. Parce que oui, je préfère garder une seule CSS pour tout le site. Niveau lisibilité, je n’ai pas trop de problème à utiliser un seul fichier parce que j’écris chaque sélecteur CSS sur une seule ligne. Niveau productivité, répartir des propriétés sur plusieurs CSS c’est passer beaucoup de temps de l’une à l’autre, trouver où se trouve ce sélecteur, éviter les conflits… J’évite. Et le seul vrai avantage d’avoir plusieurs CSS, c’est d’en appeler certaines dans certains cas, et d’autres dans les autres cas. Je préfère mettre une class au body pour différencier les pages, c’est beaucoup mieux.
Les exceptions pour utiliser plusieurs CSS sont : un fichier pour ie6, un fichier par couleur (si il y a des thèmes par couleur) et un fichier pour le print.
Je fais encore pas mal de contextualisation (ex: .bloc table tbody td.direction ) parce que ça permet d’éviter les conflits. + de contextualisation = – de classes à créer
Il y aussi le cas où vous voulez que plusieurs éléments HTML aient les mêmes propriétés CSS Dans ce cas, il y 3 choix :
La première méthode est à éviter : si on veut changer une propriété (ex: la couleur d’une bordure), il faut le changer autant de fois que l’on a copié-collé.
La deuxième méthode est la plus propre : le HTML reste relativement léger (= non alourdi de classes) mais la CSS est plus longue à maintenir. C’est ce que je faisais avant.
La troisième méthode est plus « modulaire » je dirais. Un élément HTML aura par exemple : class= ».maclasse .manouvelleclasse ». On rajoute donc une classe aux éléments qui ont le même style. Mmmh. Est-ce que c’est bien ? Est-ce que l’on sépare bien la mise en page du contenu ? Plus ou moins je dirais. En fait, dans le HTML, on ajoute la classe à tous les éléments qui doivent appraître de la même façon. Et si on veut plus qu’un élément n’aie plus ces propriétés ? Il faut supprimer la classe dans le code HTML. Ah. C’est pas bien. On ne devrait plus avoir à toucher au code HTML. En théorie, c’est vrai. Mais en pratique, c’est, d’une part, très rare de vouloir changer le style d’un seul élément, et d’autre part, pourquoi n’aurait pas-t-on le droit de modifier le HTML ? Une fois livré, on ne peut plus rien faire (voir § sur le HTML) ?
Je dois préciser une chose importante : cette méthode modulaire, je l’utilise surtout pour les blocs et les gros éléments, pour les éléments qui structurent et divisent l’affichage. Il faudrait que j’envisage de faire un article avec des exemples plus éloquents. 🙂
J’ai déjà parlé de ce que l’on pourrait faire si IE6 n’existait plus. En fait, rendre un site compatible IE6, c’est du débuggage pur et simple. On doit utiliser des overflow:hidden, position:relative, display:inline… pour aucune raison valable si ce n’est faire plaisir aux internautes du siècle dernier (ou presque). Sans compter tout ce que l’on est privé de faire. Bref, une calamité.
Dans mon souci d’avoir un code lisible, pour moi et ceux qui retoucheront aux CSS, j’essaye d’avoir des noms de class/id simples mais efficaces. Simple, ça veut dire court. Avec 4 lettres, on peut faire pas mal de choses : .bloc, .nav, .main, .side… J’ai par exemple remplacé .pagination par .page. Ou mettre .srv au lieu de .service. C’est pas très méchant et ça permet d’avoir une CSS bien plus lisible (surtout si l’on contextualise ET que l’on met tout sur une ligne).
Et si je passe autant de temps, c’est aussi pour éviter d’appeler un élément « grillade » par exemple (alors que ça n’a rien à voir avec un barbecue). J’ai vérifié, elle y est encore.
Dernier point : découper le PSD. On voit directement si un PSD est fait par quelqu’un qui sait intégrer ou pas. J’ai de la chance, c’est souvent le cas. Mais lorsque ça ne l’est pas, il faut voir les effets de dégradés, les superpositions, les ombres qui dépassent… qui n’ont l’air de rien graphiquement, mais qui sont une calamité à intégrer. D’ailleurs, c’est une calamité à cause d’IE6! Parce que pour IE6, il faut tout aplatir! L’ombre doit aller avec l’élement qui la fait ET avec l’élément où elle se projette. N’est-ce pas logique ? Et bien non. Vive les PNG. C’est tout.
J’ai essayé de faire un rapide panorama de ce que doit faire un intégrateur. On se rend compte que le grand ennemi reste IE6. Les 40% cités correspondent au temps de débuggage, mais je suis sûr qu’on peut gagner du temps dans les autres domaines (découpage, css, html) si il n’y avait pas IE6. J’ai peut-être oublié des éléments, je ne sais pas. Vous avez des idées ? Des remarques ? Des critiques ?
Le premier navigateur Web dénommé « WorldWideWeb » créé par Tim-Berners Lee tournait sous un ordinateur NeXT, et faisait office d’éditeur aussi. A la base un outil pour aider les scientifiques à s’échanger des informations, le Web a pris une dimension bien plus grande.
If households nowadays want a computer, it is not to compute, but to go on the Web.
WorldWideWeb : le premier navigateur web
12 mai 2009
A la question « Est-ce que je mets un <h1> pour mon logo ? », je répondais oui avant. Maintenant, je réponds non.
Il existe un débat assez récurrent sur l’élément de la page qui portera le h1. Que ce soit dans un post ou deux, ou dans des commentaires, la question reste ouverte. Il y a 2 écoles :
Cas particulier : il arrive d’avoir un h1 pour le logo uniquement sur la page d’accueil, les autres pages ayant un h1 différent. Je classe ces sites dans la deuxième catégorie.
C’est quoi un h1 d’abord ? Selon le W3C, ça donne :
A heading element briefly describes the topic of the section it introduces. Heading information may be used by user agents, for example, to construct a table of contents for a document automatically.
Le h1 est le titre de premier niveau et doit introduire la section qui le suit.
Si le h1 est sur le logo, alors il est tout en haut. Il doit donc décrire tout ce qui le suit, c’est à dire, le reste de la page. Il ne faut pas le mettre sur le logo alors ?
Le titre de la page (balise <title>) est défini ainsi par le W3C :
The TITLE element is not considered part of the flow of text. It should be displayed, for example as the page header or window title. Exactly one title is required per document.
Le titre est unique et doit décrire le contenu de la page. C’est à peu près de cette façon que j’utilise mon h1 : il est unique et décrit la page. Il est pour moi différent pour chaque page, comme l’est le titre.
Par contre, le titre doit être davantage fourni que le h1. L’idéal pour ce post serait :
Mon titre décrit le contenu du document et d’où il provient.
Mon h1 décrit la section qu’il introduit : mon post.
Les deux sont complémentaires parce que l’un fait partie du flux du document, l’autre non. Ils ont donc un rôle légèrement différent.
Je viens de remarquer que Digg et A List Apart ont deux h1 dans la même page (lorsque l’on va dans les commentaires ou sur un article). Ca m’a surpris parce que j’ai toujours cru que le h1 était unique, comme l’est la balise title. Le W3C ne spécifie rien sur l’unicité des headings (h1,h2,h3…) mais étant donné qu’elle préconise d’utiliser une partie de la balise title pour son contenu, je présume qu’il faut que le h1 soit unique.
Si je résume, le h1 :
Cette équation a une seule solution : il y a un h1 différent par page, un lien pour le logo (à part éventuellement pour la page d’accueil, qui est un cas particulier).
Si le h1 doit décrire ce qui le suit et que je le mets sur le logo « bbxdesign » sur toutes les pages (il l’est actuellement uniquement sur ma page d’accueil), alors toutes mes pages auront comme contenu « bbxdesign » ? C’est très léger comme description de ma page, et très redondant, surtout pour les moteurs de recherche. Toutes mes pages ne parlent pas de « bbxdesign ». C’est juste le nom du site (qui est par ailleurs dans l’url). Mes pages ont toutes un contenu différent et je veux que mon h1 reflète ceci. C’est pour ça que ma page d’accueil a le logo comme h1, mais tous mes posts ont leur titre comme h1 (et le logo devient h2).
Le logo décrit le site, pas la page que l’on consulte actuellement. Après, il est possible de mettre deux h1, un pour le logo, un pour le titre du post par exemple. Mais cela voudrait dire que le premier h1 (celui du logo) affiche « bbxdesign », et l’autre affiche « Un h1 pour le logo ou pas ? ». Pourquoi pas, mais je trouve que le second a davantage de poids et de légitimité que le premier. Et étant donné que l’on jusqu’à 6 niveaux hiérarchiques, pourquoi ne pas en tirer profit ?
Si le h1 n’est pas le logo, il se peut (et c’est mon cas) que le h1 ne soit pas le premier élément de la page, mais arrive après le header et la navigation. Est-ce que c’est problématique ? Je ne pense pas. Le W3C ne précise rien à ce sujet. Il faudrait plutôt se poser la question si les titres (h1,h2,h3…) sont davantage une question d’ordre ou de poids ?
A première vue, c’est surtout une question d’ordre. On a d’abord un h1, puis un h2, puis un ou plusieurs h3, puis peut-être un autre h2 suivi d’autres h3… A ce propos, il est interdit de « sauter » un niveau hiérarchique. On ne passe pas d’un h1 à un h3 sans avoir de h2. Il faut voir les h1-h6 comme des chapitres d’un livre.
Users should order heading elements properly. For example, in HTML, H2 elements should follow H1 elements, H3 elements should follow H2 elements, etc. Content developers should not « skip » levels (e.g., H1 directly to H3).
Pour le W3C c’est une question d’ordre. Mais il m’arrive de ne pas suivre cette règle à la lettre. Par exemple, dans une sidebar structurée, je mets des <h3> et des <ul> parce que c’est le poids que je leur donne par rapport au contenu de la page. Et mon post a lui aussi des h3-h6. Par conséquent, l’ordre de mes titres dans mon code peut passer du h6 au h3. Et ce n’est pas spécifique à la sidebar. Ca peut arriver lorsqu’il y a plusieurs zones dans la page avec un contenu différent.
Les titres h1-h6 restent des éléments assez mal utilisés (par moi d’abord), sans doute par manque de précisions de la part du W3C. En même temps, c’est peut-être têtu de s’obstiner autant. Parce qu’en ayant d’un côté le W3C (avec les soucis de standardisation et d’accessibilité) et de l’autre les moteurs de recherche (qui analysent minitieusement notre code), couplés à un flou autour de la définition de l’utilisation des titres, on se demande parfois si la solution est unique.
Je suis grand fan de ce genre de photos : des plans panoramiques à 360° de New York.
C’est intéractif, c’est fluide, et la qualité visuelle est au rendez-vous. Ca rappelle le Quicktime Virtual Reality mais en 20 fois mieux. Je me demande vraiment quel dispositif est utilisé pour prendre de telles photos.
Faites clic droit > Planet View. Vous verrez, c’est surprenant. 🙂
Pour chercher sur Google, Wikipedia ou Youtube, simultanément et rapidement, je dois dire que keyboardr a trouvé une formule efficace, en utilisant uniquement les flèches et la touche « Entrée » pour naviguer.
Vous avez une image, vous voulez savoir d’où elle vient ? TinEye permet de trouver la source des images qu’on lui fournit. Par exemple, si je lui donne une image d’un de mes posts précédénts, sur le premier navigateur web, ça me donne d’autres sites qui utilisent une image similaire.
26 mai 2009
Encore des plugins Firefox ? Oui, mais là, c’est différent :
In short, Jetpack is an API for allowing you to write Firefox add-ons using the web technologies you already know.
En gros, pour faire des plugins Jetpack, il suffit de s’y connaître en HTML/CSS mais surtout en Javascript. Tiens, « plugins »… « Javascript »… Ca rappelle exactement le plugin (XPI lui) Greasemonkey. Et dans un sens, ça rappelle aussi les bookmarklets.
Lire la suite
8 juin 2009
Best Of + Flash + XHTML / CSS
Si vous le souhaitez, allez lire le tutoriel complet sur le HTML 5 et le CSS 3 que j’ai écrit.
Le HTML 5 est la prochaine version importante du HTML. Bien qu’étant en compétition avec le XHTML 2, le HTML 5 fait davantage parler de lui parce qu’étant plus facilement implémentable et plus pragmatique dans l’utilisation des nouvelles balises qu’il introduit.
J’avais déjà parlé du HTML 5 l’an dernier, en parlant notamment des balises visant à structurer le contenu. Mais l’intérêt du HTML 5 se trouve surtout dans ces balises qui vont grandement faciliter la création d’applications web.
Tous les exemples proviennent de la Google Keynote.
Lire la suite
Opera, peut-être le meilleur navigateur qui soit, réinvente le web demain.
L’annonce peut sembler prétentieuse mais je pense que c’est à prendre avec une touche d’humour. Et puis, Opera est un pionnier en termes d’innovations. Opera était le premier pour :
Je n’ai personnellement aucune idée de ce que peut être cette « réinvention du web ». Hicksdesign pense que ça sera tout internet sur une clé usb. 🙂
Le blog assertTrue() a une autre idée, très intéressante : Opera intègerera un serveur web. En lançant Opera, on pourra partager ses favoris, des fichiers, des contacts, des pages web… Chaque navigateur sera alors un serveur web. Ca sera du P2P mais en utilisant du HTTP.
Mmmh, ça reste une spéculation mais ça ne m’étonnerait pas et j’aimerais beaucoup voir ça!
Si je pouvais utiliser toutes mes extensions Firefox avec Opera, je serais déjà utilisateur d’Opera à plein-temps. C’est pour moi le meilleur navigateur qui soit, suivi par Chrome et Firefox. Je suis très déçu par le score que fait Opera : 3,69%.
Ok, je suis web designer, j’ai besoin d’utiliser Firefox, c’est mon outil de travail principal. Mais tous ceux qui ne font pas de web, pourquoi n’utilisent-ils pas Opera ? La cause principale c’est justement parce que les gens ne font pas de web qu’ils ne connaissent pas Opera. C’est le même problème que pour Chrome. Les gens utilisent encore IE (surtout 7 maintenant).
Il me faudrait Firebug sous Opera et je pense que je switcherais définitivement. Dragonfly a l’air pas mal. Je vais tester ça. Et demain, grosse annonce d’Opera alors!
Il existe pleins de générateurs de palette de couleur, notamment kuler. Ici, ColoRotate se distingue par une interface 3D où l’axe horizontal correspond à la saturation, et le vertical à la teinte. On peut aussi choisir sur une échelle de blend entre 2 couleurs. Il suffit d’utiliser le menu en bas à droite pour passer de l’un à l’autre.
17 juin 2009
Ca peut paraître bizarre comme outil, un « compilateur de CSS », mais LESS est avant tout un outil pour écrire plus efficacement une CSS. Ca rend les CSS dynamiques. C’est un outil écrit en Ruby. J’en parle aussi d’ailleurs sur 29minparjour.
LESS se veut être une extension de CSS parce que la syntaxe utilisée pour les fichiers .less (les fichiers source) est très proche de la syntaxe CSS. L’efficacité de cet outil consiste en 4 éléments :
En utilisant des variables, on peut regrouper une valeur à un seul endroit pour pouvoir la mettre à jour facilement par la suite.
@maCouleurPrincipale: #0072bc;
a{ color:@maCouleurPrincipale;}
h1{ color:@maCouleurPrincipale;}
Dans une classe, je peux définir plusieurs propriétés puis inclure cette classe dans d’autres éléments. Ca peut s’avérer très pratique pour les propriétés CSS 3 qui ont une syntaxe différente par navigateur.
.coinsArrondis{ border-radius:5px; -moz-border-radius:5px; -webkit-border-radius:5px;}
#global{ .arrondis;}
Cet outil est le moins intéressant des 4. Il permet de gagner un peu en lignes de code mais je ne le trouve pas très lisible.
#header{
background:#fff;
position:relative;
.logo{
position:absolute;
right:0px;
}
}
Au lieu d’écrire #header puis #header .logo, je mets directement .logo dans #header.
Ca permet d’utilisation des opérations arithmétiques traditionnelles : addition, soustraction, multiplication, division. Ca peut-être pratique si on veut que les marges verticales soient le double des marges horizontales.
@marges:5px;
#global{ margin:@marges*2 @marges;}
J’ai fait un exemple complet utilisant plusieurs fonctionnalités de LESS. Voici mon fichier source bbxdesign.less :
@color01:#0072bc;
@radius:10px;
.radius{ border-radius:@radius; -moz-border-radius:@radius; -webkit-border-radius:@radius;}
@margin:5px;
body{ color:#333; font-family:Georgia,serif;}
a{ color:@color01; text-decoration:none;}
#global{ background:#fff; .radius; margin:@margin @margin*2;}
Et voici le fichier généré bbxdesign.css :
.radius { -webkit-border-radius: 10px; -moz-border-radius: 10px; border-radius: 10px; }
a { text-decoration: none; color: #0072bc; }
body { font-family: Georgia,serif; color: #333; }
#global { -webkit-border-radius: 10px; margin: 5px 10px; background: #fff; -moz-border-radius: 10px; border-radius: 10px; }
Tout se fait en lignes de commande. Il faut avoir Ruby installé sur son ordinateur et installer la gem suivante :
gem install less
Ensuite, en navigant dans le dossier où se trouve le fichier .less, on fait :
lessc monfichier.less
Et le fichier .css est automatiquement généré avec le même nom.
On peut aussi choisir un autre nom pour le fichier généré :
lessc monfichier.less monautrefichier.css
Parce qu’un fichier CSS est souvent modifier, on peut automatiser la création du fichier .css à chaque modification du fichier .less :
lessc monfichier.less --watch
D’ailleurs, si une erreur existe dans le code, le fichier .css ne serait pas généré. Bien pratique.
Il existe plusieurs méthodes pour avoir des CSS dynamiques. J’en ai déjà vues en PHP ou JSP. Mais ces outils génèrent souvent les CSS à la volée, et il faut donc avoir un serveur derrière qui tourne. Ici, le fichier est « compilé » une bonne fois pour toutes.
Autre avantage : la syntaxe de LESS est très proche de la syntaxe CSS. Il est très facile de prendre une CSS existante et la transformer en fichier LESS. Ca m’a pris 2min d’ailleurs.
Après, est-ce que je vais l’utiliser au quotidien ? Ecoutez, je vais essayer.
Acrobat.com sort de sa beta et devient public. Il consiste en plusieurs services :
A part Buzzword, j’avais jamais entendu parler de ce service. J’ai pas l’impression qu’il y aie eu de grosse annonce. En tout cas, Adobe marche sur les plate-bandes de Google Docs : des outils de collaboration en ligne, gestion/création de documents, partage de fichiers…
C’est en fait la concurrence Flash vs HTML/Ajax (et bientôt HTML 5).
Personnellement, je ne compte pas m’inscrire pour utiliser ce nouveau service. Il n’a pas l’air très rôdé. Et puis Google Docs me convient très bien pour ce dont j’ai besoin. Et y a le côté Google, toujours innovant, très fiable et intégrant parfaitement ses différents services (Mail,Reader,Calendar…) qui me rend fidèle.
La réalité augmentée, qui consite à superposer un élément virtuel 2D/3D à un élément réel, ne cesse de s’améliorer. Dernière démo en date : ce FPS qui utilise une image posée sur la table en guise de map de jeu, et permet au joueur d’inclure des éléments réels (ici des bonbons Skittles :-D) dans la map!
Dustin Curtis, un designer d’interfaces, devait réserver un billet sur le site (horrible) d’American Airlines. J’ai déjà eu à le faire aussi lorsque je suis allé à New York. Son expérience en tant qu’utilisateur n’ayant pas été très plaisante, il s’est dit qu’il allait proposer sa propre refonte du site.
Je suis personnellement très fan de cette refonte du bloc le plus important du site : la réservation. Il y a un côté aéré, léger (pour une compagnie aérienne, que demander de mieux ?) et efficace dans sa refonte. Je me rappelle que je voulais proposer une refonte du site l’Equipe.fr (un tout autre domaine, un tout autre rôle) mais j’ai pas pris le temps de le faire et entre-temps, leur refonte est plutôt réussie. 🙂
Ok, Dustin Curtis ne connaissait sans doute pas les raisons qui amènent American Airlines à garder leur site tel quel. Mais il a reçu une réponse de la part du User Experience Architect. Un extrait (repris sur Words on Design – « shameless self promotion… ») :
We could even redesign the AA.com home page without having to slog through endless review and approval cycles with their requisite revisions and re-reviews.
En résumé, dans sa lettre de réponse, il dit qu’American Airlines est une boîte trop grosse avec beaucoup trop de gens impliqués dans le design pour que l’équipe de design puisse faire son boulot correctement, ou devrais-je dire, puisse faire son boulot tout court.
Je sais exactement ce qu’il veut dire.
American Airlines a les compétences en interne pour avoir un site intéressant, mais ne les utilise pas. Un problème politique ? Je pense aussi.
C’est sans doute la crainte des grosses entreprises d’avoir un site aussi aéré et léger, avec peu de contenu. Ils se disent peut-être qu’avec tout leur argent et la taille du trafic du site, ils doivent forcément avoir un site avec beaucoup de fonctionnalités, de contenu, des liens partout, des promos par ci par là…
Je sais pas. Le peur d’innover ? De faire confiance aux plus jeunes ? A ceux qui savent ? A ceux dont c’est le boulot ?
Je pense sincèrement que la qualité d’un design est (quasiment) inversement proportionnelle au nombre de personnes (ignares?) qui donnent leur avis dessus. Avoir une équipe de plusieurs designers, OK. Mais lorsque les services commercial ou technique y mettent leur nez, ça commence à sentir le roussis. Chacun son taf et tout ira bien!
24 juin 2009
J’aimais pas trop les lightbox au début, un peu trop « fancy » à mon goût. Certains la critiquaient même exagérément. Bref, que l’on aime ou pas, ça utilise techniquement toujours du JavaScript.
Mais un ninja a réussi à le réaliser sans JavaScript, juste en CSS. Ca utilise la pseudo-classe :target. Et il appelle ça Futurebox.
Ok, ça marche pas sous IE (6,7,8) mais qu’est-ce qu’on s’en fout. Tiens d’ailleurs, gros f*ck à Microsoft pour son discours de merde (IE8 = le meilleur navigateur du monde entier de l’univers) et ses décisions de merde (Outlook 2010 utilisera le moteur de Word pour afficher le HTML).
25 juin 2009
Que faire face à IE6 ?
IE6, c’est vieux, c’est lourd, c’est moche, c’est chiant. Ca prend du temps, pour pas grand chose, et pour de moins en moins de monde (20% grande moyenne à l’échelle mondiale).
Et puis le web, c’est pour le contenu avant tout. Au lieu d’avoir un site buggé de partout sur IE6, pourquoi ne pas offrir une CSS propre et claire ? C’est l’idée derrière Universal Internet Explorer 6 CSS.
29 juin 2009
Pour savoir ce que l’on peut utiliser sans craindre une incompatibilité entre navigateurs, on peut se fier à ces tableaux des propriétés HTML, CSS, DOM et ECMAScript. Il manque juste Webkit dans le lot.
Il y a par ailleurs un tableau résumant tout.
1 juillet 2009
L’objectif de Google, avant tout, c’est la performance. Ils publient d’ailleurs des conseils pour optimiser l’affichage du navigateur.
A la trappe les standards, la beauté, la clarté du code. Extraits choisis.
Mettre uniquement des .class et des #id et pas de a{ color:#0072c;} ou de input{ font-family:Arial,sans-serif;}. Mouais. Faut mettre une classe sur tous ses liens alors ? Génial.
En gros, pas de a.maClasse et de p.maClasse. Créer plutôt 2 classes : .maClassePourUnLien et .maClassePourUnParagraphe, même si les deux classes partagent les mêmes propriétés, à une près (sinon quel intérêt de les différencier). Mouais, bof. Si je veux que .maClasse soit d’un style particulier mais que les liens ayant .maClasse aient une propriété différente, je vais pas m’amuser à créer une autre classe juste pour ça.
Je reprends le mauvais exemple de Google :
/* Ne pas mettre */
ul li {color: blue;}
ol li {color: red;}
/* Mais mettre */
.unordered-list-item {color: blue;}
.ordered-list-item {color: red;}
Bien sûr. Je vais mettre une classe sur tous mes <li>…
Pas de :hover en CSS mais des onmouseover en JS. Et si le gars a pas de JS ?
Bref, pour optimiser votre code, mettez des classes sur tous vos éléments! Merci Google!
