Reprise du message précédent :

C'est quoi l'intérêt du lien là?

source pls

http://diveintohtml5.org/semantics [...] le-element

C'est très bien niveau sémantique tout ca.. mais niveau référencement ca va plus foutre la merde qu'autre chose.. au niveau "poids" des H1 / H2 / H3, si y en a partout dans la page..
 
enfin je suppose qu'il faut faire confiance aux moteurs de recherches pour que leur indexation sacher  "discriminer" les H1 les plus importants d'une page..  

 
fancybox n'a pas de constructeurs style new fancybox() ...., obligé de cliquer sur un lien pour creer une fancy, donc un lien caché, "cliqué" automatiquement par jquery

C'est hiérarchiser : le H1 d'un article n'aura pas le même poid que le H1 de la page s'il y en a un. Et je pense qu'on peut faire confiance aux moteurs de recherches pour gérer correctement ça.

 
Comme plein de popups du genre, c'est bien chiant.

http://blog.jaysalvat.com/articles [...] search.php
hep les jeunes, comment je détecte qu'un browser supporte le type search ?

edit: bordel c'est supporté par chrome et chrome est vu comme un safari dans les tests d'UA naïfs, c'est pour ça que le style marchait toujours sous chrome et moins bien sous FF

http://diveintohtml5.org/forms.html#type-search
 
tu crées un input type="search" en JS et tu vérifies s'il a bien le type search en sortie (et non text)? (pas testé, mais je me dis que ça a pas de raison de pas marcher)
 
Ou alors tu crées ton input en type search, et quand tu hook tes évènements dessus tu regardes s'il a bien le type search en question ou pas.

tu peux me faire la version slow-learner stp ?
comment je "vérifie en sortie" ?
 
comment je "regarde" au moment du hook ?

(nan, chuis un peu teubé mais ma maman elle m'a dit qu'elle m'aimait quand même )

Ouais du code de merde quoi

Bah quand tu sélectionnes ton input en JS pour y mettre ton évènement (genre pour y binder onsearch), tu regardes quel est son type, si c'est bien search tu bindes onsearch, si c'est text ou rien t'as pas de support de input[@type='search'] donc tu bind sur un autre évènement.

Après faut test si les navigateurs n'implémentant pas input[@type='search'] ne le laissent pas en type juste pour faire chier.

Question JS/DOM, quand vous remplacez des sections de pages dynamiquement via js (avec ou sans lib/framework), vous êtes plutôt "je reçois du json et je génère tout mon DOM sur le client" ou "je reçois le HTML tout fait, j'ai plus qu'à insérer ça dans mon DOM et à hooker mes évènements"?

j'aurais tendance à dire "ça dépend" de rien
 
(de la lourdeur du json vs l'html au transfert, du type de données, et si t'as déjà un truc qui fait la mise en page coté server, t'as ptet pas envie de te faire chier a reproduire la meme chose en js/dom)

 
Le html tout fait ça va quand même fichtrement plus vite que de monter un dom à la main à partir du json (bon, tu peux aussi recevoir du json et templater un string d'html qui vient d'ailleurs cela dit), si coté serveur tu peux proprement avoir ton chunck d'html dans un template quelque part pas loin du template de la page qui va le contenir, je partirais plutôt sur la solution html.

DOM si c'est vraiment simple ou que ça touche à des endroits éparpillés (ce qui correspond à la plupart des cas en fait), HTML si c'est des vrais bouts de page (je vois même pas l'intérêt de générer en DOM dans ce cas).
 
Le HTML étant souvent inclus dans un objet JSON qui contient d'autres trucs.

Tout le monde est donc d'accord avec ce que je pensais, merci les filles

edit: omglolz, jQuery.load, c'est même pas drôle

Je reçois du json    
Dans le cas ou je fais du Ajax ya pas photo je renvoie toujours du JSON, je trouve ça plus clean que le controlleur balance juste les données, sans aucun lien avec la présentation

HTML5 video + canvas = ambilight  
http://chikuyonok.ru/ambilight/

Moi je prends du HTML parce que ça prend moins de temps et moins la tête à coder
 
J'ai une exception où je reçois du JSON, mais c'est parce que le contenu m'indique si je veux activer certains éléments cachés de ma page

c'est ouf O_o

En js, il va etre possible de jouer directement avec la vidéo

de ce que je comprends du code , tu copies une image de la video comme si tu copies une image depuis une autre :

http://dev.opera.com/articles/view [...] and-audio/

hep les jeunes, un service REST "normal" ça va marcher partout, ou il faut toujours wrapper certaines méthodes dans des entêtes HTTP à cause de certains proxys/navigateur ?

 
 
Sur les derniers projets c'était :  
- Je recois tout en JSOn, j'ai un fichier XML qui contient mes templates HTML avec des endroits style $$_vararemplater$$ (ou bien en utiliser JSDT du célèbre masklinn)
- Et ensuite je génère tout à coup de innerHTML.
 
Ca c'est surtout quand tu te sert de tes données JSon pour faire du traitement coté front, là je recois une liste de voyage que je doit trier/filtrer et ensuite afficher que les voyages correspondants, donc cette méthode est parfaite.
 
J'ai envie d'essayer une autre méthode, mais je ne sais pas trop si ça passe sous IE6.
- Récupération des données en XML
- Récupération d'un template en XSLT
- Transformer le XML en Objet JS pour faire les traitement.
- Appliquer la XSL en lui balancant les paramètres qui vont bien.
 
Ce n'est que théorie pour l'instant
 

Et ça se rouvre à chaque fois qu'il repasse par la page d'accueil ou bien une seule fois ?  

La classe, le web inspector des versions trunk de webkit intègre même un yslow de qualité
 
Genre il te dit que tes inclusions de CSS et script sont pas dans le bon ordre, et que tu te retrouves avec des loadings de fichiers js qui empêchent de charger des fichiers CSS

aïe, mon pentium M 1.6 s'est mis en grève suite à la lecture de cette vidéo

déjà que le flash, ça pompe, mais alors ce genre de truc en js, voilà l'usine à gaz

enfin cela dit, ça promet pour le futur

j'avais aussi vu des démos d'un français bossant pour mozilla (assez connu je crois, très geek sur les bords) c'était plutôt sympa les possibilités de la balise vidéo, genre pouvoir rendre des pixel de la vid transparents etc...

edit: marche beaucoup mieux sur chrome, m'enfin le cpu est quand même pied au planché

il fait quand meme, en temps réel des extractions de frames de la video

Google FTW
http://code.google.com/intl/fr-FR/ [...] chart.html

 
ptain oué sur chrome mes deux thread sont a 90 et 20%, ça fait 110% d'utilisation cpu  
 
toute façon l'ambilight en full screen !a sert a rien  

Bon les garçons, j'ai un problème que tous les experts ont sûrement déja rencontré.
 
J'ai un site A qui m'appartient, avec une base d'users.
 
A côté il y a un site B avec une autre base d'users (80000).
 
Les users du site B, actuels et futurs, doivent pouvoir se logger aussi sur le site A.  
Et sachant que ce site A est un site marchand, et pour le bien des statistiques, il faut qu'ils soient un minimum enregistrés en dur sur ce site A, au moins quand ils se sont loggés 1 fois.
 
 
Il y a des méthodes classiques pour ce genre de cas, des buzzwords à connaître ?

à propos, qqun a regardé s'il y avait du neuf de ce coté là avec Safari 4.0.5 ? (pas encore pris le temps de rebouter pour updater)

SSO

Sachant que je n'ai pas la main sur le site B, au fait

 
Ça veut dire que c'est à toi coté A de demander au gars ses identifiants sur B puis te connecter de A à B avec ces identifiants pour les valider et récupérer les infos (puis demander celles dont t'as besoin en plus, et namespacer dans ta base pour distinguer les users A-natif et A-de-B pour pas avoir de conflit d'identifiant).

 
(tant qu'a faire, z'auraient pu le faire à coup de canvas, mais bon...)

la led rouge: http://code.google.com/apis/accounts/ bonne lecture générale. jette notamment un oeil sur OAuth, je crois.
(après, bah ouais, va falloir causer au gars de l'autre site hein )

Namespacer, comment ? Et pourquoi ça limiterait les conflits, il faudrait changer les logins en leur collant un préfixe ?
 
De toute façon pour ça, on va passer à une identification par email, ça limite les conflits...