Pourquoi développer pour FireFox ?

HTML5, CSS3, Javascript, support des mobiles... Que penser de votre site ? Vous manquez d'informations pour la construction d'un site qui puisse s'afficher correctement partout ? C'est un problème simple, un peu complexe ? Venez ici !
shiftcode
Arias
Messages : 19
Inscription : 10 déc. 2004, 07:08

Pourquoi développer pour FireFox ?

Message par shiftcode »

Bonjour, je viens de télécharger FireFox pour le tester sur nos applications web, et le constat est accablant: plus rien ne marche.
Devant l'importance des modifications à faire, et parce que le temps de développement est chiffré (la direction générale nous surveille, société privée oblige), une question nous taraude.
Est-il intéressant de passer du temps à rendre nos applications compatibles avec ce navigateur? Pour mieux répondre à cette question, je voudrais savoir ce que vous en pensez, et combien d'entre vous se sont convertis à FireFox. :?:
Pour info, je n'ai rien contre FireFox, bien au contraire. Ma page perso est "FireFox compatible" depuis hier, et les modifs furent mineures, mais qu'en sera-t-il vraiment des applis web développées par mes collègues?
calimo
Animal mythique
Messages : 14118
Inscription : 26 déc. 2003, 11:51

Message par calimo »

Il faut bien comprendre une chose : tu ne dévelopes pas pour Firefox, ni pour un autre navigateur.
Les standards, c'est développer pour tous les navigateurs :wink:

Donc si tu convertis tes applications aux standards, elles fonctionneront dans tous les navigateurs (actuels et futurs) respectants les standards : Firefox et toute la famille Gecko, Opera, Khtml (Konqueror et Safari), mais aussi IE, qui contrairement à ce qu'on en dit souvent implémente aussi les standards (le problème c'est qu'il implémente aussi des trucs non standard).

En résumé, faire un site respectant les standards, c'est un pari sur l'avenir (que l'on espère tous faits de standards), c'est s'assurer de ne pas devoir tout recommancer dans trois ans lorsque les navigateurs changeront 8)

Développer avec (pas pour :wink: ) Firefox est un bon début, car ce navigateur n'implémente que peux de choses non standard (en fait, le minimum pour des raisons de compatibilité), mais ça ne veut pas dire que ton application web sera standard. Pour ça il faut lire les recommandations (HTML, ECMAScript, CSS etc., demande si tu veux des liens), et tester sous un maximum de navigateurs pour s'assurer que tel ou tel effet n'est pas du à un manquement d'un navigateur aux standards.
Une fois que cela est fait, tu as la quasi-certitude que ton application est prête pour durer (à moins d'un triomphe des navigateurs non-standards, ce qui n'est pas à espérer :? )

Consulte des sites comme openweb pour en savoir un peu plus sur les standards :wink:

Bref prendre du temps pour passer aux standards n'est pas seulement intéressant, c'est indispensable :P

Edition : je viens de lire ton autre sujet, tu as raison de te méfier du "Gecko DOM". Je ne sais pas du tout si ce n'est qu'une reformulation des recommandations ou déjà un début de dérive. Des personnes plus qualifiées que moi sauront sans doute y répondre.
Pour les recommandations DOM : http://www.w3.org/DOM/
Et la traduction pour DOM2 : http://www.yoyodesign.org/doc/w3c/w3c.html#dom2
C'est déjà nettement plus fiable :wink:
Dernière modification par calimo le 11 déc. 2004, 11:35, modifié 1 fois.
Humpfff
Tyrannosaurus Rex
Messages : 2451
Inscription : 05 avr. 2004, 13:23

Message par Humpfff »

Ma page perso est "FireFox compatible" depuis hier
Le point réellement important n'est pas de savoir si ta page est compatible avec Firefox, mais plutot si le code de ta page web est conforme aux recommandations du W3C..
Tu assures ainsi à ton site, une compatibilité maximale parmi l'ensemble des navigateurs web existants et à venir

Dans le cas d'applications web, je commencerai par faire la même remarque.
Mais j'aimerais en savoir plus sur les types de technologies que tu emploies actuellement pour ces applications ?

Tu trouveras sur openweb.eu.org de quoi t'éclairer => http://openweb.eu.org/decideur/ et notamment cet article => Les standards Web pour l'entreprise
PsyDk
Lézard à collerette
Messages : 317
Inscription : 23 sept. 2003, 09:41

Message par PsyDk »

Code selon les standards du W3C, ça permet de rendre ton application potentiellement éternelle, elle fonctionnera à vie :) Ça c'est super séduisant d'un point de vue cout.

Firefox est intéressant car c'est un navigateur qui respecte bien les standards. Il a beau venir à la base des vieilles sources de Netscape, la plupart des fonctionnalités propriétaires de Netscape ont été dégagées.

J'ai eu l'expérience de plusieurs applications développée sous IE au boulot. La première fois que j'ai testé ça sous Firefox, j'étais embêté que ça ne fonctionne pas bien. Petit à petit, des modifications ont été apportées. Souvent ce n'est pas très lourd. Genre utiliser du document.getElementById dans les scripts au lieu d'utiliser directement l'id d'un élément. Ou rendre les pages valides, notamment avec un bon doctype, pour que les navigateurs puissent les afficher en mode Standard Compliance. Au final on état bien content car ça rendait le code plus que compatible Firefox, ça le rendait conforme aux standards du Web. Et on a beaucoup appris sur le sujet.

Une de nos applis a même été au fil des versions :
- codée en mode Quirks ;
- améliorée avec du html moins dégueux, utilisant du CSS ;
- améliorée avec du html 4 en mode Standard Compliance ;
- améliorée avec du html 4 en mode Standard Compliance avec bonne séparation présentation/contenu via CSS ;
- pour finir avec du xhtml 1.0 strict desservi en mode xml, avec séparation présentation/contenu, et même plusieurs feuilles de styles pour différents designs graphiques :)
SB
Varan
Messages : 1095
Inscription : 05 mars 2004, 18:38

Re: Pourquoi développer pour FireFox ?

Message par SB »

shiftcode a écrit :Pour mieux répondre à cette question, je voudrais savoir ce que vous en pensez, et combien d'entre vous se sont convertis à FireFox. :?:
L'endoit est mal choisi pour poser la question, par ici presque tout le monde s'est converti à Firefox. En ce qui me concerne, tout ce qui est compatible IE only c'est direct à la poubelle. Si tes collègues et toi développez quelque chose de ce genre, je ne serais jamais client.
toma214

Message par toma214 »

Il y a un truc que je pige pas là.

Je suis moi même webmaster et tous les sites que je créé son compatibles avec tous les navigateurs. Si l'ont respecte bien les normes du W3C, ce que tout bon webmaster est censé connaître, il n'y a pas de problème :roll:
Jigho
Iguane
Messages : 637
Inscription : 29 juil. 2003, 08:44

Message par Jigho »

Attention tout de même : une page valide W3C (i.e., qui ne contient aucune erreur de syntaxe W3C) ne s'affiche pas forcément pareil partout... en effet, MSIE interprète parfois les données de façons différentes de ce qui est préconisé par le W3C. C'est le cas notamment avec les "margin" et "border" des éléments.
Pour des conceptions simples, ça ne se voit pas forcément, mais pour de mises en pages chiadées, ça peut poser des problèmes (i.e., il faut quand meme recourir à une astuce spéciale pour MSIE) ! :cry:
PsyDk
Lézard à collerette
Messages : 317
Inscription : 23 sept. 2003, 09:41

Message par PsyDk »

Jigho a écrit :Attention tout de même : une page valide W3C (i.e., qui ne contient aucune erreur de syntaxe W3C) ne s'affiche pas forcément pareil partout...
Y'a des bugs dans tout logiciel :) Après faut déterminer sa position vis-à-vis de ces bugs. C'est à dire évaluer jusqu'à quel point on va utiliser des méthodes pour les contourner.

Perso y'a des navigateurs trop buggés pour mériter toute mon attention. IE5 par exemple je l'ai oublié. Le fait que les marges déconnent ou que le box model est foireux sous IE5, ce n'est pas très grave du moment que le contenu reste accessible.
Invité

Message par Invité »

Voici ma réaction face à la vôtre (face contre tous :lol: ) mais je m'y attendais un peu en postant sur un site de férus de FireFox.
si tu convertis tes applications aux standards, elles fonctionneront dans tous les navigateurs (actuels et futurs) respectant les standards

Je suis moi même webmaster et tous les sites que je créé son compatibles avec tous les navigateurs. Si l'ont respecte bien les normes du W3C, ce que tout bon webmaster est censé connaître, il n'y a pas de problème
Faux : voir la solution proposée à ce thread : http://www.geckozone.org/forum/viewtopic.php?t=14146
Code selon les standards du W3C, ça permet de rendre ton application potentiellement éternelle, elle fonctionnera à vie. Ça c'est super séduisant d'un point de vue coût.
Oh, quelle douce utopie ! J’aime beaucoup ta phrase, mais là, je crois que tu rêves un peu. Les techniques des hackers évoluent et ton application peut devenir contenir une nouvelle faille de sécurité inconnue jusqu’alors. C’est le cas de la faille injection HTML découverte l’été dernier, faille pourtant présente depuis des années. Voir cet article sur la faille de type injection HTML http://www.hakin9.org/fr/attachments/inject_fr.pdf

En ce qui me concerne, tout ce qui est compatible IE only c'est direct à la poubelle. Si tes collègues et toi développez quelque chose de ce genre, je ne serais jamais client.
Il y a en effet assez peu de chances que tu sois client, car les clients pour qui on a mis cette solution en place sont des exportaeurs, donc pas de clients en France… :?

Bon, plus sérieusement, un webmaster ne réinvente pas la roue à chaque fois qu'il construit un nouveau site. Il utilise parfois du code JavaScript du domaine public développé par d'autres, et pour lequel il n'est pas toujours rentable de passer du temps à le débugger et le modifier à chaque fois qu'un nouveau navigateur arrive sur la communauté internet.

Ma question reste censée. Mes applications ne sont à priori pas trop loin du standard. Je vais lire deux trois documents pour m'en assurer, mais il va encore falloir faire le forcing auprès des collègues. J'ai déjà dû leur imposer les CSS dès le début de leurs projets, leurs mises en page sont encore basées sur des tableaux, mais on progresse, on progresse...
PsyDk
Lézard à collerette
Messages : 317
Inscription : 23 sept. 2003, 09:41

Message par PsyDk »

Anonymous a écrit :
Si l'ont respecte bien les normes du W3C, ce que tout bon webmaster est censé connaître, il n'y a pas de problème
Faux : voir la solution proposée à ce thread : http://www.geckozone.org/forum/viewtopic.php?t=14146
Pourrais-tu développer s'il te plait ? Il y avait en début de topic un code qui ne pouvait pas fonctionner correctement. Les gens (dont moi) sont même allés plus loin, car au lieu de proposer une rustine, ils ont proposé une nouvelle manière d'aborder le problème en utilisant correctement le DOM. Ou alors tu n'as rien compris à la réponse :/
Anonymous a écrit :
Code selon les standards du W3C, ça permet de rendre ton application potentiellement éternelle, elle fonctionnera à vie. Ça c'est super séduisant d'un point de vue coût.
Oh, quelle douce utopie ! J’aime beaucoup ta phrase, mais là, je crois que tu rêves un peu. Les techniques des hackers évoluent et ton application peut devenir contenir une nouvelle faille de sécurité inconnue jusqu’alors. C’est le cas de la faille injection HTML découverte l’été dernier, faille pourtant présente depuis des années. Voir cet article sur la faille de type injection HTML http://www.hakin9.org/fr/attachments/inject_fr.pdf
Là je ne comprends pas la relation. J'aimerais que tu développes aussi. Il s'agit d'une part de réaliser du code xhtml/css/javascript en respectant les standards, et d'autre part il s'agit d'applications php susceptibles d'avoir des failles, ou alors de navigateurs susceptibles d'avoir des failles.

Il n'y a rien d'utopique là-dedans. On ne parle pas de philosophie ou de politique. Ça correspond à une réalité technique. Les pages écrites correctement en HTML 3 dans les années 90 fonctionnent encore très bien dans les navigateurs actuels. De même qu'une page écrite en xhtml bien formé et valide fonctionnera dans trois siècles à partir du moment où le logiciel se dira compatible avec cette norme.
jv2759
Tyrannosaurus Rex
Messages : 4161
Inscription : 12 févr. 2004, 14:29

Message par jv2759 »

Anonymous a écrit :Bon, plus sérieusement, un webmaster ne réinvente pas la roue à chaque fois qu'il construit un nouveau site. Il utilise parfois du code JavaScript du domaine public développé par d'autres, et pour lequel il n'est pas toujours rentable de passer du temps à le débugger et le modifier à chaque fois qu'un nouveau navigateur arrive sur la communauté internet.
Je me souvien avoir vus passer un scripte de plus de 100 ligne sur le forum, scripte qui ne marchais pas avec firefox bien evidament (par contre il marchais avec netscape 4 c'est sur que 0.2% des naviguateur c'est plus important que 8%). La personne à prix le temps de refaire le scripte. Résultat il fait 10 ligne et il est compatible avec les future naviguateur...

Réhutiliser du javascript sans savoir d'ou ce dernier provien et tres dangeureux, car il n'est pas forcement compatible, pas forcement bien écrie. Sauvant c'est le chart pour tuer une mouche. Et tres chére, car casiment imintenable. Il est plus economique de passer 1h aujourd'hui à réécrire un scripte qui marche et que l'on maitrise que de passer 3 jour dans un ans pour comprendre comment marchais le scripte pour le rendre compatible.

Si tu est dans une entreprise, alors dit simplement, que les standard c'est un investissement pour l'avenir(pas si couteux que cela), alors que le propriétaire c'est reporter les cout à plus tard.

En plus il ne faut pas oublier que firefox à de forte chance de représenter environs 10% des part de marchais asser rapidement. C'est sur avec 90% ie seras toujours ultra majoritaire. Mais demande au patron s'il vois d'un bonne oeuil la perte potenciel de 10% de son ca...
Inscrit sur la liste des abonner absent...
shiftcode
Arias
Messages : 19
Inscription : 10 déc. 2004, 07:08

Message par shiftcode »

Pourrais-tu développer s'il te plait ? Il y avait en début de topic un code qui ne pouvait pas fonctionner correctement. Les gens (dont moi) sont même allés plus loin, car au lieu de proposer une rustine, ils ont proposé une nouvelle manière d'aborder le problème en utilisant correctement le DOM. Ou alors tu n'as rien compris à la réponse :/
Tu n’as compris ni mon problème, ni sa résolution ! Relis bien le thread depuis le début.
Bonjour, je viens de mettre à jour ce qui pour moi est un bug, mais qui a peut-être une explication. Voici mon code:

Code : Tout sélectionner

<body> 
<script language="JavaScript"> 
document.write('<div id="id_js">id javascript</div>'); 
document.getElementById("id_js").innerHTML   = "Javascript div modified"; 
document.getElementById("id_html").innerHTML = "HTML div modified"; 
</script> 
<div id="id_html">id html</div> 
</body>
Dans ce code, la balise DIV créée par le script (id_js) voit son contenu changer, mais rien ne se passe pour le contenu de la balise DIV codée en HTML
Et la solution de Bobo, répondant à mon problème :
La raison est simple, au moment de l'exécution du script, ta div "id_html" n'existe pas encore.
Si tu la places avant l'élément <script>, tu constateras que le script fonctionne.
Sinon, il faut placer ton code dans une fonction appelée par l'événement onload.
En résumé, pour que mon code fonctionne, il faut que mon script soit inséré à la fin de la page ou lancée par l’évènement onload, ce qui n’a rien à voir avec la compatibilité avec DOM.

Ton code était intéressant, mais hors sujet, puisque le problème se posait sur la modification du contenu d’une balise existante, et non sur la création d’une nouvelle balise, qui fonctionnait correctement malgré le fait qu’elle ne soit pas 100% standard.

Pour ta seconde réaction, PsyDk, voici la relation entre les deux : un code développé il y a dix ans est potentiellement « éternel », mis à part quand la réalité fait que tu es obligé de le modifier quand il s’avère qu’il possède une faille de sécurité. L’injection HTML utilise du code JavaScript pour envoyer (entre autres) les cookies propres à un site sur un autre serveur. L’une des solutions consiste à interdire au navigateur l’utilisation des cookies en JavaScript (cf http://www.westpoint.ltd.uk/advisories/wp-04-0001.txt) Dans ces conditions, ton code d’il y a dix ans peut ne plus fonctionner, même s’il respecte les standards définis il y a dix ans, même s’il est bien formé.
Mais demande au patron s'il vois d'un bonne oeuil la perte potenciel de 10% de son ca...
Nous n’en sommes pas là. Nos applications web font du suivi de commande auprès de nos importateurs, pas du e-business ni du B to B.
Réhutiliser du javascript sans savoir d'ou ce dernier provien et tres dangeureux, car il n'est pas forcement compatible, pas forcement bien écrit.
Celui-ci est plutôt bien écrit, mais trouver le petit grain de sable qui coince le rouage n’est pas forcément chose aisée, et prend du temps, que ce soit du code écrit par nos soins ou du code provenant de l’extérieur. Vas expliquer à ton boss que tu passes dix homme-jours à rendre tes applications compatibles avec le dernier navigateur à la mode, et tu verras sa réaction. S'il est pragmatique (ce qui est le cas pour moi), il va te demander si c'est bien utile de prendre autant de retard sur les projets en cours pour un navigateur dont on ne sait pas s'il sera utilisé dans les mois (années) à venir.
Je rappelle qu'en informatique ce n'est pas forcément le meilleur logiciel qui est utilisé, mais celui qui sera le plus populaire, donc celui qui aura fait le plus de bruit, celui qui aura eu la politique commerciale la plus percutante, la plus agressive (vois comment Microsoft s'est payé la part du lion). Dans le monde du travail, ce n'est pas la personne la plus apte à répondre au poste demandé qui sera embauchée, mais la personne qui se sera le mieux vendu.

Mais je m'égare. J'avais prévenu dans mon thread précédent que ce thread serait un troll. C'est en train de le devenir, et çà n'a que très peu d'intérêt... Je pense qu'il faut recentrer le débat.

Donnez-moi plutôt votre retour d'expérience sur les choses que vous avez dû faire pour rendre votre code compatible avec FireFox. Merci d'avance.
jv2759
Tyrannosaurus Rex
Messages : 4161
Inscription : 12 févr. 2004, 14:29

Message par jv2759 »

shiftcode a écrit :Donnez-moi plutôt votre retour d'expérience sur les choses que vous avez dû faire pour rendre votre code compatible avec FireFox. Merci d'avance.
Mais retour d'experience c'est ce forum même. Des technique à base de frame qui pour cause de faille de sécuriter exploitable ne marche plus.

Ces des mélange extrémement dangeureux entre tableaux et css pour la mise en page. Technique qui plante casiment à tout les coup.

Ce sont des site mal consut techniquement car il ne peuvent pas marchais sans javascripte, concequence si ce dernier n'est pas standard, le site est totalement bloquer car le menu qui est la seul porte d'entré n'apparer pas...

Ensuite je ne peux pas dire plus. Car tout la question et tu part d'ou? Qu'elle est la taille de l'application? Qu'elle est l'importance des pages dans l'application?

Si tu as un site ou les erreure son minime, quelque entiter, deux trois bout de javascripte mal fait. Le travaille peux être tres rapide. Maintenant si tu as fait un mélange tableaux css avec du javascripte qui controle le fonctionement de la pages et tu utilise massivement du ie-only, alors là tu est bon pour tout réécrire...

Des fois il sufit simplement de changer l'extention pour rendre compatible un fichier...


Vas expliquer à ton boss que tu passes dix homme-jours à rendre tes applications compatibles avec le dernier navigateur à la mode
Non la question n'est pas là. Personne ne te demande d'être compatible avec un naviguateur qui pourais marchais. Mais bien plutot d'être compatible avec les future naviguateur. Car même si les standard ne sont pas exent de bug. Ces dernier aurons une pereniter toujours plus grand qu'un ie-only non définit...

Les standard comme je disait sont un investissement. Dans 10 ans je peux te jurée que tout les naviguateur serons compatible xhtml 1.0, peux-tu assurer la même longeviter pour ie? Et même que seras dans 10 ans ie?

Car si firefox en soit n'as pas une vie infinie et dans 1 ans peut-être qu'il seras retomber à 1%. Mais peut-tu être sur que ce seras ie qui auras reprit le flambeaux? IE, c'est un parie à court terme, car tu peux ne peux conter que sur lui. Alors que les standard c'est du long terme, car si c'est pas firefox, ce seras un autre. Cela marcheras même sous ie...
Inscrit sur la liste des abonner absent...
PsyDk
Lézard à collerette
Messages : 317
Inscription : 23 sept. 2003, 09:41

Message par PsyDk »

shiftcode a écrit : Tu n’as compris ni mon problème, ni sa résolution ! Relis bien le thread depuis le début.

Et la solution de Bobo, répondant à mon problème :

En résumé, pour que mon code fonctionne, il faut que mon script soit inséré à la fin de la page ou lancée par l’évènement onload, ce qui n’a rien à voir avec la compatibilité avec DOM.

Ton code était intéressant, mais hors sujet, puisque le problème se posait sur la modification du contenu d’une balise existante, et non sur la création d’une nouvelle balise, qui fonctionnait correctement malgré le fait qu’elle ne soit pas 100% standard.
Oui, Bobo avait bien répondu. Il aurait pu s'agir d'une différence de comportement selon les navigateurs en effet. En revanche dans le cas qui nous intéresse la norme html 4 dit à propos des scripts :
« All SCRIPT elements are evaluated in order as the document is loaded. »

Il est donc normal que tu ne puisses accéder à un élément défini sous ce bloc de script.

La suite c'est en effet une disgression sur le sujet :) Consistant à donner des exemples de manipulation de l'arbre du document avec des fonctions sympathiques comme createElement, createNode, etc. au lieu de innerHTML (document.getElementById("monid").childNodes[0].nodeValue = "blabla" par exemple pour modifier le texte d'un élément). C'était histoire d'exposer des trus intéressants. En tout cas moi j'aime bien quand on me donne des choses nouvelles à apprendre :)
shiftcode a écrit : Pour ta seconde réaction, PsyDk, voici la relation entre les deux : un code développé il y a dix ans est potentiellement « éternel », mis à part quand la réalité fait que tu es obligé de le modifier quand il s’avère qu’il possède une faille de sécurité. L’injection HTML utilise du code JavaScript pour envoyer (entre autres) les cookies propres à un site sur un autre serveur. L’une des solutions consiste à interdire au navigateur l’utilisation des cookies en JavaScript (cf http://www.westpoint.ltd.uk/advisories/wp-04-0001.txt) Dans ces conditions, ton code d’il y a dix ans peut ne plus fonctionner, même s’il respecte les standards définis il y a dix ans, même s’il est bien formé.
Ok. Je crois comprendre ce que tu veux dire. J'ai rencontré ce genre de soucis dans mon boulot. Pas l'histoire du cookie en lui-même, mais quelque chose dans l'idée que tu exposes :

On tentait de faire passer des infos d'une page à l'autre via des frames, et une page se trouvait sur un serveur, et l'autre page sur un autre serveur. Sous IE ça passait, mais Firefox nous jetait en indiquant que c'est une manipulation interdite. Je ne sais plus comment on a résolu le problème, mais le comportement de Firefox nous a paru sensé.

Comme ça semble t'intéresser, les autres points que nous avons eu à prendre en compte :

- avoir un doctype complet pour passer le navigateur en mode Standard Compliance afin d'avoir un rendu graphique cohérent ;
- utiliser du getElementById concernant le javascript au lieu d'utiliser les id comme si c'était des objets ;
- valider souvent son code html. On ne sait pas à l'avance comment va réagir un navigateur face à du code mal formé.

L'application potentiellement éternelle veut dire ce que ça veut dire. En respectant les standards établis, tu maximises les chances d'avoir une appli qui continuera à tourner dans le futur. Ça ne veut pas dire que tu as 100% de chances que ça soit le cas :wink:
Invité

Message par Invité »

Messieurs les développeurs, je vous tire mon chapeau. Je craignais fort que ce thread dégénère et n'apporte rien de constructif à ma problématique. Je vous remercie de m'avoir apporté ces éléments de réponse qui vont m'aider à convaincre mon chef d'investir un peu de temps dans la mise en conformité de nos applications. Par contre, nous avons une application web développée et maintenue par une société extérieure qui ne fonctionne que sous IE et pour lequel aucune mise en confirmité n'est prévue. L'application est plutôt bien codée, mais ils ont fait un usage intensif du document.all d'ie. Nos spécifiques (développés par mes soins) font un usage intensif du getElementById

Encore une fois, messieurs, chapeau bas. :wink:
Répondre

Qui est en ligne ?

Utilisateurs parcourant ce forum : Aucun utilisateur inscrit et 10 invités