Reprise du message précédent :

Je vais protéger le truc en lecture et en écriture de toute façon, donc a priori pas de pb pour ça...

 
Tu peux optimiser la lib en choisissant que les composants qui t'intéressent (comme pour mootools) : http://extjs.com/download/build
Moi pour l'instant je me fais pas chier je prends la version complète à 499ko Une fois gzippée elle fait plus que 134ko
En testant vite fait leur système de build, je crois que je peux descendre à 200ko non compressés.
 
C'est quoi tes besoins ?
 
Pour mes arbres simples avec peu de données je fais en <ul><li> avec un js de quelques lignes et une CSS kivabien pour avoir un rendu arborescent avec plier/déplier.

Dans HTML5 j'vois pas où t'as vu du XML

En l'occurence, le HTML5 n'est pas impérativement sérialisé en XML.

C'est pour avoir des combos (imagine des dropdown éditables? Ben voila, c'est ça)

La gestion d'erreur super utile du XML, que quand t'as une erreur, ben tu peux te foutre au cul ton accès au contenu, ce qui est génial du point de vue de l'utilisateur final

C'est bien ça que je critique, a priori.

Oui ça j'avais compris

Justement, je critique ta critique, si Berners-Lee avait décidé d'utiliser du XML, le web n'existerait pas
 

On a qu'à faire un XML plus permissif, comme c'est déja le cas.
Fin c'est surtout que je trouve le xhtml plus propre/carré à lire... C'est tout ske jen dis

C'est moi où l'html5 essaye de se placer comme un successeur de l'html4 et de l'xhtml1.x (possibilité de faire des <img ... /> ) ?
Par contre je n'ai pas trouvé d'indication sur l'obligation (ou l'abscence d'obligation) de respecter les règles du xml (obligation de mettre le slash quand il n'y a pas de balise fermante correspondant à une balise et interdiction de faire chevaucher des couples de balise).

la grosse merde du web c pas tellement les langages, c'est le protocole...http c'était très bien au début, simple, a permit un gros essort du web...
 
mais maintenant, c'est surtout une perte de temps énorme...
 
pensez à la quantité de code qu'on doit écrire pour contourner le simple fait que c'est pas un protocole connecté...(gestion de session, emmerdements quand tu veux rafraichir une seule partie de ta page (usine à gaz d'ajax), etc...)

 
Si c'est pas de la bonne balle ça    
 

bon les experts, si je valide les URLs de mes utilisateurs avec la syntaxe des URI, personne m'en voudra ?

Ca devrait aller pour cette fois

C'est parce que t'es pas obligé. Le "HTML5" peut être sérialisé soit en HTML soit en XML, avec les règles relatives à chacun.
 
L'avantage du HTML5, c'est surtout que la spec (normalement) donne clairement le comportement en cas d'erreur, ainsi que les algos à implémenter quand il y a des calculs & autres à faire, de manière à ce que tous les navigateurs aient les mêmes réactions normalisées au lieu  que la gestion d'erreur soit laissée au choix de tout un chacun.

Bof. C'est aussi l'un des protocoles les plus efficaces en terme de scaling, justement parce qu'il est déconnecté. Et les plus gros problèmes surviennent quand on tente d'utiliser une logique connectée avec un protocole déconnecté (et qu'on a pas les outils pour, il parait que Seaside marche bien)

L'ajax, à part les trucs type Comet ça n'a aucun rapport avec le fait que le HTTP soit déconnecté

Pour l'instant, j'ai pas de besoin clairement spécifié ou alors j'ai déjà un bout de soluce. C'est juste pour préparer la suite et avoir une bonne lib de widgets sympas tout browser.
Maintenant, 134 Ko gzippé c'est bof (site perso sur le Net avec potentiellement des users ayant une ligne de merde type 64K/128K), donc je verrai une install morcelée si je dois l'utiliser

en parlant de ça, j'aime bien ce qu'à fait yui avec son "on demande delivery".
Voir cet article ou c'est tout bien expliqué: http://www.wait-till-i.com/2007/12 [...] on-demand/
 

Si, c'est à cause du X devant.

Ouais ça s'appelle du HTML.

Mais ça se place comment par rapport au frameworks genre prototype, mootools etc? C'est un complement, c'est autre chose, ça fonctionne avec ou sans ?
 

et dieu inventa le cache
 

meme q qu'a ratibus

Ca vient en paquet, mais il me semble qu'il existe une version fractionée, et niveau code c'est pas énormissime. par contre c'est pas testé.

C'est complémentaire si tu utilises déjà un de ces frameworks.
Par contre ça peut les remplacer si t'en as pas déjà.
+ de détails ici : http://extjs.com/learn/Ext_FAQ#Wha [...] run_Ext.3F

Pas forcément : http://yuiblog.com/blog/2007/01/04 [...] ch-part-2/
Du coup ça dépend de ton public aussi. Si t'as tjs les mêmes users qui reviennent, pas de souci. Si ton audience c'est des gens qui viennent qu'une fois ben faut faire gaffe. Et je parle pas des users qui désactivent le cache

ouais c'est sur que si c'est un site evenementiel d'une page... mais je vois pas bien ce qu'un arbre ferait la dedans
et ceux qui désactivent le cache euh, ben, tant pis pour leur gueule

pas testé: tu veux dire par toi ou en general?

Et de toutes façons ils adorent les grosses images et le flash dans l'événementiel.

un truc que je pige pas :
 
le html4 c'est vieu et pouri
on a évolué vers le xhtml tout propre
 
maintenant on voit des mecs reflechir sur XHTML2 et d'autre sur HTML5 ..?
mais pourquoi est ce que c'est pas le meme projet? c'est debile non ? vu que le xhtml est l'amelioration naturelle du html, pourquoi pas direct crée le xhtml5 all-in-one!
 
DamnIt

hep les gens, comment je centre horizontalement une div dans une autre ? genre un float:center quoi ...

En mettant sa marge gauche et droite en auto (et text-align:center dans le bloc parent si tu veux que ça marche dans IE6).

merci.

Parce qu'il parait qu'en fait html 4 c'était pas vieux et pourri

A mon avis c'est bien testé
C'est de la bonne came ExtJS

 
je n'evoluerai pas vers le xhtml . C'est tres joli en théorie, mais pete couille dans le monde réel  
 
je préfère servir du html 4 valide , que du XHTML invalide

ok merci

ok, perso je dois avouer que j'ai commencé directement en xhtml quand je me suis mit au developpement web.. donc.. je suis pas tres objectif..
 
Je vais me renseigner sur le html4 mais en gros c'est quoi les différences?
html4 a plus de balises?
html4 est moins chianr / restrictif ?
html4 ca veut dire codé en tableau?
ca veut dire le style en inline ?
pas de css?
 
je sent que je caricature grandement mais bon c'est vendredi demain

Y'a pas de tests fourni avec la release

Hey, en fait, dès qu'on fait un truc, même super bon sémantiquement, mais avec des display:none et du javascript pour afficher ces display:none, ce truc est-il considéré comme accessible, puisque les lecteurs d'écran listent le display:none mais pas le js ?

Perso tous mes XHTML stricts sont valides et sans peine

 
bha pour me cpup je fais le contraire..
 
Tout ce qui a besoin d'etre en display:none  est par defaut en visible.. c'est le JS qui les display none au plut tot.. et remplace par ma sauce
 
donc du coup sans JS le site est quand meme parfaitement lisible

Et du coup t'as pas un 1/10 de seconde où tout est affiché ?

Merci du tuyau
137 Ko à choper pour un ou deux composants pour un gars qui a une ligne pourrave comme celles que j'évoquais plus haut, ça fait méga-chier à la première connexion J'ai déjà jQuery à trimballer (genre 15-20 Ko) donc bon, si y a moyen d'alléger tant mieux ; c'est ce que disait ratibus en-dessous, donc j'essaierai certainement le truc mais je vais voir en fonction de mes besoins et du coût. Si la première connec du gars doit lui coûter 200 Ko, on essaiera de le faire autrement

Après tu peux feinter en chargeant tout ce qui peut servir en tache de fond sur la homepage, du coup sur les autres pages les JS seront déjà en cache car requêtés sur la homepage.
Yahoo fait un truc comme ça sur leur moteur de recherche quand tu commences à taper une recherche ils chargent les JS/images qui sont normalement chargés sur la page de résultats
http://ajaxian.com/archives/yahoo- [...] precaching

 
Ouais mais ca reste discret, je fais pas ca sur une div qui fait 2 tiers du site quoi.. Et puis ca reste leger comme inconvenient si on veux rester accessible et qu'on a pas trop le choix de faire autre chose

ça c'est certain, mais bon, on pourrait imaginer un mode hybride où le designer d'une page peut forcer un mode connecté si ça lui sert
 

ça a à voir avec HTTP malgré tout, et la structure en requete ==> réponse qui te renvoit un doc entier...ce qui signifie un refresh de ta page entière, y compris des éléments inchangés

 
en vrai je crois que le sgml c est encore plus chiant que le xml
 

 
ce qui etait censé faire la force du xhtml c et tout un tas de modules dont personne ne s est jamais servi a part deux/trois barbus au fond d une cave qui avaient reussi a se facher avec leur copines en jpg et qui faisient passer le temps
du genre avec le module math t as ca  

tu fous ce bloc n importe ou dans ton body et le module vient avec son set de balises
tu peux creer toi meme tes propres modules mais il faut trifouiller les dtd
bref du xml pur et dur  
a vomir
 

ca c est la seconde chose qui fait du xhtml une merde sans nom
je suis persuadé que t as jamais pondu un xhtml valide vu que ca passe pas sur ie

Ils sont envoyés en application/xhtml+xml?

Faire des chunks, c'est rarement la partie la plus difficile d'une ajaxification, quand même...

C'est beaucoup plus chiant à parser mais beaucoup plus simple à écrire.

Par contre je sais pas comment est la gestion d'erreur en sgml