Reprise du message précédent :

Shinuza essaye de t'expliquer que faire de longs chemins CSS est limite inutile.

Avec ce code :

.header .form-search  sont complètements inutiles puisque tu limites l'utilisations de .search-autocomplete, tu ne peux pas le mettre ailleurs.
Alors surtout que .search-autocomplete pourrait être utilisé ailleurs que dans header. En plus tu allourdis la CSS pour rien.
Pire encore, si tu dois sur styler ton UL tu devras écrire un sélecteur CSS encore plus long.

Autre chose tu utilises des classes pour des éléments uniques et surtout des éléments du corps de page :
.main, .header, etc...

C'est parties là tu leurs colles un "id" et ça ne se discute pas.

Et tiens cadal :
http://hfr-rehost.net/http://www.s [...] s-05v2.jpg

Non mais moi j'ai tout à fait compris ce que me dit Shinuza.

Et j'ai déja donné mon avis sur ça : nécessité de foutre des classes partout et de réfléchir aux nommages de trucs one-shot, CSS pas super compréhensible à mon goût, pas bcp plus factorisable, entre autres.

C'est le code de Magento que tu commentes là, pas le mien

Ceci étant : moi j'aime bien cette notation car rien qu'en regardant le CSS, je sais de quoi il s'agit, où c'est, et où c'est susceptible de se trouver. Même pas besoin de mater l'HTML pour restyler le truc, et pas besoin de fouiller toutes les pages des fois qu'un autre .search-autocomplete s'y trouverait.

je connais

Anyway je pense pas que tu aies plus envie que Shinuza d'entendre mon point de vue, et moi j'ai bien compris le vôtre je crois, donc je pense vraiment qu'on peut s'arrêter là.

Donne moi ton point de vue, car j'ai pas lu tout le topic, j'ai pas le temps en ce moment, je passe mes journées à la maternité

C'est fait, en synthèse, dans le post auquel tu réponds
 
En gros :
Quand un truc est pas factorisable : je cible de façon compréhensible, à l'aide des noms de balises et de classes "adjectifs" au besoin (nav.main section.hopital li.presentation (éventuellement #main_nav à la place de nav.main))
Quand un truc est/devient factorisable : je vire le ciblage et je le rend dispo partout (.styley-button).
 
Comme ça quand je regarde le CSS je vois de suite ce qui est utilisé à plusieurs endroits, et ce qui est du one-shot, et dans ce cas où est ce one-shot. Et j'ai pas à gérer des collisions imprévues.
 
Les inconvénients : c'est long, et probablement moins performant sur des gros docs.
 
Féloches au fait.

c'est quoi la bonne pratique ces temps-ci pour les favicons ? http://pouet.com/favicon.ico ou bien un meta ? ou toujours les deux ?

Perso je me contente d'un <link rel="shortcut icon" href="mabellleimage.truc" />, et ça fonctionne...j'ai jamais cherché plus loin.

D'accord avec shinuza, j'ai du reprendre un site qui utilisait de très longs sélecteurs pour n'importe quel éléments, c'est d'une merde à modifier putain. Au final les CSS sont à chier, incompréhensibles et ultra redondant entre elles, et tu passes des heures à ne serait-ce que surchargé la moindre propriété.

voilà, c'est super vite pète-couilles quand il te faut l'arborescence complète des éléments au-dessus de celui qui t'intéresse pour comprendre où faire des modifs dans la css, au lieu d'avoir directement l'info en voyant quelles classes sont appliquées à l'élément que tu veux modifier.

Ca c'est pas dû au principe de ciblage. Si le mec sait pas factoriser et cible n'importe comment c'est un autre pb.

Après pour surcharger, bah faut utiliser la même méthode...

Un des deux au pif. Firefox et Chrome tapent /favicon.ico quand rien n'est indiqué. Tu peux rewrite vers ton CDN ou passer par des métas

BySlideMenu v2.1 : http://jsfiddle.net/ByScripts/DzNGQ/
 
Now featuring auto-slide.
 
(Si mon spam vous emmerde, dites-le ... j'en parle ici uniquement parce que j'aime bien montrer ce que je fais pour avoir des retours )

c'est classe et je pense pas que ça emmerde qui que ce soit, ça change des débats stériles

+1

 
Niquel, dans pas mal de plugin, le code HTML est moisi, et tout se gère à partir d'injection js, donc bon...  
Toi tu as fait un truc très sémantique et très simple à maintenir donc c'est top !
 
Continue comme ça y a des tonnes de plugins à développer pour MT

Marki pour vos messages bien motivants

Alekusu2> Du genre ?

Petite question :
 
Est-ce que ce genre de code est encore valide :  
 

 
Ou est-ce que ce sont des techniques has been ?
 
D'habitude j'utilise du fullcss, mais là je dois faire une carte des régions, et vu la forme parfois nimportequoi de certaines régions, ça me fait des zones qui empiètent énormément sur d'autres... Chiant qu'en CSS on puisse pas faire autres choses que des formes rectangulaires... (sauf erreur de ma part)

Avec beaucoup de forme rectangulaire, mais surtout de la patience, tu peux faire une liste.
Mais bon, le temps que cela doit prendre…
http://winstonwolf.pl/css,europe.html#

Ca marche pas sous safari

Chez moi cela fonctionne, mais tous les pays ne sont pas actifs

Oui, <map> est encore valide en XHTML, HTML 5 etc

Pourtant ça me parait super dégueux comme code

Mais ya rien d'autre de portable pour faire ça, donc ils ont gardé
 
Et pis bon, c'est pas forcément juste un artifice de présentation, donc ça me parait pas totalement con de garder ça en html. En attendant SVG je suppose ?
 
Après c'est plus les mouseout/mouover répétés qui sont dégueu.

Toi tu n'as jamais utilisé une Map area. C'est ce qu'il y a de mieux quand tu veux rendre une zone "polygonale" d'une image clicable.
Et quand tu survoles la zone, une tu as la région qui change de couleur.
Ce genre de map tu trouveras ça sur ebay.fr ou leboncoin.fr
 
Et ya rien de dégueulasse. A part les event placé en dur mais encore ça c'est pas non plus sale.

T'es pas sympa, j'utilisais ca très souvent dans les années 90 après j'ai toujours tout pu gérer avec les formes rectangulaires, et je pensais que depuis il y avait eu une nouvelle technique pour remplacer les maps area mais non

Hep les loutres, mettons que j'ai un chouette flash video player (je sais pas encore lequel) sur un site web et que je veux lui faire lire une vidéo se trouvant sur un domaine tout à fait différent, est-ce que je vais avoir des warnings de sécurité ou quelque chose dans le genre, ou est-ce que ça va marcher comme ça?

Nan ça marche sans probs

dites, niveau javascript,  
aujourd'hui, aucun probleme pour manipuler une image (resize, drag, rotation),  
 
mais pour les textes (un div avec une texte dedans), ca passe bien aussi ? ca à deja été experimenté par un de vous ?

pourquoi faire
 
side question: avec <video>, la same-origin-policy est appliquée ? (on suppose que non, comme les images... ? what about <object> alors ? )

dans le README.txt de flot:

Deux questions:
- il est ou ce hook ?
- j'arrive pas à récuperer l'objet HtmlCanvasElement (probablement parce que je suis une burne en js/dom), je fais comment ?

Ça serait dommage tiens. Pareil pour object

Ça dépend ce que tu veux faire et quel navigateur tu cibles.

-Hooks -> http://people.iola.dk/olau/flot/API.txt  
-getCanvas() -> toujours http://people.iola.dk/olau/flot/API.txt

1/2 me semblent possible mais chiant  
 
3 pas en l'état , sauf a le faire en svg/vml ( raphaeljs)

j'ai ça dans mes favoris a finir de trié : http://www.nihilogic.dk/labs/canvas2image/

Merci
 

Parce que le client veut une chouette vidéo qui est hostée ailleurs que chez nous alors je me renseigne déjà avant

 
1/2 oui, possible j'ai testé,
 
pour le texte, je viens d'essayer, http://www.furiabike.com/_dev/rotation_texte.html
c'est encourageant,

-webkit-transform: rotate(-15deg);
tu as IE ?

http://raphaeljs.com/reference.html#rotate en seule solution viable et portable

pas testé pour IE pour le moment

merci pour raphael js

La same-origin policy c'est pour la communication pas l'inclusion AFAIK nan ?

white-space: pre-line

tain l'boulet, j'avais meme pas vu ce fichier.
par contre le paragraphe sur les hooks ne répond pas à ma question: ça décrit les hooks dans l'api de flot. Là je parlais d'un supposé hook dans l'api canvas pour "exporter" une image (bitmap donc, je suppose)