Pages :
(reprise du message précédent)

Felipe a écrit :

Un peu réducteur Smiley lol Il s'agit quand même des flux RSS et je pense que blogs et podcasts ont un certain avenir! Autant prévenir le split, d'autant que l'harmonisation ne demande pas beaucoup d'efforts.
La norme étant définie en commun au W3C (ou ailleurs), la compatibilité ne regarde que chaque entreprise/fondation, mais bon c'était l'époque qui voulait ça (la guerre des navigateurs, ouvez le feu)

Je n'ai pas cassé le rss, j'avai cru comprendre que c'etait pour le choix de l'icone a mettre (le picto orange de FF), perso le rss est tres bien géré sur safari ( beaucoup mieux que sous firefox, et mieux que sous flock), ie7 devrait en prendre de la graine.
Pour les podcasts, les lecteurs de podcasts et itunes gère ça tres bien soit via mp3, soit mieux via AAC (permettant le chapitrage, l'ajout de visuel et lien, que du bohneur pour les poditeurs ) Smiley cligne
Lanza a écrit :

Micorosoft n'est pas Adobe, leurs situations respectives sont différentes. (En fait dans l'histoire Adobe n'a pas le choix, le coeur de son marché étant sur Mac).

Daccord avec toi, adobe n'a pas la meme situation, quoique depuis l'achat de macromedia, je ne leur connait plus du tout de concurrent professionnel...

Lanza a écrit :

D'autre part, le développement d'IE a repris il y a moins d'un an, après plusieurs années de stagnation, et suite à la montée de Firefox. C'est un peu court pour refaire IE et il est indispensable pour Microsoft qu'il soit prêt pour la sortie de Vista.

Personnellement lire qu'il faut 1 an pour ameliorer un navigateur...
Autant le refaire, et je pense pas que microsoft n'ai qu'un developpeur sur le projet, ou alors c'est un stagiaire, faut etre honnete: 1 an pour developper un navigateur, perso, je le reprends depuis le debut Smiley cligne

Lanza a écrit :

Enfin réécrire un IE conforme signifierait la perte de la compatibilité des sites actuels (surtout ceux en "mode quirks"), et comme le fait remarquer Laurent Denis, Microsoft ne peut pas se le permettre.

Je ne connais pas la signification de quirks ?
Mais je vois ce que tu veux dire, de toute facon les sites codés a la chico ne sont pas de grandes enseignes ou site a fort traffic, eux respecetent un minimum les standards non ?
Et puis si du jour au lendemain, microsoft dit ie7 respectera les standards like FF, les webmasters feront l'effort de rechanger les lignes de code, ou pour ceux qui avait deja verifié sous FF ne feront rien de plus Smiley cligne
Bonjour,

Attention aux confusions sur les modes de rendu "Quirks" et "Strict". Voir à ce propos http://blog.alsacreations.com/2005/08/01/183-choix-dune-dtd-le-doctype-switching-nest-pas-pour-nous

En fonction de la syntaxe de la DTD (ou de l'absence de DTD) en tête d'un document, IE6 et IE7 basculent soit:
- en mode de rendu "strict" où les normes (X)HTML CSS sont appliquées
- en mode de rendu "quirks" où les anciennes implémentations d'IE sont appliquées.

En mode quirks, par exemple, IE6 utilise le modèle de boîte Microsoft et non le modèle CSS2. Il corrige certaines erreurs CSS comme l'absence d'unité dans une propriété "width: 200;". En revanche, en mode strict, il ne corrigera pas ce type d'erreur.

Le mode Quirks est destiné à assurer la compatibilité de rendu des anciens documents, qui avaient été construits en fonction des implémentations propre au navigateur, et non en fonction des normes.

Ce n'est donc pas, en fait, le mode "quirks" qui peut être problématique pour IE7. Au contraire, il permettra de conserver dans IE7 une partie des caractéristiques d'IE5.x-6.0, sans compromettre le rendu standard qui sera assuré en mode strict.

Enfin, concernant le type de sites codés "hors normes" et en fonction d'implémentations propres à IE : on y trouve en particulier :
- des sites de grand comptes, de grandes enseignes, à fort trafic...
- des intranet et des applications, dont le développement a parfois conduit Microsoft à des modifications spécifiques (hors normes) du navigateur, sur demande du client.

Garantir la compatibilité de ces dernières est l'une des contraintes clés...
Modifié par Laurent Denis (09 Feb 2006 - 06:19)
Laurent Denis a écrit :
Bonjour,
...

Le mode Quirks est destiné à assurer la compatibilité de rendu des anciens documents, qui avaient été construits en fonction des implémentations propre au navigateur, et non en fonction des normes.

Ce n'est donc pas, en fait, le mode "quirks" qui peut être problématique pour IE7. Au contraire, il permettra de conserver dans IE7 une partie des caractéristiques d'IE5.x-6.0, sans compromettre le rendu standard qui sera assuré en mode strict.

Enfin, concernant le type de sites codés "hors normes" et en fonction d'implémentations propres à IE : on y trouve en particulier :
- des sites de grand comptes, de grandes enseignes, à fort trafic...
- des intranet et des applications, dont le développement a parfois conduit Microsoft à des modifications spécifiques (hors normes) du navigateur, sur demande du client.

Garantir la compatibilité de ces dernières est l'une des contraintes clés...


Bonjour,

Je me demande jusqu'à quel point les deux modes utilisent du code différent et donc jusqu'où modifer le mode "strict" peut se faire sans impact sur le mode "quirks".

Et je persiste à penser qu'un an pour refaire un navigateur, cela relève du délire. Il a fallu à Mozilla, Opera et à Safari/KHTML plusieurs années, pour atteindre leur niveau de qualité actuel.
Lanza a écrit :

Et je persiste à penser qu'un an pour refaire un navigateur, cela relève du délire. Il a fallu à Mozilla, Opera et à Safari/KHTML plusieurs années, pour atteindre leur niveau de qualité actuel.


1/ je ne pense pas que ces années de developpement soit egal uniquement au developpement de l'application, il faut pas oublier que lorsque mozilla... ont commencé le developpement de leur navigateur, il n'y avait pas la transparence normative actuel, et ces normes ont evolué en meme temps que leur developpement donc ça n'a pas du aider
2/ en tant que developpeur (je pense pas etre le seul sur ce forum) si vraiment on le voulait, je pense qu'avec une equipe de 4-5 on arriverai en 11 mois à faire un navigateur strict de qualité

EDIT: merci Laurent Denis pour l'info Smiley cligne
Modifié par imikado (09 Feb 2006 - 12:53)
imikado a écrit :

2/ en tant que developpeur (je pense pas etre le seul sur ce forum) si vraiment on le voulait, je pense qu'avec une equipe de 4-5 on arriverai en 11 mois à faire un navigateur strict de qualité


Je pense que tu ne mesure pas exactement la difficulté d'un tel projet... pour t'en donner une petite idée, je t'encourage vivement à participer (même comme simple observateur) au divers projet ouvert existant : Gecko bien sur, mais aussi KHTML.

Le code source de ces deux moteur est ouvert... regarde et apprécis !
En 1 ans, à 4 ou 5 personnes... mouais, si vous vous y astreignez tous les jours (même le dimanche), 12 heures par jours... j'ai encore des doutes, mais tout est possible
Smiley cligne

imikado a écrit :

il faut pas oublier que lorsque mozilla... ont commencé le developpement de leur navigateur, il n'y avait pas la transparence normative actuel

Cette problématique est toujours en vigueur car les standards evoluent en permanence (bientot CSS 3 et XHTML 2... et quid de HTML5 qui n'est pas un standard mais qui pourrait le devenir de fait si un majorité de navigateur l'implémente ! Voir le cas de la balise canvas)
Modifié par Jep (09 Feb 2006 - 14:04)
imikado a écrit :

2/ en tant que developpeur (je pense pas etre le seul sur ce forum) si vraiment on le voulait, je pense qu'avec une equipe de 4-5 on arriverai en 11 mois à faire un navigateur strict de qualité


Qu'on pourrait utiliser pour visiter 2% des sites actuels, donc.
Smiley lol
Lanza a écrit :


Qu'on pourrait utiliser pour visiter 2% des sites actuels, donc.
Smiley lol

Oui en effet Smiley lol
Mais faut me comprendre: j'ai rajouté strict comme ça je suis plus (+) sur pour les 11 mois, alors que si je mets compatible tout même les hors normes, les 11 mois risquent au vu du projet d'etre un peu juste
Jep a écrit :

Je pense que tu ne mesure pas exactement la difficulté d'un tel projet... pour t'en donner une petite idée, je t'encourage vivement à participer (même comme simple observateur) au divers projet ouvert existant : Gecko bien sur, mais aussi KHTML.

Le code source de ces deux moteur est ouvert... regarde et apprécis !
En 1 ans, à 4 ou 5 personnes... mouais, si vous vous y astreignez tous les jours (même le dimanche), 12 heures par jours... j'ai encore des doutes, mais tout est possible
Smiley cligne

Je vais jeter un coup d'oeil, c'est quoi exactement la page pour avoir le code source pour un navigateur ouvert tournant sur osX (histoire de pouvoir tester)

Apres je pourrais confirmer ou non pour les 11 mois, mais je pars toujours du principe qu'avec une equipe motivé et bien organisé, on peut faire des merveilles en un minimum de temps Smiley cligne

Jep a écrit :

Cette problématique est toujours en vigueur car les standards evoluent en permanence (bientot CSS 3 et XHTML 2... et quid de HTML5 qui n'est pas un standard mais qui pourrait le devenir de fait si un majorité de navigateur l'implémente ! Voir le cas de la balise canvas)

Pour ca, je sais pas comment c'est fait actuellement, mais je pense qu'a l'image d'apache il faut prevoir de pouvoir rajouter des modules "loadables" en verifiant l'entete de la page, comme ça quand y a des nouveaux standard, on rajoute une ligne qui dit "si tu vois tel occurence, tu charges tel module" et bien sur travailler sur ce nouveau module
Mais je pense pas avoir inventé la roue, donc ça doit fonctionner un peu comme ca non ?
a écrit :
Je vais jeter un coup d'oeil, c'est quoi exactement la page pour avoir le code source pour un navigateur ouvert tournant sur osX (histoire de pouvoir tester)

Bon ... au hasard : Safari Smiley lol
> http://developer.apple.com/darwin/projects/webcore/

Sinon :
Khtml fai parti integrante du projet KDE (uniquement sous linux donc)
> http://developer.kde.org/source/index.html
> http://developer.kde.org/documentation/library/3.3-api/khtml/html/files.html

Gecko est multi plateforme :
> http://developer.mozilla.org/fr/docs/T%C3%A9l%C3%A9chargement_du_code_source_de_Mozilla

a écrit :
Pour ca, je sais pas comment c'est fait actuellement, mais je pense qu'a l'image d'apache il faut prevoir de pouvoir rajouter des modules "loadables" en verifiant l'entete de la page, comme ça quand y a des nouveaux standard, on rajoute une ligne qui dit "si tu vois tel occurence, tu charges tel module" et bien sur travailler sur ce nouveau module
Mais je pense pas avoir inventé la roue, donc ça doit fonctionner un peu comme ca non ?

Marrant, ça me rapelle le principe de Gecko et du framework XPFE Smiley lol ... en particulier la technologie XBL (qui permet l'implémentation de XForm au sein de FF par exemple)
> http://developer.mozilla.org/fr/docs/XBL
Modifié par Jep (09 Feb 2006 - 19:27)
Bon allez, je suis assez optimiste quand même : pour mon dernier site, ma feuille de style IE7 ne fait que quelques lignes alors que celle d'IE 6 en faisait 140 !

On se rapproche donc de la bonne voie !

Par contre en tant qu'utilisateur je n'ai vraiment pas envie de naviguer avec ce programme, et je ne vois aucun + par rapport à Firefox...
Je n'ai pas tester la version en profondeur, mais par contre une chose que j'ai apprécié c'est le nouveau mode de fonctionnement du zoom du style de celui d'Opera plus pratique que celui de Firefox Smiley smile

HS : une version beta d'opera 9 est sorti avec quelques amélioration, corrections, apports tel que la prise en charge du designMode.

Eric
Pages :