< Image sur un site internet | Page 2 | Forum des BTS

Image sur un site internet

On ne met pas d'image dans du CSS. Par exemple, les premières lignes de code CSS de cette page:
/* Normal, standard links. */
a:link
{
color: #000000;
text-decoration: none;
}
a:visited
{
color: #000000;
text-decoration: none;
}
a:active
{
color: #000000;
text-decoration: none;
}
 
patrice084 link=topic=7608.msg114079#msg114079 date=1137863843 a dit:
Faux. Une fois que l'image a été chargée elle est dans le cache du navigateur et même si elle apparait sur plusieurs pages différentes elle ne sera pas rechargée de nouveau. Quelquesoit le cas, le temps de chargement sera toujours le même.

Le préload est encore plus fastidieux car il sous entend que l'on va charger des images que le visiteur ne verra peut-être pas (cas de rollover sur image).
Cliquez pour agrandir...

On est bien d'accord donc si en definitive, on prend l'hypothese d'un site ou chaque page a ses propres images, si tes images sont dans le code, tu devras, a chaque nouvelles pages, attendre que les images se chargent. Par contre si tu reviens sur une page deja vue tu n'auras pas a attendre car elles seront dans le cache.

Si tu mets tes images dans le css, tu precharges toutes les images des le depart, donc tu auras un temps d'attente sur la premiere page mais pour toutes les autres les images seront deja dans le cache ( y compris celles que le visiteur n'ira pas voir ).

Donc c vrai que pour la premiere page vue il est important de choisir un style d'apparition de l'image car tu ne pourras pas faire autrement qu'avoir un temps d'attente. Par contre ce probleme ne se posera que sur la premiere page vue.
 
thonon74 link=topic=7608.msg114095#msg114095 date=1137864412 a dit:
tu precharges toutes les images des le depart, donc tu auras un temps d'attente sur la premiere page mais pour toutes les autres les images seront deja dans le cache ( y compris celles que le visiteur n'ira pas voir ).
Cliquez pour agrandir...

Cela est valable que pour des petites images comme par exemple pour un menu ou autre mais pas pour des images plus grandes. Un visiteur en RTC, il en reste, quittera rapidement la page s'il voit que le chargement met 3 plombes à s'afficher;

Maintenant chacun voit midi à sa porte :smile:
 
patrice084 link=topic=7608.msg114098#msg114098 date=1137864581 a dit:
Un visiteur en RTC, il en reste, quittera rapidement la page s'il voit que le chargement met 3 plombes à s'afficher;
Cliquez pour agrandir...

Je suis entierement d'accord :wink2:
Mais l'un dans l'autre le temps qu'il va perdre au debut il le rattrapera sur le temps de passage a une page suivante puisque tout sera prechargé. Enfin bref, les deux methodes sont valables :laugh:
 
thonon74 link=topic=7608.msg114101#msg114101 date=1137864770 a dit:
Il est au contraire recommandé de mettre les images dans le css, en tout cas toute celle qui n'apportent rien au contenu. Pour les images cliquables on est obligé de les laisser dans le code. C'est tres bien expliqué ici:
http://www.openweb.eu.org/articles/images_css/
Cliquez pour agrandir...
On ne peut mettre que des appels d'image en CSS. Cela ne changera rien qu'elles soient appelées par la page ou le CSS. Si, je dis une bétise. dans la page on peut lui attribuer des balises utiles pour les moteurs (alt), pas dans les css me semble il.

.quoteheader
{
background: #E4EAF2 url(images/quote.gif) no-repeat right;
border: 1px dotted #000;
border-bottom: 0;
border-left: 4px solid #8394B2;
color: #000;
font-weight: bold;
font-size: 10px;
margin: 8px auto 0 auto;
padding: 4px;
 
webmaster link=topic=7608.msg114107#msg114107 date=1137865315 a dit:
dans la page on peut lui attribuer des balises utiles pour les moteurs (alt), pas dans les css me semble il.
Cliquez pour agrandir...

C'est clair, les images insérées par CSS sont complètement absentes du contenu, et donc inaccessibles pour les navigateurs non-graphiques. Elles ne peuvent pas être dotées d'attribut alt et ne peuvent donc pas avoir d'équivalent texte. Les images CSS ne doivent donc pas remplacer des images significatives, propres au contenu.
 
Vous savez thonon74, il y a deux types de webmasters, ou du moins on passe tous par deux étapes. Dans un premier temps, on pense que le plus important c'est la technique. Le web passe alors des nuits à Peaufiner son code, mais les visiteurs ne le voient même pas. Plus tard, on se rend compte que le plus important est d'aider vos visiteurs et peut être de passer bien moins de temps sur la technique. Le code passe alors au second plan; On devient pragmatique, on s'en fout de savoir si tout est optimisé, tant que le site génère du trafic.

Je ne parle pas du référencement. Ce qui est dit dans les sites ne suffit pas pour obtenir les premières places. Il faut tricher et ne pas hésiter même.
 
webmaster link=topic=7608.msg114145#msg114145 date=1137867075 a dit:
Ce qui est dit dans les sites ne suffit pas pour obtenir les premières places. Il faut tricher et ne pas hésiter même.
Cliquez pour agrandir...

Est ce bien raisonnable? :wink2:
 
webmaster link=topic=7608.msg114145#msg114145 date=1137867075 a dit:
Vous savez thonon74, il y a deux types de webmasters, ou du moins on passe tous par deux étapes. Dans un premier temps, on pense que le plus important c'est la technique. Le web passe alors des nuits à Peaufiner son code, mais les visiteurs ne le voient même pas.
Cliquez pour agrandir...
C'est tout a l'honneur du webmaster, car le commun des mortels n'y prette pas attention, c'est clair que seuls les gens avertit remarquerons le travail fournit sur la technique.
webmaster link=topic=7608.msg114145#msg114145 date=1137867075 a dit:
Plus tard, on se rend compte que le plus important est d'aider vos visiteurs et peut être de passer bien moins de temps sur la technique. Le code passe alors au second plan; On devient pragmatique, on s'en fout de savoir si tout est optimisé, tant que le site génère du trafic.
Cliquez pour agrandir...

Je suis ok avec vous, le plus important est d'aider les visiteurs cela dit si on peut allier aide et technique pourquoi pas... non? :happy:
 
Non, la technique doit faciliter la vie du web, pas la compliquer. A mort les informaticiens. Ils ne font que compliquer la vie, c'est de cette manière là qu'ils se rendent indispensables. Avec un simple blog, on peut créer un super site. Cf le site de Salwa.
 
thonon74 link=topic=7608.msg113906#msg113906 date=1137846148 a dit:
Si tes images s'affichent soit par bande soit par flou qui s'ameliore c'est qu'elles sont lourdes a charger. En mettant tes images dans le css elles s'affichent en instantané ( si t'es en adsl pour le bas débit j ai pas testé )
Cliquez pour agrandir...
Heu, tu te rend compte que l'énormité de la connerie que tu dis la ?
La CSS c'est une feuille de style qui indique comment les images sont chargées. En aucun cas tu mets tes images dans la CSS.
 
webmaster link=topic=7608.msg114166#msg114166 date=1137868107 a dit:
Non, la technique doit faciliter la vie du web, pas la compliquer.
Cliquez pour agrandir...

Voila pour moi a quoi sert la technique

Extrait de : http://openweb.eu.org/articles/intro_accessibilite/
L'un des grands défis pour l'évolution du Web est de le rendre accessible aux personnes qui ont des besoins spécifiques en terme d'interface. On pense bien sûr aux personnes handicapées. Par handicap, on n'entend pas uniquement les handicaps visuels (non-voyant ou malvoyant), mais aussi les autres (handicap moteur et mental).


L'action du W3C

Face à ces différents handicaps, et depuis le début, le W3C a intégré dans ses travaux le concept d'accessibilité. La partie la plus visible de ces travaux est l'initiative pour l'accessibilité , qui a produit une spécification sur le contenu Web, la WCAG. Tim Berners-Lee, inventeur du Web et fondateur du W3C, déclare lui-même dans son livre Weaving the Web :

A travers tout notre travail sur les langages Hypertexte, graphiques et multimédia, on retrouve notre préoccupation d'un accès pour tous à l'information indépendemment de la culture, du langage et du handicap. La WAI conçoit des protocoles et des logiciels qui rendent le Web accessible aux personnes atteintes de handicaps auditifs, physiques, cognitifs ou neurologiques. (…) L'essentiel de cet effort là n'est effectif que si les concepteurs Web prennent en compte l'accessibilité dans le cadre de leur travail. Les communautés techniques et handicapées ont travaillé ensemble pour produire un ensemble de recommandations sur les étapes à suivre les plus efficaces et les plus pratiques. Il s'agit là d'une lecture recommandée aux webmestres.
Prise en compte de l'accessibilité dans les spécifications

L'accessibilité est en effet au c½ur de toutes les spécifications du W3C. Prenons par exemple les images, inutilisables par qui a recours à un lecteur vocal. En HTML 4 et XHTML 1.x, chaque balise img doit être accompagnée de son attribut alt=&quot;description de l'image&quot;, faute de quoi le code n'est pas valide, et donc signalé comme incorrect par le Validator. Par ailleurs, des notions spécifiques à l'accessibilité sont présentes dans les spécifications. On trouve par exemple tabindex ou accesskey, qui permettent au développeur de contrôler la navigation au clavier, ainsi que des attributs tels que longdesc, permettant l'insertion d'une description longue des éléments de type image ou appliquette.

Plus généralement, les technologies HTML et XHTML strictes (donc sans balisage de présentation), associées aux feuilles de styles CSS, permet la séparation de la structure de la présentation.
L'illusion du contrôle de l'affichage

Un des défis lié à l'accessibilité, et même au design Web en général, est l'immense disparité des terminaux utilisés pour exploiter l'information. Même en considérant qu'un site Web est prévu uniquement pour s'afficher sur un navigateur graphique tournant sur un ordinateur personnel (mais qui peut prétendre connaître toutes les configurations de ses utilisateurs ?), la diversité des équipements est ingérable pour qui souhaite un affichage identique sur les différentes plateformes. Voyons pourquoi :

* un écran informatique peut à l'heure actuelle disposer de 640 à 1920 pixels de large (soit un facteur 3) ;
* la résolution d'écran varie entre 72 ppp et 133 ppp (cas du PC portable de l'auteur de cet article, affichant 1600 pixels sur 12 pouces de large) ;
* les différents systèmes d'exploitation ne disposent pas d'un ensemble commun de polices de caractères installées par défaut ;
* tous les navigateurs n'ont pas la même taille de caractère par défaut, ni la même façon d'interpréter les spécifications du W3C ;
* les navigateurs ne supportent pas tous les même versions des spécifications du W3C. Par exemple, MSIE/Win offre une compatibilité médiocre avec la transparence des images PNG et ignore le comportement de l'élément q. Le navigateur Opera, quant à lui, n'a vu un support correct du DOM que depuis sa récente version 7 ;
* certains utilisateurs peuvent changer les préférences d'affichage et même disposer de feuilles de styles utilisateur, permettant de forcer la façon d'afficher des sites (fond toujours noir, caractères toujours blancs et gras) ;
* certains utilisateurs désactivent JavaScript pour des raisons de sécurité (11% des internautes).

Pour toutes ces raisons, l'approche consistant à chercher un affichage identique sur tous les navigateurs est une bataille perdue d'avance. La perspective de contrôler le rendu d'un document Web s'éloigne plus encore quand on prend en compte l'accessibilité et les aides techniques associées. Quelques exemples simples : comment rendre les attributs gras et italique dans un synthétiseur vocal ? Comment afficher un texte déroulant écrit en Javascript avec une plage Braille ou dans un Tréo ? Comment rendre des tableaux et des pixels transparents dans un navigateur texte ?
Séparation de la structure du document de sa présentation

La démarche proposée par le W3C est en fait très simple, et consiste à séparer la structure du document de sa présentation. Cette solution est mise en oeuvre dans HTML 4 et XHTML, qui permettent de structurer le document indépendamment du périphérique de sortie, alors que les feuilles de styles CSS permettent sa mise en page. Cette dernière technologie supporte les écrans des navigateurs, mais aussi les synthétiseurs vocaux, l'impression, les imprimantes Braille, les écrans de télévision, etc. (se reporter à la liste complète) et permet de paramétrer la restitution du document en fonction du médium. Le document HTML strict (par opposition à transitionnel) n'utilise plus de balises pour sa présentation. La notion de gras, d'italique, de couleur de caractères ont disparu au profit de notions sémantiques. Plutôt que de mettre tel partie du texte en gras, taille 24 pixels, rouge sur fond bleu, ce qui va faire que l'utilisateur va le considérer comme un titre, on utilisera la balise &lt;h1&gt;titre de premier niveau&lt;/h1&gt;. Dans un document séparé, la feuille de style, on utilisera la syntaxe CSS pour décrire la mise en forme des titres de type h1. L'intérêt de ce système est multiple. En particulier, il facilite grandement l'homogénéité des documents, dans la mesure où la feuille de style peut s'appliquer à un grand nombre de documents Web. (Pour plus de détails, se reporter à notre article pourquoi les standards). Mais au-delà de la simplicité de maintenance, séparer la structure de la présentation permet à chaque outil de navigation d'afficher le document en fonction des capacités de l'utilisateur et du périphérique de sortie.
Importance de l'accessibilité Web

A propos des travaux du W3C sur l'accessibilité du contenu Web, Tim Berners-Lee, toujours dans son ouvrage Weaving the Web, déclarait : L'essentiel de cet effort là n'est effectif que si les concepteurs Web prennent en compte l'accessibilité dans le cadre de leur travail. Les communautés techniques et handicapées ont travaillé ensemble pour produire un ensemble de recommandations sur les étapes à suivre les plus efficaces et les plus pratiques. Il s'agit là d'une lecture recommandée aux webmestres.

Les développeurs Web ont aujourd'hui une opportunité de rendre progressivement le Web accessible à plus de gens en utilisant des standards tels que CSS et (X)HTML. Parce que 2003 est l'Année Européenne du Handicap, parce que l'utilisation des standards du W3C permet de faire un grand pas dans le sens de l'accessibilité, il est du devoir de chaque concepteur Web de contribuer à l'amélioration du Web, surtout auprès des personnes qui en tirent le plus profit.

La technologie n'a t'elle pas un but de faciliter la vie du web dans ce cas?
 
Ensuite quitte a respecter les standards W3C autant le faire jusqu'au bout... Mais bon la on s'ecarte quelque peu du sujet du topic :wink2:
 
webmaster link=topic=7608.msg114195#msg114195 date=1137869245 a dit:
Pas lu, trop long, trop chiant. Je m'en bats les ... du W3C
Cliquez pour agrandir...
Moi je suis en cours de finalisation de la v3 de mon site, et je m'éfforce de rendre les pages 100% conformes XHTML 1.0 Strict.
Pas facile toujours, mais on y arrive.
Ca donne un résultat propre, qui sera facile à maintenir et faire évoluer, et un code source bien concu est également plus facile à lire pour les moteurs de recherche, aidant donc en partie au référencement.
 
Vous devez vous connecter ou vous inscrire pour répondre ici.
Retour
Haut