Discussion :

[charlycoste]

Mozilla qui dit vouloir œuvrer pour un web de qualité...

Ca fait des années qu'on a toutes les peines du monde à expliquer aux commerciaux et graphistes qu'une application web doit être utilisable sans javascript et sans flash!

Des années aussi qu'on essaye de trouver en même temps comment faire... (puisque personne ne se donne la peine de chercher des méthodes efficaces de développement)

A chaque fois, on favorise le développeur "Jean-foutre"!

Celui qui va se contenter de développer sur le navigateur le plus répandu à la date "t".

Pour tous ceux qui fixent leurs tailles de polices en pixels, on avait déjà intégré par défaut des zooms vectoriels infectes qui sont catastrophiques pour l'expérience utilisateur et qui masquent complètement le travail des bons développeurs.

Maintenant, on masque jusqu'à la possibilité pour l'utilisateur de se conformer aux recommandations du CERTA

Que l'on permette au premier gus du coin de faire du web, OK. C'est ça toute la force du web! Sa simplicité et le fait que n'importe qui peut commencer un jour à développer un site.

Mais de grâce! Arrêtez de mettre des bâtons dans les roues des développeurs consciencieux! Ou on finira bientôt par perdre tout envie de faire du web interopérable et accessible.

[Paul TOTH]

il serait plus intelligent de proposer des extensions "moz" au CSS, voir au HTML qui permettent de se passer de Javascript

au pif comme ça ce qui me vient à l'esprit:
- style css:onError
- attribut html required, numeric, date etc... (ça existe +ou- en HTML5 mais peu supporté par les navigateurs)
- une source de données sur un SELECT : <SELECT HREF="options.php"/>

bref des choses qui nous simplifies la vie sans avoir recours à du code JS

[phili_b]

Mozilla qui dit vouloir œuvrer pour un web de qualité...

Ca fait des années qu'on a toutes les peines du monde à expliquer aux commerciaux et graphistes qu'une application web doit être utilisable sans javascript et sans flash!

C'est quoi l'alternative ? C'est une vraie question. (Je ne suis pas spécialiste en la matière)

Autant on peut se passer de flash mais mais pour tout ce qui est jeux et vidéo à part le HTML5 il me semble qu'il n'y a rien. Ah si il y a sans doute le java en mode client mais je doute que ça soit plus secure. Mais bon c'est spécifique. En tout cas on en est revenu des sites fait complétement en flash (et complétement débile on est bien d'accord: j'ai vu récemment un site d'une micro ssii écrit complétement en flash avec d'ailleurs une charte déplorable, bonjour l'exemple). En plus c'était encore plus la mode alors que l'ADSL n'avait pas décollé.

Mais pour le javascript c'est pareil c'est une question de mesure. Autant je suis contre les pages qu'on ouvre avec des kilomètre de lien vers des bibliothèques entière de javascript, autant des exemples comme ceux de pmithrandir il y en a des centaines.

Le mieux effectivement serait de continuer à proposer le choix mais je n'aime pas les non-choix unilatéraux dogmatiques. Par exemple je suis à fond pour l'open source mais je suis contre les gens qui veulent abattre les logiciels propriétaires. Après je suis le premier à dire, dans mon domaine les bases de données et la BI, tel et tel truc ne doit pas se faire, on ne fait jamais ça.

Mais comment répondre aux centaines de petits tracas dont pmithrandir a donné un exemple ? Comment faire en sorte de pas reposter la page pour le moindre changement de données de la part de l'utilisateur ?

[charlycoste]

Mais comment répondre aux centaines de petits tracas dont pmithrandir a donné un exemple ? Comment faire en sorte de pas reposter la page pour le moindre changement de données de la part de l'utilisateur ?

Deux solutions:

1. Utiliser un autre protocole. HTTP n'est pas un protocole à état. On utilise bien des sessions, mais le protocole n'a pas vocation à faire des GUI. Comme son nom l'indique c'est un protocole de transfert de documents hypertextes (=> du type HTML mais pas uniquement). En gros les sites web qui agrègent des contenus en temps réel sont des aberrations en terme d'architecture technique.

2. Faire un client lourd qui se connecte en web service. Là tout est autorisé en terme d'interface puisque chacun peut installer celle qui lui convient. Et le site web n'est plus un site web mais une plateforme de service. Elle peut alors toujours utiliser du HTTP comme protocole mais éventuellement un protocole plus adapté (à condition que les ports utilisés ne soient pas bloqué par des firewall)

Le soucis actuel avec Javascript, c'est que les développeurs n'ont aucune formation sur l'aspect théorique. Combien de développeurs web on déjà lu les spécifications du HTTP et du HTML? A l'heure actuelle, l'apprentissage ne se fait qu'en se basant sur de l'existant. Les jeunes développeurs web copient donc ce qu'ils ont vu soit en codant des clients lourds soit ce qu'ils ont vu dans des sites à succès (qui sont rarement des modèles de conception)

Le fait est que le HTML a été conçu de façon à permettre au plus grand nombre possible de terminaux d'accéder à des ressources. Un terminal n'est pas forcément un PC sous Windows avec IE ni même un PC sous Ubuntu avec Firefox. Cela peut être aussi un robot d'indexation, cela peut être une plateforme de test fonctionnel, cela peut être une console braille pour les mal-voyant, mais cela peut aussi être un périphérique que l'on n'a pas encore inventé.

Le format le plus universel et le plus interopérable est le format texte et le HTML n'est en fait que du texte structuré. Vouloir utiliser des balises HTML avec une approche purement graphique en ne les considérant que comme de simples calques dénote d'une ignorance de ce que permet ce format.

Je conclurai par une simple métaphore idiote dont j'ai l'habitude:

Imaginez un immeuble de 20 étages avec ascenseur mais sans escalier. Et imaginez que l'architecte vous dise: "les escaliers c'est has been! Si vous ne voulez pas utiliser l’ascenseur retournez à l'âge de pierre!"

Posez-vous la question: "est-ce que ce sera lui qui se retrouvera bloqué si l'ascenseur tombe en panne?"

[phili_b]

Deux solutions:

1. Utiliser un autre protocole.
[..]

2. Faire un client lourd qui se connecte en web service.
[..]

Le soucis actuel avec Javascript, c'est que les développeurs n'ont aucune formation sur l'aspect théorique.[..]

Moi qui vient de me remettre, pour ma culture pour l'instant, aux IHM mais sur internet en regardant le php, javascript (Jquery pour être précis) je ne comprends vraiment l'architecture n-tiers majoritaire que maintenant. En fait ma dernière expérience en IHM date de 2001 en client serveur avec Delphi. Et donc en fait je suis d'accord avec toi que les pages html sont des vraies usines à gaz en comparaison de ce que je connaissais avec le client serveur en mode lourd. (Je me suis spécialisé en BI où je ne créés pas de clients, j'en utilise mais ils sont peu interactifs ce sont des rapports. Sinon quand je créés des bases de données je ne suis qu'en back office finalement).

N'empêche que même si sur le plan théorique tu as 100% raison, tes propositions ne sont pas utilisables actuellement car ça voudrait dire qu'il faudrait changer tout les navigateurs. Penses à IE6 qu'on a eut un mal fou à enterrer.

Sinon c'est une idée les web services, d'ailleurs c'est ce qui tend à être fait sur les mobiles si je ne m'abuse.

Le format le plus universel et le plus interopérable est le format texte et le HTML n'est en fait que du texte structuré. Vouloir utiliser des balises HTML avec une approche purement graphique en ne les considérant que comme de simples calques dénote d'une ignorance de ce que permet ce format.

Je n'ai pas tout de suite compris cette phrase mais en regardant le reste de ton message je comprends mieux. Je me demandais pourquoi tu n'aimais pas le HTML mais je préfère dans un monde intéropérable comme l'est internet un format ouvert que l'espèce de HTML-word que microsoft a essayé de nous refourguer à un moment, ou pire des formats binaires.

Mais en fait ce que tu me dis c'est que tu n'as rien contre le HTML mais qu'il doit rester pour du mode texte. Mais le souci c'est que les pages web actuelles n'ont plus rien à voir avec les années 1990. Je veux dire: comment répondre aux demandes des concepteurs non techniques des pages (les vendeurs, les journalistes, les créateurs de blogs) qui veulent des pages moins austères. Ben pour l'instant on a fait évoluer l'existant puisque l'HTML (et javascript) était le seul disponible.

D'accord avec les web services, mais en revanche je suis plus que dubitatif sur les clients lourds. Si cela a été abandonné c'est à cause des problèmes de déploiements. L'autre souci est qu'ils étaient trop dépendants de la puissance de la machine.

Autant ça peut se résoudre dans le monde de l'entreprise en remettant éventuellement des clients lourds, mais pas facilement pour le déploiement, autant sur la toile je ne vois pas comment on pourrait promouvoir un retour du client lourd. Sans parler des problèmes de sécurité: l'architecture actuelle n-tiers permet l'utilisation d'une machine virtuelle indépendante de l'OS si j'ai bien suivi).



Est-ce que HTML5 répondrait en partie à tes desideratas ? Je ne connais pas du tout ses fonctionnalités.

[charlycoste]

D'accord avec les web services, mais en revanche je suis plus que dubitatif sur les clients lourds. Si cela a été abandonné c'est aux causes des problèmes de déploiements. L'autre souci est qu'ils étaient trop dépendants de la puissance de la machine.
...
Est-ce que HTML5 répondrait en partie à tes desideratas ? Je ne connais pas du tout ses fonctionnalités.

Et ben à vrai dire... C'est ce qu'on me disait il y a 6 ans pour justifier l'utilisation de flash. Genre l'utilisateur ne saura pas installer un logiciel sur son ordinateur (pourtant ils sont suffisamment nombreux à savoir installer e-mule pour tuer l'industrie de la musique, nous dit-on)
Mais de nos jours que fait-on quand on installe une appli sur son ibidule ou sa tapette tactile? Bah... On installe un client lourd! (Qui n'est généralement qu'un navigateur web avec une URL pré-configurée parce que les utilisateurs ne sont pas assez doués pour entrer une URL dans leurs bookmarks)

C'est étrange quand même? Cette capacité qu'à l'utilisateur à devenir soit doué soit débile en fonction de si ça arrange le commercial ou pas.

Par ailleurs, concernant la puissance de la machine... Foutre des animations à deux balles avec un langage interprété, je ne suis pas sûr que ce soit plus performant qu'un client utilisant les éléments natifs d'un OS. :p

Le HTML5 c'est un peu un autre débat. Je serais heureux de te donner mon avis en apparté, mais dans cette conversation ça risque de virer au troll.

[Celelibi]

Je veux dire: comment répondre aux demandes des concepteurs non techniques des pages (les vendeurs, les journalistes, les créateurs de blogs) qui veulent des pages moins austères. Ben pour l'instant on a fait évoluer l'existant puisque l'HTML (et javascript) était le seul disponible.

Ce n'est pas parce qu'à un instant t les technologies sont limitées qu'il faut les hacker pour faire rentrer les besoins dans ces technologies à coup de tournevis, marteau, pied-de-biche et spéculum.

D'autres voies sont possibles et bien plus adaptées aux besoins actuels. Je pense notamment que le modèle smartphone / tablette est une bonne base qui mériterait simplement d'être raffinée.

D'accord avec les web services, mais en revanche je suis plus que dubitatif sur les clients lourds. Si cela a été abandonné c'est aux causes des problèmes de déploiements. L'autre souci est qu'ils étaient trop dépendants de la puissance de la machine.

Tout à fait. Au moins avec le web, on s'assure que tout le monde ait une bête de course pour faire tourner un navigateur.

[Celelibi]

Pour moi c'est simple :
Tout langage Turing complet est à bannir des navigateurs pour des raisons de sécurité.
Y'a déjà bien assez de trous de sécurité par ailleurs.

Et d'une manière générale, je pense que tout ce qui dépasse d'une page web simple n'a rien à faire sur le web. (Rien que le nom "application web" me donne des boutons.) L'internet c'est beaucoup plus que du web, alors pourquoi le restreindre au web et essayer de faire rentrer toutes les applications du monde dans un navigateur à coup de pieds de biche ?

Quand je vois webGL, ou des trucs à la con pour faire du P2P entre navigateurs, je me dis qu'on nage en plein délires... On est simplement en train de réinventer dans un navigateur ce qu'un OS sait déjà faire.
Intérêt : 0.

C'est quoi l'alternative ? C'est une vraie question. (Je ne suis pas spécialiste en la matière)

Autant on peut se passer de flash mais mais pour tout ce qui est jeux et vidéo à part le HTML5 il me semble qu'il n'y a rien.

Ma réponse est simple et péremptoire (donc forcément forcément à nuancer dans une certaine mesure) : Si t'as besoin de flash, c'est que tu t'es trompé de technologie, le web n'est pas pour toi.

Bon, après, c'est vrai que les sites à la youtube c'est un peu limite. Mais je pense pas que flash soit la réponse, c'est beaucoup trop lourd pour la tâche gourmande en calcul qu'est la lecture de vidéos. Une meilleure réponse est de laisser l'OS lire la vidéo. Après tout, c'est l'OS qui sait exploiter la carte graphique. Éventuellement, le navigateur peut servir d'intermédiaire...
Ah mais j'y pense, c'est déjà ce qu'on faisait en 2000 avec des plugin.
Et aujourd'hui, HTML5 permet de faire ça de manière bien plus "intégrée" et standard.

[Beatrice78]

Sous Chrome, il y a un plugin très pratique "Quick Javascript Switcher" pour pouvoir débrancher le Javascript sur une page qu'on visite. Ça sert occasionnellement, par exemple dans le cas de lightboxes qui se déclenchent inopportunément à l'ouverture de la page... Et ça a l'avantage de n'être actif que sur l'onglet en cours et de pouvoir se remettre en un clic.

[lilington]

je suis d'accord avec charlycoste,
http n'est pas fait pour ca a l'origine. et un navigateur de devrait pas faire tourner des applications web.
Mais c'est pas vraiment la faute aux developpeur mais plutot aux utilisateurs qui veulent avoir des TOUT en 1 par paraisse de lancer une autre application.
Mais bon firefox a raison si ils veulent avoir plus de part de marcher ca passe par relirer la charge de travail et de securite du niveau utilisateur pour la metre du cote developpeur.
On le sait tout l'utilisateur un une feignasse (sans ironie).

[laclac]

Je suis tombé par hasard sur l'article mais je vois que les conclusions de l'origine de la suppression du blocage du javascript sont érronées.
Je me permet donc d'apporter un correctif.

Cette suppresion n'est en rien lié à la gestion de l'html 5 et du javascript.
En effet, il n'y a aucune remonté indiquant qu'un site n'est plus fonctionnelle suite au déblocage du clique droit ou de la réécriture de de la barre d'état.

En faite, le financement de Firefox est fait en très grande partie par google. Ce partenariat n'est pas gratuit et en echange Mozilla s'engage a inclure du code pour son partenaire: moteur de recherche pas défaut, utilisateur de antiphisign de google, introduction des balises propres à Google etc...

Vu que Google sert en ce moment la vise, il demande plus.
On notera récemment que l autorisation es cookies tierces sont activés par defaut (indispensable pour la publicité de google). Désormais c'est la gestion du javascript que google demande de supprimée.

En effet, vous avez jamais remarqué que la désactivation de la réécriture de la barre d'état fonctionne sur tout les sites sauf sur google.
Ex: l'url suite à une recherche indique en barre d'état "www.exemple.com" alors qu'une fois cliquez dessus vous avez "www.google.com?url=www.exemple.com".
Très utile à google pour identifier les sites sur lequel vous cliquez suite à une recherche.

Voilà, inutile donc de chercher la cause là ou il n'y en a pas. C'est juste une question de politique.

Bonne journée