Appel pour le web ouvert !

Posté par Nÿco (site web personnel) le 09 février 2012 à 21:45. Édité par baud123, Nils Ratusznik et B16F4RV4RD1N. Modéré par NeoX. Licence CC By‑SA.

Étiquettes :

fév.

2012

IE6 est mort. Bon débarras. Malheureusement, il y a webkit pour lui succéder. Non pas que webkit soit mauvais, bien au contraire il est très bon, en plus il est libre...

Mais la pratique consistant à faire des tests de User Agent est encore, hélas, très répandue. Il faut cesser cela. Ajoutez à cela l'utilisation massive des sélecteurs CSS préfixés par -webkit-*, comme les préfixes -moz-*, -o-* et -ms-*. Cela n'est pas prêt de disparaître. C'est même sur le point de se généraliser. Ceux-ci sont pourtant bel et bien documentés comme à destination de tests. Cela est bien évidemment à proscrire.

Le problème se pose massivement sur les navigateurs mobiles, où webkit domine très largement, car il est le navigateur par défaut des appareils iOS et Android. Daniel Glazman, co-chairman du CSS Working Group, a donc lancé un appel, avec l'appui du CSS Working Group.

Développeurs web de tous pays, unissez-vous : ne reproduisez pas les erreurs du passé !

Aller plus loin

Call for action: The Open Web needs you *NOW* (286 clics)
Traduction de l'appel Bonnes pratiques CSS : le Web ouvert a besoin de vous (416 clics)

# Balayons chez nous

Posté par Benoît Sibaud (site web personnel) le 09 février 2012 à 21:59. Évalué à 9.

$ grep -crE -- "-webkit-|-moz-|-o-|-ms-" *|grep -v :0

contrib/grises.css:137
contrib/edition_papier.css:9
contrib/black_bling.css:47
contrib/spasibo.css:18
contrib/opensuse.css:137
contrib/blue-smooth.css:35
contrib/retro.css:11
contrib/nightgrey.css:16
contrib/kitch.css:11
contrib/kaiska-new.css:13
contrib/cascade.css:137
contrib/cascade-alternative.css:137
contrib/grayscale.css:43
RonRonnement.css:52

Ahem :).

Et on trouve :

-webkit-appearance
-{moz,o,webkit}-background-size
-{moz,o,webkit}-border-image
-{moz,webkit}-border-radius
-moz-border-radius-bottomleft // -webkit-border-bottom-left-radius
-moz-border-radius-bottomright // -webkit-border-bottom-right-radius
-moz-border-radius-topleft // -webkit-border-top-left-radius
-moz-border-radius-topright // -webkit-border-top-right-radius
-{moz,webkit}-box-shadow
-{moz,webkit}-hyphens
-moz-inline-block
-{moz,o}-linear-gradient // -webkit-gradient
-moz-selection
-{moz,o,webkit}-transform
-{moz,o,webkit}-transform-origin
-{moz,o,webkit}-transition
-{moz,webkit}-transition-duration
-webkit-transition-property
- [^] # Re: Balayons chez nous
  
  Posté par NeoX le 09 février 2012 à 22:27. Évalué à 9.
  
  si ca se trouve les -{moz,o,webkit}-xxxx-yyyy peuvent maintenant se transformer en xxxx-yyyy
  - [^] # Re: Balayons chez nous
    
    Posté par CrEv (site web personnel) le 10 février 2012 à 14:56. Évalué à 8.
    Oui et non.
    Ils peuvent si tu prends les derniers navigateurs et les propriétés anciennes.
    Mais si tu veux être compatible avec le plus grand nombre il faut aussi les préfixes pour les versions plus anciennes de certains navigateurs qui ne supportaient pas encore la version sans préfixe.
    
    Mais juste pour montrer que le CSS say bô (ok c'est pas exactement du css), un petit exemple de déclaration de dégradé...
```
@defmixin gradient_horizontal(START_COLOR, END_COLOR) {
  background-color: END_COLOR;
  background-repeat: repeat-x;
  /* @alternate */ background-image: -khtml-gradient(linear, left top, right top, from(START_COLOR), to(END_COLOR)); /* Konqueror */
  /* @alternate */ background-image: -moz-linear-gradient(left, START_COLOR, END_COLOR); /* FF 3.6+ */
  /* @alternate */ background-image: -ms-linear-gradient(left, START_COLOR, END_COLOR); /* IE10 */
  /* @alternate */ background-image: -webkit-gradient(linear, left top, right top, color-stop(0%, START_COLOR), color-stop(100%, END_COLOR)); /* Safari 4+, Chrome 2+ */
  /* @alternate */ background-image: -webkit-linear-gradient(left, START_COLOR, END_COLOR); /* Safari 5.1+, Chrome 10+ */
  /* @alternate */ background-image: -o-linear-gradient(left, START_COLOR, END_COLOR); /* Opera 11.10 */
  /* @alternate */ background-image: linear-gradient(left, START_COLOR, END_COLOR); /* Le standard */
  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr=START_COLOR, endColorstr=END_COLOR, GradientType=1); /* IE9 and down */
}
```
    Le truc c'est que si on veut utiliser les dernières propriétés CSS ben on a pas vraiment le choix...
- [^] # Re: Balayons chez nous
  
  Posté par Benoît Sibaud (site web personnel) le 09 février 2012 à 22:43. Évalué à 5.
  
  Avec les chiffres de support complet et partiel+complet donnés par caniuse.com pour la famille de fonctionnalités concernées :
  
  -webkit-appearance (dans l'absolu, il existe aussi -moz-appearance)
  -{moz,o,webkit}-background-size 66% / 70%
  -{moz,o,webkit}-border-image 24% / 58%
  -{moz,webkit}-border-radius 69% / 69% (nb: Mozilla support maintenant le nommage officiel, donc il faudrait corriger au minimum ça)
  -{moz,webkit}-box-shadow 68%
  -{moz,webkit}-hyphens 22%
  -moz-inline-block 90% / 95% (nb: bon candidat pour suppression du -moz-)
  -{moz,o}-linear-gradient // -webkit-gradient 53% / 58% (nb: besoin de la vieille syntaxe pour les vieux webkit)
  -moz-selection 70.47%
  -{moz,o,webkit}-transform 68%
  -{moz,o,webkit}-transition 54%
  - [^] # Re: Balayons chez nous
    
    Posté par NeoX le 09 février 2012 à 23:07. Évalué à 4.
    
    de ce que je comprend du site caniuse.com
    
    pour linear-gradient il faut forcement utilisé -webkit -moz -o avec les versions actuelle des logiciels
    
    alors que box-shadow ne necessite plus aucun prefix pour etre géré par les navigateurs courants (sauf opera mini)
- [^] # Re: Balayons chez nous
  
  Posté par 2PetitsVerres le 10 février 2012 à 03:13. Évalué à 5.
  
  Sauf qu'une bonne partie de ces propriétés avec préfixe ont aussi une version non préfixée. Je ne suis pas spécialiste, mais il me semble qu'à l'époque où j'étais un peu là dedans, lors de l'utilisation d'une version préfixée, il était conseillé de mettre une version non préfixée et qu'un navigateur supportant les deux ne regarderait que la version "standard". L'avantage étant que si la c'était finalement standardisé, le site fonctionnerait dans la version x-1 du navigateur Toto ainsi que dans sa version x, x étant la version du Toto web browser implémentant en premier la version standard.
  
  Mais je peux me tromper.
  
  Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
  - [^] # Re: Balayons chez nous
    
    Posté par kertiam le 10 février 2012 à 11:33. Évalué à 7.
    
    Tu te trompes-je même si ton raisonnement est pertinent.
    
    Tu ne peux pré-supposer de l'ordre et/ou de la nature des paramètres de la propriété lorsqu'elle sera dans la recommandation CSS si les paramètres des préfixes vendeurs (antérieurs) sont dans un ordre et/ou de nature différent.
    
    Ce fut le cas avec gradient.
    
    Le seul conseil vraiment tout terrain c'est de s'assurer que le rendu SANS la propriété CSS préfixées est acceptable.
- [^] # Re: Balayons chez nous
  
  Posté par Adrien le 10 février 2012 à 08:29. Évalué à 10.
  
  Une question me vient à l'esprit : Ces propriétés sont en développement si j'ai bien compris.
  
  Ça veut dire que beaucoup de gens utilisent un truc en développement – donc pas forcément finit ou stable – pour leur site web en production, y compris linuxfr ? Si c'est le cas, il me semble que c'est la méthode de travail qui est à revoir, plus que les extensions…
  - [^] # Re: Balayons chez nous
    
    Posté par Anonyme le 10 février 2012 à 10:01. Évalué à 4.
    
    Faut revoir la chose tout en amont : partir d'un appel d'offre déguisé, c'est signer l'échec.
  - [^] # Re: Balayons chez nous
    
    Posté par claudex le 12 février 2012 à 16:27. Évalué à 3.
    
    Je trouve ça justement très bien. Si on ne teste jamais ces extensions, c'est difficile d'imaginer ce que ça donnerait une fois normalisé.
    
    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Article en Français

Posté par misaflo (site web personnel) le 09 février 2012 à 22:12. Évalué à 10.

Un bel article en Français :
http://www.alsacreations.com/actu/lire/1394-web-ouvert-css-webkit.html
- [^] # Re: Article en Français
  
  Posté par BAud (site web personnel) le 09 février 2012 à 22:31. Évalué à 2.
  
  lien ajouté à la dépêche, merci :-)
# +1

Posté par alpha_one_x86 (site web personnel) le 09 février 2012 à 22:14. Évalué à 2.

Idem ici, marre des sites marchant sur firefox et pas sur chrome... juste au cause d'un filtre js...

Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
# Please fill out this field

Posté par Antoine le 09 février 2012 à 22:49. Évalué à -3.

Le problème se pose massivement sur les navigateurs mobiles, où webkit domine très largement, car il est le navigateur par défaut des appareils iOS et Android. Daniel Glazman, co-chairman du CSS Working Group, a donc lancé un appel, avec l'appui du CSS Working Group.

Donc, le « problème » c'est que les développeurs Web essaient de résoudre les besoins qui se posent à eux ?
Il n'est pas un peu gonflé, Daniel Glazman co-chairman du CSS Working Group avec l'appui du CSS Working Group ? S'ils se sortaient les doigts du cul pour répondre aux besoins des développeurs, peut-être que ceux-ci n'auraient pas besoin d'extensions. Un standard est là pour suivre l'évolution de l'écosystème, pas pour jouer les pères-la-morale.

Sérieux, pourquoi pas râler contre le fait que Linux offre des appels système en plus de POSIX ?
- [^] # Re: Please fill out this field
  
  Posté par Laurent J (site web personnel, Mastodon) le 10 février 2012 à 00:02. Évalué à 10.
  
  Donc, le « problème » c'est que les développeurs Web essaient de résoudre les besoins qui se posent à eux ?
  
  non le problème c'est que tu ne sais pas lire.
  
  Actuellement, de plus en plus de sites utilisent les propriétés en -webkit-, apportant des facilités. soit. Mais malheureusement, ils n'utilisent pas aussi les propriétés équivalentes en -moz -o etc.. ET donc on en arrive à avoir des sites "optimisés pour webkit". Bref, c'est le nouveau IE6, avec toutes les conséquences que l'on connait.
  
  À cela, il semblerait que des fabricants de navigateurs seraient prêts à nommer leurs propriétés expérimentales en -webkit- plutôt qu'utiliser leur propre prefixe. Comme ce sont en général des propriétés expérimentales, donc sous-spécifiées, ça va être un bordel monstre pour les développeurs (puisqu'on aura forcément des différences de comportements ou de syntaxe d'un navigateur à l'autre).
  
  S'ils se sortaient les doigts du cul pour répondre aux besoins des développeurs, peut-être que ceux-ci n'auraient pas besoin d'extensions.
  
  aheum... Faudrait que tu ailles jeter un coup d'oeil aux specifications en cours de redaction sur le site w3.org, tu verrais que le W3C ne chôme pas.
  
  D'autre part, avec cette réflexion, tu sembles ne pas connaitre le fonctionnement du W3C, alors je vais te l'apprendre : les membres d'un groupe de travail, comme le CSSWG, sont composés... d'employés des sociétés qui fabriquent les navigateurs. Ce sont donc ces sociétés qui écrivent les specs aux W3C. Si le CSSWG n'avance pas assez vite, il ne faut pas s'en prendre au W3C, mais à Apple, MS, Google, Mozilla, Opera etc...
  
  De plus, des gens comme google ou apple, implémentent des propriétés en -webkit-, sans soumettre les spécifications au W3C. Tu veux que le W3C fasse quoi fasse à ça ? Le CSSWG ne va pas deviner tout seul la spécification de telle ou telle nouvelle propriété expérimentale implémentée dans tel navigateur. D'autant plus qu'il y a de fortes chances qu'il y ait des brevets logiciels là dessus. le W3C ne peut qu'attendre après ces sociétés, qu'elles proposent ces specs (les specs proposées deviennent alors royalty free et les brevets qui y seraient éventuellement attachés deviennent "inoffensifs").
  
  Enfin bref, le problème n'est pas totalement du coté du W3C, mais aussi des fabricants de navigateurs, et principalement, au final, des développeurs qui utilisent des trucs pas terminés ou pas standards. et le problème c'est que ce comportement est en train de pourrir leur metier, puisqu'on va arriver à un nouveau problème de type IE6only, mais pire encore...
  - [^] # Re: Please fill out this field
    
    Posté par Antoine le 10 février 2012 à 01:18. Évalué à -10.
    
    ET donc on en arrive à avoir des sites "optimisés pour webkit". Bref, c'est le nouveau IE6, avec toutes les conséquences que l'on connait.
    
    Si j'utilise disons une fonction non-POSIX, mon but n'est pas de faire chier un organisme de normalisation mais de satisfaire un besoin. Le jour où POSIX inclut une fonctionnalité équivalente, eh ben tant mieux : je peux migrer mon code vers une API plus portable.
    
    De plus, des gens comme google ou apple, implémentent des propriétés en -webkit-, sans soumettre les spécifications au W3C. Tu veux que le W3C fasse quoi fasse à ça ?
    
    Je ne m'attends certainement pas à ce qu'il fasse des communiqués pour culpabiliser les développeurs ! Si les éditeurs en question décident d'implémenter les propriétés et que les développeurs décident de les utiliser, c'est qu'il y a un besoin. Au W3C de les fournir à la nouvelle itération et tout le monde sera content. En attendant, qu'ils évitent de la ramener...
    
    tu sembles ne pas connaitre le fonctionnement du W3C, alors je vais te l'apprendre : les membres d'un groupe de travail, comme le CSSWG, sont composés... d'employés des sociétés qui fabriquent les navigateurs
    
    Je ne vois pas pourquoi leurs problèmes d'organisation interne les autorisent à incriminer les développeurs Web qui, eux, n'y sont pour rien.
    
    L'argument jésuitique qui consiste à dire que les développeurs sont coupables alors que c'est 1) le W3C qui définit les standards 2) les éditeurs membres du W3C qui écrivent les implémentations (y compris les extensions), c'est du foutage de gueule.
    - [^] # Re: Please fill out this field
      
      Posté par Laurent J (site web personnel, Mastodon) le 10 février 2012 à 10:16. Évalué à 10.
      
      Si j'utilise disons une fonction non-POSIX, mon but n'est pas de faire chier un organisme de normalisation mais de satisfaire un besoin. Le jour où POSIX inclut une fonctionnalité équivalente, eh ben tant mieux : je peux migrer mon code vers une API plus portable.
      
      Oui. Tout comme les développeurs peuvent migrer leur code. Mais dans 99% des cas, ils ne le font pas. Parce qu'une fois le site développé, les "vieux" trucs restent. Et parfois très longtemps. Surtout quand ceux qui sont chargés de faire évoluer le site ne sont pas les développeurs initiaux. Il arrive trèèèèès souvent qu'ils ne touchent qu'à ce qu'il y a besoin d'être touché, par manque de temps, par peur de casser des choses, par j'm'enfoutisme etc..
      
      Au W3C de les fournir à la nouvelle itération
      
      Tu es à coté de la plaque. Les éditeurs implementent les trucs BIEN AVANT de proposer des specs au W3C. C'est pas le W3C qui "fournit".
      
      Je ne vois pas pourquoi leurs problèmes d'organisation interne les autorisent à incriminer les développeurs Web qui, eux, n'y sont pour rien.
      
      Non, ce sont les développeurs web qui sont responsables. les propriétés prefixées sont pour la plupart des trucs experimentaux. LES DEVELOPPEURS NE SONT PAS CENSES LES UTILISER. Ou si ils les utilisent, qu'ils aient au moins le courage de mettre les propriétés préfixés pour les autres navigateurs ET de mettre celles sans prefixe, ceci afin de garantir un minimum que leur site fonctionnera PARTOUT et dans la durée.
      
      Un développeur web est censé suivre les standards. C'est son job de faire en sorte que son site (public) soit lisible partout, parce que c'est la nature même du web d'être "agent agnostic". Ne pas le faire est une faute professionnelle selon moi. Ne pas le faire, c'est ne pas suivre les "rêgles" du WEB. Si on ne veut pas suivre ces rêgles, il faut changer de branche.
      
      Imaginons qu'un navigateur X non basé sur webkit gagne énormément de part de marché pour X raisons, sur le mobile. Que va-t-il arrivé ? Plein de sites cassés. Parce que des développeurs incompétents n'auront pas fait leur job comme il faut, en utilisant des trucs prefixés ciblant un seul navigateur. Bref, des développeurs comme il y en avait au temps de IE6. Avec les conséquences que l'on connait.
      - [^] # Re: Please fill out this field
        
        Posté par ckyl le 10 février 2012 à 16:58. Évalué à 4.
        
        Non, ce sont les développeurs web qui sont responsables. les propriétés prefixées sont pour la plupart des trucs experimentaux. LES DEVELOPPEURS NE SONT PAS CENSES LES UTILISER.
        
        Si c'est pas fait pour être utilisé pourquoi les livrer ? Qui plus est dans des versions stables des navigateur ?
        
        Quand on offre le support de quelque chose, il faut pas venir se plaindre que ca soit utilisé.
        
        [^] # Re: Please fill out this field
        
        Posté par Jux (site web personnel) le 10 février 2012 à 19:08. Évalué à 3.
        
        Les gens qui se plaignent et ceux qui développent les navigateurs ne sont pas forcément les mêmes personnes :)
        
        Ceci dit, la solution qui serait la plus saine, c'est que les navigateurs se mettent d'accord pour désactiver ces extensions spécifiques par défaut. Il faudrait passer par une option pour les activer. Ca permettrait aux développeurs de tester les dernières nouveautés, mais ça forcerait les webmaster à ne pas les utiliser, sachant que 90% des utilisateurs ne vont pas toucher les options de leur navigateur et ne les auront donc pas activées.
        
        [^] # Re: Please fill out this field
        
        Posté par Antoine le 13 février 2012 à 23:33. Évalué à -4.
        
        Les gens qui se plaignent et ceux qui développent les navigateurs ne sont pas forcément les mêmes personnes :)
        
        Non, mais c'est la même organisation, à savoir le W3C (par la voix d'un de ses représentants). Ce qui rend la complainte bien hypocrite.
        
        [^] # Re: Please fill out this field
        
        Posté par Ivan Le Lann le 16 février 2012 à 11:00. Évalué à -1.
        
        J'y connais pas grand chose, mais peut-être est-ce livré pour être utilisé dans des cadres contrôlés, hors navigateur "pur" donc, quand l'utilisation du HTML est "cachée" par un client spécifique. (Exemple: le client Steam, il me semble)
      - [^] # Re: Please fill out this field
        
        Posté par Antoine le 13 février 2012 à 23:41. Évalué à -1.
        
        Un développeur web est censé suivre les standards. C'est son job de faire en sorte que son site (public) soit lisible partout
        
        Non, ça c'est ta vision de ce que devrait faire un développeur Web. Je vois bien que ça t'embête (ainsi que cette andouille que Glazman) que certains développeurs Web raisonnent différemment, et je partage la préoccupation de fond concernant l'interopérabilité du Web. Par contre l'attitude consistant à culpabiliser les développeurs alors qu'ils utilisent des extensions implémentées par les éditeurs (eux-mêmes membres du W3C) est d'une lâcheté incroyable.
        
        Si vous aviez un semblant de courage politique, vous porteriez le fer là où est le problème : dans l'attitude des éditeurs qui, je te cite, « implementent les trucs BIEN AVANT de proposer des specs au W3C ».
        
        des trucs experimentaux. LES DEVELOPPEURS NE SONT PAS CENSES LES UTILISER
        
        Oui, oui, bien sûr. Les trucs sont publiquement disponibles, certainement documentés, bref tout est fait pour que les développeurs puissent les utiliser, mais ce sont les développeurs les méchants car ils les utilisent !
        
        Décidément, il n'y a pas pire aveugle que celui qui ne veut pas voir.
        
        [^] # Re: Please fill out this field
        
        Posté par djano le 07 mars 2012 à 09:02. Évalué à 2.
        
        Par contre l'attitude consistant à culpabiliser les développeurs alors qu'ils utilisent des extensions implémentées par les éditeurs (eux-mêmes membres du W3C) est d'une lâcheté incroyable.
        
        Ce n'est pas parce que les éditeurs font partie du W3C qu'ils soumettent tous leurs travaux au W3C, loin de la. Tu te heurte a la main droite qui ignore ce que fait la main gauche.
        Tu as raison: les éditeurs font tout pour que leurs travaux soit utilisables, mais ils ne font pas tout pour que ce soit standardisé, loin de la.
        
        Maintenant, je ne comprend pas ta défense de certains développeurs web qui font des sites webkit-only tout comme l'on avait des sites IE-only. Ce ne sont quand même pas les éditeurs de navigateurs qui ont forcé les développeurs a faire ça?
        
        Alors je maintiens que le problème est double, et c'est exactement ce que Daniel Glazman dit aussi (respire un coup et relis ce qu'il a écrit). L'appel du W3C CSS Working Group demande a TOUT LE MONDE de faire un effort pour stopper cette situation: les éditeurs de navigateurs, les développeurs web et les utilisateurs de sites web.
    - [^] # Re: Please fill out this field
      
      Posté par TImaniac (site web personnel) le 10 février 2012 à 10:40. Évalué à 10.
      
      Si j'utilise disons une fonction non-POSIX, mon but n'est pas de faire chier un organisme de normalisation mais de satisfaire un besoin.
      
      Oui mais tu crées une application non portable. On peut s'en branler totalement dans le contexte de ton programme dont tout le monde se cogne, mais quand on parle d'un site web, certains sont attachés à une certaine interopérabilité et au respect des standards pour permettre à chacun de librement choisir son navigateur.
      
      Je ne vois pas pourquoi leurs problèmes d'organisation interne les autorisent à incriminer les développeurs Web qui, eux, n'y sont pour rien.
      
      Les développeurs font ce qu'ils veulent on est d'accord, comme y'a 10 ans ils avaient tout à fait le droit de faire un site IE6 only avec de bons gros ActiveX qui répondaient à leurs besoins. Mais il est normal d'attirer leur attention sur la problématique de l'interopérabilité et à faire attention de ne pas s'enfermer dans une logique où il n'y aurait qu'un seul navigateur.
  - [^] # Re: Please fill out this field
    
    Posté par Manuel Vonthron (site web personnel) le 10 février 2012 à 02:28. Évalué à 4.
    
    Il me semble que quelqu'un (et je crois justement que c'était Glazman) avait proposé de limiter le support des propriétés préfixées aux versions de développement des navigateurs.
    Les versions stables ne supporteraient alors que les propriétés normalisées. Ça râlerait dans les chaumières mais si tout le monde joue le jeu (ce qui n'est pas une mince affaire) le problème serait réglé et il serait toujours possible de tester les implémentations et les futures propriétés.
    - [^] # Re: Please fill out this field
      
      Posté par Laurent J (site web personnel, Mastodon) le 10 février 2012 à 10:17. Évalué à 3.
      
      oui, c'est une bonne idée. Mais j'ai bien peur qu'il soit trop tard, vu apparemment les centaines de milliers de sites pour mobile qui ciblent webkit..
      - [^] # Re: Please fill out this field
        
        Posté par djano le 07 mars 2012 à 09:08. Évalué à 2.
        
        Ce n'est pas parce que la situation actuelle est mauvaise que l'on doit la laisser se pourrir encore plus.
        
        Si a partir d'aujourd'hui, toute nouvelle fonctionnalité est "protégée" d'une libre utilisation dans la nature comme Manuel Vonthron et Daniel Glazman le proposent, alors on va s'épargner le besoin de refaire une telle campagne de comm' dans le futur.
        
        Reste a convaincre tous les éditeurs de navigateurs. Ce ne sera pas une mince affaire. Mais chat échaudé craint l'eau froide? S'ils n'aiment pas la situation actuelle, alors ils vont faire quelque chose pour 1) qu'elle ne se reproduise jamais, 2) qu'elle se résorbe petit a petit.
- [^] # Re: Please fill out this field
  
  Posté par Laurent J (site web personnel, Mastodon) le 10 février 2012 à 00:07. Évalué à 7. Dernière modification le 09 juillet 2020 à 19:35.
  
  Un bel article pour mieux comprendre le problème http://www.webmonkey.com/2012/02/webkit-isnt-breaking-the-web-you-are/ NdM: lien cassé remplacé par https://www.wired.com/2012/02/webkit-isnt-breaking-the-web-you-are/
  - [^] # Re: Please fill out this field
    
    Posté par bilboa le 10 février 2012 à 08:48. Évalué à 3.
    
    attention car c'est un point de vue, pas une explication.
    webkit "break" le web car on est pas dans un monde idéal, tout le monde sait très bien que personne n'arrêtera d'utiliser les prefix, sauf si les navigateur arrêtent de les proposer.
    
    Vu que Google sort des trucs sans le webkit- en moins de 3 mois je pense pas qu'on ai besoin de balises.
    
    Il "suffit" de fixer CSS et d'arrêter l'usage des balises au niveau de webkit, gecko, etc.
  - [^] # Re: Please fill out this field
    
    Posté par djano le 07 mars 2012 à 09:19. Évalué à 2.
    
    Euh, je suis moyennement d'accord. Comme il le dit bien:
    
    At the same time both Apple and Google have set some bad examples by building a number of WebKit-only demos that might be part of what lead some developers to conclude that only WebKit supports such features. That has also spilled over into the world of tutorials where even sometimes even standards advocates showcase -webkit in their sample code while ignoring -moz-, -ms- and -o-*.
    
    Appelez ça gagner de la part de marché, appelez ça lock-in, mais oui ils ont une responsabilité la dedans. Laisser cette porte ouverte, a laissé certains développeurs peu soucieux ou ignorant des standards du web s'engouffrer dedans sans se poser aucune question.
    
    Je comprends les besoins des navigateurs de se différencier et de proposer des innovations, mais je regrette qu'ils ne jouent pas le jeu des standards en premier. Lâcher une implémentation non spécifiée dans a la nature tout en faisant de la communication sur ces nouvelles fonctionnalités super-cool sans communiquer les habituels garde-fous (EXPÉRIMENTAL, etc.) montre une responsabilité.
    
    Mozilla est bien plus vertueux lorsqu'ils publient publiquement des specs pour les nouvelles fonctionnalités, lorsqu'il les poussent dans les comités du W3C (ou du WHATWG précédemment) et ainsi de suite. Si tous les éditeurs faisaient la même chose, on n'en serait pas la.
    
    Bref, je refuse de dire que le problème est uniquement du cote des développeurs web. C'est trop facile de dire ça.
- [^] # Re: Please fill out this field
  
  Posté par djano le 07 mars 2012 à 08:54. Évalué à 2.
  Le problème est double:
  1. Le mécanisme des extensions spécifiques au navigateur ont été créées pour permettre de tester les propositions de fonctionnalités faites au W3C CSS Working Group. Le problème c'est que ces propriétés sont accessibles dans les versions stables des navigateurs sans rien faire de spécial. Daniel Glazman a déjà dit que c’était un problème et que ce serait bien mieux si ces propriétés n'étaient accessibles que lorsque l'on active une configuration spéciale.
  2. Les développeurs web se sont emparés de ces possibilités et ont commencé a créer des sites webs avec elles. Malheureusement ce qu'ils n'ont pas compris, c'est que ces fonctionnalités sont EXPÉRIMENTALES, parfois propriétaires car non soumises au W3C, parfois refusées par le W3C, parfois sous spécifiées, souvent pleines de bugs, …. Bref, autant je comprends leurs besoins, autant ils ont joué avec le feu surtout lorsque certains n'utilisaient que les extensions spécifiques a webkit.
  Daniel Glazman fait parti du camp des éditeurs de navigateurs puisqu'il travaille énormément sur et autour de gecko.
  
  Bref, le W3C CSS Working Group demande:
  - aux éditeurs de fournir les specs des extensions au W3C.
  - aux développeurs web de faire des sites web qui marchent avec tous les navigateurs (le plus possibles en tout cas) et pas seulement webkit, en utilisant les préfixes des autres navigateurs et les propriétés non préfixées lorsque cela est possible.
  - aux développeurs web d'arrêter de faire des sites web qui refoulent toute personne n'utilisant pas IE/Firefox/webkit.
  - aux utilisateurs de site web de se plaindre aux sites webs qui ne fonctionnent qu'avec un navigateur et de ne pas recommander de tels sites.
# Les mêmes problèmes qu'il y a 10 ans

Posté par Pierre Jarillon (site web personnel) le 10 février 2012 à 02:52. Évalué à 10. Dernière modification le 10 février 2012 à 16:05.

Il y a 10 ans les mêmes problèmes se posaient avec les extensions de Microsoft. Le sites facilement générés avec FrontPage ne fonctionnaient bien qu'avec IE6 et ceci à l'insu des utilisateurs qui croyaient avoir bien fait.

Le site de référence pour le web est http://openweb.eu.org/ . J'y ai puisé de nombreux conseils et finalement, sans grand effort, j'ai réalisé des sites valides (conformes aux normes du W3C) et accessibles. Pour cela je n'ai utilisé aucun artifice ni aucune spécifité des navigateurs¹.
On peut voir mes sites aussi bien sur un smartphone que sur un écran 1980x1200 de 66 cm.

¹ En vérité j'ai utilisé quand même utilisé une instruction conditionnelle dans l'un d'eux :


- [^] # Re: Les mêmes problèmes qu'il y a 10 ans
  
  Posté par CrEv (site web personnel) le 10 février 2012 à 09:33. Évalué à 6.
  
  Il y a 10 ans les mêmes problèmes se posaient avec les extensions de Microsoft.
  
  Pas tout à fait.
  Ici on se plaint d'un usage trop important (et parfois incorrect) de fonctionnalités prévues par le W3C. Les préfixes font partie des normes, c'est juste que leur usage peut ne pas être idéal si on utilise uniquement les préfixes et pas la version non préfixée, pire si on utilise uniquement une version d'un navigateur en oubliant les autres.
  Mais il ne faut pas tout mélanger, il ne s'agit pas d'extensions purement spécifiques, incompatibles et indisponibles avec les autres navigateurs.
  D'un côté c'est bien ce fonctionnement qui a été voulu avec HTML5 (et surtout virer la version) : avoir quelque chose en évolution constante. Et ça va assez loin, bien au delà du css, par exemple des changements au niveau d'XHR peuvent transformer des appels synchrones en asynchrones juste parce que la spec a changée en cours de route (http://updates.html5rocks.com/2012/01/Getting-Rid-of-Synchronous-XHRs oar exemple) (avant le troll, oui parfois un appel synchrone est bienvenue, par exemple pour soumettre un formuaire d'authentification).
- [^] # Re: Les mêmes problèmes qu'il y a 10 ans
  
  Posté par kertiam le 10 février 2012 à 11:13. Évalué à 2.
  
  Sans rien enlever à ton propos, le w3c édite des recommandations. Non des normes.
# hum...

Posté par CrEv (site web personnel) le 10 février 2012 à 07:12. Évalué à 7.

Je dois dire que je suis plutôt mitigé face à cet appel... (je base sur la version fr)

nous sommes devant un nouveau monopole: celui du moteur de rendu WebKit

Heu, oué, mais pourquoi ? Si on arrive à cette situation c'est, en partie, parce que Gecko n'a jamais été un bon candidat pour être embarqué facilement alors que webkit a tout fait pour. Ce que je veux dire par là c'est : quel serait l'autre choix que d'embarquer du webkit aujourd'hui ? Et ça c'est pas la faute de webkit...
Donc si les sites mobiles (entre autre) sont par défaut optimisés pour webkit c'est simplement que le presque seul navigateur sur mobile c'est ... webkit. C'est un choix qui peut donc paraître tout à fait logique (il n'y a quasiment que du webkit alors je met du webkit).

En pratique le problème c'est quoi ?

Ben le problème c'est que s'il y avait autre chose que du webkit, si gecko était facilement embarquable, etc, le problème n'existerait surement pas

L'autre par du problème (c'est un peu ce que dit Antoine) c'est qu'en tant que dev on veut des propriétés CSS. Donc on prend ce qui existe.
Et franchement avoir besoin de 7 lignes pour faire un dégradé c'est vraiment gonflant ! Donc si je sais sur quelle plateforme ça va tourner je vais réduire au max.
Et heureusement qu'il existe des frameworks comme less, sass, closure stylesheets car sans cela le web serait inutilisable côté style (enfin si, mais uniquement avec le dénominateur commun en terme de propriétés non préfixées).

Au final :
Je suis totalement d'accord avec la conclusion de l'article, il faut évidemment avoir toutes ces bonnes pratiques, mais pas du tout de la manière dont c'est amené (monopole, webkit, etc ... mais où est gecko ? mozilla n'aurait-il pas encore une fois raté le coche ?)
- [^] # Re: hum...
  
  Posté par bilboa le 10 février 2012 à 08:56. Évalué à 1.
  
  Dans ta logique, IE6 était le meilleur browser donc c'est normal d'avoir tout "standardizé" dessus (et puis activex aussi,le seul truc qui fait du natif, donc hein, pourquoi faire standard et ouvert?)
  
  Ca ne rime a rien. Tout le monde peut faire tourner webkit, mais il faut garder les standard, standards, et ouvert.
  Et le vote sur les standards tout aussi ouvert (et pas avec 90% d'ingés Google évidement)
  - [^] # Re: hum...
    
    Posté par CrEv (site web personnel) le 10 février 2012 à 09:28. Évalué à 5.
    
    Mais qu'est-ce que tu racontes ?
    
    Dans ta logique, IE6 était le meilleur browser
    
    T'as lu ça où ? Nan mais vas-y, explique un peu car là je vois pas.
    
    Tout le monde peut faire tourner webkit
    
    Oui, et le problème c'est que c'est le seul moteur html/css qui s'embarque bien, et ça c'est pas la faute de webkit c'est la faute des autres qui ne font pas grand chose pour et qui se plaignent ensuite. Moi j'aimerais bien avoir des navigateurs sous gecko, webkit, et même le moteur d'IE10 un peu partout. Mais c'est pas le cas et c'est pas pour rien. C'est pas pour rien non plus que les navigateurs précédemment basés sur gecko migrent sur webkit (on a surtout l'impression qu'à l'époque il y avait du gecko juste parce que c'était la seule solution, et maintenant qu'il y a mieux tout le monde passe à quelque chose de mieux)
    
    mais il faut garder les standard, standards, et ouvert
    
    C'est quelle partie de Je suis totalement d'accord avec la conclusion de l'article, il faut évidemment avoir toutes ces bonnes pratiques que tu ne comprends pas ?
    - [^] # Re: hum...
      
      Posté par Etienne Bagnoud (site web personnel) le 10 février 2012 à 12:50. Évalué à -1.
      
      Dans ta logique, IE6 était le meilleur browser
      
      T'as lu ça où ? Nan mais vas-y, explique un peu car là je vois pas.
      
      À la fin de la BW 1 ...
      
      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
  - [^] # Re: hum...
    
    Posté par Jux (site web personnel) le 10 février 2012 à 10:18. Évalué à 1.
    
    Il y a quand même une différence entre Webkit et IE6 : Webkit est libre. Les specs des propriétés webkit-* sont donc accessibles. J'imagine qu'il y a également des specs écrits qu'on peut trouver ou des discussions entre les dev Webkit. Bref, là où IE6 était une boîte noire au comportement vraiment bizarre, Webkit est au moins ouvert.
    
    Ceci dit, je suis tout à fait d'accord avec les arguments de l'appel. C'est juste que la comparaison WebKit = IE6 n'est pas vraiment exact.
    - [^] # Re: hum...
      
      Posté par Laurent J (site web personnel, Mastodon) le 10 février 2012 à 12:52. Évalué à 6.
      
      Oui il y a cette différence d'ouverture de source et de spec.
      
      Mais il n'y a aucune différence quant à la situation et aux conséquences. Le problème se situe dans l'utilisation de propriété non standards ou experimentales. Tout comme avec IE6, les développeurs utilisent des fonctionnalités qui ne sont implémentées que dans un seul moteur de navigateur (ou qui ne sont interprétables que par un seul moteur de navigateur). Cela conduit donc à un web "optimisé pour", tout comme avec IE6. Le fait que lesdites fonctionnalités soient implémentées sous licence libre ou proprio ne change rien au problème, et encore moins à une éventuel solution. On assiste à nouveau à une balkanisation du web.
    - [^] # Re: hum...
      
      Posté par Littleboy le 12 février 2012 à 00:04. Évalué à 4.
      
      Les specs des propriétés webkit-* sont donc accessibles. J'imagine qu'il y a également des specs écrits qu'on peut trouver ou des discussions entre les dev Webkit. Bref, là où IE6 était une boîte noire au comportement vraiment bizarre, Webkit est au moins ouvert.
      
      Deja, la doc se resume souvent a peau de chagrin, donc ca commence mal. Ensuite le gros probleme d'aller pecher le fonctionnement dans le code source, c'est que tu zappes l'etape ou Apple fournit les specs au W3C sous RAND, et donc c'est potentiellement couvert par des brevets (et vu le comportement d'Apple sur d'autres parties de la spec, faut pas avoir peur de se faire attaquer...)
- [^] # Re: hum...
  
  Posté par Okki (site web personnel, Mastodon) le 10 février 2012 à 11:15. Évalué à 3.
  
  De ce que j'ai lu dans l'article anglophone de Wikipédia concernant Opera Mini, il semblerai que ce dernier ai tout de même des parts de marché non négligeables dans le domaine de l'embarqué. Il n'y a donc pas que Webkit.
  - [^] # Re: hum...
    
    Posté par CrEv (site web personnel) le 10 février 2012 à 11:30. Évalué à 3.
    
    Tout dépend ce qu'on regarde.
    Si on prend les téléphones, oui, opera mini est là. (perso je ne l'utilise pas, ne serait-ce que parce que tout est proxifié)
    D'ailleurs ce proxy vient un peu tout fausser, son but est de transformer les pages pour quelles soient plus lisibles sur mobile, en gros je vois pas comment on peut bien coder en pensant à ça comme cible...
    
    Par contre, si on prend les smartphones et tablettes (sûrement les plus gros consommateurs) on a surtout du webkit (safari, navigateur d'android, chrome). Il y a un peu de gecko et deux trois autres (dolphin, mais je sais plus si c'est un moteur maison ou non) et opéra (mais je ne vois personne dans mon entourage l'utiliser)
    - [^] # Re: hum...
      
      Posté par BohwaZ (site web personnel, Mastodon) le 10 février 2012 à 13:37. Évalué à 4.
      
      Opera (Mini/Mobile), est juste le brouteur mobile le plus utilisé au monde.
      
      Opera Mobile est un vrai navigateur, pas de proxy (enfin c'est facultatif, mais le proxy ne fait alors que compresser le contenu, toute l'interprétation est au client), alors que Mini est un navigateur déporté où la plus grande partie de l'interprétation se fait au niveau du serveur, le client recevant quelque chose de très simplifié.
      
      A noter qu'il existe des dizaines de navigateurs web déportés comme ça, certains très populaires, comme UC Browser (10% de part de marché en Asie, très sympa avec son mode nuit qui inverse les couleurs des pages web pour une lecture un peu plus reposante) ou le Nokia Browser (ex-OVI Browser, 30% de part de marché, basé sur Gecko) qui est fourni dans les téléphones Series40 de Nokia. Si on additionne Opera et ces deux-là, on arrive déjà à 80% de part de marché en asie. C'est à dire que là-bas les navigateurs webkit c'est que dalle, le marché est écrasé par les navigateurs déportés.
      
      Le marché européen est différent, mais le web c'est mondial :-)
      
      « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
      - [^] # Re: hum...
        
        Posté par usbplug le 12 février 2012 à 21:32. Évalué à -1.
        
        Je suis étonné.
        
        Ici, aux US, personne ou presque ne connait Opera.
        
        Tout au plus, les gens connaissent vaguement, de nom, mais n'ont jamais entendu parler d'Opera Mini et des proxies.
        
        Obligé d'expliquer "c'est un peu comme le truc d'Amazon pour le Kindle Fire". Là, ça clique immédiatement.
      - [^] # Re: hum...
        
        Posté par Frank-N-Furter le 13 février 2012 à 11:09. Évalué à 1.
        
        Ouais, et? Vu que le proxy va remâcher la page, il va de toute façon gicler les propriétés en -webkit-.
        
        Depending on the time of day, the French go either way.
    - [^] # Re: hum...
      
      Posté par navaati le 10 février 2012 à 20:06. Évalué à 3.
      
      Faut noter quand même qu'avec les pubs massives pour le Lumia (un phone de nokia sous Windows Phone), les sites pour mobile vont voir arriver une quantité non négligeable de gens qui seront pas sous webkit mais sous… IE Mobile (ou un truc dans le genre).
      
      Et là, si les sites se cassent vraiment la gueule sous autre chose que webkit, on va bien se marrer \o/.
      - [^] # Re: hum...
        
        Posté par nud le 13 février 2012 à 12:16. Évalué à 2.
        
        Encore faut-il que les gens achètent le Lumia, qui paraît-il est bien en dessous des ventes du N9 qui n'a pourtant bénéficié d'aucun marketting...
      - [^] # Re: hum...
        
        Posté par Argon le 13 février 2012 à 22:20. Évalué à 4.
        
        Et là, si les sites se cassent vraiment la gueule sous autre chose que webkit, on va bien se marrer \o/.
        
        Il ne se passera pas grand chose dans la plupart ces cas. Pour le moment les préfixes servent surtout pour des balises "cosmétiques". Les web designers s'en servent pour faire des ombres, des bordures arrondies ou des effets de transitions mais ça reste simple. Un navigateur qui ne comprend aucune de ces balises affichera le site correctement. Le rendu sera juste moins flatteur. C'est d'ailleur pour ça que je trouve la comparaison avec la période IE6 un peu limite.
        
        de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
    - [^] # Re: hum...
      
      Posté par Laurent Mouillart le 10 février 2012 à 23:56. Évalué à 2.
      
      J'utilise beaucoup Opera Mini/Mobile car lorsque le réseau 3G (parisien) est saturé c'est le seul qui passe et qui permet de surfer rapidement, justement grâce au proxy de compression.
# Commentaire supprimé

Posté par Anonyme le 11 février 2012 à 12:32. Évalué à 10.

Ce commentaire a été supprimé par l’équipe de modération.
- [^] # Re: ptet que le probleme est ailleurs
  
  Posté par Laurent Pointecouteau (site web personnel, Mastodon) le 18 février 2012 à 18:12. Évalué à 0. Dernière modification le 18 février 2012 à 18:12.
  
  Quel rapport avec vouloir mettre un dégradé de couleur en arrière-plan ? Le CSS, pour ce que j'en connais, n'a rien à voir avec l'"(i)OS-ification" du web. Pour ça, faut voir avec les Chromebooks et Boot2Gecko.
  - [^] # Commentaire supprimé
    
    Posté par Anonyme le 18 février 2012 à 19:46. Évalué à 1.
    
    Ce commentaire a été supprimé par l’équipe de modération.
    - [^] # Re: ptet que le probleme est ailleurs
      
      Posté par Laurent Pointecouteau (site web personnel, Mastodon) le 19 février 2012 à 14:17. Évalué à 1.
      
      Je ne suis pas un grand fan de préfixes CSS à tout va, mais je pense que tu te trompes d'ennemi. Ce n'est pas un dégradé de couleur qui rend les pages web lentes à la détente sur un vieil ordi. J'en sais quelque chose, mon ordi était un P4 à 512 de RAM jusqu'à septembre dernier, et effectivement, fallait avoir le goût du risque pour aller sur un profil Myspace sans Flashblock, par exemple. Mais ça n'a aucun rapport avec les feuilles CSS. Qui peuvent d'ailleurs être désactivées pour rendre la page plus légère : le HTML est conçu pour ça.
      
      Personne n'a attendu le CSS3 pour se livrer à la surenchère de trucs inutiles de toute façon : pour les autres, c'est une technologie qui permet de rendre leurs pages plus jolies sans recourir aux images ou aux scripts. Elle ne mérite pas d'être taxée de "branlette".
      - [^] # Commentaire supprimé
        
        Posté par Anonyme le 22 février 2012 à 07:12. Évalué à 1.
        
        Ce commentaire a été supprimé par l’équipe de modération.
# Commentaire supprimé

Posté par Anonyme le 13 février 2012 à 10:27. Évalué à -4.

Ce commentaire a été supprimé par l’équipe de modération.
- [^] # JS à la poubelle !
  
  Posté par Octabrain le 13 février 2012 à 13:27. Évalué à -1.
  - [^] # Commentaire supprimé
    
    Posté par Anonyme le 13 février 2012 à 15:43. Évalué à -3.
    
    Ce commentaire a été supprimé par l’équipe de modération.
# Le pb ne viens pas des développeurs mais des navigateurs.

Posté par Olivier LAHAYE (site web personnel) le 13 février 2012 à 12:58. Évalué à -3.

Quelle idiotie d'avoir inventé ces préfixes!!!

Ils ne pouvaient pas mettre directement le bon nom sans préfixe et dans un paramétrage (caché (genre about:config) ou pas (bouton avancé dans les préférences)) mettre l'option "support des fonctionnalités expérimentales"?

À part ça, c'est marrant de voir les gens s'énerver contre -webkit- alors que on a rien entendu lors des -moz-.

De toutes façons, webkit est un super moteur, alors pourquoi s'en plaindre?
# Commentaire supprimé

Posté par Anonyme le 13 février 2012 à 15:54. Évalué à -10.

Ce commentaire a été supprimé par l’équipe de modération.
- [^] # Re: lib
  
  Posté par Octabrain le 14 février 2012 à 20:38. Évalué à 3. Dernière modification le 14 février 2012 à 20:41.
  
  Ça résume bien l'attitude des gens du web ça...
  
  "-webkit- c'est de la merde ? Non on va pas corriger c'est trop chiant. Rechercher-remplacer ? Trop chiant je te dis ! Alors qu'on pourrait surcharger encore un peu plus le navigateur avec encore une lib javascript à la con trouvée sur github, pourquoi se priver ?"
  - [^] # Commentaire supprimé
    
    Posté par Anonyme le 15 février 2012 à 12:34. Évalué à -10.
    
    Ce commentaire a été supprimé par l’équipe de modération.
# Mon avis de noob du développement web.

Posté par deasy le 16 février 2012 à 17:50. Évalué à -1.

J'ai démarré le site de ma soeur en html5.
Pour certaines choses dans le css j'ai vu qu'il y a des préfixes mais j'ai testé la version sans préfixe tout simplement.
Et bien la plupart du temps ça fonctionne.
Donc n'utilisez pas les préfixes tout simplement.
- [^] # Re: Mon avis de noob du développement web.
  
  Posté par claudex le 16 février 2012 à 18:05. Évalué à 2. Dernière modification le 16 février 2012 à 18:06.
  
  Ce qui est vrai pour les navigateurs très récents ne l'est pas forcément pour les versions précédentes.
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: Mon avis de noob du développement web.
    
    Posté par deasy le 16 février 2012 à 18:39. Évalué à -2. Dernière modification le 16 février 2012 à 18:42.
    
    Dans cette logique, on en serait encore à l'âge de pierre.
    Définir très récent: j'ai testé sur plusieurs nav et plusieurs versions, ça passe sans les préfixes.
    - [^] # Re: Mon avis de noob du développement web.
      
      Posté par ckyl le 16 février 2012 à 19:06. Évalué à 2.
      
      C'est vrai que si ca marche avec le site de sœur c'est qu'on peut y aller ! On va pouvoir arrêter de se prendre la tête et aller à la piscine à la place \o/
      
      Le site web de ta sœur ca vaut toute l'XP des devs frontend et la QA du monde.
      - [^] # Re: Mon avis de noob du développement web.
        
        Posté par Anonyme le 16 février 2012 à 19:41. Évalué à 2.
        
        Le site web de ta sœur ca vaut toute l'XP des devs frontend et la QA du monde.
        
        FOUTAISE §
        
        [^] # Re: Mon avis de noob du développement web.
        
        Posté par deasy le 17 février 2012 à 00:01. Évalué à -1.
        
        En effet quand on voit les produits logiciels actuels avec cette fameuse QA il y a de quoi se poser de sérieuses questions sur la QA...
        
        Mais étant donné que de nos jours on essaye de refiler un produit dans les pattes du client alors qu'il commence seulement sa phase de test...rien ne m'étonne.
      - [^] # Re: Mon avis de noob du développement web.
        
        Posté par deasy le 16 février 2012 à 23:39. Évalué à 1. Dernière modification le 16 février 2012 à 23:41.
        
        Tu parles de ceux qui ont verrouillé le web avec du ie6only?
    - [^] # Re: Mon avis de noob du développement web.
      
      Posté par claudex le 16 février 2012 à 19:08. Évalué à 1.
      
      Dans cette logique, on en serait encore à l'âge de pierre.
      
      Je n'ai pas dit qu'il ne fallait pas utiliser les versions sans les préfixes mais qu'il ne fallait pas oublier les versions avec préfixe.
      
      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
- [^] # Re: Mon avis de noob du développement web.
  
  Posté par deasy le 17 février 2012 à 00:12. Évalué à 1.
  
  J'oubliais de préciser que je n'ai pas utilisé ces propriétés css3 à l'arrache, j'ai consulté le site caniuse avant.
  Et ensuite j'ai testé.
  
  Et ça fonctionne sans préfixe partout.
  
  Enjoy et basta les préfixes.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.