Reprise du message précédent :

Mise à jour y'a 3 mois. Bah écoute ça suit mon rythme de mise à jour de mes sites, ça me convient
 
Sinon
 
XaT

putain je venais justement poser une question à propos de ce truc
 
ma question c'était: vous connaissiez ? je viens de découvrir par hasard sur http://developers.whatwg.org/ (et encore, j'en étais resté à http://fonts.googleapis.com/, j'étais sur le point de googler), et je demandais
- où est documentée cette api ? (je suppose sur le lien du raynaud, pas encore cliqué)
- comment vous avez découvert, comment vous êtes au courant ? Je suis 2/3 blogs orientés css/html5, sans doute pas d'assez près. SAUCE ?

la doc est là : http://code.google.com/intl/fr/apis/webfonts/
moi j'ai vu passer plusieurs fois sur le net, genre reddit ou ycombinator.

Vu un peu partout.
 
Sinon ce qui sux souvent avec les fonts comme ça, c'est le format TTF qui rend dégueulasse sous Win. Je garde toujours la version OTF si disponible, plus jolie

ils disent pas justement qu'ils servent une font différente suivant le navigateur ?

Normallement ouais, mais beaucoup envoient du TTF pourri, alors que sous FF et Chrome, l'OTF est mieux rendu

je l'ai utilisé là-dessus : http://woosmap.com/ là tu penses que la typo est bien ?

Ça dépend la font et les couleurs. Là ça rend bien
 
Un exemple de la différence OTF/TTF (sous Firefox, IE <= 8 ne gérant que le TTF), avec CallunaSans
 

 
Au-dessus le TTF : l'antialiasing déconne complètement sur certaines courbes qui pixellisent (et rien n'y fait, même en supprimant le hinting et tout).
En-dessous, l'OTF : là la font est correctement affichée. Un poil légèrement floue, mais ça se rapproche du rendu sous Mac.

et y'a des outils "standard" pour convertir ttf<->otf<->autres ou bien faut "acheter" les 2, et garder des copies dans tous les formats sur le vcs ?

guillemets -> ban

FontSquirrel a un générateur qui se charge de convertir une font en tout (y compris en SVG pour les iPhones)

ouais, jsuis pas sur d'avoir envie de dépendre d'un outil web dans mon build.
Et avec cette conversion, les résultats sont bons ? Genre si tu convertis le ttf de ton exemple plus haut en otf, et que tu regardes le resultat sous ie?

Tu peux pas convertir de TTF en OTF Et leur machin n'inclut pas l'OTF dans le zip généré, faut l'ajouter à la main Mais tu te retrouves avec un truc du coup qui marche partout : un EOT pour les IE, l'OTF que t'aura remis dedans pour les navigateurs gentils, le SVG pour les iPhone, et encore du WOFF je crois pour je sais pas qui

et je viens de que la fonte de notre CI est .. euh le format adobe, j'ai oublié le nom.

Faut test

ça se fait ça en CSS ?

/* Page en cours .selected */
header nav a.selected{
    text-decoration:none;
    color:#fff;
    text-shadow: rgba(0, 0, 0, 0.4) 0 1px 2px;
    background:transparent url('../img/navhover.png') no-repeat;
}
header nav a.accueil.selected { background-position:2px 0; }
header nav a.plortfolio.selected { background-position:-81px 0; }
header nav a.about.selected { background-position:-181px 0; }
header nav a.blog.selected { background-position:-276px 0; }
header nav a.contact.selected { background-position:-181px 0; }

 
d'avoir deux classes sur un element ? en HTML je sais que oui, mais en CSS j'avais jamais fait. En tout cas, ça marche

/* Page en cours .selected */
header nav a.selected{
    text-decoration:none;
    color:#fff;
    text-shadow: rgba(0, 0, 0, 0.4) 0 1px 2px;
    background:transparent url('../img/navhover.png') no-repeat;
}
header nav a.accueil.selected { background-position:2px 0; }
header nav a.plortfolio.selected { background-position:-81px 0; }
header nav a.about.selected { background-position:-181px 0; }
header nav a.blog.selected { background-position:-276px 0; }
header nav a.contact.selected { background-position:-181px 0; }

IE6 comprend pas (il prend que la dernière). À part ça, bah tu peux mettre tous les sélecteurs que tu veux sur ton truc, c'est complètement arbitraire, tu peux aussi ajouter une platrée d'attribute selectors.

je viens devoir en effet http://kimblim.dk/css-tests/selectors/
 
vivement que IE6 crève pour de bon

Bad guys never die !

Moi pour les selected je remplace le <a> par un <strong> : il est de bon conseil de ne pas rendre un lien sur la même page cliquable (cf Nielsen etc.)

 
Nielsen dit ça pour l'aspect "se repérer", mais j'ai vu pas mal d'users utiliser le bouton qui mène à où ils sont déjà pour faire F5.
 
Du coup ça m'est arrivé de laisser le <a> en <a> mais si c'est la page en cours je vire reset le cursor à défault et le hover, pas d'affordance donc on sait qu'on est déjà là, mais si on clique quand même ça marche.
 
Cela dit, à part Nielsen y'a bcp d'autres sources qui conseillent ça (et qui en fait ne le citent pas) ? Je suis pas super convaincu par le truc

Dans le cadre d'une page qui nécessite des refresh réguliers alors Pour un site "standard", on n'a pas forcément le besoin de rafraîchir ?
 
J'ai aussi vu des utilisateurs cliquer sur un lien qui renvoie sur la même page, et attendre qu'il se passe quelque chose, pensant qu'une autre page allait s'ouvrir On voit un peu de tout au final
 

Ça me paraît être un bon juste milieu ouais
 

J'ai vu ça chez ALA aussi (Where Am I)
 
Hors Nielsen encore, voir ce commentaire avec diverses discussions. Apparemment plein de gens ont vu la confusion que ça pouvait provoquer.
 
Bon avec ton implémentation, donc avec le lien en cours bien en évidence, ça devrait pas poser de problèmes.

Remarque si aveugle, un strong est plus explicite qu'un <a> qui n'aurait pas de différence
 
-> strong + onclick

Un navigateur qui a plus de 10 ans et deux versions de windows de retard, je vois pas l'intérêt de continuer à s'en soucier.
T'as qu'à tester tes sites sous netscape 4 tant que t'y es...à part dans les boites qui se reposent encore sur des intranets antédiluviens ne fonctionnant que sous IE 6, ce navigateur est mort.

Vrai
 
Moi je veille juste à ce que ça "marchouille" : qu'il n'y ai pas de gros problèmes d'affichage. Genre pour un site avec 2 colonnes, qu'elles soient bien côte-à-côte. Ou que des PNG-32 ne bloquent pas l'affichage d'éléments en-dessous.
 
Après pour mon CMS c'est pareil, en cas d'extrême urgence pouvoir utiliser IE6 si on n'a que ça sous la main, avec quelques fonctionnalités moins vitales ne fonctionnant pas.

Voilà. Eventuellement tester pour vérifier vite fait que c'est pas complètement HS, mais c'est tout...je vois pas de raison de perdre son temps plus que ça.
IE6 représente maintenant moins de 5% du marché, en chute violente depuis un bon moment...et c'est pas la chute tout aussi violente de winXP qui va ralentir le mouvement.

...d'ailleurs IE7 aussi est en train de crever la bouche ouverte.

 
J'ai des clients qui me demandent encore le même rendu sous IE6. La plupart du temps ça me rend fou, après pour d'autres c'est plus justifié (quand sur tout leur parc IE6 est le nav par défaut...).

Faut facturer plus cher, dans ce cas...On est en 2011, s'ils veulent faire tourner des trucs modernes sur des dinosaures ça implique plus de boulot, donc ça coûte plus cher.
Tu vas voir que tout de suite ce sera vachement moins crucial...enfin si tu peux te le permettre, évidemment.

2% du marché en France, IE6, maintenant...et ça ne fait que diminuer.  
Ca allonge le temps de développement de combien chez vous, de faire tout fonctionner à l'identique dessus?

sur une année, il y a 2 ans, IE6 représentait 1 mois de dev en plus, maintenant avec l'expérience acquise et l'anticipation des problème IE6 ne représente que 4% du temps chez moi, et encore.

Moué, vous amortissez le taf fait précédemment, et ça suffit même pas à compenser la baisse de parts de marché...

lulbankzor

Attends, ils sont en train d'étudier le passage à IE 7, je crois

C'est déjà un grand pas en avant...mais faudrait les prévenir qu'IE 9 est sur le point de sortir, quand même, quitte à changer.

Si IE-tout-court pouvait crever la bouche ouverte aussi, ça m'arrangerait

Chuis sous IE7/8 et je suis chargé de corriger un bug sur un site dont les formulaires sont soumis au serveur par Javascript. Ils lancent une fonction SubmitForm maison qui va initialiser quelques champs cachés puis déclencher le form.submit(). Cette fonction SubmitForm est attachée aux évènements onClick des boutons du formulaire en question. Sauf que si je suis dans un champ texte et que je tape Enter, l'évènement onClick du bouton par défaut n'est pas déclenché sous IE, du coup mes champs sont pas initialisés et c'est la merde.

Ya des workarounds pour ça?

(virer Javascript et toucher aux propriétés du formulaire ne sont pas une option, ce mécanisme est sur tout le site et j'ai pas le budget pour changer tout )

OnSubmit. Je vois pas pourquoi "entrée" déclencherais un onclick, IE a raison sur ce coup

Tu choppes le onKeyPress sur la touche "entrée" et tu déclanche le onClick ?

Edit : trl a raison tout de même

tu rigoles
ca veut dire passer a seven
 
IE7 ici