Les articles de la catégorie « Veille »

Les États-Unis et l’Union Européenne viennent de donner leur approbation pour le rachat de Motorola Mobility par Google annoncé en août dernier, pour la modique somme de 12,5 milliards de dollars. MG Siegler avait publié il y a quelques semaines un très bon article résumant ce que Google achetait pour cette somme :

Motorola Mobility ont livré — livré, pas vendu — 5,3 millions de smartphones au cours du trimestre. Pour rappel, Apple en a vendu 37 millions.

Sur toute l’année, Motorola a livré — livré, pas vendu — 18,7 millions de smartphones. Pour rappel, Apple a vendu 37 millions de smartphones ce dernier trimestre.

Ils ont livré — livré, pas vendu — 200 000 tablettes ce dernier trimestre. DEUX CENT MILLE. Pour rappel, Apple a vendu 15 millions de tablettes.

Sur toute l’année, Motorola a livré — livré, pas vendu — 1 million de tablettes. Pour rappel, Apple a vendu 15 millions de tablettes ce dernier trimestre.

La société a perdu 80 millions de dollars au cours du trimestre — dont 70 millions étaient de la division mobile. L’unité a perdu 285 millions de dollars au cours de l’année.

Et tout ça pour DOUZE VIRGULE CINQ MILLIARDS DE DOLLARS. En août dernier, John Gruber rappelait ce que cette somme représentait pour Google :

Regardez les résultats financiers de Google. Ils ont rapporté 8,5 milliards de revenus nets cette année, et 6,5 milliards l’année dernière. C’est pour la totalité de Google. Ils offrent 12,5 milliards de dollars pour Motorola. Donc Google vient de dépenser quasiment deux années de ses bénéfices pour acheter un fabricant de téléphone de seconde classe qui est lui même peu rentable, a quasiment fait faillite, et est sans doute seulement le troisième meilleur fabricant d’appareils sous Android, derrière HTC et Samsung.

J’ai un tout petit peu de mal à croire que Google ait dépensé autant pour laisser Motorola « opérer comme une unité commerciale distincte ».

Après le débat lancé par le W3C face aux préfixes des navigateurs, Raphaël Goetter d’Alsacréations a partagé sa solution pour facilement adapter ses sites en utilisant le script -prefix-free.

Comme beaucoup d’outils de ce genre, -prefix-free nécessite une requête HTTP et un traitement du JavaScript, au détriment des performances du navigateur.

En ce qui me concerne, je considère que les avantages fournis contrebalancent ce handicap. Mais sur mobiles, où les temps de chargement sont prépondérants, la question mérite le détour.

J’ai d’abord cru à une blague, mais il est apparemment très sérieux. Jérémie Patonnier a ce matin très bien détaillé la problématique, en titrant son article « Lier CSS à JavaScript : une mauvaise idée ».

De manière générale, ce genre d’interrogations arrive rarement quand on applique un mantra, une philosophie globale, un fil conducteur qu’on applique dans n’importe quelle situation. Personnellement, ma philosophie se résume en une question.

Qu’est-ce qui est le mieux pour l’utilisateur ? 

Le graphiste a maquetté des listes déroulantes personnalisées. Je peux utiliser un script pour simuler une liste déroulante avec la charte maquettée, au détriment des performances de la page, ou laisser les listes déroulantes par défaut du navigateur, au détriment de la charte graphique. Qu’est-ce qui est le mieux pour l’utilisateur ?

Je dois intégrer une page simple avec quelques éléments à rendre dynamique (apparition au clic ou au survol). Je peux utiliser une librairie type jQuery pour coder ça rapidement, ou prendre un peu plus de temps pour coder la même chose en JavaScript seul. Qu’est-ce qui est le mieux pour l’utilisateur ?

J’ai du texte dans une police personnalisée. Je peux importer une police en CSS3 de plusieurs dizaines de Ko, ou découper une image de quelques Ko. Qu’est-ce qui est le mieux pour l’utilisateur ?

En octobre dernier, je partageais déjà mon point de vue sur la finalité d’une page web :

On ne fait pas un site web pour le client. On fait un site web pour un utilisateur. Un utilisateur est une vraie personne. Un utilisateur a son terminal (ordinateur, smartphone, télévision, …), son entrée (clavier/souris, tactile, …), sa sortie (écran 16/9, 4/3, 72 dpi, 326 ppi, …), sa connexion internet (56k, ADSL, Fibre, Edge, 3G, …). Un terminal à son système d’exploitation (Windows, Mac OS, iOS, Android, …), son processeur, sa carte graphique, … En pratique, vous aurez quasiment autant de configurations possibles que de visiteurs. Quand vous travaillez pour le client, vous rendez 1 personne heureuse. Quand vous travaillez pour l’utilisateur, vous rendez des milliers voire des millions de personnes heureuses.

D’autres intégrateurs auront surement un mantra différent, privilégiant par exemple la charte graphique, le temps de réalisation ou le coût d’un projet. On peut y trouver un intérêt sur le court terme. Mais je pense que seule une conception pensée pour l’utilisateur reste valable sur le long terme.

Daniel Glazman, co-président du groupe de travail CSS du W3C, a lancé aujourd’hui un appel à tous les acteurs du web pour éviter que les fabricants de navigateurs n’implémentent les préfixes -webkit- sur le long terme.

Je demande à toute la communauté des acteurs du web d’arrêter de concevoir des sites pour WebKit seulement, en particulier quand le support d’autres navigateurs n’est qu’une question d’ajouter quelques lignes de propriétés CSS avec des préfixes.

Je demande à toute la communauté des acteurs du web de supprimer immédiatement et d’arrêter d’implémenter la détection (sniffing) de navigateurs basés sur WebKit. Vous possédez un tel site ? Montrez votre soutien pour le Web Ouvert et supprimer cette détection immédiatement après avoir lu cet appel.

Je demande à la communauté des utilisateurs du web et des designers du web d’arrêter de recommander des sites qui nécessitent un navigateur en particulier alors qu’ils pourraient être ouverts à plusieurs navigateurs. Ne faites pas de lien vers ces sites, et mentionnez les uniquement pour faire savoir à la communauté qu’ils échouent dans leur service du Web Ouvert. Ne nourrissez pas les trolls, blacklistez les, peu importe à quel point le service qu’ils fournissent est cool.

Je suis totalement d’accord avec Daniel Glazman sur les deux premiers paragraphes. Je plaide coupable d’avoir moi même déjà utilisé des propriétés CSS avec uniquement leur préfixe WebKit (en particulier il y a 1 ou 2 ans, avant que Firefox ne revienne dans la course et commence à implémenter pleins de nouvelles propriétés).

Par contre, je suis convaincu qu’il se trompe de combat en cherchant à lancer une chasse aux sorcières. Mais puisqu’il insiste…

http://www.w3.org/2008/site/css/minimum
Ligne 134: .w3c_leftCol a:hover,.w3c_leftCol li a:focus{ -moz-transition-property:background-color;-webkit-transition-property:background-color;-o-transition-property:background-color;-moz-transition-duration:.3s;-webkit-transition-duration:.3s;-o-transition-duration:.3s;}
Ligne 181: .button{border:0;-moz-border-radius:3px;-moz-box-shadow:0 1px 3px rgba(0,0,0,0.5);-webkit-border-radius:3px;-webkit-box-shadow:0 1px 3px rgba(0,0,0,0.5);border-bottom:1px solid rgba(0,0,0,0.25);background-color:#555;color:#FFF;cursor:pointer;font-size:81%;font-weight:bold;left:5px;padding:2px 5px;position:relative;text-shadow:0 -1px 1px rgba(0,0,0,0.25);} http://www.w3.org/2008/site/css/advanced
Ligne 31: .secondary_nav{ -webkit-box-shadow:0 1px 2px #fff;-moz-box-shadow:0 1px 2px #fff;-webkit-border-radius:5px;-moz-border-radius:5px; }
Ligne 35: #search-form{ -webkit-border-radius:5px;-moz-border-radius:5px;}
Ligne 233: #request_form fieldset input:focus,#request_form fieldset textarea:focus{ -webkit-transition:border .2s linear,-webkit-box-shadow .2s linear;-moz-transition:border .2s linear,-moz-box-shadow .2s linear; }


Le site du W3C lui-même n’utilise pas systématiquement les noms de propriétés non-préfixées, et jamais les préfixes pour l’ensemble des navigateurs (pourquoi tant de haine envers -ms- ?). Je suppose que je devrais faire comme Daniel Glazman, et lui envoyer un e-mail.

C’est facile de dénoncer et de pénaliser. Les acteurs du web ont fait quelque chose de stupide en utilisant uniquement des préfixes -webkit-. Les fabricants de navigateurs vont faire quelque chose de stupide en implémentant les propriétés avec le préfixe -webkit-. Le W3C propose une réponse stupide visant à pénaliser les auteurs du web ignorants ou peu consciencieux.

Avant de vouloir pointer du doigt et pénaliser les sites qui favorisent WebKit, il serait peut être bon d’éduquer les acteurs du web. Nous sommes en 2012 et le W3C ne propose aucune documentation simple et claire, compréhensible par le commun des mortels, indiquant le bon usage et le bon fonctionnement des propriétés CSS. C’est regrettable, mais pas étonnant qu’on se retrouve dans une telle situation.

Hier, lors d’un comité du groupe www-style du W3C, réunissant Daniel Glazman (co-président du groupe de travail CSS du W3C), Tantek Çelik (Mozilla), Florian Rivoal (Opera) et Sylvain Galineau (Microsoft), la discussion la plus hallucinante que j’ai pu lire à ce jour.

glazou: Title is: Why and How to Implement Other Vendors’ Prefixes
tantek: This is a specific subtopic of vendor prefixes
tantek: The problem statement right now, and this is a problem for
Mozilla and any other non-WebKit browser
tantek: Sites have webkit-specific content, and serve backup content to
everyone else. Specifically for mobile content.
tantek: Non-WebKit browsers face prisoners dilemma
tantek: similar to quirks in 2003 or so
tantek: At this point we’re trying to figure out which and how many webkit
prefix properties to actually implement support for in Mozilla
plinss: Zero.
tantek: Currently we have zero. Zero is no longer an option for us.
Florian, Sylvain: Zero is not an option for us anymore either.

Vous avez bien lu : pour Mozilla, Opera et Microsoft, il n’est plus envisageable de ne pas implémenter les propriétés en utilisant les préfixes -webkit-. Et ça ne va pas s’arrêter là :

tantek: We will also need to send a webkit-tricking UA string.
tantek: Just like WebKit sent « like Gecko » in its UA string, we have to do
the same thing again

Je ne sais pas trop comment on peut s’y prendre, mais il va falloir gentiment dire à Mozilla, Opera et Microsoft d’arrêter leurs âneries.

Hier, une toute première beta de Chrome sous Android est sortie. L’application est disponible uniquement sur Ice Cream Sandwich (qui 3 mois après sa sortie représente 1% des appareils sous Android).

Signe des temps, Adobe et Google ont confirmé que Chrome sous Android ne supportera jamais Flash Player. A terme, Chrome va remplacer le navigateur par défaut sous Android. Si vous pensiez encore pouvoir faire des sites en Flash pour mobiles, repensez-y.