Ajout de HTML et JS dans le contenu

Faudrait mettre a jour le guide markdown a ce sujet d'ailleurs

Pas encore. Le but était de faire des essais sur quelques contenus pour avoir les retours des auteurs, lecteurs et valido. Parce que si faut changer de système après, ça fera beaucoup de contenu à mettre à jour.

Déjà quand la prochaine version du markdown sera mergé, et que le https sera forcé, ce sera temps d'en parler plus publiquement.

Est-il possible de placer deux fiddles l'un à côté de l'autre horizontalement ?

Probablement pas. Tente de mettre deux vidéo, c'est la même chose.

Si notre démo a besoin de faire une requête vers un domaine extérieur, c'est fichu ?

J'ai lu les messages précédents avant-hier et ai déjà oublié s'il était envisageable pour ZdS de servir des fichiers statiques pour les démos (autrement dit : héberger le fiddle).

Actuellement on a rien pour héberger.

Pour les requêtes je ne sais pas trop, je pense que ça doit pouvoir passer si ça reste en HTTPS.

Si c'est des fichiers statiques, qu'est-ce qui empêche de les balancer sur jsfiddle ? Au moins ça permet une interface cohérente d'un bout à l'autre du site…

Surtout qu'ils ont des CDN et des systèmes de gestion de charge largement supérieurs à ce qu'un membre classique de ZdS peut avoir…

Ça dépend de ce que c'est.

@viki : ils n'autorisent pas les requêtes vers un domaine extérieur.

Je ne peux donc pas contacter wss://demo.crossbar.io/ws (voir ici).

Je sais pas si ca repond a la question, mais dans une demo je pouvais inclure l'API google Maps sans souci.

En même temps les WS et les requêtes HTTP(S) ne fonctionnent pas de la même façon et il peut forcément y avoir des restrictions de domaine d'un côté comme de l'autre.

Après ZdS pourrait autoriser n'importe quel contenu d'iframe tant qu'elle est en mode sandbox, mais c'est quand même autoriser n'importe quel contenu externe, donc la porte ouverte à tout et n'importe quoi…

Après ZdS pourrait autoriser n'importe quel contenu d'iframe tant qu'elle est en mode sandbox, mais c'est quand même autoriser n'importe quel contenu externe, donc la porte ouverte à tout et n'importe quoi…

Et je pense que ce n'est pas le but actuellement. Il y a une PR en cours car jsfiddle supporte enfin le httpS. Du coup on va le forcer et ils s'afficheront bien pour tout le monde.

A partir de maintenant le but va etre de tester cette fonctionnalité sur quelques exemples. Le but est de tester, évaluer et avoir des retours. On verra ce que ça donne. Peut être que la conclusion sera qu'il nous faudra notre propre système mais a voir.

A noter que l'iframe généralisé : non jamais probablement. Le problème est qu'on ne contrôle alors plus du tout ce qui est publié. L'auteur peut, après publication et validation, changer le truc totalement. Avec jsfiddle on oblige d'utiliser une url avec la révision du code explicite. Du coup la mise a jour du code oblige a repasser en validation pour mettre a jour le markdown. Ça permet alors aux valido de vérifier que l'élément extérieur est toujours pertinent. Et ça c'est une bonen chose.

A court terme il n'y aura rien de plus que jsfiddle. On regarde déjà ce que ça peut donner sur quelques exemples choisis et ça nous permettra d'en tirer avantages et inconvénients. Et on adapatera a moyen terme. C'est pas pour rien qu'il faut demander l'activation du js manuellement à un staff/admin : c'est pour éviter qu'on ai trop de contenu qui l'utilise en période de test. Si on doit le virer, faudrait pas que tous les tutos soient bon a reprendre.

Si le websocket marchait pas, c'est effectivement parce que l'iframe n'était pas en HTTPS, alors que le websocket était sur une connexion sécurisée (d'où le wss:// ) ; c'est le navigateur qui n'autorise pas ce genre de truc. Si maintenant on affiche l'iframe de jsfiddle en HTTPS, ça devrait régler le soucis

@Vayel: Si c'est des websocket, "wait and see" de base ce n'est pas bloqué par le navigateur contrairement au HTTP, où le navigateur demande Access-Control-Allow-Origin: *

Désolé pour mon incompréhension, mais il me semble que le problème provient de JSFiddle, qui ne permet pas les requêtes vers un domaine extérieur. Par exemple, ce fiddle ne fonctionne pas. En regardant dans la console, on lit : "Use POST request instead.".

Merci !

Bah peut être, je ne connais pas jsfiddle mais Eskimon a réussi a faire communiquer jsfiddle et Google map donc ça doit bien être possible

ouais mais ca utilisait des trucs "classiques" (http[s]), je sais pas si jsfiddle supporte tout…

Perso j'ai pas de problème sur le jsfiddle que tu cites (avec Chrome). La preuve en image

J'ai eu des erreurs au premier chargement à cause d'une extension (µBlock) qui empêche l'accès à certaines ressources externes par défaut. Mais une fois désactivée c'est tout bon à priori…

Oui mais c'est plus un problème de jsfiddle que de zeste de savoir. La meilleure chose que je peux te proposer c'est de faire un sujet sur le forum pour ton problème avec jsfiddle et de noter dans un coin les limitations de jsfiddle pour le jour où on devra faire le bilan.

Ca semble marcher pour moi aussi, je rentre bien dans le cas de "onmessage" et jamais dans "onerror". Mais comme dit le fantome, tout ca c'est lie a jsfiddle, pas a ZdS

Il fonctionne ton JSFiddle. Et je ne vois pas de raison pour laquelle il ne devrait pas fonctionner.

De plus, "Use POST request instead" ça ne me dit rien du tout comme erreur "standard" d'un navigateur quelconque. J'ai pas mal bricolé avec les websockets et j'ai absolument jamais vu ça, et j'ai pas l'impression que grand monde non plus. `

T'utilises quel navigateur ?

J'ai l'impression que c'est un message que te renvoie le serveur websocket. Qui grosso modo te dit "oula je comprends rien à ce que tu m'envoies dans la websocket, passe par du Http classique stp".

EDIT : escaping d'URL dans le md, je pensais qu'il le faisait tout seul ? j'ai du craquer.