Suis-je le seul à ne pas aimer Firefox? - Page 17

Je ne préconise pas l'utilisation intensive de <div> absolument partout hein, je trouve juste qu'utiliser des tables pour toute la présentation (là où par exemple, dans l'exemple que je prenais, des balises <ul> et <li> existent depuis des années pour représenter des listes à puce) est une assez mauvaise idée pour tout un tas de raisons. Si ça te semple "FUD" (je trouve un peu facile de classer une remarque dans cette catégorie "sans suite" plutôt que de prendre une minute pour se remettre en cause), on peut continuer dans un autre topic ou abandonner ici.

Après, oui, dans tous les cas Fx (puisqu'il parait que c'est l'abréviation officielle ? ^^) aurait du l'afficher correctement.

onur (./480) :
./475 > Non les "table" sont très utilisés, c'est à la limite mauvais pour toi-même au niveau de maintenabilité de la mise en forme (et encore ca se discute parce que c'est un grand débat dans le monde du dév. Les alternatifs à table passent parfois par des hacks browser-dependent alors qu'ils parlaient de proprété au départ...)
Néanmoins, il doit afficher correctement les table il me semble :-/

Ben euuuh pour des puces pas trop, hein Le mieux c'est d'utiliser <ol> (ou <ul>) et <li> pour des listes simples, ou un (mais là c'est pas normalisé, mais en tout cas plus "logique" et pertinent que des tables) un <div> de largeur fixe avec une image de fond qui fera ta puce (deux implémentations possibles : la puce *est* ton div, ou la puce est un fond au début de ton <div> en no-repeat et tu as le texte qui suit grâce à une marge assez large).

(la méthode la plus "saine" me semble quand même être utilisation de l'attribut CSS qui sert justement à redéfinir l'image des puces, mais je crois qu'on s'éloigne de plus en plus du sujet ^^)

Ah, ça existe ? Je me doutais bien qu'il devait y avoir un truc comme ça, mais ne l'ayant jamais utilisé, je ne savais pas. En tout cas merci ^^.

( http://fr.selfhtml.org/css/proprietes/listes.htm#list_style_image )

Oui j'ai fait des ul, li au départ mais je suis venu à un bidouillage comme ça par la suite (d'où les noms de classes "ul" et "li") je sais plus pourquoi.

Mais Firefox de merde était censé l'afficher correctement quand meme.

Tiens peut-etre une idée de pourquoi Fx fait un truc bizzare :

Myth - "Firefox supports Progressive Rendering and Internet Explorer does not" - Example

Reality - "Actually this is not true and you can see from going to many pages that Internet Explorer does support progressive rendering of content as it arrives. This is true however for table rendering. When Internet Explorer encounters a table it measures all the content of the table before rendering so that it knows what the widths of the columns are to render the content correctly. On the other hand Firefox uses a different algorithm in that it renders the table contents progressively before it has all been passed. There are pros and cons to both approaches. In the case of progressive rendering a table it can result in an experience where content is initially displayed and then moved as the browser progresses creating a clunky and poor quality feel. On the other hand if we parse the entire table content first then it can take some time to display in the case of heavily nested tables. I've heard user feedback supporting both arguments and more than a few people have mentioned that they find Firefox's rendering a little off putting in this regard." - Source

Ce qui expliquerait aussi pourquoi il y a parfois des soucis avec le Bugzilla de WineHQ.

Godzil > oui ca a l'air d'etre vraiment ça. pour le problème de ./1 aussi d'ailleurs.

./489 > pourtant y'a pas de table dans l'exemple du ./1 ?

Si, les trois éléments sont dans une table. cf ./16 et ./46

ok

J'ai vu quelques pages plus tôt que bcp de gens trouvaient que FF s'intégrait mal. Je comprends pas pourquoi, au contraire (en tous cas sous Windows) même les trucs auxquels on ne s'attend pas sont identiques (Ctrl+F4 pour fermer un onglet, Alt+Gauche/Droite pour précédente/suivante, Ctrl+W pour fermer et enregistrer, etc.). Ils n'ont pas fait le même effort sur les autres OS?

parce que FF suxxx


En tout cas sur mac il prend facilement 3-4 fois plus de temps que Safari au démarrage, et rien que pour ça il vaut pas le coup.

Brunni : Sur Linux+KDE, les boites de dialogues d'ouverture et d'envoi de fichiers de Firefox sont à chier :





Normalement une boîte de dialogue sous KDE est comme ça :





A part ça, tout me semble normal. Donc cette histoire d'intégration est un détail (chiant, quand même).

Je crois qu'il y a des trucs à installer pour obtenir une meilleure intégration des applications GTK+ dans KDE (et il me semble que ce truc comprend l'utilisation des boîtes de dialogues natives de KDE).

Le truc pour les boites de dialogues est un hack (c'est une sorte de lanceur d'application qui bidouille je ne sais quoi) et il faut le configurer pour chaque appli, sans compter que ça doit buger sur firefox au niveau du focus de l'application (enfin je dis ça de mémoire mais bon).
De toutes façons le truc qui sux c'est les boites de dialogue GTK, que tu sois sous KDE sous Windows, sous Mac OS ou sous Gnome
Encore un truc totalement contre-intuitif super simpliste dans le concept (donc inutilisable, en fait des qu'on a plus de 20 fichiers dans un dossier c'est la mort a utiliser) pensé par des génies de l'opensource
Et encore j'ai oublié de mentionner le fait que c'est moche, peu importe l'environnement autour

Je me demande ce que les gens trouvent à Gnome d'ailleurs. KDE est mille fois plus beau, mille fois plus personnalisable.

Martial Demolins (./497) :
Et au moins, contrairement aux boites de windows, tu peux personnaliser ton menu de gauche, globalement ou par application.

Ah ? Comment on fait ?

thibaut: beh ca depend des gouts, moi je trouve KDE grossier contrairement a Gnome...

XFCE roxorz w00t w00t

C'est clair que les dialogues de fichiers GTK+ sont pourris, c'est bien pour ça que TiLP, TiEmu et GFM permettent d'utiliser les dialogues KDE.

Après une longue période KDE, je préfère finalement Gnome qui me paraît plus sobre et plus simple. Après, tout dépend de l'utilisateur et de ses besoins. Comme KDE est plus configurable sur de nombreux points, j'arrive à faire certaines choses que je ne peux pas faire avec Gnome en raison de mon matériel bizarre (sur mon chipset audio, c'est le canal "PCM" qui règle le volume, et pas le canal "Master". Sur gnome, on peut régler le contrôle du volume sur 'PCM', mais contrairement à KDE ça ne change pas l'action des touches volume du clavier pour qu'elles agissent sur ce canal). D'un autre côté, je peux faire presque tout ce que je souhaite avec Gnome sauf que je passe moins de temps à fouiller dans les menus parmi la vingtaine d'options qui me serviront une fois en vingt ans. Pour ces cas là, la console est ma meilleure amie :-)
De plus, étant un adepte de Clearlooks, c'est dur de se remettre à Plastik ;-)

Thibaut (./496) :
Brunni : Sur Linux+KDE, les boites de dialogues d'ouverture et d'envoi de fichiers de Firefox sont à chier :





Normalement une boîte de dialogue sous KDE est comme ça :





A part ça, tout me semble normal. Donc cette histoire d'intégration est un détail (chiant, quand même).

Hm ok, en tous cas sous Windows tu as les boîtes OpenFile 100% standard. Donc le problème vient probablement de l'API multiplateforme utilisée par Firefox (je sais pas laquelle c'est, j'arrive pas à trouver et tant pis ).
Sous Windows la seule différence qui peut faire dire que ce n'est pas une application "standard", c'est que les contrôles ne sont pas animés.
Thibaut> Bah un Gnome configuré par défaut avec Ubuntu par exemple fait très bien son travail, il est accessible, configurable comme on veut mais pas trop, enfin bref ça va très bien, je pense qu'un KDE aurait vite fait de décourager les débutants

a priori firefox/x11 est basé sur gtk+

C'est basé sur XUL qui lui même utilise GTK+.

bref on pourrait sans doute faire un XUL/Qt

Ouais ça serait très bien

carrément, ca ferait une sacré meilleure intégration à KDE!

(mais ça doit être sacrément chaud a coder )