Reprise du message précédent :

je lui ai pourtant recommandé de foutre une applet au milieu de sa page

http://wiki.script.aculo.us/script [...] ocompleter
hep les gens, quand j'utilise ça, si j'appuie sur enter après avoir sélectionné mon bousin, ça submitte le formulaire au lieu de juste saisir la valeur, y'a une parade ?

oui, appuyer sur tab, ne pas utiliser cette merde de scrpiptacoulus ou le modifier pour qu'il renvoit false.

tu me conseille quoi de mieux que scriptaculous ? Je comprends pas, je croyais que Rails c'était le meilleur truc du monde.

Perso j'utilise scriptaculous (c'est ce qui est fourni avec symfony et quand j'ai commencé le dev de mon projet actuel y a 9 mois ça répondait, et ça répond toujours, à mes besoins).
Y a pas mal de gens qui ont l'air d'apprécier Mootools sinon

Et tu utilises ce composant aussi ? ça marche chez toi ?

Je viens de tester : je tape mon texte dans le champ, ça m'affiche les résultats, je choisis l'élément qui m'intéresse avec les flèches par exemple, je valide avec entrée et ça me soumets pas le formulaire (testé sous FF 2)
Sous IE7 bizarrement les flèches haut/bas pour descendre dans la liste des choix n'a pas l'air de fonctionner.

ClearType? Ce truc infame qui trouble les caractères dans IE7 ?
Personnellement, c'est le premier truc que je désactive quand j'installe IE7 sur un PC : j'aime les polices de caractères nettes ce qui est loin d'être le cas quand ClearType est activé dans IE7 (on dirait que le texte est légèrement flouté ce qui rend la lecture plus fatigante).

C'est dispo sous XP en standard. Le truc, c'est que ça marche mieux avec un LCD. Et faut surtout le régler pour avoir un bon contraste. Enjoy your ugly, pixelized fonts

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

 
chui d'accord, avec un LCD bien réglé c'est un régal, par contre quand tu va chez les autres, ou que tu teste ton site sur une autre config... t'en prend un coup

Va falloir qu'on m'apprenne à "bien régler" un LCD alors par ce que quelque soit le LCD devant lequel je me suis retrouvé (et dans le tas il y avait pas que des LCD bas de gamme ) IE7 affichait toujours aussi mal les textes quand l'option "cleartype" est coché. D'ailleurs, mes collègues ont fait la même constatation que moi.
 
PS : Sans rire, il est planqué où le menu caché qui permet de "bien régler" les LCD de façon à avoir de belles écritures dans IE7 même quand l'option "cleartype" est coché?

Faut aussi un petit temps d'adapdation, histoire de régler la rétine. Sinon : http://www.microsoft.com/typograph [...] Step1.aspx

Quand tu vois la différence quand-même :

 
Celui de gauche est presque illisible

 
en ajoutant l'élément "Element.Selector" ça fonctionne bien. Super, merci. Pourtant je pensais que si je choisissait "Accordion" dans la page de téléchargement de Mootools, il m'ajoutait automatiquement toutes les dépendances.
Par contre je suis en train de constater que c'est pas accordion que je devrais utiliser, mais plutôt un simple système d'ouverture/fermeture : dans mon cas, aucune raison de fermer les autres éléments quand on en ouvre un.
Autre chose : $$('h3.atStart'), j'imagine que ça liste le contenu du tableau h3.atStart, mais tu l'as fait où, ce truc ? (dans la console JS ça donne rien).

En gros, "cleartype" est là pour améliorer la lecture de texte mis en italique (surement 0.5% du texte total qu'on est susceptible de lire quelque soit le site)
Dans ce cas pourquoi c'est aussi activé pour le reste du texte alors que ça rend la lecture moins confortable? Gagné en confort dans 0.5% des cas pour perdre en confort dans 99.5% des cas, ça me semble pas un très bon calcul.
 
Pour l'exemple que tu montres, c'est quoi la police de caractère qu'ils ont utilisé et dans quelle taille?

La bonne question est : c'est quoi le rapport avec le web ? si on peut rien faire côté serveur.

mIRROR > L'exemple de FlorentG est basé sur l'affichage de texte en italique (seul cas où les caractères sont penché) et c'est vrai que dans ce cas là l'utilisation de "cleartype" est utile. Par contre regarde sur ton poste comment s'affiche du texte sans activation de "cleartype" et sans que le texte soit en italique. Tu trouves que les caractères sont dur à décrypter/comprendre? Cleartype n'a donc aucune utilité dans ce cas là.
 
En plus court, ça donne ce que t'as cité.
 
nraynaud > La réponse est : le web n'est pas que les serveurs, c'est aussi les navigateurs. (et l'activation ou non de "cleartype" est réglable dans (un) certain(s) navigateur(s))

Ouais enfin faut pas exagérer non plus, hein

Il y a même une catégorie entière dédiée (XML/XSL)

dans print.css j'ai

pourquoi ff/webdev/editcss et safari/inspect me disent que j'ai screen.css loadé deux fois?

 
1> De rien
2> Oui et non. Si la seule classe que tu avais sur tes éléments était "atStart", ça fonctionnerait. Seuls les éléments indispensables sont ajoutés automatiquement. Element.selector est un plus, mais pas indispensable
3> Un système simple d'ouverture/fermeture doit exister, au pire ça doit être facile à mettre en place
4> J'ai bien tapé $$('h3.atStart') dans la console oui, ce qui ne donnait rien. (tableau vide)

@the real moins moins:Parce qu'il est chargé deux fois.

k lol, merci, super helpful.

Si, y'a une grosse utilité. Les polices ne sont pas aliasés. Même pour un texte normal, c'est grave moins moche, et plus facile à lire, surtout sur LCD. Ca triple virtuellement la résolution horizontalle de rendu. Les polices sont mieux retranscrites, sont plus agréables à lire, plus contrastées, plus douces. Si elles peuvent paraître légèrement floue, soit faut un peu s'habituer, soit régler le contraste.

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

Tu l'as écris toi même.
 
Numéro 1 :
<link rel="stylesheet" type="text/css" media="screen" href="screen.css"/>  
 
Numéro 2 :
@import url('screen.css');
 
Je vois pas ce qui t'étonne, et je vois encore moins pourquoi tu fais ça.

euh non
le truc c est pour lisser les polices
apres chipoter sur l utilité de l anti aliasing hein...

peut-être pour avoir une CSS principale différente suivant son média ?

En tout logique, le media="screen" n'est pas censé être chargé lors de l'impression

Lors de l'impression, il devrait y avoir le media="print" et le import seulement non ?

Edit : Et d'ailleurs, lors de l'impression, pourquoi ton "numéro 1" serait chargé, puisqu'il est en media="screen" ?

C'est bien la question que se pose moinmoin, bande de couillons

 
Ben je sais, mais  vu que Shinuza n'avait pas l'air de comprendre la question, je lui explique

J'ai très compris la question. La css est bien chargée deux fois, vu que c'est écrit explicitement. Le moteur de rendu s'appuie sur la css qui correspond au média ciblé, donc y'a rien d'étonnant à ce que la css soit chargée puisque la feuille de print est également interprétée.

 
Donc en gros, si on met media="print", le navigateur la charge mais ne l'utilise pas ?

C'est quoi la réponse ? print est utilisée aussi pour l'écran ?

Il a une CSS liée en "screen" et une CSS liée en "print", logiquement si il lance une impression ça charge la CSS "print" mais pas la CSS "screen"
 
Enfin c'est ce qu'on aurait tendance à se dire, après faudrait aller voir la spec CSS pour voir ce qu'elle dit exactement sur les styles de média mais je vois pas ce que ça a de normal, que la CSS screen soit chargée 2 fois alors qu'il ne la demande qu'une seule et unique fois (dans le @import de print)

Bingo

Voir le message de Dj YeLL

J'ai jamais dis le contraire.

Non, il a un link qui appelle la css, et il fait un import dans sa css de print.
 
Le navigateur se fout de savoir quel média est restitué, il évalue les css point. Ensuite il applique le bon rendu en fonction du média ciblé.

C'est hautement stupide d'importer toutes les CSS et ensuite seulement de se demander lesquelles on utilise en fonction du média

Bravo, une page de posts à la con pour 2 phrases intéressantes, rapport signal/bruit très faible mais au bout d'un moment on arrive à avoir un truc.