WebKit ?
WebKit est souvent pris pour plusieurs choses à la fois. On pense que c'est un navigateur, on pense que ce sont les versions de développement de Safari ou tout autre idée répandue. En réalité, ce n'est qu'un moteur web. Tout ceci est bien résumé sur la page d'accueil du projet ou sur Back to the basics. Là où ça devient un peu plus confus, c'est que c'est aussi le nom d'un framework de Mac OS X. Ainsi, il est possible simplement d'afficher du contenu web dans son application en utilisant ce framework. On passe au niveau d'incompréhension supérieur : les nightlies. Régulièrement, des compilations nocturnes sont mises à jour. Il y a le source dans une archive tar.gz. Afin que de nombreuses personnes testent, il y a aussi des versions compilées pouvant tourner avec Safari Mac ou Safari Windows. Elles ne font que lancer le navigateur Safari installé sur votre machine avec une autre version du moteur.
Une autre particularité du projet est l'absence de versions à proprement parlé. Chaque éditeur souhaitant utiliser WebKit choisit ce qu'il souhaite intégrer.
Pourquoi Firebug et Web Inspector ?
Firebug est un très bon outil, pourquoi en apprendre un autre ? Tout simplement, les fonctionnalités, bugs et autres particularités des navigateurs nous obligent à avoir des outils pour analyser nos pages sous chaque navigateur. IE8 intégrera de nouveaux outils annoncés plus adaptés, Opera intègre déjà DragonFly. Et WebKit possède le Web Inspector depuis Safari 2. Une mise à jour a eu lieu avec Safari 3 puis avec Safari 3.1. Mais tout cela restait bien fade par rapport à ce qui arrivera dans la prochaine version majeure de Safari (Safari 4 en bêta depuis quelques jours). Il est intéressant de tester ses pages avec le Web Inspector dès aujourd'hui. Safari représente déjà près de 7% aux États-Unis, cela est appelé a augmenté naturellement par la part de marché croissante des Mac. L'iPhone représente une partie non négligeable du trafic provenant de mobiles. Chrome est désormais sorti de beta. Et il y a bien d'autres logiciels qui embarquent ou embarqueront WebKit.
Fonctionnalités
Pour les fonctionnalités, je vais avoir du mal à retranscrire la présentation, vu que c'était plutôt "hands-on" (et brouillon aussi). Je vous invite à consulter la documentation de Firebug et la présentation des dernières nouveautés du Web Inspector (et ma traduction).
Ce qu'il faut retenir, c'est qu'il n'y a pas que l'onglet HTML de Firebug. Il est bien utile mais l'onglet Réseau (ou Resources côté WI) peut vous aider à améliorer les performances de votre site. Par exemple, on peut regardez quelles ressources prennent vraiment du temps à être téléchargé, quels sont les headers envoyés, reçus. Abusez des profilers si vous utilisez JavaScript. Cela vous permettra de trouver les fonctions les plus lentes ou trop souvent appelées dans votre code. Sans oublier le Débugueur. Positionnez des points d'arrêt, regardez l'état des variables à cet instant, parcourir la suite du code, etc. Autant d'infos précieuses pour comprendre le fonctionnement réel de votre code (ou le code d'un autre site). Et bien entendu, la console permet d'essayer des morceaux de code, d'étudier la page, elle est également disponible lorsque le débugueur est utilisé.
La Console API est tout simplement géniale. Fini le débug avec alert(). Utilisez console.log, console.warn, console.group ou console.assert pour suivre le déroulement de votre application. Vous pourrez les enlever très facilement de votre application en environnement de production et cela vous fera gagner un temps précieux en développement. Contrairement à alert() qui est bloquant, les messages de l'API console ne vous gêneront pas dans vos tests. Abusez-en !
Dans les astuces peu documentées, je rappelle souvent le mot clef debugger; en JavaScript qui permet de mettre en pause l'exécution du script, comme un point d'arrêt classique.
Autre astuce : $0 dans la console permet d'accéder au dernier élément inspecté. On peut ainsi par exemple rapidement faire $0.style.display = 'none'; . $1 permet d'accéder à l'élément inspecté avant $0 et ainsi de suite. Cela n'est pour l'instant valable que dans Firebug.
Contribuez !
Hormis les outils de IE8, tous les autres sont libres, même DragonFly. Ce sont vos outils de tous les jours, ne les négligez pas. Si quelque chose vous gêne, n'hésitez pas à remonter l'info. Il y a bien entendu les bug trackers mais vous pouvez aussi me remonter l'info si vous préférez parler directement à quelqu'un (en tout cas pour le Web Inspector).
Un exemple concret de retours dont nous avons besoin : beaucoup de gens se plaignaient que les styles n'étaient pas éditables. Cela fait longtemps qu'ils le sont et nous ne comprenions pas pourquoi nous avions ces retours. Après quelques discussions, nous nous sommes rendus compte que les gens ne comprenaient pas ce qu'était les "Computed Styles", premier onglet de style ouvert. Depuis ces discussions, cet onglet est toujours présent mais replié. Nous ne pouvions pas découvrir ce problème sans retours.
En plus de cela, si vous souhaitez vous impliquer, sachez que le Web Inspector est intégralement réalisé en HTML/JS/CSS (tout comme DragonFly). Il est donc très facile pour un développeur Web de s'essayer au développement de ces outils.
Quelques URLs utiles :