Appeler un numéro d’une page html depuis son mobile.

J'ai récemment fait l'acquisition d'un HTC Touch HD avec lequel je m'amuse un petit peu.

Le navigateur mobile que je préfère est Iris de Torch Mobile, basé sur le moteur Webkit (le même moteur que l'iPhone). J'attends impatiemment Mozilla Fennec ou une version stable et gratuite d'Opera Mobile.

Grâce à Iris, je peux suivre mes réseaux sociaux d'où que je puisse me trouver.

L'un d'entre eux (Facebook) a bien intégré la possibilité de pouvoir appeler directement numéro de téléphone sur une page html.

Exemple 1 : Facebook Mobile

Disponible au téléchargement sur Viméo: Demo of the TEL URI protocol #1: Facebook

Je me rends sur le profil d'un compte de test Facebook qui contient un numéro de téléphone défini, je clique sur le numéro, et la communication téléphonique s'initialise !

Exemple 2 : les pages .tel

Le TLD .tel vient d'être libéré et donc tout le monde peut, dès à présent, enregistrer son domaine .tel.

Qu'offre un domaine .tel ?

".tel est un service permettant aux particuliers et aux entreprises de stocker et de gérer toutes leurs coordonnées et leurs mots-clés, directement dans le DNS, sans avoir à concevoir, héberger ni gérer de site Web."

En théorie, c'est alléchant. Via mon navigateur mobile (et pourquoi pas associé avec un code QR ?), je saisis l'adresse .tel d'une personne/entreprise et je pourrais être à même de lui téléphoner directement.

Disponible au téléchargement sur Viméo: Demo of the TEL URI protocol #2: dot.tel page

Je me rends sur une page .tel, je clique sur le numéro de téléphone et j'ai une erreur "l'url n'emploie pas un protocole reconnu" !!!

Le code pour téléphoner d'une page html depuis un mobile.

Le pseudo-protocole callto:

Il est employé par beaucoup (Skype, NetMeeting, ...) mais n'est pas enregistré. En fait, il est "Une réinvention de la roue".

Comme ce protocole n'est pas défini, les développeurs de navigateurs sont libres de faire un peu ce qu'ils veulent.

C'est le protocole qu'utilisent les pages .tel :

<a class="data" title="callto:+12125551234" href="callto:+12125551234">+12125551234</a>


Ce code marche bien pour les navigateurs ayant Skype ou NetMeeting, mais sur une page vue sur un mobile...

Solution : servir un contenu différent pour les navigateurs mobiles et desktop

Le standard existants: le protocole tel:

La RFC3966, intitulée "The tel URI for Telephone Numbers" (ou l'URI tel pour les numéros téléphoniques) nous éclaire.

Le protocole a employer est tel:. Il sera suivi du numéro de téléphone (avec quelques contraintes).

C'est le code employé par la version iPhone de Facebook :

<a class="listButton" href="tel:+320123456789">Call +320123456789</a>


Le protocole tel: permet donc de passer un coup de fil rapidement et sans problèmes !

IE8 est là, mettez à jour vos butineurs

Internet Explorer 8 (IE8) vient de sortir, réjouissons-nous !

Ce qu'il manque dans IE8 :

C'est un grand pas en avant vers les standards web, mais pas encore parfait. Pour moi, il manque l'implémentation de certaines propriétés CSS 3 qui pourraient enfin faciliter la vie des développeurs, à savoir :

  • multiple background, pour avoir plusieurs images de fond sur un seul élément
  • border radius, pour faire des coins arrondis (sans image) sur un éléments
  • svg, canvas, video,...

Ce que IE8 corrige :

Par contre IE8 supporte enfin les data URI, qui permettent d'éviter des requêtes http sur des petites image.

IE8 corrige aussi un bug étrange sur le caractère "Euro" en fonte grasse qui n'apparaît que sur IE7.

Capture d'écran IE6, pas de bug
IE6 : affichage correct.

Capture d'écran IE7
IE7 : la fonte affichée n'est pas la bonne, la Verdana est remplacée par de la Times New Roman.

Capture d'écran IE8, pas de bug
IE8 : affichage correct

La liste des propriétés CSS supportées (ou pas) est éloquente.

Mises à jour.

J'espère vraiment qu'on ne devra pas pas attendre deux ans avant la prochaine mise à jour (pour l'implémentation des recommandations CSS3) et que le système de mise à jours se rapprochera de ce qui se fait sur Firefox, Chrome ou Opera. À savoir : des mises à jour fréquentes et automatiques !

Quelles sont vos raisons ?

IE6 reste encore bien implanté pour un navigateur qui date quand même de 2001, je donnerai mes chiffres plus tard.

Certainement la faute aux infrastructures IT qui ne veulent pas mettre à jour leurs parcs informatiques. Personnellement, je n'ai rien contre ce navigateur (je préfère son interface à celle de ses successeurs et puis, j'ai fini par bien connaître ses bugs).

Je serais juste curieux de connaître vos raisons de rester avec un si vieux navigateur alors que d'autres beaucoup plus performants (et pas gourmants en ressources quoi qu'on en dise) sont disponibles au téléchargement : Firefox, Chrome, Opera, IE8.

De même, il y a encore pas mal de vieilles versions de navigateurs qui sont installées (FF1.5, FF2, IE5.2 mac), qui sont tout aussi obsolètes que IE6, pourquoi ne les mettez-vous pas à jour ?

Performances Web: Impact du SSL

Depuis quelques temps, avec l'apparition de l'extension Firebug YSLOW, je m'intéresse de près aux performances des sites web.

J'ai profité des conseils avisés de Steve Souders et d'Éric Daspet dans quelques projets réalisés chez Emakina.

Un d'entre eux, le site smart.brusselsairlines.com, permettait aux participants de recevoir une réduction augmentant avec le nombre de participants (revenez-y de temps pour les prochaines promotions).

La mesure des visites du sites est gérée par une société externe EStat. Et, bien que je leur ai demandé de la documentation sur l'implémentation de leur script de tracking, on emploie toujours le vieux bout de code qui date de la première version du site.

Hors, le script de tracking est appelé via HTTPS. Vous voyez où je veux en venir.

Mesure des connections avec HTTPS.

Waterfall des connections du site smart.brusselsairlines.com - Estat avec HTTPS
DNS Lookup: 178 ms Initial Connection: 171 ms SSL Negotiation: 505 ms Time to First Byte: 164 ms Content Download: 2 ms Initial Connection: 148 ms SSL Negotiation: 152 ms Time to First Byte: 162 ms Content Download: 1 ms

Résultats de la requête #5 :

URL: https://prof.estat.com/js/m.js
Host: prof.estat.com
IP: 194.126.157.11
Location: Valbonne, France*
Error/Status Code: 200
Start Offset: 1.04 s
DNS Lookup: 178 ms
Initial Connection: 171 ms
SSL Negotiation: 505 ms
Time to First Byte: 164 ms
Content Download: 2 ms
Bytes In (downloaded): 2.0 KB
Bytes Out (uploaded): 0.6 KB

Analyse :

Sur un total de 1023 ms, 505 ms - soit presque 50% du temps de la requête - sont consacrées à la négociation SSL pour des données ne nécéssitant pas l'emploi du SSL...

N'ayant pas eu la documentation du fournisseur de service EStat, je me suis permis de tester la technique pour supprimer le protocole https lors de l'appel à la ressource.

J'ai donc refait le test en faisant un requête vers le même fichier JS, mais sans passer par HTTPS.

Mesure des connections sans HTTPS.

Waterfall des connections du site smart.brusselsairlines.com - Estat sans HTTPS
DNS Lookup: 56 ms Initial Connection: 155 ms Time to First Byte: 163 ms Content Download: 3 ms Initial Connection: 147 ms Time to First Byte: 162 ms Content Download: 0 ms

Résultats de la requête #5 :

URL: http://prof.estat.com/js/m.js
Host: prof.estat.com
IP: 194.126.157.11
Location: Valbonne, France*
Error/Status Code: 200
Start Offset: 1.19 s
DNS Lookup: 56 ms
Initial Connection: 155 ms
Time to First Byte: 163 ms
Content Download: 3 ms
Bytes In (downloaded): 1.1 KB
Bytes Out (uploaded): 0.3 KB

Verdict :

Le résultat est flagrant : 378 ms contre 1023, il n'y a pas photo.

Quand vous devez reprendre un vieux site et l'optimiser pour, entre autre, des raisons de performance, n'oubliez pas de tenir compte des ressources externes en https !

Et en plus si le fournisseur de service ne vous fourni pas de documentation, et n'active pas le Keep-Alive sur ses serveurs, vous pouvez vivement envisager de changer de prestataire ! À bon entendeur...

IE: supprimer les alertes de sécurité en mode https

Internet Explorer, dans toutes ses versions, affiche une alerte de sécurité lorsque l'on visite une page, servie via le protocole de sécurité https, si celle-ci contient des ressources servies via le protocole http.

Alerte de sécurité sur IE < 8.

Capture d'écran IE7: Security Information, This page contains both secure and unsecure items. Do you want to display the nonsecure items?

Security Information

This page contains both secure and unsecure items.

Do you want to display the nonsecure items?

[Yes] [No] [More Info]

Ou en français :

Information sur la sécurité

Cette page contient des éléments sécurisés et non sécurisés.

Souhaitez-vous afficher les éléments non sécurisés ?

[Oui] [Non] [Plus d'infos]

Alerte de sécurité sur IE8b2.

A l'heure actuelle, la version finale d'IE8 n'est pas encore sortie. J'ai donc fait des tests sur la version bêta 2.

Capture d'écran IE8b2: Security Warning, Do you want to view only the webpage content that was delivered securely?

Security Warning

Do you want to view only the webpage content that was delivered securely?

This webpage contains content that will not be delivered usin a secure HTTPS connection, which could compromise the security of the entire webpage.

[More Info] [Yes] [No]

Notez la tournure de la phrase qui est completement l'inverse du message de sécurité des versions précédantes...

Examples d'alerte de sécurité.

Démonstration.

J'ai mis en place une page démontrant cette popup de sécurité. Je sais que le certificat n'est pas valable pour le domain, d'où la première alerte.

Cette page est servie via le protocole sécurisé https et contient un lien vers une image servie via http.

Sur Internet Explorer, vous devriez avoir le message d'alerte ci-dessus.

Code.

<div>
<img src="http://noscript.be/demo/https-mixed-content-warning/404.jpg" alt="Un chat dans un pc démonté" title="src: http://www.catswhocode.com/blog/404" />
</div>

Supprimer l'alerte de sécurité une fois pour toute.

Il y a plusieurs solutions pour cela. Dont une consiste à changer les paramètres d'IE.

Je me vois mal conseiller à mes clients de changer leurs paramètres.

La seule solution est d'employer correctement le Common Internet Scheme Syntax, en supprimant le protocole.

Démonstration.

Dans cet exemple, le protocole https du lien vers l'image à simplement été supprimé.

Le message de sécurité n'apparaît plus.

Code.

<div>
<img src="//noscript.be/demo/https-mixed-content-warning/404.jpg" alt="Un chat dans un pc démonté" title="src: http://www.catswhocode.com/blog/404" />
</div>

Notez que la même technique est d'application pour les fichiers .swf que vous pourriez avoir dans vos pages sécurisées.

<OBJECT classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
codebase="//download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0"
WIDTH="550" HEIGHT="400" id="myMovieName">
<PARAM NAME=movie VALUE="myFlashMovie.swf">
<PARAM NAME=quality VALUE=high>
<PARAM NAME=bgcolor VALUE=#FFFFFF>
<EMBED src="/support/flash/ts/documents/myFlashMovie.swf"quality=high bgcolor=#FFFFFF WIDTH="550" HEIGHT="400"
NAME="myMovieName" ALIGN="" TYPE="application/x-shockwave-flash"
PLUGINSPAGE="http://www.macromedia.com/go/getflashplayer">
</EMBED>
</OBJECT>

code vu sur la base de connaissance Macromedia

J'ai enlevé le protocole http de l'attribut codebase du tag object.

Maintenant, ceux qui utilisent encore Internet Explorer (et qui devraient vraiment essayer un meilleur browser) n'ont plus de raisons de se plaindre de ces messages d'alerte !

JavaScript : Récupérer l’id d’une vidéo YouTube

Un de mes collègue m'a demandé un petit script pour retrouver l'id d'une Vidéo de YouTube.

Un namespace, une petite expression régulières et on obtient ceci :

var YT=(function(){
	return {
		getId:function(u){
			var a=u.match(/(\/vi\/|v=)([^&amp;]+)/);
			return (a&amp;&amp;a[a.length-1]);
		}
	};
})();
prompt("VideoId",YT.getId("http://www.youtube.com/watch?v=_TiQCJXpbKg&amp;fmt=6"));

Cette version ne se base pas sur la longueur de l'id vu que les id's sont susceptibles de changer...

Si ça peut servir à quelqu'un d'autre...

← Previous PageNext Page →