À lire ton journal, on a l'impression que ça vient de sortir alors que XulRunner 1.9 est sorti en même temps que Firefox 3.0, c'est à dire il y a quelques mois (juin 2008)... Il aurait fallu precisé (dans le titre entre autre), que tu parles de la version de mise à jour 1.9.0.6.
Ceci dit, merci d'en avoir fait un peu de pub :-)
Et n'hésitez pas à aller sur les forums de xulfr.org (ou channel irc #xulfr sur irc.mozilla.org) pour poser toutes vos questions :-)
Pour ce qui est de l'avenir de XulRunner face à silverlight/adobe Air. C'est clair qu'on n'a pas le même rouleau compresseur marketing de MS et Adobe, et Mozilla préfère promouvoir les technos purement web que sa plateforme XUL (pour diverses raisons). Cependant, techniquement, XulRunner n'a rien à envier à Adobe Air. Deux exemples :
1) le Flex dans adobe air (qui est un XUL-like), n'est pas "dynamique" : on ne peut pas le changer à la volée, on ne travaille pas avec un DOM contrairement à XulRunner. Dans XulRunner, on manipule donc l'interface comme une simple page web.
2) Avec XulRunner, on peut intégrer n'importe quelle lib tierce et il y a un système de chargement dynamique de composant (XPcom). Adobe Air: rien de tout ça, vous êtes limités à l'API embarquée dans AIR.
Et je ne parle pas de l'extensibilité (cf système d'extension de Firefox) et de tout ce que propose XulRunner...
À noter que Firefox est une pure application XulRunner, et peut lancer des applis faites pour XulRunner.
> il fait référence à des trucs "unofficial" ou à l'état de draft. Et certain navigateurs les implémente. Ca revient à ajouter des extensions non standards, travers de IE il y a quelques années...
Pour les drafts, tu exagères un peu. Un draft a quand même plus de chance de devenir un standard qu'un unofficial. Du coup, les mettre dans le paquet "non standard", c'est un peu aller vite.
Implémenter un draft, c'est pas plus mal : on s'aperçoit ainsi plus vite ce qui est implémentable de ce qui ne l'est pas. ça permet aussi de faire avancer plus vite la spec, puisqu'alors on détecte les parties floues de la spec (et qu'est ce qu'il y en a dans CSS2 !), ça peut aussi amener de meilleurs idées etc.. Et je te rappelle que pour qu'une spec devienne une recommandation au W3C, il faut qu'il y ait au moins deux implémentations. Alors si il y a déjà deux implémentations quand la spec passe de draft à candidate recommandation, le processus ira plus vite.
Bref, pour les drafts, je n'y vois personnellement pas de problème.
Pour les non official. Bah c'est bien d'innover aussi sans avoir à attendre après le W3C. C'est certes pas standard, mais pas forcément un "travers" comme tu dis car finalement, si tu suis bien, l'evolution de ces specs non standards (en majorité conçernant CSS dans la page en question) :
1) il y a une spécification publique quelques part, que tout le monde peut lire, commenter et implémenter. Ce n'était pas le cas dans les années 90 pour les extensions d'IE et de Netscape (oui, il n'y avait pas que IE qui avait des extensions propriétaires, Netscape en avait probablement plus d'ailleurs)
2) Toutes ces spécifications css non standards sont discutées entre les principaux éditeurs de navigateurs (et même au CSS Working Group), et c'est pour ça que ça commence déjà à être implémenté un peu partout
3) Apple (l'auteur de pas mal de ces specs CSS, comme CSS transition &co) commence à les proposer au CSS Working group, donc ça va peut être finir en standard un jour.
Enfin, pour finir, ces specs CSS non standards, c'est pas non plus un drame. Suffit de pas en abuser sur son site, ce manière à ce qu'il reste lisible sur des navigateurs qui n'implémentent pas ces styles.
Sur l'un de mes sites, http://jelix.org, je n'ai pas hésité à mettre des ombrages (box-shadow et cie), des transitions et transformations (boites inclinées). Parce que :
1) Ça m'amusait
2) Ça m'a évité de perdre des heures avec gimp ou autre pour faire la même chose en png/div dans tout les sens (versus une ligne de code CSS pour faire de l'ombrage), et évité de faire un truc à moitié accessible (faire des images pourles boites de contenu inclinées)
3) ça n'a pas d'incidence sur des "vieux" navigateurs, sinon que le design est un peu moins fun.
Bref, inutile de diaboliser ces nouvelles fonctionnalités qui débarquent, surtout conçernant CSS : ce n'est que de la présentation. Si ça avait été des balises HTML, ça aurait été un autre problème, car bien souvent ces balises apporte des fonctionnalités. Par exemple, utiliser uniquement la balise video est facheux, car cela empêche l'accès à du contenu dans la majorité des navigateurs (On peut toutefois l'utiliser à condition d'utiliser aussi une balise object à l'interieur pour proposer un format/player alternatif).
Le fanatisme sur les standards, c'est pas bon (et je sais de quoi je parle ;-) ). Soyons un peu pragmatique.
>mais y a pas SMIL tout court. Ah ben tiens, mais pourquoi donc...
parce que ça avantagerai IE, qui l'implémente depuis la version 5.5 si je me souvient bien. Ce serait tellement dommage de lui faire prendre un point ;-)
>un récent article sur Tuxradar [1] montre que la banquise est loin d'être une de leurs priorités
Article complètement faussé.
à la question "What compile options did you use for Firefox?", ils répondent qu'ils n'ont rien compilé, et qu'ils ont pris la version de fedora, parce qu'ils veulent une version "standards".
Et là, ils perdent totalement en crédibilité. Parce que si ils avaient voulu vraiment faire jeu égale entre windows et linux, ils auraient utilisés les binaires linux fourni par Mozilla comme ils ont fait pour windows, et non pas par ceux de Fedora, qui eux, ont peut être des options de compil pas optimum, ou pas les mêmes versions de lib tierces. Je n'accuse pas Fedora, j'ai pas regardé, il est possible que ce soit pareil que le binaire officiel, mais le procédé que tuxradar a utilisé n'est finalement pas "honnete".
Bref, test à recommencer.
Ensuite, que dire que Linux n'est pas une priorité pour Mozilla est totalement faux. La majorité des devs sont sous linux (ou mac). Et crois tu qu'il y aurait autant de machines de test pour linux si ce n'était pas important pour Mozilla ? http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox3.1
1% de part de marché pour linux, 99% pour windows, mais ils consacrent plus de 40% des ressources pour linux. Proportionnellement parlant, ils tiennent donc beaucoup plus à Linux qu'à Windows.
>Tout ça pour d'éventuels contributeurs anglais qui n'existent pas à ce jour.
C'est sûr que tu n'a pas de contributeurs anglais (et tu auras peu de chances d'en avoir), vu que c'est en français. C'est un peu comme faire un site qui a un script qui check le navigateur et n'accepte que IE, et dire ensuite que ce n'est pas la peine de faire un site compatible avec les autres navigateurs vu que dans les stats, ils sont totalement insignifiants. (c'est du vecu :-) )
Ensuite, en parlant de "contributeurs anglais": Le monde est vaste, les contributeurs peuvent venir de tout pays, pas seulement des états unis ou Angleterre. Et l'anglais est probablement la langue la plus "universelle" (surtout en informatique). Donc c'est pas seulement des contributeurs "anglais" que tu pourrais avoir ;-)
Bonne continuation dans ce projet tout de même :-)
ouai bon, on peut appeler XUL un langage, mais pour moi ce n'est pas un langage au sens que l'on entend en parlant de python, C ou autre. Ce n'est pas avec XUL que tu va pouvoir implémenter le moindre algorithme. C'est pour ça que pour moi, le XUL est plus un format qu'un langage (même si y a "langage" dans le nom)
Bref, la comparaison entre Python et XUL n'a pas lieu d'être.
>qu'est-ce-qui te ferait préférer XML-based_User_interface_Language au hasard ?
Euh, c'est quoi le rapport avec un langage de programmation comme python ? Le XUL n'est qu'un format descriptif d'une interface utilisateur. Tu compares dont un format avec un langage. Très fort :-)
C'est certainement pas avec ça que je vais développer le moteur de rendu d'un browser (j'ai bien dit : moteur de rendu). à coup sûr, si je n'avais qu'à choisir entre XUL et python, je choisirais bien évidement python pour un projet comme ça, parce qu'avec XUL, je ne vais pas aller loin...
> certainement pas le fait que c'est interprété,
"interpreter" un fichier XML, c'est pas pertinent... Surtout que dans Gecko, le XUL n'est pas interprété, mais analysé et ensuite on travaille avec un DOM...
>qu'il n'y a pas d'éditeur dédié,
y a des plugins pour eclipse, y a Komodo...
> ni de tests unitaires normalisés,
Je ne vois pas ce que tu appelles "normalisés", mais il existe des outils pour faire des tests unitaires dans Mozilla.
>ni de compilation pour la vérification des types
hors sujet vis à vis de XUL
> encore d'équivalent de valgrind pour les fuites mémoires ?
Valgrind est utilisé dans le developpement de Gecko (même si il n'y a toujours aucun rapport avec XUL).
>parce que c'est la meilleure façon de produire agréablement des logiciels maintenables de qualité, et vous ?
Ouaouuu... Rien que ça. C'est totalement subjectif ça. C'est peut être la meilleur façon pour TOI. Mais sûrement pas pour tout le monde. Chacun a ses préférences, ses goûts en matière de langage. Personnellement, ce n'est certainement pas avec Python que je vais produire des logiciels maintenables et de qualité. Tout simplement parce que je n'aime pas trop Python. Et ça veut pas dire qu'avec un autre langage, je ne vais pas produire des logiciels maintenables et de qualité.
Et puis, en dehors des gouts et des couleurs, il y a aussi le fait que chaque langage a ses spécificités, qui lui permet d'être plus efficace que d'autres pour la réalisation d'un type de logiciel particulier. Ce n'est par exemple certainement pas avec Python que je vais m'amuser à faire le moteur de rendu d'un browser HTML...
>Mozilla décide à la place des utilisateurs ce qui est bon pour eux, et pour cela utilise exclusivement les services de Google. Ce qui donne à Google un contrôle sur le web. La preuve hier.
C'est pas du tout exclusif. Faut arreter la parano.
Pour le moteur de recherche, je te rappel que tu as le choix. Firefox est livré avec un certain nombre de moteur de recherche, et tu peux les supprimer, en installer d'autres. bref. Aucune exclusivité si ce n'est que Mozilla met en avant Google parce qu'ils ont un plus gros contrat avec eux qu'avec les autres (et que la cantine google est à deux pas et est très bonne :-))
Pour le service anti "sites pourris", c'est totalement paramètrable : about:config -> browser.safebrowsing.
Il t'embete ? tu le désactives (à partir de la boite des préférences ou dans le about:config). Tu veux en choisir un autre, tu renseignes les bons paramètres dans le about:config. Et si ça se trouve, il y a des extensions qui te permettent de configurer facilement vers d'autres fournisseurs.
Quant à ta liste de "Mozilla aurait pu", c'est facile à dire, il y en a qui ont refait le monde avec des "si". Et si pour chaque fonctionnalité qu'il y a dans Firefox, il fallait proposer un choix à l'installation, je doute que Firefox aurait eu le succés qu'il a. Et à mon avis, proposer le choix d'activer au premier démarrage n'aurait servi à rien, car pour 90% des gens, ils ne sauraient pas quoi répondre et activerait sans se poser de question (surtout si on leur dit que ça rend la navigation plus sûre).
>Le jour ou Mozilla voudra dire merde à google, google pourra envoyer des listes gonflées aux navigateurs utilisant ce service (majoritairement mozilla) pour planter la réputation de la fondation.
Mouai bof. Mozilla push une nouvelle version mineure de Firefox, avec des nouveaux paramètres de confs, et la majorité des installations n'utiliseront plus le service de Google. Et très franchement, je doute que Google fasse se genre de bêtise, sous peine de se prendre un procés aux fesses et une très mauvaise image (et contredire leur moto, "don't be evil").
Mozilla ne s'est pas livré pieds et poings lié à google. Il y a juste un contrat entre les deux parties. Point barre. Si demain Mozilla veut casser le contrat, ou ne pas le renouveler, elle peut le faire. Tout comme arrêter d'utiliser StopBadware. Alors certes, les revenus de Mozilla seront moindre (mais ils ont maintenant suffisamment de sous en banque pour survivre plusieurs mois..), et leur système anti-site-malveillant moins performant, voir inefficace. Car quelle réèlle alternative y a-t-il à StopBadware, qui soit la plus exhaustive possible et fiable ? (vraie question, je ne connais pas ce domaine).
>Sauf que les roues ovales, si un concurent les propose je peut aller les acheter chez lui, et si je veux de roues ovales je vais pas aller acheter une voiture qui a des roues rondes ou carrée.
je serais curieux de savoir quel constructeur automobile accepterai de vendre des roues ovales. Très franchement ;-)
> Le problème c'est si tu dis au mec je peut pas faire un design au pixel près et que ton concurent le fais, eh bien il va aller chez le concurent.
Non, parce que je lui aurais fait (ou tenter) comprendre le pourquoi de la chose. Et si après ça, il comprend toujours pas, ben alors tant pis. C'est signe que de toute façon, lui et moi on va pas s'entendre, et donc vaut mieux arrêter là et répondre à d'autres demandes de client certainement plus intéressantes.
Et puis si je fonde mon activité sous le signe de la qualité, je n'ai pas intérêt à continuer avec ce genre de client, puisqu'alors je trahi mon engagement vis à vis ce que je propose comme prestation.
Et puis, peut être que le client va aller chez la concurrence, mais peut être aussi se rendra-t-il compte que son site n'est pas si top que ça, quand il verra le site de son pote ou de son concurrent s'afficher sans problème dans son iphone au contraire du sien, et pour peut-être pour un montant moindre...
>- tu refuse en disant que non c'est pas comme ça qu'il faut faire, et tu as un ou deux client par ans seulement. Résultats tu prend un autre job à côter pour bouffer.
Pour les mauvais professionnels, oui, c'est comme ça. Pour les bons, non, car ils ont compris ce qu'est le web, et arrive à faire comprendre à leur client ce qu'est le web.
>C'est chiant à faire : oui, mais c'est possible.
Non, c'est de la poudre au yeux. Je te ruine un design soit disant au pixel près quand tu veux.
>Et si tu pense qu'un professionel qui le fait est un mauvais professionel, et bien il doit pas y avoir beaucoup de bons professionels.
Bah oui, c'est ce que j'ai dit. Il n'y a pas beaucoup de bon professionnels en france, parce que peu veulent faire de la qualité, peu arrivent à faire comprendre (ou à faire vouloir comprendre) à leur client ce qu'est un site web de qualité, ce qu'est un vrai site web etc...
Si il n'y avait peu de mauvais professionnel, on serait pas à expliquer aux clients sans arret que le" pixel pret", c'est de l'utopie.
>Faut pas croire que le créateur de site aime faire ce genre de merdes, mais il n'a pas le choix.
On a toujours le choix. Faire de la merde. Ou pas.
> Si tu compare le Web de maintenant à celui d'il y a quelques année, au niveau du respect des standards ça à quand même évolué.
Ça je le reconnais. Et je me bats depuis plusieurs années pour que ça evolue justement. Ce ciombat porte ses fruits, mais manifestement, à la lecture de tes commentaires et d'autres, il faut continuer...
>Mais le marcher des petits écran par exemple est encore trop faible.
Ouai enfin, ça explose quand même hein. Tu es resté bloqué en 2003 ? :-)
> De même les gens qui changent la taille des polices représentent un très faible pourcentage du public.
Tu as des statistiques ? des vraies ? qu'en sais tu ?
Je dirais plutôt le contraire. Quand dans firefox on a changé la manière de zoomer, on a eu des plaintes (ou des remerciements) de toutes part. Preuve que le zoom est bien plus utilisé que tu le crois, mais alors bien plus.
Je ne suis pas handicapé visuellement (quoiqu'une legère myopie), mais ça m'arrive souvent de zoomer, parce que par exemple y a des webdesigners qui trouvent qu'une police de 6pt ça fait super top, que le design est à chier et qu'on voit mal le texte, ou parce que je veux voir les details sur une photo minuscule etc..
>Pour l'instant les client voient pas trop l'intéret de changer leur mode de fonctionement pour un public aussi marginal,
parce qu'ils sont justement mal renseigné, par des (mauvais) professionnels mal renseignés. Ce public dont tu parles est loin d'être marginal. Tout le monde est différent. Tout le monde ont des modes de consultations differents, des écrans differents, des navigateurs différents etc..
> Tu ne lui dit pas comment fabriquer la voiture car c'est son metier (enfin pas le siens mais celui de lamarque) mais tu lui dit à quoi tu veux qu'elle ressemble et ce que tu veux exactement qu'il y ait dedans.
Bah, oui comme pour un site web. Ton client te demande comment il veux que son site ressemble, et ce qu'il veut dedans. Mais c'est comme pour les bagnoles, y a des limites à tes désirs.
Va essayer de demander à avoir des roues ovales parce que tu trouves ça super chouette, ou plus realiste, d'avoir un pare-brise super foncé parce que tu veux pas qu'on te voit, le constructeur/concessionnaire va gentillement t'expliquer que c'est pas possible, à cause de contraintes techniques ou légales. Si il accepte, c'est que c'est un constructeur/concessionnaire verreux et tot ou tard tu te fera avoir (problème mécaniques pour les roues ovales ou accident/amendes à cause du pare brise foncé)
C'est pareil pour un site web HTML/CSS. Y a des contraintes techniques. L'une d'elle est que le design au pixel près est IMPOSSIBLE, parce que c'est pas fait pour. Si tu lui dit "oui oui je le fais", au mieux, tu es un mauvais professionnel parce que tu sais très bien qu'au fond de toi ça va être dur et que ça va de toute façon pas passer dans pas mal de cas. Et au pire, tu es un professionnel malhonnete parce que tu fais croire à ton client que c'est possible et qu'il n'y aura pas de problème, alors que c'est faux. Et du coup, il va croire que ceux qui lui disent que ce n'est pas possible sont des menteurs etc..
bref, des attitudes comme celle que tu décris pourri le milieu professionnel du web, et entretien la mauvaise qualité générale des sites web.
>Quand ton client gagne beaucoup d'argent sur Internet, il serait présomptueux de vouloir lui apprendre son travail.
Gni ?
Si il te demande de faire son site web, c'est que ce n'est pas son travail. Lui son travail, c'est de faire vivre le site (ou pas), point barre.
Et si il prétend savoir que le pixel pres c'est bien, ba désolé, c'est toujours pas son boulot, même si il prétend que ça l'est, parce que dans ce cas cela montre qu'il n'a absolument rien compris à internet.
Et toi, si tu continue à penser que c'est à ton client de te dicter les details techniques, de comment il faut faire son site web : change de metier.
Toi, quand tu va faire reviser ta bagnole, tu vas dire à ton garagiste ce qu'il faut qu'il fasse, et comment il faut qu'il le fasse ? Non hein. Au pire, tu lui indiques qu'il se pourrait qu'il y ait un problème ici ou là parce que tu entend un bruit bizarre, ou des conneries comme ça.
Ben là c'est pareil. C'est pas à ton client de t'expliquer de comment il faut faire ton métier. C'est à toi de lui expliquer les choses, de lui faire comprendre pourquoi tu fais comme ci et comme ça, point. Et ça, c'est vraiment faire preuve de professionnalisme.
Très honnetement, si tu ne sais pas te faire entendre/comprendre, encore une fois, change de métier.
>Et ouais, mais des fois, ya pas grand chose a lire, c'est juste une plaquette publicitaire.
Et ? une plaquette publicitaire peut très bien s'adapter à un contexte de consultation précis. Inutile de vouloir du pixel près sur chaque type de navigateur.
> Mais comment fait pdf pour garder un rendu identique sur toutes les machines du monde si c'est impossible?
Le format PDF impose des dimensions à la page, a des rêgles strictes de présentation. Et pour cause, il est destiné à l'impression !
Le web n'est pas destiné à l'impression. Le web est déstiné à pouvoir être lu dans n'importe quelle circonstance, quel que soit le type de navigateur, le type de périphérique de sortie etc. Bref, une page web a la faculté (si elle n'est pas faite comme on fait du print) de s'adapter à la majorité des circonstances.
Tu parles de pixel. Le pixel n'est qu'une unité. Une indication. Qui est vite convertie par le navigateur. Il suffit que l'utilisateur zoom d'un cran, et ton pixel, tu peux aller l'oublier. Ton pixel n'est plus un pixel. Tout simplement parce que c'est ça le web : pouvoir adapter et transformer une page web en fonction des conditions de lecture et des besoins.
Et c'est d'autant plus vrai que la diversité des modes de consultations explosent, à cause de la diversité des mobiles entre autre.
>Va expliquer ca a ceux qui font des applis web style webmail ou autre, que leurs boutons ne vont pas etre alignes comme ils le veulent et autres joyeusetes.
Si ça ne s'aligne pas comme ils veulent, c'est qu'ils utilisent mal les technos du web. Je n'ai personnellement aucun mal à faire un design, fluide, liquide, qui s'adapte à bon nombre de circonstance, sans avoir à faire des hacks dans tout les sens pour tel ou tel navigateur. Et l'une des raisons du pourquoi je n'ai aucun mal : c'est parce que j'ai accepté l'idée de ne pas avoir un design identique au pixel près dans tous les contextes. (je te jure, une fois qu'on accepte cette idée, tout devient plus simple, puisqu'on s'enlève des tonnes de contraintes inutiles)
Et si tu expliques bien à un client le pourquoi du comment (en gros, les arguments donnés dans le lien que j'ai donné plus haut), il acceptera certainement ce fait, et sera même probablement très content que son site passe sur un maximum de navigateur même si il n'est pas identique au pixel près.
Au passage, ne pas avoir un design identique au pixel près, ça ne veux pas forcément dire un design moche dans telle ou telle situation. Faut juste oublier les habitudes du "print" sur le web.
Et pour finir : très franchement, je n'ai jamais vu d'internaute ouvrir un site sur plusieurs navigateurs en même temps pour vérifier qu'il est identique au pixel prés dans chacun d'eux. L'internaute il en a rien à battre. L'internaute il veut juste que ce soit lisible.
> Donc non il n'y a pas de gain de debit, taille ou qualité a attendre de la part de theora. Theora est un codec somme toute médiocre dont le seul avantage est d'être totalement libre.
c'est probablement le cas aujourd'hui.
Mais il me semble, d'après la news, que le financement de Mozilla est déstiné justement à améliorer tout ça ;-)
> Attends, le monsieur dit qu'il veut que la page rende comme elle doit etre rendre sur tout les navigateurs, ca me semble etre LE precepte de base du web
Absolument pas ! Le web n'est pas un media figé. Donc le "pixel près" est absolument incompatible.
Le principal pour un site web c'est qu'il reste lisible et agréable à lire. Qu'il soit équivalent au pixel près d'un navigateur à un autre, est absolument inutile, et impossible.
Ton discours est digne des soit-disant "web designer" du siècle dernier.
La transition est toute faite : utiliser un element object comme on fait d'habitude, à l'interieur d'un element video. Le navigateur qui ne connait pas video "executera" l'element object, et celui qui connait la balise video, est censé ignoré le contenu de cet element.
<video src="mavideo.ogg">
<p class="avertissement">Pour profiter au maximum de la vidéo et des possibilités de cette page web, vous devriez installer un navigateur récent : Firefox 3.1, Safari, ou Opera.</p>
<object>
<param name="movie" value="flvplayer.swf?file=mavideo.flv"></param>
<embed src="flvplayer.swf?file=mavideo.flv" type="application/x-shockwave-flash"></embed>
</object>
</video>
Pour en savoir plus http://ljouanneau.com/blog/post/2008/10/16/L-element-video
>ou de réaffecter une partie du personnel à la R&D.
hum... Dans le cas d'une entreprise automobile, j'aurai personnellement du mal à réaffecter tout ces ouvriers de la chaine de fabrication (actuellement les plus touchés par le chomage technique chez Renault) vers de la R&D...
C'est pas que je prend les ouvriers pour des abrutis. Mais pour la majorité d'entre eux, je ne pense pas qu'ils aient les bagages qu'il faut (connaissances, compétences...).
Et puis la R&D, ça coute. Et surtout ça ne rapporte rien directement et à court terme. Donc au niveau financement, c'est très très lourd.
M'enfin c'est toi qui voit. Y en a qui ont essayé. Ils ont eu des problèmes !
> <?=$variable?> marche bien en php, avec l'option "short_open_tag = On".
short_open_tag est deprecié il me semble. Ensuite, personnellement, je trouve que l'usage du <?(php) et ?> apporte de la confusion dans la lecture du source, avec les balises html.
Et globalement, tu tapes sur 3 touches de plus (ouai je chipote :-).
> Avec une coloration syntaxique c'est clair comme de l'eau de roche.
{$personnes|count} listée(s) :
{foreach $personnes as $p}
Nom : {$p->nom}, Age : {$p->age} ans
{/foreach}
avec ou SANS coloration syntaxique, ça reste clair comme de l'eau de roche.
;-)
enfin bon, là on en arrive à des question de gouts et de couleurs...
>Car au final, le mainteneur devra se familiariser avec tout un nouveau jargon, des nouveaux concepts et j'en passe,
Sauf si il connait déjà lesdits frameworks, moteur de templates et cie. Ce qui a de forte chance d'arriver si c'est un framework connu et pas mal utilisé dans l'industrie.
Alors que pour du "simple" code php (qui n'est jamais vraiment simple dès que le site devient conséquent), même clair, structuré et uniforme, bah c'est structuré différement à chaque projet, donc le développeur doit d'abord à chaque fois apprendre comment le site s'articule avant de pouvoir modifier le code metier à maintenir.
Donc, non, un développeur ne se "contente" jamais de maintenir un simple code PHP (sauf pour les sites de 3 pages).
Et le meilleur moyen d'avoir un code maintenable, c'est d'écrire du code selon des normes et des structures reconnus, c'est à dire, utiliser des frameworks, puisque tel est le but des framework: offrir une structuration (troll: ZF mise à part, puisque ZF n'impose pas de structure, et est plus une grosse lib dans laquelle on pioche qu'autre chose).
CQFD.
fais un tour en SSII, en demandant à bosser sur des missions courtes, de manière à travailler sur un maximum de projet, et là tu te rendra compte de l'intérêt des frameworks, et à coup sûr, tu pesteras sur les projets développé sans framework connu. Projets qui sont, forcément, vu que le boulot est toujours pour il y a deux jours, développé à l'arrache, donc souvent difficilement maintenable, alors que pour ceux avec un framework, les développeurs n'ont pas eu à passer du temps à réinventer la roue, et ont pu se concentrer rapidement sur le code métier, et ont donc un code naturellement plus structuré
bon, je dis pas non plus qu'il n'est pas possible de faire du super crad avec un framework, mais c'est déjà moins facile de faire du code crad avec un framework qui impose une structure que dans un projet sans framework.
# Précisions...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal XULrunner 1.9 est là. Évalué à 5.
Ceci dit, merci d'en avoir fait un peu de pub :-)
Et n'hésitez pas à aller sur les forums de xulfr.org (ou channel irc #xulfr sur irc.mozilla.org) pour poser toutes vos questions :-)
Pour ce qui est de l'avenir de XulRunner face à silverlight/adobe Air. C'est clair qu'on n'a pas le même rouleau compresseur marketing de MS et Adobe, et Mozilla préfère promouvoir les technos purement web que sa plateforme XUL (pour diverses raisons). Cependant, techniquement, XulRunner n'a rien à envier à Adobe Air. Deux exemples :
1) le Flex dans adobe air (qui est un XUL-like), n'est pas "dynamique" : on ne peut pas le changer à la volée, on ne travaille pas avec un DOM contrairement à XulRunner. Dans XulRunner, on manipule donc l'interface comme une simple page web.
2) Avec XulRunner, on peut intégrer n'importe quelle lib tierce et il y a un système de chargement dynamique de composant (XPcom). Adobe Air: rien de tout ça, vous êtes limités à l'API embarquée dans AIR.
Et je ne parle pas de l'extensibilité (cf système d'extension de Firefox) et de tout ce que propose XulRunner...
À noter que Firefox est une pure application XulRunner, et peut lancer des applis faites pour XulRunner.
[^] # Re: mouais
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 2400 sites incompatibles avec IE8 dont Microsoft.com. Évalué à 9.
Pour les drafts, tu exagères un peu. Un draft a quand même plus de chance de devenir un standard qu'un unofficial. Du coup, les mettre dans le paquet "non standard", c'est un peu aller vite.
Implémenter un draft, c'est pas plus mal : on s'aperçoit ainsi plus vite ce qui est implémentable de ce qui ne l'est pas. ça permet aussi de faire avancer plus vite la spec, puisqu'alors on détecte les parties floues de la spec (et qu'est ce qu'il y en a dans CSS2 !), ça peut aussi amener de meilleurs idées etc.. Et je te rappelle que pour qu'une spec devienne une recommandation au W3C, il faut qu'il y ait au moins deux implémentations. Alors si il y a déjà deux implémentations quand la spec passe de draft à candidate recommandation, le processus ira plus vite.
Bref, pour les drafts, je n'y vois personnellement pas de problème.
Pour les non official. Bah c'est bien d'innover aussi sans avoir à attendre après le W3C. C'est certes pas standard, mais pas forcément un "travers" comme tu dis car finalement, si tu suis bien, l'evolution de ces specs non standards (en majorité conçernant CSS dans la page en question) :
1) il y a une spécification publique quelques part, que tout le monde peut lire, commenter et implémenter. Ce n'était pas le cas dans les années 90 pour les extensions d'IE et de Netscape (oui, il n'y avait pas que IE qui avait des extensions propriétaires, Netscape en avait probablement plus d'ailleurs)
2) Toutes ces spécifications css non standards sont discutées entre les principaux éditeurs de navigateurs (et même au CSS Working Group), et c'est pour ça que ça commence déjà à être implémenté un peu partout
3) Apple (l'auteur de pas mal de ces specs CSS, comme CSS transition &co) commence à les proposer au CSS Working group, donc ça va peut être finir en standard un jour.
Enfin, pour finir, ces specs CSS non standards, c'est pas non plus un drame. Suffit de pas en abuser sur son site, ce manière à ce qu'il reste lisible sur des navigateurs qui n'implémentent pas ces styles.
Sur l'un de mes sites, http://jelix.org, je n'ai pas hésité à mettre des ombrages (box-shadow et cie), des transitions et transformations (boites inclinées). Parce que :
1) Ça m'amusait
2) Ça m'a évité de perdre des heures avec gimp ou autre pour faire la même chose en png/div dans tout les sens (versus une ligne de code CSS pour faire de l'ombrage), et évité de faire un truc à moitié accessible (faire des images pourles boites de contenu inclinées)
3) ça n'a pas d'incidence sur des "vieux" navigateurs, sinon que le design est un peu moins fun.
Bref, inutile de diaboliser ces nouvelles fonctionnalités qui débarquent, surtout conçernant CSS : ce n'est que de la présentation. Si ça avait été des balises HTML, ça aurait été un autre problème, car bien souvent ces balises apporte des fonctionnalités. Par exemple, utiliser uniquement la balise video est facheux, car cela empêche l'accès à du contenu dans la majorité des navigateurs (On peut toutefois l'utiliser à condition d'utiliser aussi une balise object à l'interieur pour proposer un format/player alternatif).
Le fanatisme sur les standards, c'est pas bon (et je sais de quoi je parle ;-) ). Soyons un peu pragmatique.
[^] # Re: mouais
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 2400 sites incompatibles avec IE8 dont Microsoft.com. Évalué à 2.
parce que ça avantagerai IE, qui l'implémente depuis la version 5.5 si je me souvient bien. Ce serait tellement dommage de lui faire prendre un point ;-)
[^] # Re: Au top de la modernitude !
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Debian Lenny 5.0 is out !. Évalué à 4.
[^] # Re: Au top de la modernitude !
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Debian Lenny 5.0 is out !. Évalué à 5.
Article complètement faussé.
à la question "What compile options did you use for Firefox?", ils répondent qu'ils n'ont rien compilé, et qu'ils ont pris la version de fedora, parce qu'ils veulent une version "standards".
Et là, ils perdent totalement en crédibilité. Parce que si ils avaient voulu vraiment faire jeu égale entre windows et linux, ils auraient utilisés les binaires linux fourni par Mozilla comme ils ont fait pour windows, et non pas par ceux de Fedora, qui eux, ont peut être des options de compil pas optimum, ou pas les mêmes versions de lib tierces. Je n'accuse pas Fedora, j'ai pas regardé, il est possible que ce soit pareil que le binaire officiel, mais le procédé que tuxradar a utilisé n'est finalement pas "honnete".
Bref, test à recommencer.
Ensuite, que dire que Linux n'est pas une priorité pour Mozilla est totalement faux. La majorité des devs sont sous linux (ou mac). Et crois tu qu'il y aurait autant de machines de test pour linux si ce n'était pas important pour Mozilla ? http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox3.1
1% de part de marché pour linux, 99% pour windows, mais ils consacrent plus de 40% des ressources pour linux. Proportionnellement parlant, ils tiennent donc beaucoup plus à Linux qu'à Windows.
[^] # Re: Bad design
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Bélier 0.6 : Outil d'automatisation de connexions ssh complexes. Évalué à 1.
C'est sûr que tu n'a pas de contributeurs anglais (et tu auras peu de chances d'en avoir), vu que c'est en français. C'est un peu comme faire un site qui a un script qui check le navigateur et n'accepte que IE, et dire ensuite que ce n'est pas la peine de faire un site compatible avec les autres navigateurs vu que dans les stats, ils sont totalement insignifiants. (c'est du vecu :-) )
Ensuite, en parlant de "contributeurs anglais": Le monde est vaste, les contributeurs peuvent venir de tout pays, pas seulement des états unis ou Angleterre. Et l'anglais est probablement la langue la plus "universelle" (surtout en informatique). Donc c'est pas seulement des contributeurs "anglais" que tu pourrais avoir ;-)
Bonne continuation dans ce projet tout de même :-)
[^] # Re: On n'est pas vendredi
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Python, langage de l'année pour la seconde année consécutive. Évalué à 2.
Bref, la comparaison entre Python et XUL n'a pas lieu d'être.
[^] # Re: On n'est pas vendredi
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Python, langage de l'année pour la seconde année consécutive. Évalué à 6.
Euh, c'est quoi le rapport avec un langage de programmation comme python ? Le XUL n'est qu'un format descriptif d'une interface utilisateur. Tu compares dont un format avec un langage. Très fort :-)
C'est certainement pas avec ça que je vais développer le moteur de rendu d'un browser (j'ai bien dit : moteur de rendu). à coup sûr, si je n'avais qu'à choisir entre XUL et python, je choisirais bien évidement python pour un projet comme ça, parce qu'avec XUL, je ne vais pas aller loin...
> certainement pas le fait que c'est interprété,
"interpreter" un fichier XML, c'est pas pertinent... Surtout que dans Gecko, le XUL n'est pas interprété, mais analysé et ensuite on travaille avec un DOM...
>qu'il n'y a pas d'éditeur dédié,
y a des plugins pour eclipse, y a Komodo...
> ni de tests unitaires normalisés,
Je ne vois pas ce que tu appelles "normalisés", mais il existe des outils pour faire des tests unitaires dans Mozilla.
>ni de compilation pour la vérification des types
hors sujet vis à vis de XUL
> encore d'équivalent de valgrind pour les fuites mémoires ?
Valgrind est utilisé dans le developpement de Gecko (même si il n'y a toujours aucun rapport avec XUL).
# On n'est pas vendredi
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Python, langage de l'année pour la seconde année consécutive. Évalué à 4.
Ouaouuu... Rien que ça. C'est totalement subjectif ça. C'est peut être la meilleur façon pour TOI. Mais sûrement pas pour tout le monde. Chacun a ses préférences, ses goûts en matière de langage. Personnellement, ce n'est certainement pas avec Python que je vais produire des logiciels maintenables et de qualité. Tout simplement parce que je n'aime pas trop Python. Et ça veut pas dire qu'avec un autre langage, je ne vais pas produire des logiciels maintenables et de qualité.
Et puis, en dehors des gouts et des couleurs, il y a aussi le fait que chaque langage a ses spécificités, qui lui permet d'être plus efficace que d'autres pour la réalisation d'un type de logiciel particulier. Ce n'est par exemple certainement pas avec Python que je vais m'amuser à faire le moteur de rendu d'un browser HTML...
[^] # Re: Editeur svg
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Sortie d'Amaya 11. Évalué à 2.
Euh, ça fait des lustres qu'il sait faire. Au moins depuis sa version 2. Et bien avant pour le XHTML+MathML.
[^] # Re: Google sabote Internet... avec la complicité de Mozilla
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal [HS] Attention, internet peut endomager votre ordinateur. Évalué à 3.
C'est pas du tout exclusif. Faut arreter la parano.
Pour le moteur de recherche, je te rappel que tu as le choix. Firefox est livré avec un certain nombre de moteur de recherche, et tu peux les supprimer, en installer d'autres. bref. Aucune exclusivité si ce n'est que Mozilla met en avant Google parce qu'ils ont un plus gros contrat avec eux qu'avec les autres (et que la cantine google est à deux pas et est très bonne :-))
Pour le service anti "sites pourris", c'est totalement paramètrable : about:config -> browser.safebrowsing.
Il t'embete ? tu le désactives (à partir de la boite des préférences ou dans le about:config). Tu veux en choisir un autre, tu renseignes les bons paramètres dans le about:config. Et si ça se trouve, il y a des extensions qui te permettent de configurer facilement vers d'autres fournisseurs.
Quant à ta liste de "Mozilla aurait pu", c'est facile à dire, il y en a qui ont refait le monde avec des "si". Et si pour chaque fonctionnalité qu'il y a dans Firefox, il fallait proposer un choix à l'installation, je doute que Firefox aurait eu le succés qu'il a. Et à mon avis, proposer le choix d'activer au premier démarrage n'aurait servi à rien, car pour 90% des gens, ils ne sauraient pas quoi répondre et activerait sans se poser de question (surtout si on leur dit que ça rend la navigation plus sûre).
>Le jour ou Mozilla voudra dire merde à google, google pourra envoyer des listes gonflées aux navigateurs utilisant ce service (majoritairement mozilla) pour planter la réputation de la fondation.
Mouai bof. Mozilla push une nouvelle version mineure de Firefox, avec des nouveaux paramètres de confs, et la majorité des installations n'utiliseront plus le service de Google. Et très franchement, je doute que Google fasse se genre de bêtise, sous peine de se prendre un procés aux fesses et une très mauvaise image (et contredire leur moto, "don't be evil").
[^] # Re: Google sabote Internet... avec la complicité de Mozilla
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal [HS] Attention, internet peut endomager votre ordinateur. Évalué à 5.
[^] # Re: Transition
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 1.
>Sauf que les roues ovales, si un concurent les propose je peut aller les acheter chez lui, et si je veux de roues ovales je vais pas aller acheter une voiture qui a des roues rondes ou carrée.
je serais curieux de savoir quel constructeur automobile accepterai de vendre des roues ovales. Très franchement ;-)
> Le problème c'est si tu dis au mec je peut pas faire un design au pixel près et que ton concurent le fais, eh bien il va aller chez le concurent.
Non, parce que je lui aurais fait (ou tenter) comprendre le pourquoi de la chose. Et si après ça, il comprend toujours pas, ben alors tant pis. C'est signe que de toute façon, lui et moi on va pas s'entendre, et donc vaut mieux arrêter là et répondre à d'autres demandes de client certainement plus intéressantes.
Et puis si je fonde mon activité sous le signe de la qualité, je n'ai pas intérêt à continuer avec ce genre de client, puisqu'alors je trahi mon engagement vis à vis ce que je propose comme prestation.
Et puis, peut être que le client va aller chez la concurrence, mais peut être aussi se rendra-t-il compte que son site n'est pas si top que ça, quand il verra le site de son pote ou de son concurrent s'afficher sans problème dans son iphone au contraire du sien, et pour peut-être pour un montant moindre...
[^] # Re: Transition
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 2.
Pour les mauvais professionnels, oui, c'est comme ça. Pour les bons, non, car ils ont compris ce qu'est le web, et arrive à faire comprendre à leur client ce qu'est le web.
>C'est chiant à faire : oui, mais c'est possible.
Non, c'est de la poudre au yeux. Je te ruine un design soit disant au pixel près quand tu veux.
>Et si tu pense qu'un professionel qui le fait est un mauvais professionel, et bien il doit pas y avoir beaucoup de bons professionels.
Bah oui, c'est ce que j'ai dit. Il n'y a pas beaucoup de bon professionnels en france, parce que peu veulent faire de la qualité, peu arrivent à faire comprendre (ou à faire vouloir comprendre) à leur client ce qu'est un site web de qualité, ce qu'est un vrai site web etc...
Si il n'y avait peu de mauvais professionnel, on serait pas à expliquer aux clients sans arret que le" pixel pret", c'est de l'utopie.
>Faut pas croire que le créateur de site aime faire ce genre de merdes, mais il n'a pas le choix.
On a toujours le choix. Faire de la merde. Ou pas.
> Si tu compare le Web de maintenant à celui d'il y a quelques année, au niveau du respect des standards ça à quand même évolué.
Ça je le reconnais. Et je me bats depuis plusieurs années pour que ça evolue justement. Ce ciombat porte ses fruits, mais manifestement, à la lecture de tes commentaires et d'autres, il faut continuer...
>Mais le marcher des petits écran par exemple est encore trop faible.
Ouai enfin, ça explose quand même hein. Tu es resté bloqué en 2003 ? :-)
> De même les gens qui changent la taille des polices représentent un très faible pourcentage du public.
Tu as des statistiques ? des vraies ? qu'en sais tu ?
Je dirais plutôt le contraire. Quand dans firefox on a changé la manière de zoomer, on a eu des plaintes (ou des remerciements) de toutes part. Preuve que le zoom est bien plus utilisé que tu le crois, mais alors bien plus.
Je ne suis pas handicapé visuellement (quoiqu'une legère myopie), mais ça m'arrive souvent de zoomer, parce que par exemple y a des webdesigners qui trouvent qu'une police de 6pt ça fait super top, que le design est à chier et qu'on voit mal le texte, ou parce que je veux voir les details sur une photo minuscule etc..
>Pour l'instant les client voient pas trop l'intéret de changer leur mode de fonctionement pour un public aussi marginal,
parce qu'ils sont justement mal renseigné, par des (mauvais) professionnels mal renseignés. Ce public dont tu parles est loin d'être marginal. Tout le monde est différent. Tout le monde ont des modes de consultations differents, des écrans differents, des navigateurs différents etc..
[^] # Re: Transition
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 1.
Bah, oui comme pour un site web. Ton client te demande comment il veux que son site ressemble, et ce qu'il veut dedans. Mais c'est comme pour les bagnoles, y a des limites à tes désirs.
Va essayer de demander à avoir des roues ovales parce que tu trouves ça super chouette, ou plus realiste, d'avoir un pare-brise super foncé parce que tu veux pas qu'on te voit, le constructeur/concessionnaire va gentillement t'expliquer que c'est pas possible, à cause de contraintes techniques ou légales. Si il accepte, c'est que c'est un constructeur/concessionnaire verreux et tot ou tard tu te fera avoir (problème mécaniques pour les roues ovales ou accident/amendes à cause du pare brise foncé)
C'est pareil pour un site web HTML/CSS. Y a des contraintes techniques. L'une d'elle est que le design au pixel près est IMPOSSIBLE, parce que c'est pas fait pour. Si tu lui dit "oui oui je le fais", au mieux, tu es un mauvais professionnel parce que tu sais très bien qu'au fond de toi ça va être dur et que ça va de toute façon pas passer dans pas mal de cas. Et au pire, tu es un professionnel malhonnete parce que tu fais croire à ton client que c'est possible et qu'il n'y aura pas de problème, alors que c'est faux. Et du coup, il va croire que ceux qui lui disent que ce n'est pas possible sont des menteurs etc..
bref, des attitudes comme celle que tu décris pourri le milieu professionnel du web, et entretien la mauvaise qualité générale des sites web.
[^] # Re: Transition
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 4.
Gni ?
Si il te demande de faire son site web, c'est que ce n'est pas son travail. Lui son travail, c'est de faire vivre le site (ou pas), point barre.
Et si il prétend savoir que le pixel pres c'est bien, ba désolé, c'est toujours pas son boulot, même si il prétend que ça l'est, parce que dans ce cas cela montre qu'il n'a absolument rien compris à internet.
Et toi, si tu continue à penser que c'est à ton client de te dicter les details techniques, de comment il faut faire son site web : change de metier.
Toi, quand tu va faire reviser ta bagnole, tu vas dire à ton garagiste ce qu'il faut qu'il fasse, et comment il faut qu'il le fasse ? Non hein. Au pire, tu lui indiques qu'il se pourrait qu'il y ait un problème ici ou là parce que tu entend un bruit bizarre, ou des conneries comme ça.
Ben là c'est pareil. C'est pas à ton client de t'expliquer de comment il faut faire ton métier. C'est à toi de lui expliquer les choses, de lui faire comprendre pourquoi tu fais comme ci et comme ça, point. Et ça, c'est vraiment faire preuve de professionnalisme.
Très honnetement, si tu ne sais pas te faire entendre/comprendre, encore une fois, change de métier.
[^] # Re: Transition
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 10.
Et ? une plaquette publicitaire peut très bien s'adapter à un contexte de consultation précis. Inutile de vouloir du pixel près sur chaque type de navigateur.
> Mais comment fait pdf pour garder un rendu identique sur toutes les machines du monde si c'est impossible?
Le format PDF impose des dimensions à la page, a des rêgles strictes de présentation. Et pour cause, il est destiné à l'impression !
Le web n'est pas destiné à l'impression. Le web est déstiné à pouvoir être lu dans n'importe quelle circonstance, quel que soit le type de navigateur, le type de périphérique de sortie etc. Bref, une page web a la faculté (si elle n'est pas faite comme on fait du print) de s'adapter à la majorité des circonstances.
Tu parles de pixel. Le pixel n'est qu'une unité. Une indication. Qui est vite convertie par le navigateur. Il suffit que l'utilisateur zoom d'un cran, et ton pixel, tu peux aller l'oublier. Ton pixel n'est plus un pixel. Tout simplement parce que c'est ça le web : pouvoir adapter et transformer une page web en fonction des conditions de lecture et des besoins.
Et c'est d'autant plus vrai que la diversité des modes de consultations explosent, à cause de la diversité des mobiles entre autre.
>Va expliquer ca a ceux qui font des applis web style webmail ou autre, que leurs boutons ne vont pas etre alignes comme ils le veulent et autres joyeusetes.
Si ça ne s'aligne pas comme ils veulent, c'est qu'ils utilisent mal les technos du web. Je n'ai personnellement aucun mal à faire un design, fluide, liquide, qui s'adapte à bon nombre de circonstance, sans avoir à faire des hacks dans tout les sens pour tel ou tel navigateur. Et l'une des raisons du pourquoi je n'ai aucun mal : c'est parce que j'ai accepté l'idée de ne pas avoir un design identique au pixel près dans tous les contextes. (je te jure, une fois qu'on accepte cette idée, tout devient plus simple, puisqu'on s'enlève des tonnes de contraintes inutiles)
Et si tu expliques bien à un client le pourquoi du comment (en gros, les arguments donnés dans le lien que j'ai donné plus haut), il acceptera certainement ce fait, et sera même probablement très content que son site passe sur un maximum de navigateur même si il n'est pas identique au pixel près.
Au passage, ne pas avoir un design identique au pixel près, ça ne veux pas forcément dire un design moche dans telle ou telle situation. Faut juste oublier les habitudes du "print" sur le web.
Et pour finir : très franchement, je n'ai jamais vu d'internaute ouvrir un site sur plusieurs navigateurs en même temps pour vérifier qu'il est identique au pixel prés dans chacun d'eux. L'internaute il en a rien à battre. L'internaute il veut juste que ce soit lisible.
[^] # Re: Youtube
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 1.
c'est probablement le cas aujourd'hui.
Mais il me semble, d'après la news, que le financement de Mozilla est déstiné justement à améliorer tout ça ;-)
[^] # Re: Transition
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 4.
Absolument pas ! Le web n'est pas un media figé. Donc le "pixel près" est absolument incompatible.
Le principal pour un site web c'est qu'il reste lisible et agréable à lire. Qu'il soit équivalent au pixel près d'un navigateur à un autre, est absolument inutile, et impossible.
Ton discours est digne des soit-disant "web designer" du siècle dernier.
Aller, hop, une petite lecture pour que tu ais une autre vision, plus réèlle, du web : http://www.pompage.net/pompe/tao/
[^] # Re: Transition
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 1.
[^] # Re: Transition
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 9.
<video src="mavideo.ogg">
<p class="avertissement">Pour profiter au maximum de la vidéo et des possibilités de cette page web, vous devriez installer un navigateur récent : Firefox 3.1, Safari, ou Opera.</p>
<object>
<param name="movie" value="flvplayer.swf?file=mavideo.flv"></param>
<embed src="flvplayer.swf?file=mavideo.flv" type="application/x-shockwave-flash"></embed>
</object>
</video>
Pour en savoir plus http://ljouanneau.com/blog/post/2008/10/16/L-element-video
[^] # Re: c'est beau le capitalisme
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal MS va supprimer 5000 postes. Évalué à 1.
hum... Dans le cas d'une entreprise automobile, j'aurai personnellement du mal à réaffecter tout ces ouvriers de la chaine de fabrication (actuellement les plus touchés par le chomage technique chez Renault) vers de la R&D...
C'est pas que je prend les ouvriers pour des abrutis. Mais pour la majorité d'entre eux, je ne pense pas qu'ils aient les bagages qu'il faut (connaissances, compétences...).
Et puis la R&D, ça coute. Et surtout ça ne rapporte rien directement et à court terme. Donc au niveau financement, c'est très très lourd.
M'enfin c'est toi qui voit. Y en a qui ont essayé. Ils ont eu des problèmes !
# le titre
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Carrefour et les licences liées. Évalué à 6.
"vente liée" par contre, ça correspond plus au sujet de ton journal ;-)
[^] # Re: Un moteur de templates est très utile
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal De l'utilité des moteurs de templates en PHP. Évalué à 1.
short_open_tag est deprecié il me semble. Ensuite, personnellement, je trouve que l'usage du <?(php) et ?> apporte de la confusion dans la lecture du source, avec les balises html.
Et globalement, tu tapes sur 3 touches de plus (ouai je chipote :-).
> Avec une coloration syntaxique c'est clair comme de l'eau de roche.
{$personnes|count} listée(s) :
{foreach $personnes as $p}
Nom : {$p->nom}, Age : {$p->age} ans
{/foreach}
avec ou SANS coloration syntaxique, ça reste clair comme de l'eau de roche.
;-)
enfin bon, là on en arrive à des question de gouts et de couleurs...
[^] # Re: Keep It Simple, Stupid
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal De l'utilité des moteurs de templates en PHP. Évalué à 1.
Sauf si il connait déjà lesdits frameworks, moteur de templates et cie. Ce qui a de forte chance d'arriver si c'est un framework connu et pas mal utilisé dans l'industrie.
Alors que pour du "simple" code php (qui n'est jamais vraiment simple dès que le site devient conséquent), même clair, structuré et uniforme, bah c'est structuré différement à chaque projet, donc le développeur doit d'abord à chaque fois apprendre comment le site s'articule avant de pouvoir modifier le code metier à maintenir.
Donc, non, un développeur ne se "contente" jamais de maintenir un simple code PHP (sauf pour les sites de 3 pages).
Et le meilleur moyen d'avoir un code maintenable, c'est d'écrire du code selon des normes et des structures reconnus, c'est à dire, utiliser des frameworks, puisque tel est le but des framework: offrir une structuration (troll: ZF mise à part, puisque ZF n'impose pas de structure, et est plus une grosse lib dans laquelle on pioche qu'autre chose).
CQFD.
fais un tour en SSII, en demandant à bosser sur des missions courtes, de manière à travailler sur un maximum de projet, et là tu te rendra compte de l'intérêt des frameworks, et à coup sûr, tu pesteras sur les projets développé sans framework connu. Projets qui sont, forcément, vu que le boulot est toujours pour il y a deux jours, développé à l'arrache, donc souvent difficilement maintenable, alors que pour ceux avec un framework, les développeurs n'ont pas eu à passer du temps à réinventer la roue, et ont pu se concentrer rapidement sur le code métier, et ont donc un code naturellement plus structuré
bon, je dis pas non plus qu'il n'est pas possible de faire du super crad avec un framework, mais c'est déjà moins facile de faire du code crad avec un framework qui impose une structure que dans un projet sans framework.