urn:sha1:b2b4b25b360b2a28a9d30d3284597f0822a36e87Webnaute : Conception webConception de sites, de scripts et d’applications en rapport avec le web. PHP, xhtml, css, DOM, xml…2021-02-03T13:15:31+01:00Copyright (c) 2021, Aurélien Maille (Licence Attribution-NonCommercial 2.5 de Creative Commons)http://creativecommons.org/licenses/by-nc/2.5/urn:sha1:fb8a8cf20b6c87a6d12177bc833077c6af090efbWamailer et OpenPGP2006-08-13T17:07:28+02:002006-08-13T17:07:28+02:00
<p>J’ai terminé cette nuit l’implémentation d’OpenPGP/MIME dans Wamailer.
L’<a href="http://fr.php.net/manual/fr/ref.gnupg.php" hreflang="fr">extension gnupg</a> de
<abbr title="PHP: Hypertext Preprocessor" lang="en">PHP</abbr> étant considérée
comme expérimentale, les opérations de signature et de chiffrement sont faites en exécutant des commandes
systèmes à destination du programme GnuPG.</p>
<p>Je ne sais ce qu’il en est du support d’OpenPGP/MIME dans la plupart des clients mail, mais je suppose qu’il doit
être largement supporté, vu la relative facilité avec laquelle j’ai appréhendé le principe des clés et implémenté
OpenPGP/MIME dans Wamailer.</p>
<p>J’ai aussi mis à jour la page de garde du wiki et ajouté la page <a href="http://dev.webnaute.net/wamailer/trac/wiki/OpenPgp">OpenPgp</a>
pour fournir des explications et exemples.</p>
<ul>
<li><a href="http://dev.webnaute.net/wamailer/trac/">Zone de développement de Wamailer</a></li>
<li><a href="http://www.gnupg.org/" hreflang="en">Site officiel de GnuPG</a></li>
<li><a href="http://www.faqs.org/rfcs/rfc3156" hreflang="en">La RFC 3156 sur le format OpenPGP/MIME de sécurisation des emails</a></li>
</ul>
urn:sha1:c1f781af522e74a1804266ccf3c6900b4c94d4cbMise à jour de XHTML22006-07-27T15:04:18+02:002006-08-05T20:06:16+02:00
<p>Le <abbr title="Word Wide Web Consortium" lang="en">W3C</abbr> a publié hier une mise à jour de <a href="http://www.w3.org/TR/xhtml2/">XHTML 2.0</a>. Je mets à jour ce billet dès que j’aurai trouvé une liste des changements.</p>
<ins datetime="2006-08-05T20:06:16+02:00" title="Ajouté le samedi 5 août 2006 à 20h06"><p>Au temps pour moi, le lien vers le fichier diff était sur la page que j’ai liée.</p></ins>
<ul>
<li><a href="http://www.w3.org/TR/2006/WD-xhtml2-20060726/">XHTML 2.0 : <span lang="en">Working Draft</span> du 26 juillet 2006</a></li>
<li><a href="http://www.w3.org/TR/2006/WD-xhtml2-20060726/xhtml2-diff.html">Changements avec la version précédente</a></li>
</ul>
urn:sha1:882c14dca2dfbb299b2cfa1b3757ce63209080dcSQL et structure arborescente2006-05-23T18:22:34+02:002006-05-23T18:23:26+02:00
<p>Dans le cadre d’un projet que je développe en ce moment, j’ai besoin de stocker un arbre dans une base de
données, c’est à dire un groupe d’éléments reliés par une relation de type parent-enfant. Plusieurs solutions existent :</p>
<h3>Les listes adjacentes</h3>
<p>C’est la méthode la plus naturelle et celle à laquelle j’ai d’abord penser.
Le principe est tout simplement d’associer à chaque nœud l’identifiant du nœud parent.
On peut ensuite extraire nos données de différentes façons avec des auto-jointures
(voir le lien vers mysql en fin de billet).</p>
<p>Le problème est que cela n’est pas applicable si la profondeur de l’arbre n’est pas fixée. Il faut alors en passer
par une routine récursive (en PHP dans mon cas) pour construire l’arbre et travailler dessus.
C’est bourrin, c’est coûteux…</p>
<h3>Les ensembles imbriquées ou <q>représentation intervallaire</q></h3>
<p>Moins facile à appréhender, cette technique offre en revanche une bien plus grande facilité pour lire tout ou
partie de l’arbre. La plupart des opérations de lecture ne nécessitent qu’une requête
<abbr title="Structured Query Language" lang="en">SQL</abbr> !</p>
<p>Le principe est d’assigner à chaque élément deux bornes, les descendants de cet élément étant englobés dans
l’interval créé par ces deux bornes. Je me permets de copier ici la représentation visuelle en tranche donnée dans l’article de SQLpro, ça permet de tout de suite se faire une bonne idée du mécanisme :</p>
<img src="http://blog.webnaute.net/2006/05/23/SQL_et_structure_arborescente/images/Tree.gif" alt="Représentation sous forme de tranches englobantes du mécanisme des ensembles imbriqués">
<p>Je ne m’attarde pas sur les requêtes <abbr>SQL</abbr> à utiliser pour consulter un tel arbre, consultez
l’excellent article <a href="http://sql.developpez.com/arborescence/" hreflang="fr"><q>Gestion d'arbres par
représentation intervallaire</q></a> pour en savoir plus.</p>
<p>Ici, donc, pas besoin de récursivité, la lecture est simple et claire. Mais les choses se gâtent dès qu’on souhaite
effectuer des changements sur notre arbre. Souhaite t-on ajouter un élément dans notre arbre ?
Paf, trois requêtes ! Une pour décaler les bornes droite, une autre pour décaler les bornes gauches, et enfin, la requête pour insérer le nouvel élément. Et si plusieurs modifications peuvent potentiellement survenir quasiment
au même moment, ne pas utiliser les transactions, et donc, dans le cas de MySQL, les tables innoDB, serait plutôt hasardeux.</p>
<h3>Autres idées</h3>
<p>Comme autre technique, il y en a une qui consiste à stocker carrément le chemin canonisé d’un élément à la racine.
Pas super élégant et viable seulement pour des petits arbrisseaux ;¬)</p>
<p>J’ai vaguement pensé à stocker la structure de l’arbre sous forme <abbr title="eXtensible Markup Language" lang="en">XML</abbr>, elle-même stockée dans la base de données, mais là comme ça, sans
creuser l’idée, je me dis que les performances ne seront pas vraiment au rendez-vous.
Qu’en penses-tu toi, visiteur perdu sur mon journal ? Et si tu as d’autres idées pour gérer un arbre,
n’hésite pas ;¬)</p>
<ul>
<li><a href="http://dev.mysql.com/tech-resources/articles/hierarchical-data.html" hreflang="en" lang="en">
Managing Hierarchical Data in MySQL</a></li>
<li><a href="http://sql.developpez.com/arborescence/" hreflang="fr">Une référence : Gestion d’arbres par représentation intervallaire</a></li>
<li><a href="http://www.dbazine.com/oracle/or-articles/tropashko4" hreflang="en" lang="en">Trees in SQL: Nested Sets and Materialized Path</a></li>
<li><a href="http://pear.php.net/package/DB_NestedSet" hreflang="en"><abbr title="PHP Extension and Application Repository" lang="en">PEAR</abbr> : Paquet DB_NestedSet</a></li>
<li><a href="http://www.evolt.org/article/Four_ways_to_work_with_hierarchical_data/17/4047/index.html" hreflang="en" lang="en">Four ways to work with hierarchical data</a></li>
</ul>
urn:sha1:4194d149e1929b2acff4721df3c064de609eebf1Un cookie pas si récalcitrant2006-05-17T22:52:13+02:002006-05-17T22:53:32+02:00
<p>Errata concernant mon <a href="http://blog.webnaute.net/2006/05/02/Cookie_r%C3%A9calcitrant/">précédent
billet sur le sujet</a>.</p>
<p>D’abord, en envoyant un cookie avec pour domaine de validité <samp>.example.com</samp>, celui-ci sera
viable également sur <samp>example.com</samp>. L’extension <q lang="en">View Cookies</q>
de Firefox m’a induit en erreur.</p>
<p>Il semble que seuls les cookies dont le domaine de validité matche exactement le
domaine courant soient affichés par cette extension, les cookies avec un domaine de validité de type
<samp>.example.com</samp> valides sur plusieurs sous-domaines ne sont pas du tout affichés.
Un coup d’œil à liveHttpHeaders ou avec <code>print_r($_COOKIE);</code> montre qu’ils sont bien actifs.</p>
<p>Ensuite, concernant le nombre minimum de caractères point dans le domaine de validité, celui-ci doit contenir
au moins un point "embarqué" (x.y est bon, .y ou x. ne l’est pas) et la partie précédent le domaine de validité du cookie
dans le nom d’hôte courant ne doit pas contenir de point. Example : le cookie avec le domaine de validité
<samp>.foo.com</samp> sera valide sur <samp>foo.com</samp> et n’importe quel sous-domaine
<samp>*.foo.com</samp> où * est une chaîne ne contenant pas de caractère point. Donc le cookie n’est pas
valable sur <samp>*.bar.foo.com</samp>.</p>
<p>Au vu de ces règles (extraites de la RFC 2965), je ne vois plus ce qui empêche en principe d’émettre un cookie
avec un domaine de validité tel que <samp>.co.uk</samp> et qui serait valable par exemple sur
<samp>blah.co.uk</samp>. Ce billet est donc sujet à une mise à jour ultérieure, quand j’aurais éclairci ce point :¬)</p>
<ul>
<li><a href="http://www.faqs.org/rfcs/rfc2965" hreflang="en">RFC 2965 - <abbr>HTTP</abbr> State Management Mechanism</a></li>
</ul>
urn:sha1:537f4ea0e738305889f3b972dc10a2ee0ae12ae7Un cookie récalcitrant2006-05-02T19:39:15+02:002006-05-02T19:50:09+02:00
<p>Je viens de passer une demi-heure sur un problème à la con. La réponse servira peut-être à d’autres personnes :</p>
<p>L’attribut <code>domain</code> d’un cookie ne peut cibler qu’un sous-domaine (le nom complet doit
comporter au moins deux points, par exemple <samp>www.example.com</samp>). Pour que le cookie soit
actif sur tous les sous-domaines, n’indiquez pas de sous-domaine (mais laissez le point en tête) :
<samp>.example.com</samp><br>
Problème : <samp>example.com</samp> ne fait pas partie des heureux élus.</p>
<p>Compte tenu de l’obligation d’indiquer un nom de domaine comportant au moins deux points, toute
tentative d’envoyer un cookie sur la racine d’un domaine (<samp>example.com</samp>) en précisant
le domaine dans la fonction <code>setcookie()</code> sera vouée à l’échec. La seule solution est de
ne pas préciser le domaine de validité du cookie (= cookie valable uniquement sur <samp>example.com</samp> dans notre cas).</p>
<p>D’après la spécification, cette limitation est là pour éviter des émissions de cookie dans des domaines
de validité tels que <samp>.com</samp> ou encore <samp>.co.uk</samp>.<br>
je lis d’ailleurs à l’instant que le nombre de caractères points minimum est porté à trois si l’extension du domaine
n’est pas dans la liste des extensions "spéciales" : "COM", "EDU", "NET", "ORG", "GOV", "MIL", et "INT".</p>
<ul>
<li><a href="http://wp.netscape.com/newsref/std/cookie_spec.html" hreflang="en">Persistent client state <abbr title="Hyper Text Transfer Protocol" lang="en">HTTP</abbr> cookies</a></li>
<li><a href="http://www.faqs.org/rfcs/rfc2965" hreflang="en">RFC 2965 - <abbr>HTTP</abbr> State Management Mechanism</a></li>
</ul>
urn:sha1:4f7c1410b6223b67f137fc448992ea273920cb8bWD : Window object2006-04-10T20:47:26+02:002006-04-10T20:47:26+02:00
<p>Le <abbr title="World Wide Web Consortium" lang="en">W3C</abbr> avait publié il y a
quelques jours un premier <a href="http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/" hreflang="en">brouillon sur l’objet <code>XMLHttpRequest</code></a>, c’est maintenant le tour de
l’<a href="http://www.w3.org/TR/2006/WD-Window-20060407/" hreflang="en">objet <code>Window</code></a>.
Affaire à suivre…</p>
urn:sha1:64159c9b79135bed035b0a709bfd229ffe89967bPHP5, getter et empty()2006-03-09T19:23:20+01:002006-03-09T19:23:20+01:00
<p>Je viens de constater une chose étrange avec PHP5. Si la valeur d’une propriété d’un objet est récupérée par le
biais de la méthode magique <code>__get()</code>, cette propriété est toujours considérée comme vide lorsqu’on
la teste avec <code>empty()</code> :</p>
<pre><code>
class Test {
private $_foo = 'bar';
public function __get($name)
{
if( $name == 'foo' ) {
return $this->_foo;
}
}
}
$test = new Test();
echo $test->foo;// affiche bien 'bar'
var_dump(empty($test->foo));// affiche bool(true) ?!
</code></pre>
<p>Il y a probablement une logique interne derrière ce comportement surprenant, mais basiquement, on s’attend simplement
à ce que <code>empty()</code> nous dise si la variable ou l’attribut testé est vide ou pas, point barre. Cela fait
partie de ces comportements vicieux qu’a parfois <abbr title="PHP: Hypertext Preprocessor" lang="en">PHP</abbr>.</p>
<p>Dans la même veine, on a le résultat d’une comparaison non stricte entre un entier et une chaîne (par exemple issue de $_POST) :</p>
<pre><code>
$var1 = 1;
$var2 = '1textQuelconque';
var_dump($var1 == $var2);
</code></pre>
<p>…affichera 'bool(true)'. Et oui… C’est déjà plus logique, si l’on veut, mais c’est tout aussi vicieux.
Attention donc, quand vous contrôlez les données provenant d’un formulaire. Rappelez-vous que tout ce que vous
recevez dans $_GET, $_POST et les autres ont le type 'string' (ou 'array', si vous passez des tableaux), donc faites
vos comparaisons exclusivement entre valeur de type 'string', ou bien utilisez <code>intval()</code> et ses amis
quand vous attendez des données précises.</p>
urn:sha1:3de2b56efe65fa3999726a80748ffb67ed916ca7PHP5 et passage par référence2006-02-24T14:18:36+01:002006-02-28T19:47:24+01:00
<p>Avec PHP5, il est possible de passer par référence un argument optionnel, ce qui n’était pas possible auparavant
avec php4 :</p>
<pre><code>function myfunc($arg1, &$arg2 = null) {
$foo = 'bar';
}</code></pre>
<p>PHP4, dans une telle situation, retournera une erreur <samp>Parse error: syntax error, unexpected '='…</samp>.
Ce changement ne semble pas documenté dans le manuel <abbr title="PHP: Hypertext Preprocessor" lang="en">PHP</abbr>.</p>
<ins datetime="2006-02-28T19:47:24+01:00" title="Ajouté le mardi 28 février 2006 à 19h47"><p>Je viens de trouver le passage dans le manuel <abbr>PHP</abbr> où ce changement est indiqué :
<a href="http://fr.php.net/manual/fr/functions.arguments.php" hreflang="fr">Chapitre 17. Les fonctions - Les arguments de fonction</a> (la note de l’exemple 17.10).</p></ins>
urn:sha1:35426de7437770445e6105145a2de1ae412f3207PHP et SQLite 32006-01-02T20:09:41+01:002006-01-02T20:09:41+01:00
<p>Pour pouvoir utiliser SQLite version 3 avec <abbr title="PHP: Hypertext Preprocessor" lang="en"
>PHP</abbr>, celui-ci oblige les développeurs à passer par la nouvelle extension <abbr title="PHP Data Objects" lang="en">PDO</abbr>.</p>
<p>Mes paquets deb concernant <abbr>PHP</abbr>5 proviennent de <a href="http://dotdeb.org/"
hreflang="en">dotdeb.org</a>. Malheureusement, les extensions pdo et pdo_* n’y sont pas présentes.
Installation en passant par <abbr title="PHP Extension Community Library" lang="en">PECL</abbr> :</p>
<pre><samp>root@nog:~# apt-get install libsqlite3-0 php5-dev
root@nog:~# pecl install PDO
root@nog:~# pecl install PDO_SQLITE
root@nog:~# echo "extension=pdo.so" >> /etc/php5/apache2/php.ini
root@nog:~# echo "extension=pdo_sqlite.so" >> /etc/php5/apache2/php.ini
root@nog:~# echo "extension=pdo.so" >> /etc/php5/cli/php.ini
root@nog:~# echo "extension=pdo_sqlite.so" >> /etc/php5/cli/php.ini
root@nog:~# /etc/init.d/apache2 restart</samp></pre>
<p>Le paquet php5-dev est nécessaire pour que la compilation des deux librairies puisse être effectuée.</p>
<p><abbr title="Post Scriptum" lang="la">P.S</abbr> : Je cherche aussi l’extension permettant d’interagir avec les bases de données Firebird/InterBase.</p>
urn:sha1:729e7a662c30ee91e7a0e5ffe9af125afe680721Gecko 1.8 : Extras de dernière minute2005-09-29T22:53:39+02:002005-09-29T22:54:40+02:00
<p>Les développeurs de Mozilla ont achevé ces derniers jours les travaux sur deux demandes d’implémentation
<abbr title="Cascading Style Sheets" lang="en">CSS</abbr>. Il semble bien que ces
deux "bugs" soient corrigés également sur la version 1.5 de Firefox.</p>
<ul lang="en">
<li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=302462" hreflang="en">[Bug 302462]
Support <code>:valid</code>, <code>:invalid</code>, <code>:out-of-range</code>, and <code>:in-range</code> pseudoclasses</a></li>
<li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=84400" hreflang="en">[Bug 84400]
Support <code>:disabled</code> and <code>:enabled</code> pseudo-classes</a></li>
</ul>
urn:sha1:bf3220da02831fd704305296c8e2f69818b2bfe1XHTML et schéma XML2005-09-14T19:34:35+02:002005-09-14T19:34:35+02:00
<p>Le format <abbr>XHTML</abbr> 1.0 exprimé avec un schéma <abbr>XML</abbr> au lieu d’une
<abbr title="Document Type Definition" lang="en">DTD</abbr> :
<a href="http://www.w3.org/TR/xhtml1-schema/#schemas" hreflang="en"><abbr>XHTML</abbr> 1.0 in
<abbr>XML</abbr> Schema</a>.</p>
urn:sha1:02e77ba22bb85122215465a9ab09e923a92abecbNouveautés dans JavaScript 1.62005-09-10T22:07:54+02:002005-09-10T22:07:54+02:00
<p>Parmi les nouveautés qu’apporte Firefox 1.5, il en est une que j’ai bètement passé sous silence dans le
billet <a href="http://blog.webnaute.net/2005/09/08/Nouveaut%C3%A9s_dans_firefox_1.5/"><q>Nouveautés dans Firefox 1.5</q></a> :
Le passage de JavaScript en version 1.6, imposé par l’arrivée de certaines nouveautés. Rappelé à l’ordre par
Benoit, me voilà contraint de détailler dans ce billet les nouveautés en question ;¬)</p>
<h3 lang="en">ECMAScript for <abbr title="eXtensible Markup Language">XML</abbr></h3>
<p>De son petit nom, <abbr title="ECMAScript for XML" lang="en">E4X</abbr>.
<abbr>E4X</abbr> est standardisé par l’Ecma sous l’appellation <a href="http://www.ecma-international.org/publications/standards/Ecma-357.htm"
hreflang="en" title="Standard publié en 2004">ECMA-357</a> et ajoute un support natif du <abbr>XML</abbr>
dans l’ECMAScript (la version normalisée du cœur de JavaScript). Grâce à une syntaxe simple et intuitive,
<abbr>E4X</abbr> se veut une alternative crédible aux méthodes <abbr title="Document Object Model" lang="en">DOM</abbr> classiques d’accés à un document <abbr>XML</abbr>. Quelques
exemples :</p>
<pre><code>var xmlObject = new XML("<items>
<item val="attrVal">essai1</item>
<item>essai2</item>
<item>essai3</item>
</items>");
alert(xmlObject.text()); // affiche essai1 essai2 essai3 (avec les sauts de ligne et indentation)
var itemList = xmlObject.item;
alert(itemList); /* affiche
<item val="attrVal">essai1</item>
<item>essai2</item>
<item>essai3</item> */
alert(itemList.length); // affiche 3
alert(itemList[0].@val); // affiche attrVal
// Utiliser E4X en conjonction avec le DOM ? C’est possible !
xmlObject = new XML(document); // ou n’importe quel autre nœud DOM</code></pre>
<p>Ce ne sont que de brefs exemples. Consultez les liens suivants pour en savoir plus :</p>
<ul>
<li><a href="http://www.ecma-international.org/publications/standards/Ecma-357.htm"
hreflang="en" title="Standard publié en 2004">ECMA-357</a> (La spec. officielle, probablement imbuvable pour le commun des mortels)</li>
<li><a href="http://developer.mozilla.org/presentations/xtech2005/e4x/" hreflang="en">Une présentation par
Brendan Eich</a>, architecte en chef chez Mozilla (L’inventeur de JavaScript)</li>
<li><a href="http://developer.mozilla.org/en/docs/Category:E4X" hreflang="en">Zone dédiée à <abbr>E4X</abbr>
sur DevMo</a></li>
<li><a href="http://www.faqts.com/knowledge_base/index.phtml/fid/1762" hreflang="en"><abbr title="Frequently Asked Questions" lang="en">FAQ</abbr> dédiée sur faqts.com</a></li>
</ul>
<h3>Méthodes sur les objets <code>Array</code></h3>
<p>De nouvelles méthodes font leur apparition sur les tableaux JavaScript. Les méthodes <code>indexOf()</code>
et <code>lastIndexOf()</code> sur un tableau permettent désormais de récupérer l’index d’une valeur donnée,
éventuellement en partant d’un index donné. Exemples :</p>
<pre><code>var aColors = ["rouge", "bleu", "vert", "orange", "violet", "vert", "marron"];
alert(aColors.indexOf("vert")); // affiche 2
alert(aColors.lastIndexOf("vert")); // affiche 5
// En spécifiant un index de départ
alert(aColors.indexOf("vert", 3)); // affiche 5
alert(aColors.lastIndexOf("vert", 4)); // affiche 2
alert(aColors.indexOf("blanc")); // affiche -1, cette valeur n’est pas présente dans le tableau</code></pre>
<p>Cinq méthodes sont maintenant utilisables pour appeler une fonction sur chaque entrée d’un tableau.</p>
<dl>
<dt><code>every(callback[, thisObject])</code></dt>
<dd>Applique la fonction <var>callback</var> sur chaque entrée du tableau et renvoie <code>true</code>
si la fonction <var>callback</var> a renvoyé <code>true</code> pour chaque entrée</dd>
<dt><code>filter(callback[, thisObject])</code></dt>
<dd>Applique la fonction <var>callback</var> sur chaque entrée du tableau et renvoie un tableau contenant
les entrées pour lesquelles la fonction <var>callback</var> a renvoyé <code>true</code></dd>
<dt><code>forEach(callback[, thisObject])</code></dt>
<dd>Applique la fonction <var>callback</var> sur chaque entrée du tableau</dd>
<dt><code>map(callback[, thisObject])</code></dt>
<dd>Idem que <code>forEach()</code>, mais la fonction <var>callback</var> est appliquée sur une copie
du tableau, la-dite copie étant ensuite retournée par <code>map()</code></dd>
<dt><code>some(callback[, thisObject])</code></dt>
<dd>Idem que la méthode <code>every()</code> sauf que cette méthode renvoie <code>true</code> si
la fonction <var>callback</var> a renvoyé <code>true</code> pour au moins une des entrées du tableau</dd>
</dl>
<p>Consultez les liens suivants pour plus de détails :</p>
<ul lang="en">
<li><a href="http://developer.mozilla.org/en/docs/New_in_JavaScript_1.6#Array_extras" hreflang="en">
New in JavaScript 1.6 : Array extras</a></li>
<li><a href="http://www.webreference.com/programming/javascript/ncz/column4/index.html" hreflang="en">
Mozilla’s New Array Methods</a></li>
</ul>
<p>Il y a aussi une section <q lang="en">Array and String generics</q> dans la page
<a href="http://developer.mozilla.org/en/docs/New_in_JavaScript_1.6" hreflang="en">
<q lang="en">New in JavaScript 1.6</q></a> mais vide pour l’instant. Je complèterai donc ce
billet ultérieurement.</p>
urn:sha1:c30c36e35ca50842db831afb73bb0a0cf6a62433xml:id passe en recommandation2005-09-09T23:01:28+02:002005-09-19T15:10:40+02:00
<p>Le <abbr title="World Wide Web Consortium" lang="en">W3C</abbr> a validé
aujourd’hui même la spécification sur l’attribut <code>xml:id</code> en tant que recommandation officielle.</p>
<p>Si vous possédez un compte sur le <a href="https://bugzilla.mozilla.org/" hreflang="en">traqueur de bugs de
Mozilla</a>, je vous invite fortement à voter pour la correction du <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=275196"
hreflang="en" title="xml:id support">bug 275196</a> ;¬).</p>
<ul>
<li><a href="http://www.w3.org/News/2005#item124" hreflang="en">L’annonce du <abbr>W3C</abbr></a></li>
<li><a href="http://blog.webnaute.net/2005/07/13/xml%3Aid_passe_en_PR/"><code>xml:id</code> passe en pré-recommandation</a></li>
<li><ins datetime="2005-09-19T15:10:40+02:00" title="Ajouté le lundi 19 septembre 2005 à 15h10"><a href="http://www.yoyodesign.org/doc/w3c/xml-id/" hreflang="fr">Traduction française de la recommandation</a> par J.J Solari</ins></li>
</ul>
urn:sha1:e463c907d5c88f9df7237c4bdd125cdc5cd0af42Nouveautés dans Firefox 1.52005-09-08T04:30:51+02:002005-09-08T04:39:19+02:00
<p>Après une nouvelle mise à jour automatique via le système de mises à jour de <q
lang="en">Deer Park</q>, je constate qu’il a changé de nom pour reprendre l’appellation <q>Mozilla Firefox</q>
(suivi d’un petit <q>Beta 1</q>). La chaîne <abbr title="User Agent" lang="en">UA</abbr>
confirme ce changement. La sortie de la première version bêta de Firefox 1.5 est désormais imminente (c’est une
question d’heures). Profitons-en pour refaire un petit tour des
<a href="http://www.mozilla.org/projects/deerpark/whatsnew.html" hreflang="en">nouveautés qu’apporte
Firefox 1.5</a>.</p>
<h3>Éléments <abbr title="HyperText Markup Language" lang="en">HTML</abbr>, <code>tabindex</code> et attention (focus)</h3>
<p>Les éléments possédant un attribut <code>tabindex</code> avec une valeur négative peuvent maintenant
obtenir l’attention (<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=171366" hreflang="en">Bug
171366</a>). Bon point : Cela permettra une plus grande accessibilité pour les scripts générant des structures
avec le <abbr title="Document Object Model" lang="en">DOM</abbr>. Mauvais point :
<strong>Ce n’est pas</strong> à priori en conformité avec la recommandation <abbr>HTML</abbr>, laquelle
indique que <a href="http://www.la-grange.net/w3c/html4.01/interact/forms.html#adef-tabindex" hreflang="fr">cet attribut peut prendre une valeur entre 0 et 32767</a>. Ceci dit, du strict point de vue de la
<abbr title="Document Type Definition" lang="en">DTD</abbr>, c’est valide.</p>
<p>Par contre, la recommandation dit également : <q>Les éléments suivants reconnaissent l'attribut
<code>tabindex</code> : <code>A</code>, <code>AREA</code>, <code>BUTTON</code>,
<code>INPUT</code>, <code>OBJECT</code>, <code>SELECT</code>, et <code>TEXTAREA</code></q>,
donc évitez quand même les trucs du genre <code><div tabindex="-1"></code> en dur dans vos
documents <abbr>HTML</abbr> ;¬)</p>
<h3>Formulaires et élément <code>OBJECT</code></h3>
<p>Les éléments <code>OBJECT</code> présents dans un formulaire et possédant un attribut <code>name</code>
font maintenant parti des données soumises lors de la validation du formulaire. La partie de la recommandation
sur <a href="http://www.la-grange.net/w3c/html4.01/interact/forms.html#form-controls" hreflang="fr">les
commandes dans les formulaires</a> n’est pas très claire sur ce qu’il est sensé se passer :
<q>la valeur initiale d'un élément <code>OBJECT</code> dans un formulaire est déterminée par l'implémentation
de l'objet (i.e., elle n'est pas précisée par cette spécification)</q>. Avec ça, on est bien avancé tiens…
(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=188938" hreflang="en">Bug 188938</a>).</p>
<h3>Support des citations imbriquées</h3>
<p>Elles sont désormais supportées comme <a href="http://www.w3.org/TR/2005/WD-CSS21-20050613/generate.html#quotes-specify"
hreflang="en">décrites dans la spécification <abbr>CSS</abbr> 2.1</a>.</p>
<p><a href="http://blog.webnaute.net/2005/06/15/Nouvelle_version_CSS2.1/">Ce mécanisme est en sursis</a> en ce qui concerne
la spécification <abbr>CSS</abbr> 2.1 mais est néanmoins bien présent dans le module
<abbr>CSS</abbr> 3 sur le <a href="http://www.w3.org/TR/2003/WD-css3-content-20030514/#inserting2"
hreflang="en">contenu généré</a>.</p>
<h3>Support de la pseudo-classe <code>:only-child</code> (<abbr>CSS</abbr> 3)</h3>
<p>Bètement, ça sélectionne l’élément (ou n’importe quel élément si on ne le précise pas ou qu’on utilise le
sélecteur universel) seulement s’il est l’unique enfant de son parent.</p>
<h3>Surlignements <abbr>CSS</abbr> 3</h3>
<p>Firefox supporte maintenant les propriétés <code>outline</code>, <code>outline-width</code>,
<code>outline-style</code> et <code>outline-color</code> <a href="http://www.w3.org/TR/css3-ui/#outline1"
hreflang="en">décrites dans <abbr>CSS</abbr> 3</a>. Firefox 1.0.x les supportait déjà, mais uniquement
avec le préfixe <code>-moz-</code>, et ce support était boiteux :</p>
<ul>
<li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=151375" hreflang="en" lang="en">
[Bug 151375] Focus outline should be drawn outside of element</a></li>
<li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=133165" hreflang="en" lang="en">
[Bug 133165] Focus outline should include larger descendants of inline elements</a></li>
</ul>
<p>La <a href="http://www.w3.org/TR/css3-ui/#outline-offset" hreflang="en">propriété <code>outline-offset</code></a>
est également supportée (Je l’utilise d’ailleurs sur ce site pour le menu).</p>
<h3>Module <q lang="en">Multi-column layout</q> (expérimental)</h3>
<p>Ce <a href="http://www.w3.org/TR/css3-multicol/" hreflang="en">module</a> est pour l’instant supporté
à titre expérimental. Un bel <a href="http://weblogs.mozillazine.org/roc/archives/2005/03/gecko_18_for_we.html"
hreflang="en">exemple d’utilisation</a> (et en bonus, des précisions sur cette implémentation).</p>
<h3>Curseurs et <abbr>CSS</abbr></h3>
<p>Les nouvelles <a href="http://www.w3.org/TR/css3-ui/#cursor" hreflang="en">valeurs possibles dans
<abbr>CSS</abbr> 3 pour la propriété <code>cursor</code></a> sont désormais supportées
(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=163174" hreflang="en">bug 163174</a>), de même
que la syntaxe permettant de spécifier un icône de curseur avec une <abbr title="Uniform Resource Locator" lang="en">URL</abbr> (<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=286303" hreflang="en">
bug 286303</a>). J’ose espérer que ce sera désactivable à l’aide d’une préférence dans <samp>about:config</samp>. Le document <a href="http://www.mozilla.org/projects/deerpark/new-web-dev-features.html" hreflang="en">
<q lang="en">What’s new</q></a> indique de toute façon que les curseurs animés (en
<abbr title="Scalable Vector Graphics" lang="en">SVG</abbr>, GIF ou autre) ne sont pas supportés.</p>
<h3>Autres nouveautés <abbr>CSS</abbr></h3>
<p>Support des propriétés <code>overflow-x</code> et <code>overflow-y</code> de <abbr>CSS</abbr> 3
(Ces propriétés sont supportées également au moins par <abbr title="Internet Explorer"
lang="en">IE</abbr>). Ajout également de la propriété <code>-moz-outline-radius</code> (non standard et
je n’en ai rien vu dans <abbr>CSS</abbr> 3).</p>
<p>Il y a aussi bien sùr une des nouveautés les plus attendues :
<a href="http://www.w3.org/TR/CSS21/generate.html#counters" hreflang="en">Le mécanisme de génération
de compteurs</a>. Sauf que l’implémentation faite dans Firefox correspond apparamment à une mise à jour
à venir de <abbr>CSS</abbr> 2.1, donc il y a peut-être quelques différences mineures avec l’implémentation
existante dans Opera. Encores des maux de tête en perspective…</p>
<p>N’oublions pas également le nombre élevé de <a href="https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Core&component=Layout&component=Layout%3A+BiDi+Hebrew+%26+Arabic&component=Layout%3A+Block+and+Inline&component=Layout%3A+Canvas&component=Layout%3A+CTL&component=Layout%3A+Floats&component=Layout%3A+Fonts+and+Text&component=Layout%3A+Form+Controls&component=Layout%3A+HTML+Frames&component=Layout%3A+Images&component=Layout%3A+Misc+Code&component=Layout%3A+R+%26+A+Pos&component=Layout%3A+Tables&component=Layout%3A+View+Rendering&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&resolution=FIXED&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2004-08-10&chfieldto=2005-09-08&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0="
hreflang="en">bugs <abbr>CSS</abbr> corrigés</a> (grr… d’<abbr>URL</abbr> à rallonge).</p>
<h3>Et pour JavaScript ? Et le <abbr>DOM</abbr> ?</h3>
<p>À vrai dire, les nouveautés n’ont pas de quoi faire entrer en transe vu qu’il y en a très peu. Pas de
diminution <strong>drastique</strong> de la <strong>ribambelle de bugs</strong> présents dans
l’implémentation du <abbr>DOM</abbr> Events. Pas d’implémentation de l’interface
<code>nodeIterator</code> (supportée par Opera). Pas de nouveauté percutante quoi.</p>
<p>Bon, il y a quand même, de façon globale, un nombre conséquent de
<a href="https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Core&component=DOM&component=DOM+to+Text+Conversion&component=DOM%3A+Abstract+Schemas&component=DOM%3A+Core&component=DOM%3A+CSSOM&component=DOM%3A+Events&component=DOM%3A+HTML&component=DOM%3A+Level+0&component=DOM%3A+Load+and+Save&component=DOM%3A+Mozilla+Extensions&component=DOM%3A+Traversal-Range&component=DOM%3A+Validation&component=DOM%3A+Views+and+Formatting&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&resolution=FIXED&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2004-08-10&chfieldto=2005-09-08&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0="
hreflang="en">bugs corrigés</a>. Pour les quelques nouveautés, je vous renvoie au document dont j’ai
donné l’<abbr>URL</abbr> au début de ce billet.</p>
<h3>Support de <abbr>SVG</abbr></h3>
<p>Je n’ai que très peu de connaissances de ce format, mais c’est assez important donc je le dis :
Firefox 1.5 supporte nativement le <abbr>SVG</abbr> ( de même qu’Opera si je ne m’abuse).
<a href="http://www.mozilla.org/projects/svg/" hreflang="en">Mozilla <abbr>SVG</abbr> Project</a>
(pour les infos et les exemples).</p>
<h3>Support de XForms</h3>
<p><a href="http://www.w3.org/MarkUp/Forms/" hreflang="en">XForms</a> est appelé à devenir la prochaine
génération de formulaires en lieu et place des basiques formulaires du <abbr>HTML</abbr>.
Basé sur <abbr title="eXtensible Markup Language" lang="en">XML</abbr> et disposant bien
évidemment d’un espace de nom, il pourra donc être utilisé dans n’importe quel document <abbr>XML</abbr>
le nécessitant, et notamment <abbr title="eXtensible HyperText Markup Language" lang="en">
XHTML</abbr> 2.0.</p>
<p>Le support de XForms dans Firefox ne sera pour l’instant disponible que via l’ajout d’une extension. Ça plus
le fait que Firefox est, à ma connaissance, le seul navigateur à supporter XForms signifie que cela ne sera utilisable
à court terme, et au mieux, que sur un intranet par exemple (mais c’est déjà pas mal si on fait abstraction de la
complexité de XForms). <a href="http://www.mozilla.org/projects/xforms/" hreflang="en">Mozilla XForms Project</a>.</p>
<h3>En vrac</h3>
<p>Parmi les autres nouveautés ou corrections importantes, citons notamment :</p>
<ul>
<li>Ajout de la propriété <code>@-moz-document</code> dont <a href="http://navigosaure.net/carnet/index.php/2005/08/30/15-feuilles-de-styles-utilisateur-site-par-site"
hreflang="fr">Thomas Bassetto</a> et <a href="http://www.chevrel.org/fr/carnet/index.php?2005/09/06/491-firefox-15-jouons-avec-les-feuilles-de-styles-utilisateur"
hreflang="fr">Pascal Chevrel</a> nous montrent avec brio les possibilités.
<a href="http://lists.w3.org/Archives/Public/www-style/2004Aug/0135.html" hreflang="en">Détails de
l’implémentation</a>.</li>
<li>Support des nouveaux <a href="http://blog.webnaute.net/2005/07/25/Types_de_m%C3%A9dia_de_scripts/">types de média
de scripts</a></li>
</ul>
<p>Voilà, je pense que ce petit tour d’horizon (qui ne concerne que la partie développement web des nouveautés
de Firefox 1.5; voir aussi la catégorie dans laquelle est publié ce billet) est relativement complet.
Pour la liste des bugs notables corrigés et concernant le développement web, je m’attelerai à la tâche ces prochains
jours dans un autre billet.</p>
<ul>
<li><a href="http://mozillazine-fr.org/nouveautes/firefox-et-thunderbird-1-5/" hreflang="fr">
Les nouveautés de Mozilla Firefox 1.5 et Mozilla Thunderbird 1.5</a></li>
<li><a href="http://www.chevrel.org/fr/carnet/index.php?2005/05/01/446-ce-qu-apportera-firefox-11-en-juin"
hreflang="fr">Ce qu'apportera Firefox 1.5 en Novembre (?)</a></li>
<li><a href="http://blogzinet.free.fr/index.php?2005/05/24/656-les-nouveautes-de-firefox-11"
hreflang="fr">Les nouveautés de Firefox <del datetime="2005-09-08T04:39:19+02:00" title="Supprimé le jeudi 8 septembre 2005 à 04h39">1.1</del> <ins datetime="2005-09-08T04:39:19+02:00" title="Ajouté le jeudi 8 septembre 2005 à 04h39">1.5</ins></a></li>
</ul>
urn:sha1:3798617c204029821ed42c9c40ceabb3b6a98704Bugs en série - suite2005-08-27T23:52:53+02:002005-08-28T02:19:13+02:00
<p>Continuant mon voyage fantastique au pays des bugs, je m’en vais maintenant vous relater
comment je me suis trouvé aux prises avec deux bugs <abbr title="Cascading Style Sheets"
lang="en">CSS</abbr> teigneux, l’un affectant Safari, l’autre, beaucoup plus vicieux, continue de
me résister et affecte selon les cas au moins Opera et Firefox.</p>
<h3>Safari et styles de sélection de texte</h3>
<p>J’applique les styles suivants sur tous les éléments de la page et, notamment, sur des paragraphes
dont le contenu est justifié (<code>text-align: justify;</code>) :</p>
<pre><code>*::selection { background-color: une_couleur; color: autre_couleur; }
*::-moz-selection { background-color: une_couleur; color: autre_couleur; }</code></pre>
<p>Résultat sur Safari 2.0 (cliquez sur les images pour les voir grandeur réelle) :<br>
<a href="http://blog.webnaute.net/2005/08/27/Bugs_en_s%C3%A9rie-suite/images/Safari_et_s%C3%A9lection" type="image/*">
<img src="http://blog.webnaute.net/2005/08/27/Bugs_en_s%C3%A9rie-suite/images/Safari_et_s%C3%A9lection-thumb"
alt="Lorsque l’utilisateur sélectionne du texte, celui-ci part en sucette" width="500" height="51"></a><br>
<a href="http://blog.webnaute.net/2005/08/27/Bugs_en_s%C3%A9rie-suite/images/Safari_et_s%C3%A9lection-2" type="image/*">
<img src="http://blog.webnaute.net/2005/08/27/Bugs_en_s%C3%A9rie-suite/images/Safari_et_s%C3%A9lection-2-thumb"
alt="Lorsque l’utilisateur sélectionne du texte, celui-ci part en sucette" width="500" height="48"></a></p>
<p>Safari a manifestement quelques problèmes pour gérer <strong>et</strong> la justification de texte
<strong>et</strong> les styles <abbr>CSS</abbr> sur la sélection de celui-ci.</p>
<p>J’ai d’abord fait quelques recherches sur l’existence éventuelle d’un pseudo-élément
<code>::-khtml-selection</code>, ce qui m’aurait permis d’annuler ces styles de sélection
uniquement pour les navigateurs basés sur <span title="Le moteur de rendu du projet KDE">KHTML</span>
(pour peu que les mots-clés <abbr>CSS</abbr> nécessaires fussent gérés aussi par KHTML) :</p>
<pre><code>*::selection { background-color: une_couleur; color: autre_couleur; }
*::-moz-selection { background-color: une_couleur; color: autre_couleur; }
*::-khtml-selection { background-color: Highlight; color: HighlightText; }</code></pre>
<p>Mais ce pseudo-élément n’existe apparamment pas. Étant donné que je me posais déjà la question de
savoir si la justification de texte était adaptée pour un rendu à l’écran, ce bug n’a fait que me
pousser à prendre la décision de retourner au plus raisonnable <code>text-align: left;</code>.</p>
<h3>Feuilles de styles et encodage</h3>
<p>Tout est parti d’un bug de Safari lié à la génération de contenu. Voici la règle <abbr>CSS</abbr> en cause
(vous pouvez en voir le résultat dans Firefox, Opera et Safari dans le billet précédent) :</p>
<pre><code>table td[scope="row"]::after { content: "\00A0»"; }</code></pre>
<p>Safari affiche donc <samp>»</samp> au lieu d’afficher <samp> »</samp> (le guillemet fermant est
précédé d’une espace insécable). J’ai d’abord simplement pensé sans réfléchir que Safari ignore
simplement le paramètre <code>charset</code> de l’en-tête <abbr title="HyperText Transfer Protocol" lang="en">HTTP</abbr> <code>Content-Type</code> et utilise le jeu de caractère ISO-8859-1
pour les feuilles de styles. En fait, ça semble être un plus tordu.</p>
<p>Mon hypothèse est la suivante : Safari ignore effectivement le paramètre <code>charset</code>
de l’en-tête <abbr>HTTP</abbr> (premier bug) et utilise donc le jeu de caractère ISO-8859-1, mais fait
une autre boulette en résolvant les appels de caractères (ici, <code>\00A0</code>) <strong>avant</strong>
de convertir la feuille de style dans le même encodage (ici, l’UTF-8) que celui de la page liant
la feuille de style. Résultat, l’espace insécable se retrouve encodée deux fois de suite en UTF-8.
Le test suivant semble confirmer mon hypothèse puisque j’obtiens alors ce qu’affiche Safari (sauf l’espace,
apparamment supprimé par Safari) :</p>
<pre><code><?php
header('Content-Type: text/plain; charset=UTF-8');
echo utf8_encode("\xC2\xA0");// \xC2\xA0 est l’espace insécable encodée en UTF-8 Le résultat affiché est  suivi d’une espace
?></code></pre>
<ins datetime="2005-08-28T00:38:18+02:00" title="Ajouté le dimanche 28 août 2005 à 00h38">
<p>Bon, mon raisonnement est débile.
Si Safari utilisait ISO-8859-1 pour la feuille de style, le guillemet fermant s’afficherait aussi de façon foireuse. Donc forcément,
Safari utilise bien l’UTF-8 pour la feuille de style</p>
<p>Les appels de caractères (<code>\00A0</code> en tout cas) sont donc résolus et le caractère résultant encodé dans le charset
de la feuille de style. Ça semble être plus logique comme explication.</p></ins>
<h3>L’enfer des règles-at</h3>
<p>Pensant d’abord pouvoir régler son compte au bug d’encodage avec la règle-at <code>@charset</code>
(c’était avant d’en arriver à l’hypothèse du paragraphe précédent), et malgré le bug
d’<a href="http://blog.webnaute.net/2005/08/20/Note_%3A_Opera_et_la_r%C3%A8gle-at_%40charset/">Opera et de la règle-at
<code>@charset</code></a> que j’allais devoir lui aussi tenter de contourner, je décide d’ajouter des
<code>@charset "UTF-8";</code> (Rappel pour ceux qui n’ont pas vu ; Opera Mac ne semble pas affecter
par le bug de la règle <code>@charset</code>, seules les versions Windows et Linux le sont). Par exemple,
là :</p>
<pre><code>
@charset "UTF-8";
@import url("/une_feuille");
@import url("/une_autre");
html { font-size: .9em; }</code></pre>
<p>Cela ne fait ni chaud ni froid à Safari (le bug du contenu généré demeure). Comme prévu, Opera perd la
boule et ignore toutes les règles-at qui suivent immédiatement (ici, les deux <code>@import</code>) ainsi
que la règle <abbr>CSS</abbr> suivante (ici, <code>html { font-size: .9em; }</code>).
Quant à Firefox, les tests que j’avais fait à une certaine époque m’avaient fait constater qu’il ne gérait
pas lui non plus la règle <code>@charset</code>, cependant, il a le bon goût de tenir compte de ce que je
lui dis dans les en-têtes <abbr>HTTP</abbr>, il n’était donc pas concerné par ces tests. Et pourtant,
j’ai la surprise de constater qu’il zappe lui aussi purement et simplement les deux règles
<code>@import</code>. Gasp…</p>
<p>Après pas mal d’essais infructueux, un éclair de lucidité me pousse à retourner lire la recommandation
<abbr>CSS</abbr>, dont la traduction n’était d’ailleurs pas accessible à ce moment-là. Heureusement, j’en
ai une copie complète sur mon disque dur ;¬). Bref, je suis tombé là-dessus :</p>
<blockquote cite="http://www.yoyodesign.org/doc/w3c/css2/syndata.html#x66">
<p>Il ne peut y avoir qu'une règle @charset dans une feuille de style externe et elle doit survenir au
tout début de celle-ci, aucun caractère ne devant précéder. <em>Cette règle ne doit pas apparaître dans une
feuille de style incorporée</em>.</p>
</blockquote>
<p>Ah, forcément, fallait le savoir. Je comprends mal les raisons de cette limitation. Cela veut dire
que toutes les feuilles de styles importées ont l’obligation d’être dans le même jeu de caractère que la
feuille de styles principale. Et puis il y a un autre problème du coup :</p>
<blockquote cite="http://www.yoyodesign.org/doc/w3c/css2/cascade.html#x5">
<p>La règle <code>@import</code> permet aux utilisateurs l’importation de règles de style à partir d’une
autre feuille de style. Les règles <code>@import</code> doivent précéder toutes autres règles dans la
feuille de style.</p>
</blockquote>
<p>Ah ouais… Comment que je fais moi ? Bon, heureusement, <abbr>CSS</abbr> 2.1 vient éclaircir
les choses comme toujours :</p>
<blockquote cite="http://www.w3.org/TR/CSS21/syndata.html#x10" lang="en">
<p><abbr>CSS</abbr> 2.1 user agents must ignore any <code>@import</code> rule that occurs inside a
block or after any valid rule other than an @charset or an <code>@import</code> rule.</p>
</blockquote>
<p>Bon, je passe sur les essais avec <a href="http://www.w3.org/TR/css3-namespace/" hreflang="en"><code>@namespace</code></a>
pour contourner le bug d’Opera (que de toute façon, c’est pas valide puisque <code>@charset</code> doit être en premier)
et les heures à tester/modifier/retester sinon, ce billet risque d’être déraisonnablement long. Encore une fois,
merci à J.J Solari pour ses tests du design sur les navigateurs Mac et les impressions d’écran fournies. Il va finir par
devenir mon testeur mac attitré si ça continue ;¬)</p>
<ins datetime="2005-08-28T02:19:13+02:00" title="Ajouté le dimanche 28 août 2005 à 02h19"><p>Tiens, un bug de plus :</p>
<pre><code>label { float: left; width: 15em; }/* La présence du width n’est pas significative */
label { float: none; }</code></pre>
<p>La mise en flottant passe automatiquement la boîte en type bloc (comme si on mettait explicitement <code>display: block;</code>
(jusque là, tout est normal). Avec la règle suivante, on enlève le caractère flottant de la boîte. La boîte reste de type bloc sur
Firefox 1.0 (Deerpark n’est pas affecté par ce bug).</p></ins>