Journal
Archives de juin 2010
Renverser les URLs
21 juin 2010 17 commentaires — domains, idéaux, rant, url, web, www
Les utilisateurs ne comprennent rien aux URLs. On ne peut pas les blâmer car c’est compliqué d’en décoder une. Pourtant elles sont la meilleure façon de se protéger du phishing.
Qu’est ce qui cloche dans les URLs ?
-
L’ordre des parties est illogique. Je m’en plaignais déjà dans les commentaires, la plus haute autorité pour une adresse (le nom du site) est en plein milieu de l’adresse et l’ordre de lecture est différent pour le domaine et l’adresse.
Il n’y a qu’à voir l’ordre de lecture d’une URL : 4 3 1 2 5 6 https:// secure .elysnet .hsbc .co.uk /pay /form .html -
https://foo:bar@[4242:baaa::4242]:4242/qux/corge.php?grault=garply&waldo=fred#thudest un exemple d’URI qu’un utilisateur est sensé savoir décortiquer. -
Les suffixes de noms de domaines
.org,.com,.net,.info, … ne veulent plus rien dire. -
Les entreprises doivent acheter tous les noms de domaines de leurs marques pour chaque suffixe rien que pour ne pas se les faire piquer. C’est un jeu sans fin car on continue de créer de nouveaux suffixes.
-
Le nom de domaine principal attendu par tout le monde est le
.com. -
Les suffixes qu’il est possible d’acheter peuvent être décomposés comme
.co.uk,pvt.k12.wy.uset la liste de suffixes publics est longue et doit être maintenue. -
Les
wwwne servent à rien. Retirons-les. -
Les
//sont inutiles également, l’inventeur du Web s’en excuse.
Exemples de simplifications
En changeant les URLs telles qu’on les les connaît on pourrait avoir :
http:google
http://www.google.com/https:google.mail
https://mail.google.com/http:flickr.static.farm5/4008/4307231011_ce7f628393.jpg
http://farm5.static.flickr.com/4008/4307231011_ce7f628393.jpg
Plus court, plus simple, respectant l’ordre de lecture, la plus haute autorité du lien serait le premier mot après http:.
Malheureusement le gain est trop petit pour changer une infrastructure et des habitudes aussi énormes. Dommage.
Quelques caractères Unicode
19 juin 2010 2 commentaires — images, unicode, web
☀ ☼ ☽ ☾ ☂ ☔ ☁ ☃ ☄ ☎ ☏ ✉ ⌨ ✍ ✌ ☯ ☺ ☻ ☹ ☠ ☢ ☣ ✆ ✇ ♨ ✎ ✏ ✐ ✂ ✄ ✈ ♻ ♜ ♞ ♝ ♛ ♚ ♟ ♖ ♘ ♗ ♕ ♔ ♙ ☬ ☭ ❤ ❥ ❀ ➳ ☜ ☝ ☞ ☟ ★ ✪ ✰ ♬ ♀ ♂ ⚤ ⚣ ⚢ ⚥ ⚦ ⚧
Utiliser font-face pour des images ?
18 juin 2010 3 commentaires — font-face, html, images, performances, sprites, unicode, web
Depuis que @font-face est utilisable partout, on a envie de pousser les limites de son utilisation. Utiliser des générateurs automatiques, créée des police d’écritures qui ne transforment que le caractère &, etc.
Dans l’article ever- thought about using font face for icons? ils expliquent comment faire une page où toutes les images seraient contenues dans un fichier de police. En appliquant chaque icône à une lettre, on a des images dans la police d’écriture
Cela donne des images :
- qui s’agrandissent sans perte de qualité ;
- très faciles à colorer, agrandir, souligner en CSS ;
- rapides à charger car cela ne fait qu’une requête HTTP pour tout le paquet d’icônes.
Mais cette technique souffre de serieux points faibles. En plus d’être plus difficile à maintenir, il faut choisir entre un HTML qui n’a aucun sens comme <span class="phone-icon">a</span> ou une feuille de style CSS imbitable qui ne fonctionne pas sous IE :
.phone-number:before {
content: 'a';
font-family: "Mes Icônes"
}La solution serait de ne remplacer que les quelques caractères Unicode qui représentent déjà des icônes. Ainsi on garde du sens à l’HTML et on peut profiter de la cascade des polices d’écriture disponibles.
