Reprise du message précédent :

 
Désolé, je pensais que tu avais suivi le topic depuis quelques jours.
Donc, le framwork c'est prototype, l'arbre c'est tafeltree, et pour les events c'est les observes de prototypes.

J'ai trouvé ça :

http://www.brucelawson.co.uk/

Et dans le source y'a ça :

<!--  hack to make IE able to apply CSS to elements that it doesn't usually know about. See http://remysharp.com/2009/01/07/html5-enabling-script/ -->
<!--[if IE]>
<script type="text/javascript">
(function(){if(!/*@cc_on!@*/0)return;var e = "abbr,article,aside,audio,bb,canvas,datagrid...video".split(','),i=0,length=e.length;while(i<length){document.createElement(e[i++])}})();
</script>
<![endif]-->

Donc j'ai dis une bétise plus haut, IE n'interprete pas n'importe quelle balise.

C'est quoi cette merde

Bref monitor tes éléments, il me semble que Prototype leur crée des propriétés avec les Events qui vont bien. Regarde s'ils existent toujours après le D&D

 
C'est le seul treeview prototype que j'ai trouvé...
Et là j'ai un truc überlol, je n'arrive pas à avoir le focus dans mes inputs contenus dans mon arbre

http://blog.gigaspaces.com/2008/08 [...] -in-sales/

annevankesteren.nl, mais il utilise encore plus de SVG, donc le haut est pêté même sous Firefox, ça passe correctement sous opera
 
Et google ne permet pas de chercher le doctype html5, vu qu'il dégage les caractères de ponctuation

Nah.

Oh ! un svg qui ne sert à rien et qui pourrait être avantageusement remplacé par un gif

Pourtant faut en vouloir pour fucker une mise en page aussi bateau. Et pourquoi utliser des SVG de logo alors que des PNG feraient tout à fait l'affaire ? C'est le genre de type à mettre un fond beige et à utiliser des png transparent en 3 couleurs juste pour montrer qu'IE6 ne sait pas gérer les PNG

 
Il prend le focus avec un clic droit

Sûrement pas, faudrait du PNG/32, le truc est bourré de transparences

Pas spécialement non. Faut juste ne tester à aucun moment dans MSIE, avec un bonus de facilité si tu utilises des sélecteurs CSS2

Bien sûr, ça aide si tu t'amuses: http://intertwingly.net/blog/2008/ [...] ist-Markup

Parce que le SVG est moins lourd, parce qu'il crée ses SVG directement et serait obligé de les rasteriser pour sortir du PNG et ensuite de les lier au document, et parce que les SVG sont inline (directement intégrés au markup), ce ne sont pas des images séparées. MSIE ne gère pas les url data, ça ne s'afficherait donc pas mieux.

Ah, et parce que Sam Ruby est un fort supporter de SVG, aussi.

edit: et ça permet aussi d'avoir tous les logos en high res, et d'intégrer des liens (y compris multiples) directement à l'image.

Je sens que je vais pouvoir recommencer ce putain de tree avec mif et mootools...

Ah c'était ça l'avertissement
M'enfin j'ai juste recopier

 j'ai juste récopier un script js qui trainait

 
glandu
 
XaT

Je ne peux même pas dire de tester Mif Tree pour le moment vu que je ne peux pas télécharger

Chuis d'accord avec mareek perso
 
Et pourtant il fait tout son possible pour empêcher un tel évènement

putin, 10 plombes que je cherche comment sont fait des includes ... Je viens de découvrir l'utilité de la fonction __autoload qui était devant moi depuis le début \o/
 
noob powa

Bah perdu du coup. Surtout que t'as l'avantage d'avoir le contenu inline donc pas de requête HTTP en plus.

En l'occurence tu n'économise pas de requête http:

#nav:after {
content:url(/img/daddy);
display:block;
margin:20px 0 0 -15px;
}

Quelqu'un à une estimation sur la sortie de CSS 3 et sa prise en charge par les navigateurs (Firefox et IE) ?

Cette question n'a aucun sens.

Les personnes qui m'ont conseillée Mif Tree pour mootools, vous tournez avec la dernière version ?
 
Parce que semble y avoir un problème, hormis le fait que rien n'est précisé quant aux fichiers JS à inclure pour faire tourner les exemples, j'inclus mootools, tout mootools more et le js complet de mif (toutes les options du builder cochées), et il me sort que "Parent.child is undefined"
 
J'ai tenté de télécharger tout le zip pour voir, rien ne va dans les exemples offline

Le contenu de ce message a été effacé par son auteur

Ce qui ne veut pas dire qu'elle a un sens, dans la mesure ou elle assume des choses complètement incorrectes.  

Le contenu de ce message a été effacé par son auteur

Si on me le demande uniquement

Le contenu de ce message a été effacé par son auteur

Ne nous précipitons pas, je me refuse à interpréter les écrits insuffisament clairs

2 problèmes:

1. Inclure MSIE dans la demande. Si tu inclus MSIE, faut pas tabler avant 2038
2. "la sortie de CSS3" n'a pas de sens, parce que contrairement aux CSS1 et CSS2(.1), "CSS3" n'est pas une spec mais un ensemble de modules complètement indépendants ou presque (sélecteurs, text, text layout, cascade, line grid, fonts, background & borders, ... il y a plus d'une 20aine de modules différents en tout). Certains de ces modules sont prêts (sélecteurs) ou pas loin, d'autres sont tout juste démarrés, et rien n'empêche d'utiliser le module sélecteurs avant que le positioning ne soit finalisé.

Ca se voit bien quand on regarde les tables de compatibilité: dans la majorité des navigateurs "prochaine génération" (FF 3.1, Safari 4, Chrome 2, Opera 10) les sélecteurs CSS3 sont largement implémentés (:nth-child() étant le seul tendant à vraiment poser des problèmes) et il y a des morceaux de déclarations implémentés (habituellement variant d'un navigateur à l'autre donc il est difficile de les utiliser). Donc il est possible d'utiliser les CSS3 maintenant si:

• Tu te fous de MSIE (ou tu n'y accordes en tout cas pas une importance majeure), tu peux te lacher sur les sélecteurs CSS3, ne serait-ce qu'en augmentation des sélecteurs CSS2 (supportés par IE8 et permettant déjà des trucs funky)
• Tu veux utiliser des effets pour améliorer tes pages dans les navigateurs le supportant (text shadow, multiple background, rounded corners) sans que ça soit primordial au styling du site

 
Et si j'ai bien compris les discussions récentes, c'est le gros intérêt de cette méthode par rapport aux specs monolithique, on parlait pas de HTML5 dans ce cas de figure ?

Nope, HTML5 n'est pas modularisé (à ce que je sache, certains voudraient pêter la spec en morceau pour séparer les bouts) c'est une spec monolithique et assez énorme. Mais, et c'est important, HTML5 est composé de 2 (ou 3? ou 4? ou 5?) efforts séparés (bien que joints dans la même spec, ceux que les gens de la parenthèse d'avant critiques):

• Standardiser et fixer la gestion d'erreur du parsing HTML, entre autres en spécifiant intégralement de quelle manière ça doit être parsé et comment gérer les erreurs (à noter d'ailleurs que HTML5 est un langage à part entière, séparé de XML et de SGML), en tenant en compte dans cette spec la manière dont c'est géré actuellement
• Standardiser les éléments propriétaires ajoutés aussi bien à HTML4 qu'au JS et au DOM (innerHTML, XMLHttpRequest & stuff)
• Dégager complètement les éléments dépréciés en HTML4 (center, font, ...)
• Ajouter des éléments, contrôles et attributs pour rendre le markup plus sémantiquement précis, et plus flexible (nav, section, footer, @async, email, ...)
• Ajouter (ou standardiser, cf 2) des APIs orientées "webapps" au DOM pour permettre plus de flexibilité et un codage des webapps plus haut niveau côté client (Drag&Drop, édition de documents, offline storage)

Et donc comme expliqué dans les parenthèses précédentes, certains voudraient séparer les différentes "parts" de HTML5 pour avoir d'un côté le cleanup et la standardisation de l'existant et de l'autre les évolutions, afin de ne pas avoir à implémenter les évolutions

http://blog.seanmartell.com/2009/0 [...] or-mobile/

J'arrive pas non plus à avoir le focus dans mes inputs avec le mif tree

C'était bien un bug de la librairie.

Vous pensez quoi du websock de html5?
 
genre: kaazing
 
perso    
 

Comme indiqué dans la doc de mootools , faut inclure mootools, core et more, et lancer les trucs dans le window.addEvent('domready', function() {/* ici */});

Tel quels ? Pas eu de pb perso, ma version date d'y a 6 mois.

Après les gens ici ils ont bcp tendance à conseiller [je sais plus quel autre tree de je sais plus quelle lib].
Avec lui t'aura ptet plus de gens pour t'aider.

ça doit être marrant de spécifier comment gérer qqch qui n'est pas conforme à la spécification
 
BTW, si les navigateurs avaient été moins permissifs on en serait pas là

La doc de mootools qui parle de mif tree

Regarde mon post précédent, c'était bien un bug de la librarie.
Et d'ailleurs je trouve ça merdique parce que si je n'avais pas demandé c'était inutilisable.
M'enfin tafltree ou miftree, même combat...

on serait pas là tout court :

Non, elle parle de mootools et miftree c'est un plugin mootools

De ce que j'ai vu de tafltree, faut ptet pas déconner

J'ai pas trouvé de référence à mif tree dans la doc mootools

Je suis passé à mif tree pour régle rmon problème de focus sur les inputs.
Or, j'ai exactement le même problème, donc ça avance pas mon merdier

Bah c'est le principe de la gestion d'erreur

Clairement, il n'y aurait pas de web

j'ai dit qu'y en avait pas mais c'est le mm fonctionnement pour n'importe quel outil mootools.

alors essaye [je sais plus quel autre tree de je sais plus quelle lib] que tlm a tendance à conseiller ici.
=> extJS

Après ça vient pas forcément du plugin

D'ici la fin de mon stage j'aurai fait toutes les fw existants, testé tous les tree, pour, je le sens, rien...
 
Ah, faut que le tree ait du d&d aussi.