Page 23 sur 38

Publié : 08 août 2009, 11:37
par Thomas
En fait ce que fait dbaron c'est quoi ? Il enlève tous les widgets natifs ? C'est à dire que Firefox sera encore "moins" intégré aux OS ?

Publié : 08 août 2009, 12:09
par Zefling
En tout cas, c'est la premier fois que je vois un « -ms- », pour qui cherchait si ça existait ou non. ^^; Bon, faudrait que je trouve la liste pour chaque navigateur. Pour les « -moz » il y a des trucs un peu trop spécifique à cause du XUL, mais utilisable dans les pages.



Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

Publié : 08 août 2009, 13:23
par teoli2003
Toto a écrit :En fait ce que fait dbaron c'est quoi ? Il enlève tous les widgets natifs ? C'est à dire que Firefox sera encore "moins" intégré aux OS ?
De quoi tu parles?

Message envoyé avec : Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090807 Minefield/3.6a1pre

Publié : 08 août 2009, 15:09
par Thomas
J'ai suivit de loin le travail sur le "Compositor". J'ai lu le billet de RoC (et pas dbaron, je me suis trompé) : http://weblogs.mozillazine.org/roc/arch ... dgets.html

Pour moi les "native widget" ce sont les parties de l'interface directement déléguées au système d'exploitation, comme l'affichage des champs de formulaires. C'est bien ça ? Si oui, pourquoi les retirer ?

Publié : 08 août 2009, 15:37
par teoli2003
OK. Non, non je peux te rassurer. Il ne s'agit pas d'enlever les widgets natifs. Seulement d'enlever dans les structures internes les widgets natifs. Ils réapparaissent au dernier moment.

Ce que fait Robert O'Callahan, aux perf près, est transparent pour l'utilisateur.

Message envoyé avec : Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a2pre) Gecko/20090808 Minefield/3.6a2pre

Publié : 08 août 2009, 15:44
par Thomas
Okay !

Publié : 11 août 2009, 13:20
par Morgoth
Version finale pour Novembre.
Un peu plus tôt que prévu quand-même. :D

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729)

Publié : 11 août 2009, 13:30
par teoli2003
Morgoth a écrit :Version finale pour Novembre.
Un peu plus tôt que prévu quand-même. :D

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729)
Cela fait deux mois qu'ils ont coupé Namoroka en 3.6 (Namoroka), 3.7 (Gecko 1.9.3) et Fx.next (4.0?).

Trois raisons à cela: 1) Fennec a besoin de Gecko 1.9.2 pour passer en 1.0;
2) Pas de raison d'empêcher les utilisateurs de Fx d'avoir les bénéfices déjà stabilisés;
3) L'intégration dans Windows 7: l'avoir lors de la sortie de l'OS c'est toujours bien ( même si tout ne sera pas déjà là): multitouch, Jump list et Aero Peek.

Publié : 11 août 2009, 13:35
par Zefling
Ça semble logique.

Le truc c'est qu'on leur reprocher la succession des misesà jours (il y en a qui ne sont jamais content).

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

Publié : 11 août 2009, 13:42
par teoli2003
Le désavantage, c'est que les extensions doivent être à nouveau bumpées...

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) Gecko/20090729 JYP Firefox/3.5.2

Publié : 11 août 2009, 15:39
par teoli2003
Ceux qui avaient des soucis avec les onglets détachables, le bug semble avoir été corrigé:

Bug 489729 - Clicking a tab once and then moving your mouse in a downward motion causes a new window to open.

Dans votre prochaine nocturne.

Pour l'intégration Mac OS, les boutons-menus sont désormais natifs:

- avant : https://bug508724.bugzilla.mozilla.org/ ... ?id=392861
- après : https://bug508724.bugzilla.mozilla.org/ ... ?id=392862

Pas utilisé dans l'interface de Firefox, mais dans Chatzilla par exemple.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) Gecko/20090729 JYP Firefox/3.5.2

Publié : 11 août 2009, 19:00
par Zefling
teoli2003 a écrit :Le désavantage, c'est que les extensions doivent être à nouveau bumpées...
C'est vrai, pour ça c'est assez pénible et je crois que je vais mettre directement 3.7 sur le mienne, par qu'il n'y a aucune raison que les choses changes pour mon extension.

teoli2003 a écrit :Pour l'intégration Mac OS, les boutons-menus sont désormais natifs:

- avant : https://bug508724.bugzilla.mozilla.org/ ... ?id=392861
- après : https://bug508724.bugzilla.mozilla.org/ ... ?id=392862

Pas utilisé dans l'interface de Firefox, mais dans Chatzilla par exemple.
Moi, j'aimerais bien que le CSS pour les éléments de formulaires évolue un peu. Parce que c'est bien jolie d'avoir des trucs qui colle très bien au système, mais qui ne colle absolument pas au site. Et il est impossible de faire un site qui satisfasse Windows Classic, Luna, Areo, MacOs, Gnome, KDE, etc. Mais il me semble que cela vienne du vide de recommandation à ce niveau.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

Publié : 11 août 2009, 22:08
par Benoit
Ça vient plutôt du danger énorme de spoofing si on permet à des contrôles de formulaires, en particulier de sélection de fichiers, d'avoir l'air de n'importe quoi.

Pour des listes déroulantes c'est à priori moins important, mais ça peut poser de gros problèmes d'accessibilité si ils ne respectent pas les réglages de l'OS (contraste élevé par exemple).

Publié : 12 août 2009, 00:52
par Zefling
Benoit a écrit :Ça vient plutôt du danger énorme de spoofing si on permet à des contrôles de formulaires, en particulier de sélection de fichiers, d'avoir l'air de n'importe quoi.

Pour des listes déroulantes c'est à priori moins important, mais ça peut poser de gros problèmes d'accessibilité si ils ne respectent pas les réglages de l'OS (contraste élevé par exemple).
Mais bon avec le JavaScript/Flash ça fait bien longtemps qu'on peut faire n'importe quoi.
Rien que pour un input=text/button/submit/delete on peut donne l'apparence que l'on veut. Pour la select il y a juste la flèche d'ailleurs il n'est pas rare que je voie pour contourner le problème fait que les éléments soit tout bêtement recréer avec des balises simples et du CSS, du coup sans CSS ou javascript ça devient inutilisable contrairement à un élément form. Le input=file est tout de même le summum due l'emmerde, impossible de prédire sa taille suivant l'OS ou le navigateur. Du coup, pour contourner le problème : Flash/JavaScript, qui niveau accessibilité est plutôt l'horreur et on peut lui donner vraiment l'apparence que l'on veut.

De tout façon si on le veut on peut facilement faire n'importe quoi et le CSS va de plus en plus tendre à ces problèmes (rien qu'avec la transparence).

Bref, autant de donner aucune droit de mise en forme CSS plutôt que partiel et bancale.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

Publié : 12 août 2009, 08:05
par Benoit
Pour le bouton « Parcourir », il n'y a pas que l'OS et le navigateur il y a aussi la langue du système.

Déterminer sa taille à l'avance ça ne marchera jamais.