"The purpose of ASK is to offer you a simple way to get content into your page on-the-fly through asynchronous JavaScript and XmlHttpRequest, without sacrificing accessibility or usability"
Ce qui peut se traduire par: « L'objectif de ASK est de vous offrir une solution simple pour actualiser votre page à la volée en utilisant Javascript et XmlHttpRequest, sans pour autant perdre en accessibilité ou en utilisabilité »
En effet, de plus en plus de sites se mettent à la mode « 2.0 » et sacrifient divers aspects :
- Gestion des bookmarks ;
- Gestion des fonctions suivant, précédent, rafraîchir ;
- Accessibilité de certains navigateurs ;
- Accessibilité pour les clients n'utilisant pas Javascript.
Il suffit de surfer quelques temps avec l'extension NoScript de Firefox pour vite s'apercevoir que tous les webmaistres n'envisagent pas le minitel 2.0 du même point de vue.
ASK est donc une manière élégante et légère (8 Ko) d'implémenter l'Ajax sur votre site, tout en limitant les sacrifices d'accessibilité.
NdM : la licence est précisée en entête du script. L'auteur a précisé qu'il n'avait pas approfondi la question de la licence et qu'il n'avait rien contre changer pour une licence open-source si cela avait un intérêt. D'autre part, l'intégration de ASK à votre site est relativement simple. Il suffit de :
- Inclure ask.js dans votre page: ;
- Ajouter deux choses aux liens que vous souhaitez faire agir dynamiquement :
- La classe CSS ask ;
- La classe CSS target-idOfTargetElement, où idOfTargetElement est l'ID de l'élément de la page que vous souhaitez mettre à jour
Un exemple de lien utilisant ASK, qui présentera le contenu dynamiquement dans l'élément target :
Get countries
ASK présente les fonctionnalités et restrictions suivantes :
Navigateurs supportés :
- IE 5+
- Firefox 1.0+
- Safari 1.2+
- Opera 8+
La fonctionnalité d'historique ne fonctionne pas avec les navigateurs suivants :
- IE 5.0
- Safari
- Opera 8.0, pas du tout. Dans Opera 8.5+, le comportement n'est pas stable à 100% avec le bouton 'suivant'.
La fonctionnalité de bookmarking ne fonctionne pas avec les navigateurs suivants :
- IE 5.0
Chapeau bas à l'auteur, Robert Nyman, qui en plus propose d'autres scripts intéressants :
Aller plus loin
- ASK (4 clics)
- Release notes (1 clic)
- Robert Nyman (1 clic)
# lien enrhumé
Posté par ZeroHeure (site web personnel) . Évalué à 3.
le lien n'est pas complet, ça ne marche pas!
voici le vrai: http://www.robertnyman.com/ask/content.php?continents=true&a(...)
Apparemment, ça marche bien avec Konqueror (3.5.8) aussi.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: lien enrhumé
Posté par superna (site web personnel) . Évalué à -2.
[^] # Re: lien enrhumé
Posté par ZeroHeure (site web personnel) . Évalué à 5.
l'historique ne marche pas avec Safari, en revanche il marche avec Konqueror.
Ce n'est d'ailleurs pas très surprenant: Konqueror évolue en permanence tandis que Safari ne change qu'avec les nouvelle versions de MacOSX.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: lien enrhumé
Posté par Temsa (site web personnel) . Évalué à 2.
Il ya de vrais grosse différences entre les 2. Surtout niveau "chargement" (tout ce qui se passe en gros avant le "onload").
En fait même Safari 3 entre la version Mac et Windows il y a des différences. Archetype semblerait ne pas fonctionner sur la version Mac (néanmoins on a très peu d'informations et pas de Mac pr debugger :'( ) alors qu'elle fonctionne comme un charme sur la version Windows.
Sinon, personnellement je préfèrerais que les gens se concentrent sur l'intègration de moteur javascript (spider monkey, rhino ...) dans les navigateurs "accessibles" pour l'accessibilité plutôt que de se limiter dans ce qu'il font, alors qu'à part le chargement javascript, les applications peuvent facilement être accessibles ...
Pour moi arrêter de faire du javascript car les navigateurs accessibles ne le supportent pas est débile :/
P.S.: Je suis d'ailleurs tout à fait pret à aider un projet dans ce sens s'il en existe ! ;)
[^] # Re: lien enrhumé
Posté par fyah . Évalué à 2.
J'ai ouvert une entrée dans le système de suivi pour cela:
https://linuxfr.org/tracker/685.html
pour résumer: a chaque fois que l'on post un message sur dlfp, on passe le contenu du message 'à la moulinette'(tm) (boutons vérifier, valider).
Cette moulinette à l'avantage de supprimer toutes les balises que l'on ne souhaite pas et c'est très bien. Cependant, si je souhaite écrire une balise interdite en tant que texte, j'utilise alors les codes html des caractères, ainsi la balise n'est pas reconnue.
Le problème c'est que les caractères encodés sont décodés par la moulinette, et donc interprété au deuxième passage (validation)...
donc par exemple, pour réussir à afficher cette balise script, j'ai du la reéditer après l'étape de vérification pour remplacer les balises par leur code html correspondant juste avant la validation.
<script type="text/javascript" src="js/ask.js"></script>
# Amélioration possible
Posté par Infernal Quack (site web personnel) . Évalué à 2.
En fait, j'avais pensé qu'en indiquant comme class "ask target-bidule" pour un lien, il allait récupérer via AJAX (XmlHTTPRequest) le résultat de la requête et qu'il allait dans ce résultat récupérer le contenu de la balise d'identifiant "bidule" pour la remettre dans la balise d'identifiant "bidule" de la page. Et ensuite j'ai découvert que dans content.php il y avait des "if" pour afficher ou non le contenu selon ce qu'il y avait dans la requête et si on était ou non en mode AJAX :(
Vous allez me dire "Mais à quoi ça sert d'envoyer tout le contenu pour en récupérer juste un bout ?". A cela je réponderais : "Pouvoir profiter simplement d'une des fonctionnalités offerte par AJAX sur des applications-webs dont il serait coûteux de toucher au code : le non-rechargement de la page".
En effet, en indiquant via "target-bidule" les zones que l'on veut récupérer, cela permetterait d'éviter des rechargement inesthétique de page. Ok on dépense autant de bande passante, mais ce n'est pas incompatible avec une mise à jour futur du code où à l'appel d'une requête on filtre le contenu selon la requête pour n'envoyer que le nécessaire. Bref, on profite des fonctionnalités d'AJAX en 2 temps : d'abord le non-rechargement, ensuite si on a le temps de toucher fortement au code de la réduction des échanges.
Le pied serait aussi de pouvoir avoir plusieurs target : class="ask target-bidule target-machin" avec le parsing qui va bien.
Sinon, je vois qu'il manque le support des requête en POST, c'est à dire la soumission des formulaires. Dommage car ce n'est pas rare d'en trouver. Cela pourrait se faire via la gestion d'évènement sur les onSubmit car beaucoup d'applications-webs utilisent du javascript pour soumettre les formulaires au changement d'une zone via onChange par exemple.
Si quelqu'un développe mon idée concernant un parsing via DOM au retour de la requête pour mettre à jour uniquement les targets, je lui offrirais mon plus grand respect :)
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
# C'est ça le progrès!
Posté par ome . Évalué à -3.
[^] # Re: C'est ça le progrès!
Posté par Victor . Évalué à 3.
[^] # Re: C'est ça le progrès!
Posté par wismerhill . Évalué à 8.
Et les personnes déficientes moteur n'ont qu'à apprendre à pointer avec la langue, la navigation au clavier c'est un truc du siècle dernier!
[^] # Re: C'est ça le progrès!
Posté par ome . Évalué à -1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.