J’avoue que le modèle de boite CSS proposé par IE6 est plus logique (et surtout bien plus pratique à utiliser) que celui du W3C.
Heureusement qu’on peut utiliser un « box-sizing: border-box » en CSS3 pour revenir à la définition d’IE.
Ah, on me signale que mon SVG ne marche pas dans Chrome. Le SVG est syntaxiquement bien valide pourtant…
Il marche dans Firefox, Opera, IE (et eog, Gimp, InkScape…) mais pas Chrome.
Lol.
Chrome est en train de devenir le IE6 2.0 : c’est pas la première fois qu’il me fait chier.
Génial !
Bon, je me suis dit, je vais refaire mon logo (du site) en SVG. Mais pas avec Inkscape : dans Gedit (je veux apprendre le langage, avant de savoir cliquer).
Déjà, merci à Sebsauvage pour la version hors-ligne du tuto du SDZ :P.
Ensuite : je râle, car SVG ne permet pas (encore) de faire des ombres simplement colorées simplement (de la couleur de son choix, je veux dire ; ex: ombre rouge sur forme verte).
L’astuce est d’utiliser les ColorMatrix et de jouer avec la matrice, avec les « -1 » pour inverser la couleur du input en la couleur voulue (pour aller du noir au blanc il faut -1 0 0 0 1 0 -1 0 0 1 0 0 -1 0 1 0 0 0 1 0).
Enfin, je note : GIMP ne comprend pas le « #id * { css }. C’est le sélecteur css « * » qu’il ne comprend pas.
Faut lister tous les éléments un à un. Le programme qui s’occupe de faire les miniatures des images sous Gnome/Mate, c’est la même chose.
Le navigateur, lui, il reconnaît le sélecteur « * ».
C’est trop ça.
Une fois j’ai fait un « sudo rm -rf » sur la mauvaise partition.
…
Je m’en suis finalement sorti en copiant les fichiers du live-CD sur le disque dur. Ça permettait de dépanner (j’avais pas le net sur le coup).
Un live-cd c’est quand même très pratique.
Tout ce qu’il faut savoir sur le fichier .gitconfig, où on peut mettre plein de choses, pas juste le nom/email.
Webmasters,
vous qui êtes très forts pour détecter les smartphones et envoyer vos visiteurs (qui n'ont rien demandé) sur la version mobile de votre site (souvent la page d'accueil et non le lien précis, d'ailleurs), cela vous trouerait le cul de faire aussi l'inverse ?
C'est à dire de rediriger sur le site normal quand on visite le site mobile avec un ordinateur.
Évidemment, le plus pratique serait que votre design s'adapte tout seul (responsive design), mais vu que vous aimez bien ce qui est compliqué, foireux et qui demande beaucoup de maintenance (detection d'UA qu'il faut mettre à jour régulièrement, redirection apache...) on vous excuse de ne pas utiliser du CSS natif fonctionnel et pratique.
Signé moi, qui râle contre l'impossibilité d'avoir le site normal sur un mobile ou même sur desktop après avoir dû partager un lien mobile car l'url normal m'est interdit sur mon téléphone.
FU.
Bitch please : 010110101011111101101010101011110 !
À l’heure où j’ai supprimé ABP d’Android (trop lourd, et oui je met à payer pour quelques applis sans pub), je suis en train de créer un URL-filter pour Opera Mobile.
Pour l’instant je vire tous les gadgets Facebook, Twitter et G+ : ça permet déjà de gagner grandement en vitesse.
Je suis en train de voir mes sites préférés pour voir ce qui me prend des MB dessus…
Là, un un blog que j’aime bien : 110 fichiers hébergés sur 12 domaines différents, dont 36 fichiers CSS. TRENTE SIX FICHIERS CSS bordel de @%#!?*& !
Et pourquoi ? D’où ça vient ça ?
En grande partie à cause des plugins Wordpress qui ont chacun leur petit bout de CSS (pas plus de quelques centaines d’octets) et leur morceau de JS…
C’est pas sérieux : pourquoi les fichiers sont pas unifiés ? Un petit « readfile() » en PHP, qui va inclure tous les fichiers CSS en une requête, mais les laisser séparés sur le disque, personne ?
Mouais.
Les deux seules raisons proposées selon moi sont invalides :
— dans le cas des programmeurs de lecteur atom qui lisent pas les spec, ce sont eux qui méritent des baffes.
— dans le cas des permaliens qui changent, c'est en soi quelque chose de mal. C'est pas la faute à l'atom.
Un tuto très clair sur le PHP Objet.
Ça sert à quoi d’avoir une version 6, si tout est déjà dans 5.3/5.4 ? Je veux dire, c’est qu’un numéro de version.
Btw, je rigole par la même occasion du numéro des versions des navigateurs : ils semblent faire la course.
Visiblement ils sont maintenant uniquement en release majeure (ce qui n’est pas plus mal) et plus de numéro majeure toutes les six semaines avec plein de mini-versions entre temps.
M’enfin… on va être bien avancé quand on sera à Chrome version 80 et Firefox 60. Surtout les devs : avant on connaissait les branches 3.x ou 2.x, maintenant on doit connaître toutes les versions (ceci dit, y’a moins de différence entre les navigateurs qu’il y a quelques années)…
Hop, voilà ma page pour calculer un MD5/SHA1/SHA256/SHA512/SHA3 d’un texte ou d’un fichier.
(Merci au passage à Paul R pour m’avoir pointé son outil similaire (qui marche lui) :
http://fox-photography.net63.net/outils/hasher/
Qui m’a permis de résoudre le bug de hier, sur la conversion ArrayBuffer<>string : ma page donne maintenant les hash corrects des fichiers).
Ce service en ligne donne des checksum de fichier… en javascript.
Ce qui n’est pas si simple : JS n’a aucun moyen de lire un fichier binaire.
Je veux faire la même chose, mais cryptoJS ne prend en entrée que des chaînes de caractères, or JS fail au moment de transformer les données binaires en chaîne.
Cette page là, elle utilise une représenation "blob" (apportée en JS depuis html5) avec sa propre implémentation de MD5 (basée sur cryptoJS) pour accepter des données binaires brutes (avec ArrayBuffer).
Bref, c’est compliqué…
Mon outil en ligne n’acceptera donc que du texte à hasher, pas les fichiers.
Le Hollandais Volant
