yep

Une possibilité pas sensationnel est de placer tes "id" plus haut dans le contenu afin que la hauteur entre l'id et le véritable contenu soit identique à celle du menu. Une autre piste est d'exploiter JavaScript pour décaler le contenu de la hauteur du menu, une fois l'ancre (le lien) activé.

Bonjour, Ah non pas vraiment : http://gs.statcounter.com/#browser_version-FR-monthly-201009-201109 Avec ce graph, on voit que la suite Firefox augmente sa part de marché, tout en ayant un logiciel à jour : FF6 a remplacé FF5 qui a lui même remplacé FF4. Attendons de voir ce que donnera la version 7 de Firefox. Plus globalement, http://gs.statcounter.com/#browser-FR-monthly-201009-201109 donne IE à 40% d'utilisateurs, chiffre expliqué par la domination de ce navigateur depuis 10 ans, mais largement en baisse et talonné par Firefox (sans prise en compte de la version 7). Si les navigateurs évoluent c'est pour pallier des bugs, supprimer des failles de sécurité, augmenter la rapidité d’exécution, supporter les nouvelles technologies, etc. : pour ma part, je n'utilise plus les machines à écrire, les calèches ou encore le minitel. Chaque nouvelle version est donc théoriquement mieux que la précédente. A vrai dire, ce n'est pas IE9 qui pose des problèmes, ceux sont plutôt les sites web qui sont mal construits. Il y a des standards, les respecter c'est vous assurez une principale pérennité d'affichage : les navigateurs tentent de respecter par défaut les standards mais comme personne ne les respectent, ils font leur sauce pour restituer les pages web... et IE est vraiment à la traîne. Utiliser ce navigateur dans le cadre d'une production de sites web n'est pas professionnel : la quasi-totalité des développeurs réalisent des pages HTML sur n'importe quel navigateur excepté IE, puis patch leur développement pour l'adapter sur les anciennes versions d'IE (5.5, 6, 7). Par exemple : http://browsershots.org/, après vous pouvez tester votre site sur 15 applications différentes : http://www.graphicrating.com/2009/08/11/15-tools-for-testing-your-website/ (rendu graphique, performance, accessibilité, etc.). Mais ce type d'outils (uniquement pour tester le rendu graphique) ne restitue pas véritablement le rendu des navigateurs, d'autant qu'ils ont tous des milliers de versions intermédiaires. Rien ne vaut une installation pour chaque navigateur, chaque version, chaque OS, soit déjà au bas mot près d'un millier d'installation... fastidieux : voilà pourquoi développer selon les standards permet de se décoréler des rendus (même si on peut vouloir quand même déboguer pour IE6/7 alors qu'ils représentent moins de 5% des utilisateurs en France).

Je pencherais pour une SAS, vous fixez vos statuts comme bon vous semble, mais son coût au départ est un poil plus élevé qu'une SARL.

Pourquoi ? si elles sont correctement écrites (caractères ASCII encodées en UTF-8) il n'y a pas de souci, non ?

<a> <xsl:attribute name="href"> $url_prefix <xsl:value-of select="big_img_url" /> </xsl:attribute> </a> Il existe aussi une autre syntaxe en utilisant les variables. <xsl:variable name="hrefxml"> $url_prefix <xsl:value-of select="big_img_url" /> </xsl:variable> <xsl:template match="produit"> <a href="$hrefxml">texte du lien</a> </xsl:template>

Je ne suis pas d'accord, tout dépend de tes besoins. Un excellent article : http://www.pompage.net/pompe/doctype/

Pour avoir passé cette certification, les connaissances des standards HTML est un plus, en particulier pour ce qui est d'apporter des solutions techniques. Je t'invite à consulter en long, en large et en travers cette ressource : http://www.braillenet.org/accessibilite/referentiel-aw2/

Un répartiteur de charges peut être envisagé avec plusieurs serveurs d'envoi.

Tu as également l'outil online d'Adobe : http://www.adobe.com/products/acrobat/access_onlinetools.html Mais le mieux reste de ne pas les convertir pour des raisons d'accessibilité.

Effectivement, parce que le premier cas est une ligne d'entête (<thead> et <th>) et non du contenu placé dans le <tbody>.

Ahem ? Et le lien "plus d'information" en HTML, je l'ai proposé pour quelle raison ? Je parle bien de fournir cette information à un second niveau de lecture : - par défaut, en HTML, sur une autre page - si JS, l'information serait rapatriée dans la page. L'information est accessible avec ou sans JS, c'est seulement l'expérience utilisateur qui est légèrement modifiée malgré un accès à cette information dans un second niveau de lecture.

C'est pas faux toutefois je ne parle pas du fait que Flash (ou SWF) soit open-source mais du fait que cette technologie ne soit pas standardisée (et donc pérenne). _AT_captain_torche : valide ? apparemment tu n'as pas compris ce que j'écrivais. Je ne parle pas de comment on intègre Flash dans une page HTML : pour cela, il y a un standard et avec un SWFobject, il est très facile d'embarquer une ressource SWF en ayant un document HTML correctement formaté. Je parle du fait que d'une part la ressource est principalement publiée via une technologie qui est standardisée, ouverte et donc pérenne, alors que d'autre part Flash est également utilisé : le choix des technologies dans la publication des contenus n'est pas cohérent, ainsi pourquoi vouloir absolument valider un format (HTML) et pas l'autre (ce qui ne sera jamais possible) ? Globalement, il me semble que la question posée n'est faite que pour un objectif : valider son code HTML. Mais je souhaitais rebondir en lui faisant prendre conscience que valider une page pour la valider ne sert à rien. C'est simplement l'assurance de correctement formater son information et donc d'en faciliter sa ré-exploitation. Et cela même si pour HTML des traitements complémentaires (quirk modes) peuvent être effectués, ce qui ne serait pas le cas par exemple pour un .doc corrompu.

Pourquoi souhaiter valider le code source HTML selon le standard émis par le W3C alors que vous exploitez une technologie (Flash) qui ne l'est pas ? SVG et SMIL, la mort de flash? Mort au Flash Démonstration de Firefox à Paris Web 2009 (en), l'auteur de cette démo en propose d'autres.

Cet élément n'a pas au départ été conçu que pour lier des feuilles de style mais pour réaliser le système de navigation du site : />http://www.w3.org/TR/html401/struct/links.html#h-12.3 Toutefois, pour faciliter la navigation, l'utilisation de la balise <a> s'est développée à la place des <link> qui peuvent être utilisées dans plusieurs cas : />http://www.w3.org/TR/html401/types.html#type-links A l'heure actuelle, seul Opéra retranscrit cette information via une toolbar dédiée. Un lien (<link>) entre les documents liés est plus d'ordre structurel qu'une simple ancre (<a>). Enfin, ce n'est pas parce qu'on ne voit pas cette information qu'elle n'est pas utile (sinon à quoi servirait les métadonnées).

Proposition : Tu proposes un second niveau d'informations. Traite la comme telle. Déploiement : Par défaut (sans JavaScript), construit ton tableau HTML sans cette information. Il faudra toutefois ajouter une colonne supplémentaire permettant d'y accéder par le biais d'un simple lien du type "Plus d'informations" (même si l'intitulé n'est pas très accessible). <table> <thead> <tr> <th></th> <th>Texte 1</th> <th>Texte 2</th> <th>Texte 3</th> <th>Texte 4</th> <th>Texte 5</th> <th>Plus d'informations</th> </tr> </thead> <tbody> <tr> <td></td> <td>Result 1</td> <td>Result 2</td> <td>Result 3</td> <td>Result 4</td> <td>Result 5</td> <td><a href="#">Plus d'informations</a></td> </tr> </tbody> </table> Vient ensuite améliorer l'expérience utilisateur en optimisant l'interface via JavaScript (avec ou sans JQuery à toi de voir) avec un appel externe (AJAX) du contenu "Plus d'informations" disponible sur des pages HTML externes et ainsi afficher ta <div>.