Dive the web

I’ve been working in the Web industry for about 12 years. During these years, I started to read about best practices in web development. I found a lot of them useful, both to ensure a better quality to my work, but also to make it easier - and sometimes quicker. I’m not claiming to have the best solutions to everything, the following tips are just a few of the things I try to do when coding. Some apply to (X)HTML or CSS, others are more appropriate to PHP or even JavaScript. Some are valid when working in a team, others when working alone.

• Follow conventions.

  This is valid both for team and solo work. When working on your personal projects, pick a style and stick to it. When working with a team, either agree with a coding style with the team or, if one is already chose, use it - even if it’s different than yours. It will make it easier for both you and your team members to understand your code.

• Validate HTML and use semantically correct markup.

  HTML tags have a meaning. A <p> indicates a paragraph. A <ul> indicates a list. Valid HTML has meaning, both to humans and machines.

  Validating HTML may help you find errors in your code. Not just markup errors, but also display errors. Something that may look great in a browser may look terrible in another. And most of the time, you have to support more than one browser.

• Comment your code

  This one will never be repeated enough. Commenting helps you and team members. In six month, you may not remember what you did today. Comment! Comment! Comment!

• Don’t commit incomplete or buggy code

  Except on rare occasions, it’s better to never commit incomplete or buggy code when using a source control tool. Stuff that goes into the common repository is supposed to work.

• Keep team members informed

  Communication is important. You refactoring code, you need to let team members know. Email is useful. Documentation is better. When you create a new library, let team members know about it. If they don’t know about it, they may create something that does pretty much the same thing. Time wasted.

• Be consistent when indenting.

  This is good for whatever language you use. Consistency in indentation helps finding your way around your code. By indenting, you can quickly see blocks of code or remove unused blocks.

• White space is your friend

  Yes, this goes with the consistency in indentation. But white space also means inserting white lines between statements or functions. But don’t overuse it. There’s no need to put 10 carriage returns between blocks of code.

• Google too

  Yep, Google is your friend. Your best friend. If you have a problem, chances are, you’re not the first one. It’s probably documented on mailing lists or Stack Overflow. Google knows, Google remembers!

• IRC channels

  It’s amazing who you may run into on an IRC. Lots of people hang around on those channels and may help you. If you ask nicely and respect the channel’s rules.

• Use available tools: good IDE, debugger, Firefox addons.

  A good IDE will help you in may ways: auto-complete built-in functions, sometimes a built in debugger or direct access to your version control tools.

  Firefox has great addons such as Firebug, the web developer tool bar or the regular expression tester that could save you lots of headaches.

• Check logs

  Logs may indicate problems. Apache logs, PHP logs… The information you may find in these logs may prove useful. But you need to learn how to read them!

• PHP Errors

  In a development environment, set your php.ini’s error reporting to E_ALL and display_errors to ON. This can help tracking errors and solving problems. But make sure you change this when going online.

What are your tips? What techniques do you use to ensure the quality of your code?

Twitter This

Usuario: Password:

Je m’occupe du blog d’une amie. Une fois de temps en temps, je vais vérifier le spam et l’effacer (si nécessaire). Le spam, c’est un combat perpétuel. Qui est quand même relativement bien contrôlé. Du moins, dans mon cas et dans celui de Lady Guy.

Pourtant, la dernière fois que j’ai été voir sur le blog de LG, j’ai trouvé un message qui m’a un peu vexée : Did u ever heard about CSS…? it will help your site. D’accord, je sais que ces blogs pourraient être améliorés, que la feuille de style pourrait être mieux, mais pour qui se prend-il ce spammeur? Zut, je sais quand même faire la différence entre un em, un px et un pt!

Alors, aujourd’hui, quand j’ai vu le carnet d’Eric Meyer… j’ai éclaté de rire! Surtout de ma prompte réaction d’il y a deux semaines

C’est ça le spam sans filet!

Twitter This

Usuario: Password:

Enfin! On l’attendait depuis longtemps cette chanson! J’espère qu’il va aussi nous faire XHTML

Un petit extrait :

CSS oh oui CSS
j’applique ta sémantique
tu es parfois si stricte

Allez en grand nombre écouter CSS par di13774n73.

Twitter This

Usuario: Password:

L’article Balise <img> ou feuille de style ? publié par Raphaël sur Alsacréations (avec un S!!!) vaut le détour. En effet, ce n’est pas toujours évident de savoir si une image est porteuse de contenu (et doit donc être insérée dans le HTML) ou est uniquement décorative.

Dans un monde idéal, les rédacteurs devraient fournir aux intégrateurs les ALT et les descriptions longues des images quand ces dernières sont porteuses de sens. évidement, dans le vrai monde, ce n’est pas toujours le cas - dans l’agence où je travaille, on nous a dit que c’était aux intégrateurs de rédiger ces textes. D’accord quand il s’agit d’un bouton sur lequel on peu voir en belles lettres blanches le mot “recherche”. Mais dans la plupart des cas, ça peut devenir un réel problème. Imaginez un site web pour une compagnie de camionnage ayant une flotte de camions de la marque X. Personnellement, je n’y connais rien. Pour moi, un camion, c’est un camion. Si je dois mettre la marque du camion dans le ALT, il y a beaucoup de chances pour que je fasse de la publicité pour la marque Y.

Le métier est encore jeune, il y a beaucoup à faire pour avoir une méthode de travail vraiment efficace. Une équipe complète en agence devrait toujours avoir un rédacteur web (j’insiste sur le web).

Twitter This

Usuario: Password:

la spandivite, vous connaissez ? de Normand et aussi la liste complète de diverses maladies sur Alsacréation. Symptômes, conséquences et traitements…

Twitter This

Usuario: Password:

Fallait bien que quelqu’un finisse par faire un design qui donne envie de porter des lunettes de soleil pour CSS Zen Garden. Ça me rappelle vaguement ma première page HTML (faite avec PageMill à la préhistoire). Sauf que ma page était un peu moins pizza.

Ce qui me fait penser - excusez-moi, je suis dans une drôle d’humeur ce matin - où en sommes-nous dans l’évolution du web? On s’entend certainement pour dire que PageMill, Netscape Navigator 2 font partie de la préhistoire, mais maintenant, où en sommes-nous?

Sommes-nous au Moyen Âge? Époque souvent reconnue comme étant sombre (pas par tout le monde, je sais…), se caractérise-t-elle par une absence d’ordre (de normes) dans le web?

Où sommes-nous plutôt à la Renaissance? Mais dans ce cas, je ne sais pas vraiment de quoi on renaîtrait, parce que sincèrement, le web n’est pas encore arrivé au status de phénix - y’a encore pas mal de croutes à manger il me semble…

Je crois que nous sommes dans une période en pleine ébulition - et c’est un peu idiot de tenter le parallèle avec l’histoire de l’humanité ;)…

Un virage semble se faire vers l’adoption de normes et de standards - peut-être est-ce un développement logique pour une nouvelle technologie. J’imagine facillement que les premiers à fabriquer du béton le faisaient comme bon leur semblait. Le jour est peut-être arrivé où une association ou un regroupement a proposé des méthodes de standardiser la production et d’assurer ainsi un minimum de qualité commune…

Mais je ne fais que divaguer ce matin…

Twitter This

Usuario: Password:

Un petit trésor sur Alsacréation: centrer un site et un calque div en CSS.

Twitter This

Usuario: Password:

Le language CSS est sensible à la casse. Du moins, c’est ce que je croyais.

Et bien, me voici toute ébaubie, je découvre qu’il ne l’est pas. J’ai défini une class smallTxt et j’ai fait une faute de frappe en oubliant de capitaliser le t… et ça marche. Je m’étonne, je crois d’abord faire face à un bug du navigateur. Je teste dans FireFox 1.0 et IE6. J’ai ensuite essayé le coup avec SMALLTxt et SmALLtxt… Même résultat: le style est toujours appliqué.

Je vérifie donc sur quelques sites et j’ai la confirmation que je cherchais: le CSS n’est pas sensible à la casse. J’ai un réel sentiment d’étrangeté. Ça fait des années que je fais du CSS en faisant super attention à la casse… OK, c’est toujours mieux pour des raisons de clarté de se donner une convention (y compris pour la casse) et de la respecter. N’empêche…

Mise à jour (18 novembre): voir aussi CSS, sensibilité à la casse, doctype switching et lecture des specs

Twitter This

Usuario: Password:

à qui revient le droit de choisir le look d’un site? Au propriétaire du site ou aux usagers? J’entends déjà des grognements. Au propriétaire du site diront certains - évidement, c’est lui qui décide, c’est son site, il est chez lui… Aux usagers, s’exclameront d’autres. Après tout, pourquoi pas? Sans eux, le site n’a pas de raison de vivre. Le débat peut aller encore plus loin: est-ce que les styles switchers ont une utilité? Ne sont-ils pas de simples gadgets servant à mystifier les foules? Quels sont les usagers qui s’en servent réellement?

En général, les styles switchers utilisent des cookies - je ne vois pas de réel problème d’accessibilité ici: même si ces derniers sont en JavaScript, ils n’empêchent personne de profiter du contenu. à moins, évidement, que le style par défaut soit innaccessible. Ce qui serait un peu… un peu…

Est-ce que ces derniers améliorent l’expérience de l’usager? Selon moi, oui. L’usager peu choisir la mise en page qu’il préfère et qui lui convient le mieux. Encore faut-il qu’une mise en page qui corresponde à ses besoins soit disponible.

Mais l’usage de cette technique ne devrait pas nous empêcher de développer des feuilles de style correspondant aux normes. Ce n’est pas parce qu’on permet à l’usager de choisir une feuille de style plus accessible que nous pouvons nous permettre de négliger l’accessibilité - surtout dans la feuille de style par défaut.

Voir aussi: Stopdesign

Twitter This

Usuario: Password:

Pour vous tous amoureux des CSS, je vous conseille le guide définitif du Z-positionnement, tel qu’annoncé sur WASP.

Le guide est assez complet puisqu’il couvre les éléments positionnés relativement et absolument.

Le positionnement Z est un des trucs que je trouve le plus chouette des feuilles de style. Ça permet de créer des effets fantastiques tout en maintenant l’accessibilité à un niveau optimal.

Twitter This

Usuario: Password: