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,

effectivement IE9 risque de connaître le succès de ses prédécesseurs

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).

je préfère, pour l'instant garder IE7

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.

Ayant Internet Explorer 7 je ne vois pas, pour l'instant, l'intérêt de télécharger la version 9 qui semble poser quelques problèmes à ses utilisateurs.

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).

Je crois qu'il y a un site qui permet de visualiser le résultat de l'affichage de son site sur différents navigateurs, mais je ne me souviens plus de son url et je ne l'ai pas retrouvé sur Google

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.

Il ne faut jamais mettre d'espace dans les urls

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é.

Ca n'était pas flagrant dans ton exemple : dans un des cas, tu ne mettais pas de lien, et dans l'autre, tu en mettais un avec une ancre '#'

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

Comme il n'y a apparemment pas de moyen d'accéder à l'information "secondaire", il faut absolument que cette information soit présente dans le code source.

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.

STOP !

Le lecteur Flash est propriétaire (mais il existe des alternatives non propriétaires)

Le format .fla est propriétaire.

Le format .swf est ouvert !

Une petite piqûre de rappel ne fait jamais de mal

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).

mais c'est parfaitement valide !

_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>.

Ah la bonne vieille source : http://openweb.eu.org/articles/jeux_caracteres

Pour ta problématique multi-lingue, je t'invite à consulter http://www.paris-web.fr/2007/Presentations...multi-linguisme

Paiement à la requête ou licence globale ?

Tu devrais plutôt faire ta demande sur des forums US/UK.

Par ailleurs, l'implémentation de la méta-donnée n'est pas la plus conseillée.

En effet, c'est un équivalent HTTP (http-equiv), donc cette information est plutôt à déployer dans l'entête HTTP.

Ensuite, la meilleure pratique reste de définir la langue d'un document par l'attribut lang sur la balise <html>.

Source : http://www.w3.org/TR/i18n-html-tech-lang/ (Best Practice 6)

Je dirais développer le contenu.

Mais plus globalement, concentre toi sur les utilisateurs plutôt que sur ton trafic.

Le graal n'est pas d'avoir le plus de trafic mais d'avoir un trafic qualifié (qui convertit).

Niet pour moi.

Ce qui est étonnant, c'est de voir que les inscriptions automatiques sur les annuaires sont en train de se déporter sur les sites gratuits de diffusion de communiqués de presse.

Même démarche donc et certainement même conséquences à terme : les utilisateurs exploiteront moins ces sites.

il faut penser à créer une version "sans flash" et "sans javascript" (une version dégradée)

Je parlerais plutôt d'améliorer l'expérience utilisateur en exploitant au mieux les surcouches technologiques que sont le CSS, le JavaScript et le Flash ce qui nécessite jusqu'à la conception de storyboards dédiés par technologie/rendu/expérience.

Quelques exemples : rolex.com, nurun.com, nakheel.com.

... alors qu'il est si simple de RTFM (sitemaps.org).

Et plus globalement, ne pense pas à Google, consacre-toi plutôt à tes utilisateurs !

Certains sites sont connus pour ça : rolex.com est un des plus aboutis.