Ich tendiere jetzt auch zu MSIE ...

Re(4): Ich tendiere jetzt auch zu MSIE ...

MidiFan — Thu, 31 Jul 2008 08:39:11 GMT

Früher hat Open All In Tabs die bisherigen Tabs zugemacht und dafür die neuen
Tabs aufgemacht. Im Firefox 3 ersetzt er das gerade aktive Tab, hängt die
restlichen an, und läßt die anderen alten Tabs so wie sie gerade sind.

gefällt mir besser als die alte version. hängt aber klarerweise vom surfverhalten ab.
ich öffne zb. den ordner news, dann lese ich alle seiten und schliesse eine nach dem anderen wieder zu und surfe dort weiter wo ich vorher war.

Re(3): Ich tendiere jetzt auch zu MSIE ...

juwb — Thu, 31 Jul 2008 08:35:34 GMT

Früher hat Open All In Tabs die bisherigen Tabs zugemacht und dafür die neuen Tabs aufgemacht. Im Firefox 3 ersetzt er das gerade aktive Tab, hängt die restlichen an, und läßt die anderen alten Tabs so wie sie gerade sind.

Finde ich nervig, da ich z.B. meine Bookmarks nach Kategorien sortiere (Foren, Newsseiten, Webcomics, Uni/Studium, etc.). Früher habe ich mit Open All In Tabs zuerst die Foren aufgemacht, wenn ich die neuen Postings gelesen habe dann die News, dann die Webcomics, und so weiter.

Im FF2 klappte das wunderbar (Browsen nach Thema), im FF3 muss ich jedes Mal vorher ein Close All Tabs vorher machen, damit ich am Ende nicht mit einem Tab-Chaos dastehe.

Re(5): Ich tendiere jetzt auch zu MSIE ...

pong — Thu, 31 Jul 2008 08:13:10 GMT

Niemand klappt alles auf (bei threads mit 1000+ Postings),

so gewaltig kann man sich irren .. ich hab niemals eine andere Ansicht als "alles anzeigen" offen, schon seit eh und je

pong

Re(6): Ich tendiere jetzt auch zu MSIE ...

MidiFan — Thu, 31 Jul 2008 07:58:27 GMT

zustimm. bei mir dauert das überprüfen des icq onlinestatus am längsten... vielleicht lässt sich ja das ausschalten...

Re(6): Ich tendiere jetzt auch zu MSIE ...

MidiFan — Thu, 31 Jul 2008 07:58:27 GMT

zustimm. ~~bei mir dauert das überprüfen des icq onlinestatus am längsten... vielleicht lässt sich ja das ausschalten...~~
gibts ja eh schon und war bei mir auch schon aktiviert ^^

Re(2): Ich tendiere jetzt auch zu MSIE ...

MidiFan — Thu, 31 Jul 2008 07:30:17 GMT

'Open All in Tabs'

was meinst den? rechtsklick auf lesezeichen "alle in tabs öffnen"
funktioniert wie eh und je.

Re(3): Ich tendiere jetzt auch zu MSIE ...

Oliver_nur echt mit 2 Kastratern und Daisy! — Thu, 31 Jul 2008 05:27:56 GMT

Keine Ahnung, bei mir läuft FF immer.

Re(3): Ich tendiere jetzt auch zu MSIE ...

hansi99 — Wed, 30 Jul 2008 18:39:19 GMT

Eine Möglichkeit wäre der Firefox Preloader. Ich weiß allerdings nicht, ob man das Taskleistensymbol deaktivieren kann, zur Not blendest du es eben aus.

Re(2): Ich tendiere jetzt auch zu MSIE ...

grizzerl — Wed, 30 Jul 2008 13:57:08 GMT

Kennst Du einen Weg, das zu verhindern?

Gibts da eine Möglichkeitn, das letzte FF-Fenster zu schliessen und trotzdem eine Instanz für die nächste Seite parat zu halten?

Ein weiteres Symbol in der Startleiste bei der Uhrzeit will ich nicht.

In musikalischer Form

Dr. Watson — Wed, 30 Jul 2008 12:52:12 GMT

http://www.youtube.com/watch?v=a0qMe7Z3EYg

Please don’t use tables even though they work fine
when it come to indexing they give searches a hard time

make it easy for the spiders to crawl what you provide
remove font type, font color and font size

no background colors, keep your coding real neat,
tag your look and feel on a separate style sheet

better results with xml and css
now you making progress, a lil closer to success

describe your doctype so the browser can relate
make sure you do it great or it won’t validate

Re(19): Ich tendiere jetzt auch zu MSIE ...

Dr. Watson — Wed, 30 Jul 2008 11:59:46 GMT

Dafür unterstützt der IE7 nun die Pseudo-Klasse :first-child, evtl. lässt sich damit was tricksen.

Re(18): Ich tendiere jetzt auch zu MSIE ...

mjy@geizhals.at — Wed, 30 Jul 2008 11:55:10 GMT

Tja, Pech gehabt. MSIE7 (unter XP - 7.0.5730.13) unterstützt li:before übrigens offenbar auch nicht.

Re: Ich tendiere jetzt auch zu MSIE ...

w2k3srv — Wed, 30 Jul 2008 11:52:46 GMT

Komischerweise ist der Firefox unter Ubuntu sauschnell

komisch.

User31003 — Wed, 30 Jul 2008 11:49:28 GMT

Es ist erstaunlich, wie lahm FF 3.0 geworden ist, richtige Bloatware

kann ich nicht nachvollziehen. ich merke ein deutliches geschwindigkeitsplus gegenüber ff2. ibook g4, 1,25ghz, osx 10.4.11, 756mb ram.

Re(17): Ich tendiere jetzt auch zu MSIE ...

Dr. Watson — Wed, 30 Jul 2008 11:40:46 GMT

HTML Entities werden im Stylesheet nicht geparst, daher kannst du dort kein » verwenden.

Re(16): Ich tendiere jetzt auch zu MSIE ...

mjy@geizhals.at — Wed, 30 Jul 2008 11:38:25 GMT

LI:before {content: "» "}

Danke, das kannte ich nicht - bei CSS2 habe ich irgendwann wegen der schlechten Browser-Unterstützung vor ca. 2 Jahren resigniert. Damit sollte sich das wirklich lösen lassen.

Hoffentlich funktioniert » dort, schließlich müssen wir auch utf-8 unterstützen.

Re(15): Ich tendiere jetzt auch zu MSIE ...

Dr. Watson — Wed, 30 Jul 2008 11:06:01 GMT

Die korrekte Lösung wäre:

LI:before {content: "» "}

Funktioniert im IE(6) freilich nicht, hier würde ich einen normalen list-style-type: disc; für den IE verwenden.

Hat den Vorteil, dass die Listenansicht auch für den IE User ersichtlich ist, also die Funktionalität der Seite ist gewährleistet. Der optische Unterschied weist ihn sanft darauf hin, auf deinen aktuellen Browser umzusteigen.

PS: In einem kurzen Testlauf zeigte sich eben, dass Listen-Elemente niemals umgebrochen werden.

Re(15): Ich tendiere jetzt auch zu MSIE ...

Dr. Watson — Wed, 30 Jul 2008 11:06:01 GMT

Re(7): Ich tendiere jetzt auch zu MSIE ...

adhoc — Wed, 30 Jul 2008 10:51:16 GMT

würds am anfang mal nicht zu kompliziert machen

einfach einen "+++" button (neben dem jetzigen "+" button) bei der "detailansicht" von einem posting
ab dem dann alles aufgeklappt wird
(kann man IMHO auch gut in der url "einbauen" als zusätzlich)
z.b.
von
http://forum.geizhals.at/t583844,4937012.html#4937012
nach->
http://forum.geizhals.at/t583844,4937012,MitSubthreads.html#4937012

also so das immer nur EIN subthread (komplett) aufgeklatt ist...

Re(7): Ich tendiere jetzt auch zu MSIE ...

Srv-02 — Wed, 30 Jul 2008 10:40:49 GMT

Du kannst bei neuen Postings den Klappentext ja fett schreiben wenn sich darin ein neues Posting befindet.

Achja und ich würde es automatisch ab x Postings aktivieren lassen, aber den Usern über einen Link im Thread manuell aktivieren bzw. deaktivieren lassen.

Re(6): Ich tendiere jetzt auch zu MSIE ...

mjy@geizhals.at — Wed, 30 Jul 2008 10:33:52 GMT

wie wärs mal mit "subthreads aufklappen" ...

Ja, das wäre ein sinnvolles Feature. Heise hatte das AFAIR früher per Cookies gelöst, weil es sonst schwierig ist, den gesamten "Klappstatus" über die Navigation mitzuschleppen (z.B. wenn man zum Beitrag zurückkehrt und dann wieder ins Forum). Bei Slashdot waren große Threads früher besser navigierbar (ohne Aufklappen).

Vielleicht fällt mir ja etwas dazu ein, das nicht allzu viel Java-Programmierzeit (= Verbrechen an der Menschheit) benötigt. Theoretisch könnte man ab einer gewissen Thread-Tiefe (z.B. 2) die Subthreads zugeklappt lassen, bis auf die Vorgänger und direkten Nachkommen des aktuell offenen Postings, also ca. so:


[ OP ]
+- bla1
|  +- (27 weitere Postings)    
|
|--+-------------
|  | bla bla ... 
|  +-------------
|    +- bla
|    |  +- (19 weitere Postings)
|    +- bla
|
+- bla
+- bla2
|   +- (93 weitere Postings)
+- bla

Allerdings kann man dann z.B. nicht mehr zu den ungelesenen, neuen Beiträgen springen, die man zufällig (dann nicht mehr) sieht. Daher wäre es wohl besser, das als separaten Modus zu implementieren, der nur aktiviert wird, wenn es mind. XXX Postings in einem Thread gibt.

Re(14): Ich tendiere jetzt auch zu MSIE ...

mjy@geizhals.at — Wed, 30 Jul 2008 10:20:39 GMT

Tja, dann bleibt noch immer: » als list-bullet zu verwenden geht nicht (eine Grafik ist aus verschiedenen Gründen unpraktisch) und wenn man list-style: none verwendet und das &:raquo; innerhalb des

verwendet bräuchte man noch immer einen Umbruchschutz, damit Browser nicht direkt nach dem "bullet"-Zeichen umbrechen.

Re(5): Ich tendiere jetzt auch zu MSIE ...

adhoc — Wed, 30 Jul 2008 10:10:56 GMT

>Niemand klappt alles auf (bei threads mit 1000+ Postings),

leider ist es schon bei 200+ postings recht mühsam

wie wärs mal mit "subthreads aufklappen" ...

Re: Ich tendiere jetzt auch zu MSIE ...

Oliver_nur echt mit 2 Kastratern und Daisy! — Wed, 30 Jul 2008 10:10:33 GMT

Beim Anfahren braucht der FF einige Sekunden. Danach ist FF3 für den Rest des Tages suaschnell.

Re(5): Ich tendiere jetzt auch zu MSIE ...

Srv-02 — Wed, 30 Jul 2008 10:05:52 GMT

Niemand klappt alles auf (bei threads mit 1000+ Postings), wie ein einziges
Posting dargestellt wird, ist daher ziemlich egal.

Ich sags eher anders: Keine Sau klickt in einem 1000 Posting Thread alle Beiträge an. Wenn ich im Thread aktiv mitposte, dann schon ... aber rein zur Nachlese niemals.

Re(13): Ich tendiere jetzt auch zu MSIE ...

Dr. Watson — Wed, 30 Jul 2008 10:00:29 GMT

Mir ist bewusst, dass man Themen wie den Quelltext als Unternehmer gerne vernachlässigt, weil die Zeit sowieso knapp ist, und man lieber an wichtigeren Dingen arbeitet, die sich eher auf den Umsatz auswirken. Kenne ich alles, wer denkt man könnte alles so mustergütig lösen wie es einem die Bücher eintrichtern, lebt in einer Traumwelt.

Aber dann kann ich mich nicht beklagen, wenn jemand diese Fehler irgendwann anspricht, oder ich selbst bemerke, dass mein Browser plötzlich lahm wirkt.

Die modernen Browser sind einfach nicht (mehr?) dafür geschaffen, komplexe Layouts im HTML4 Stil (der aus euren Quelltext unverkennbar ist) schnell zu rendern, das liegt eben an der generellen Entwicklung des Webs.

Nochmal, es geht mir mir nicht um Web 2.0 Propaganda und tolle JS Spielereien, sondern das zu nutzen, was die modernen Browser heutzutage unterstützen. Klar muss man erst den kleinsten gemeinsamen Nenner finden, man kann aber durch diverse Hacks einiges ausbügeln, betrifft in 90% aller Fälle nur den IE5+6.

Re(13): Ich tendiere jetzt auch zu MSIE ...

Dr. Watson — Wed, 30 Jul 2008 09:56:42 GMT

PS. ich kann mich vage daran erinnern, die LI-Variante aufgegeben zu haben,
nachdem jeder Browser das padding anders interpretierte. Vielleicht geht das
ja heutzutage besser.

"Jeder" Browser hat unterschiedliche Grundeinstellungen für padding und margin für Listen und Listenelemente. Entweder alle vorab auf 0 setzen, oder ein Reset Stylesheet verwenden, dann ist das Problem vom Tisch.

Re(13): Ich tendiere jetzt auch zu MSIE ...

Dr. Watson — Wed, 30 Jul 2008 09:56:42 GMT

PS. ich kann mich vage daran erinnern, die
-Variante aufgegeben zu haben,
nachdem jeder Browser das padding anders interpretierte. Vielleicht geht das
ja heutzutage besser.

Re(12): Ich tendiere jetzt auch zu MSIE ...

mjy@geizhals.at — Wed, 30 Jul 2008 09:50:06 GMT

Was dir ein eventueller Umbruch für Probleme macht, in einer Spalte mit fixer Breite, musst du erst mal erklären.

Wir hatten schon mal breitere Texte dort stehen (und schließen das auch für die Zukunft nicht aus) und die Spalte war schmäler.

Aber gut, dir fällt also auch keine Lösung ein, die einen Umbruch vor/nach » vermeidet und insgesamt kürzer ist. Dann bin ich ja beruhigt und kann mich anderen Dingen widmen.

PS. ich kann mich vage daran erinnern, die

-Variante aufgegeben zu haben, nachdem jeder Browser das padding anders interpretierte. Vielleicht geht das ja heutzutage besser.

Re(12): Ich tendiere jetzt auch zu MSIE ...

mjy@geizhals.at — Wed, 30 Jul 2008 09:50:06 GMT

Was dir ein eventueller Umbruch für Probleme macht, in einer Spalte mit fixer Breite, musst du erst mal erklären.

Re(12): Ich tendiere jetzt auch zu MSIE ...

mjy@geizhals.at — Wed, 30 Jul 2008 09:42:41 GMT

Hier wird ganz klar mehr Zeit in das bestreiten von offensichtlichen Schwachstellen investiert, als die Behebung dieser in Anspruch nehmen würde. Das ist alles andere als pragmatisch.

Sei mir nicht bös, aber ein paar als "offensichtliche Schwachstellen" zu bezeichnen ist lächerlich. Ich diskutiere mit dir lediglich darüber, weil du vehement behauptest (ohne es zu belegen), daß "Euer Quelltext gehört mit zum Schlimmsten, was man im WWW heutzutage noch finden kann, bei Seiten dieser Größenordnung." ...

Ich investiere wirklich lieber Zeit in Verbesserungen am Code und an der Server-Infrastruktur, für HTML-"Verbesserungen" dieser Art ist mir die Zeit eigentlich zu schade, v.a. wegen der Inkonsistenten CSS-/HTML-/DOM-Implementierungen der Browser. Ich verstehe aber, daß jemand, der täglich mit solchen Sachen gequält wird, solche Dinge als wichtiger empfindet.

Re(11): Ich tendiere jetzt auch zu MSIE ...

Dr. Watson — Wed, 30 Jul 2008 09:36:05 GMT

Eine stinknormale ungeordnete Liste (UL) mit je einem Listenelement pro Link (LI).
Abstände zu den Rändern per padding regeln (im Stylesheet), class=n Attribute von sämtlichen Links entfernen, Stile für die Links ebenfalls im Stylesheet regeln.

Entferne pro Link 2x , 1x class=n, füge li und /li Tags hinzu, ingesamt also Bandbreite gespart, und eine Auflistung auch wirklich so geregelt, dass _jeder_ Browser erkennt, dass es sich um eine Auflistung handelt, und nicht um puren Text, der durch Zeilenumbrüche getrennt ist.

Selbst ein primitiver Handy Browser, der die Seite nicht in voller Breite anzeigen kann erkennt somit, dass der User hier eine Liste sehen soll, und keinen durcheinander gewürfelten Text.

Was dir ein eventueller Umbruch für Probleme macht, in einer Spalte mit fixer Breite, musst du erst mal erklären.

Re(11): Ich tendiere jetzt auch zu MSIE ...

Dr. Watson — Wed, 30 Jul 2008 09:26:10 GMT

Was für eine alljährliche Diskussion?

Kritik führt doch leider in den seltensten Fällen zu einer Verbesserung. Hier wird ganz klar mehr Zeit in das bestreiten von offensichtlichen Schwachstellen investiert, als die Behebung dieser in Anspruch nehmen würde. Das ist alles andere als pragmatisch.

Wenn du der Meinung bist, mir gehts darum, einen Dienst zu "bashen" den ich täglich nutze, dann teile mir das bitte gleich mit. Themen wie dieses sind "schuld" daran, dass sich mein Feierabend um eine Stunde hinauszögert, das ist pure Freizeit die ich hier aufwende; und nur ungern verschwende.

Re: Ich tendiere jetzt auch zu MSIE ...

Newbie007 — Wed, 30 Jul 2008 09:18:11 GMT

Hmm ich hab schon das Gefühl, dass der IE7 langsamer ist als FF3, zumindest bei mir dauert das öffnen von Seiten spürbar länger

Re(10): Ich tendiere jetzt auch zu MSIE ...

mjy@geizhals.at — Wed, 30 Jul 2008 09:15:48 GMT

Werfen wir einen Blick auf die Startseite - speziell die Linkpartner - hier
wird z.b. Bandbreite durch 6*3 nbsp's verbraten, obwohl sich mit einem
simplen, einzelnen CSS Selektor des Elternelements (P) ein padding für alle
enthaltenen Links definieren lassen würde. Ein class= für jeden einzelnen Link
wäre ebenso schwachsinnig.

Was das betrifft - kannst du gerne eine CSS-Definition vorschlagen, die exakt dasselbe macht (kein Umbruch vor und nach », sonst überall möglich), ohne zusätzliche Tags o.ä.. Pluspunkte gibt es, wenn das auch noch auf allen Browsern funktioniert. Ich weiß ja nicht, warum du glaubst, daß wir nur für die Einrückung verwenden.

Re(10): Ich tendiere jetzt auch zu MSIE ...

mjy@geizhals.at — Wed, 30 Jul 2008 09:10:34 GMT

Beispiele von mir gibts keine, weil ich a) kein Frontend Entwickler bin, und b) nur firmenintern entwickle, wir sind keine Dienstleister.

Na dann ist ja alles kar. An diesem Punkt endet dieser alljährliche Diskussion von uns immer wieder.

Aber meine Kritik am Quelltext sehe ich als untermauert an.

Kritik ist gut, sie kann zur Verbesserung führen. Der Punkt, den du nicht belegen kannst ist jedoch die Aussage, daß wir mit unserem HTML unter führenden Websites besonders schlecht liegen. Dafür bleibst du den Nachweis wieder schuldig.

Re(5): Ich tendiere jetzt auch zu MSIE ...

phj — Sat, 26 Jul 2008 20:44:19 GMT

Hab zwar vom Rest was ihr da redet keinerlei Dunst, aber

Niemand klappt alles auf (bei threads mit 1000+ Postings),

ist definitiv nicht korrekt. Und es stimmt, dass es elend lang dauert

Re(9): Ich tendiere jetzt auch zu MSIE ...

Dr. Watson — Sat, 26 Jul 2008 15:11:19 GMT

Du verstehst es nicht ... Eine Seite besteht nicht nur aus Layout, sondern
auch aus Content.

Ein ist kürzer als "class=bla" und kürzer als .

Nein (nänänä), du verstehst es nicht.

Werfen wir einen Blick auf die Startseite - speziell die Linkpartner - hier wird z.b. Bandbreite durch 6*3 nbsp's verbraten, obwohl sich mit einem simplen, einzelnen CSS Selektor des Elternelements (P) ein padding für alle enthaltenen Links definieren lassen würde. Ein class= für jeden einzelnen Link wäre ebenso schwachsinnig.

Wenn die Seite sauber gegliedert wäre, gäbe es da relativ wenige class-Attribute, grade mal die wichtigsten Eltern Elemente müssen welche Tragen, der Rest läuft per *, + und ~. Kennt eben kaum jemand, siehe Punkt "gute Frontend Entwickler..:".

Nun, entweder sind wir keine guten Frontend-Entwickler, oder deine
Behauptungen sind praxisfern. Wir haben gerade z.B. ein Angebot einer
bekannteren und kompetenteren Agentur für ein CSS-Design eines Projekts
erhalten und da wird nicht einmal Opera erwähnt. Tatsache ist, daß (wie du
auch fallweise auf GH sehen kannst) weder CSS, noch DOM auf sämtlichen
modernen Browsern ohne ständige Sonderfallbehandlungen unproblematisch
verwendbar sind und irgendwann ist es den Aufwand nicht wert, das verkrampft
mit CSS zu lösen wenn es ohne genausogut geht.

Ich rede nicht von Klickibunti-Web2.0 Seiten, bei denen eine Serverfarm nötig ist, um die xmlhttprequests abzuwickeln, die durch diverse Spielereien verursacht werden. Sondern von seriösen Seiten, die eine möglichst große Zielgruppe ansprechen wollen, z.b. diverse Nachrichtenagenturen. Beispiele von mir gibts keine, weil ich a) kein Frontend Entwickler bin, und b) nur firmenintern entwickle, wir sind keine Dienstleister.

Deine Ausdrucksweise ("verkrampft") spricht ja schon Bände - für jemanden, der das nicht zum 1. mal macht, ist die CSS Lösung schneller umzusetzen und besser wartbar.

Meine Aussage ist übrigens nicht, dass das GH Layout oder Design umgekrempelt gehört, von mir aus könnte es optisch für immer so bleiben. Aber meine Kritik am Quelltext sehe ich als untermauert an.

Re: Ich tendiere jetzt auch zu MSIE ...

Bart Simpson — Sat, 26 Jul 2008 13:28:41 GMT

einmal auf "zurück" gedrückt und der MSIE wird, verglichen mit opera, zur schnecke..

Re(8): Ich tendiere jetzt auch zu MSIE ...

mjy@geizhals.at — Sat, 26 Jul 2008 11:54:17 GMT

Nochmal - wozu muss dies von einem Redakteur festgelegt werden? So viele designmäßig unterschiedliche Seiten hat GH nun wirklich nicht (öffentlich), als das man nicht für jede einzelne die Styles einmal definieren, und dann ohne diesen Overhead leben könnte. Ein "modernes" 20k Stylesheet ist um keinen deut mieser, als das positionieren von Inhalt durch Leerzeichen und Umbrüche, die immer geladen werden müssen.

Du verstehst es nicht ... Eine Seite besteht nicht nur aus Layout, sondern auch aus Content.

Ein ist kürzer als "class=bla" und kürzer als .

Ja, ich habe keine Ahnung. Offensichtlich auch die anderen Autoren größerer Seiten nicht. Du tust hier, als müsse GH möglichst altmodisch aufgebaut sein, damit es mit jedem antiken Browser läuft - dabei gibt es seiten, die in der Hinsicht modern sind, UND sogar im uralt Browser mit deaktivierten Bildern / JS noch lesbar sind. Stichwort Barrierefreiheit.

Welche Autoren größerer Seiten? Seiten, die nicht mal im "Standardkonformen Modus" funktionieren? Die ach so modernen Seiten sind wirklich meistens Seiten ohne Content aber mit schönen stylesheets, die meisten Seiten mit Content sind mehrere Jahre alt. Aber sicher könnten wir alles neu machen und dann gleich mal YUI reset als Basis verwenden, aber ... jetzt nicht, keine Zeit und kein Grund. Alle Änderungen der letzten Jahre nutzen eh CSS, sofern sinnvoll und nicht langsamer.

Aber du kannst ja gern mal ein paar "größere Seiten" posten, die deiner Meinung nach vorbildlich sind. Vielleicht mal auch eine von dir?

Ein guter Frontend Entwickler hat die Eigenheiten der letzten Browsergenerationen im Kopf, und bügelt Fehler sofort aus, nachdem er in allen möglichen Konstellationen Tests durchgeführt hat. Dann gibts ebenen für den Uralt-IE ein alternatives Stylesheet, Opera, FF, Safari kommen auch mit einem gemeinsamen bestens zurecht, auch in älteren Versionen.

Nun, entweder sind wir keine guten Frontend-Entwickler, oder deine Behauptungen sind praxisfern. Wir haben gerade z.B. ein Angebot einer bekannteren und kompetenteren Agentur für ein CSS-Design eines Projekts erhalten und da wird nicht einmal Opera erwähnt. Tatsache ist, daß (wie du auch fallweise auf GH sehen kannst) weder CSS, noch DOM auf sämtlichen modernen Browsern ohne ständige Sonderfallbehandlungen unproblematisch verwendbar sind und irgendwann ist es den Aufwand nicht wert, das verkrampft mit CSS zu lösen wenn es ohne genausogut geht.

ad Prefetching - ich wiederhole mich - selbstständig lädt der Browser nichts voraus, sonst würden sich seit dem FF 3.0 Update Millionen User darüber beklagen, dass der Browser selbsttätig Bestellungen / Logouts / was auch immer ausführt, weil er einen Link aufruft, der mit Vorsicht zu genießen ist.

Er lädt nichts voraus, hatte ich auch nicht behauptet. Er braucht aber dennoch massig CPU-Zeit und Plattenzugriffe.

Es gibt gewiss Erweiterungen, die dir alle internen Aktionen vom FF anzeigen, darunter auch die selbstständigen Requests, das sollte Klarheit verschaffen. Wenn alles scheitert, werfen wir eben einen Blick in den Quelltext

Dazu fehlt mir die Zeit, aber das Problem ist ja jetzt gelöst und die Ursache (oder etwas, das kausal damit zusammenhängt) ist beseitigt, nämlich die Prefetch-Einstellung.

Re(8): Ich tendiere jetzt auch zu MSIE ...

mjy@geizhals.at — Sat, 26 Jul 2008 11:54:17 GMT

Nochmal - wozu muss dies von einem Redakteur festgelegt werden? So viele designmäßig unterschiedliche Seiten hat GH nun wirklich nicht (öffentlich), als das man nicht für jede einzelne die Styles einmal definieren, und dann ohne diesen Overhead leben könnte. Ein "modernes" 20k Stylesheet ist um keinen deut mieser, als das positionieren von Inhalt durch Leerzeichen und Umbrüche, die immer geladen werden müssen.

Du verstehst es nicht ... Eine Seite besteht nicht nur aus Layout, sondern auch aus Content.

Ein ist kürzer als "class=bla" und kürzer als .

Ja, ich habe keine Ahnung. Offensichtlich auch die anderen Autoren größerer Seiten nicht. Du tust hier, als müsse GH möglichst altmodisch aufgebaut sein, damit es mit jedem antiken Browser läuft - dabei gibt es seiten, die in der Hinsicht modern sind, UND sogar im uralt Browser mit deaktivierten Bildern / JS noch lesbar sind. Stichwort Barrierefreiheit.

Ein guter Frontend Entwickler hat die Eigenheiten der letzten Browsergenerationen im Kopf, und bügelt Fehler sofort aus, nachdem er in allen möglichen Konstellationen Tests durchgeführt hat. Dann gibts ebenen für den Uralt-IE ein alternatives Stylesheet, Opera, FF, Safari kommen auch mit einem gemeinsamen bestens zurecht, auch in älteren Versionen.

ad Prefetching - ich wiederhole mich - selbstständig lädt der Browser nichts voraus, sonst würden sich seit dem FF 3.0 Update Millionen User darüber beklagen, dass der Browser selbsttätig Bestellungen / Logouts / was auch immer ausführt, weil er einen Link aufruft, der mit Vorsicht zu genießen ist.

Er lädt nichts voraus, hatte ich auch nicht behauptet. Er braucht aber dennoch massig CPU-Zeit und Plattenzugriffe.

Es gibt gewiss Erweiterungen, die dir alle internen Aktionen vom FF anzeigen, darunter auch die selbstständigen Requests, das sollte Klarheit verschaffen. Wenn alles scheitert, werfen wir eben einen Blick in den Quelltext

Dazu fehlt mir die Zeit, aber das Problem ist ja jetzt gelöst und die Ursache (oder etwas, das kausal damit zusammenhängt) ist beseitigt, nämlich die Prefetch-Einstellung.

Re(7): Ich tendiere jetzt auch zu MSIE ...

Dr. Watson — Sat, 26 Jul 2008 11:30:06 GMT

Zahlreiche s stammen z.B. von der Redaktion - Artikelbeschreibungen,
Überschriften... In anderen Fällen ist es einfach eine kompakte Alternative zu
..., weil man nicht für jeden Furz einen style definieren will
(so kriegt man die "modernen" 20K stylesheets).

Nochmal - wozu muss dies von einem Redakteur festgelegt werden? So viele designmäßig unterschiedliche Seiten hat GH nun wirklich nicht (öffentlich), als das man nicht für jede einzelne die Styles einmal definieren, und dann ohne diesen Overhead leben könnte. Ein "modernes" 20k Stylesheet ist um keinen deut mieser, als das positionieren von Inhalt durch Leerzeichen und Umbrüche, die immer geladen werden müssen.

a) Falsch und b) du hast vermutlich keine Ahnung, wozu sie da ist - siehe
width-Angabe für einen Hinweis. Aber wenn Browser irgendwann verläßlich
Breitenangaben in CSS verarbeiten, kann man das ja durch eine Style-Definition
ersetzen, die "modern" ist und genausoviel Platz (eher mehr) braucht.

Oje, jetzt kommt eine philosophische Diskussion ... Manche Layouts lassen sich
nun mal nur mit Tabellen verläßlich lösen, weil Browser noch immer
größtenteils fehlerhafte / unterschiedliche CSS-Implementierungen haben (wobei
das in dem konkreten Fall andere Gründe hatte, aber es gibt wirklich keinen
ersthaften Grund, das zu ändern).

Ja, ich habe keine Ahnung. Offensichtlich auch die anderen Autoren größerer Seiten nicht. Du tust hier, als müsse GH möglichst altmodisch aufgebaut sein, damit es mit jedem antiken Browser läuft - dabei gibt es seiten, die in der Hinsicht modern sind, UND sogar im uralt Browser mit deaktivierten Bildern / JS noch lesbar sind. Stichwort Barrierefreiheit.

Ein guter Frontend Entwickler hat die Eigenheiten der letzten Browsergenerationen im Kopf, und bügelt Fehler sofort aus, nachdem er in allen möglichen Konstellationen Tests durchgeführt hat. Dann gibts ebenen für den Uralt-IE ein alternatives Stylesheet, Opera, FF, Safari kommen auch mit einem gemeinsamen bestens zurecht, auch in älteren Versionen.

ad Prefetching - ich wiederhole mich - selbstständig lädt der Browser nichts voraus, sonst würden sich seit dem FF 3.0 Update Millionen User darüber beklagen, dass der Browser selbsttätig Bestellungen / Logouts / was auch immer ausführt, weil er einen Link aufruft, der mit Vorsicht zu genießen ist.

Es gibt gewiss Erweiterungen, die dir alle internen Aktionen vom FF anzeigen, darunter auch die selbstständigen Requests, das sollte Klarheit verschaffen. Wenn alles scheitert, werfen wir eben einen Blick in den Quelltext

Re(6): Ich tendiere jetzt auch zu MSIE ...

mjy@geizhals.at — Sat, 26 Jul 2008 11:14:09 GMT

Was hat denn der Quelltext mit eurer Redaktion zu tun? Normalerweise sollte es vordefinierte Stile geben und das wars, jemand der sich um die Inhalte kümmer braucht also keinen Zugriff auf Stylesheets. Oder anders rum - wäre ich Redakteur, wären technische Dinge wie der Quelltext das letzte, um das ich mich kümmern will.

Zahlreiche s stammen z.B. von der Redaktion - Artikelbeschreibungen, Überschriften... In anderen Fällen ist es einfach eine kompakte Alternative zu ..., weil man nicht für jeden Furz einen style definieren will (so kriegt man die "modernen" 20K stylesheets).

Die Hälfte der Attribute und Klassen könnte man durch geschickte CSS Selektoren einsparen , und eine blank-Grafik bedarf keines weiteren Kommentars.

a) Falsch und b) du hast vermutlich keine Ahnung, wozu sie da ist - siehe width-Angabe für einen Hinweis. Aber wenn Browser irgendwann verläßlich Breitenangaben in CSS verarbeiten, kann man das ja durch eine Style-Definition ersetzen, die "modern" ist und genausoviel Platz (eher mehr) braucht.

Tabellen sind da, um tabellarische Inhalte darzustellen. Für Produktauflistungen geschaffen, für Forenpostings missbraucht.

Oje, jetzt kommt eine philosophische Diskussion ... Manche Layouts lassen sich nun mal nur mit Tabellen verläßlich lösen, weil Browser noch immer größtenteils fehlerhafte / unterschiedliche CSS-Implementierungen haben (wobei das in dem konkreten Fall andere Gründe hatte, aber es gibt wirklich keinen ersthaften Grund, das zu ändern).

Das nehme ich dir beim besten Willen nicht ab. Ich habe das Prefetching aus Paranoia auf unterschiedlichen Rechnern aktiviert / deaktiviert, und stelle keine Unterschiede in der Performance auch. Auch wärst du scheinbar der erste, bei dem das der Fall wäre.

Tja, es ist aber wirklich so. Dabei bin ich mir ziemlich sicher, daß ich kaum/keine Seiten offen habe, die Prefetching überhaupt nutzen, aber diese 1-2 Sekunden-Freezes (sogar beim Bewegen der Maus über Links manchmal) sind verschwunden und Geizhals wirkt deutlich schneller.

Aber ich weiß ja nicht, was für eine Leitung du hast, bei den 12Mbit/s hier fällt es stark auf.

Übrigens: Prefetching ist bereits seit Firefox 1.x implementiert, und war über viele Versionen hinweg defaultmäßig aktiviert (so wie jetzt in 3.x), nur hat man es damals nicht wirklich bekannt gemacht. Du warst also möglicherweise schon ständig damit unterwegs. Und wie gesagt, ohne zutun des Seitenbetreibers hat Prefetching keine Auswirkungen.

Dann ist es Prefetching in Kombination mit der Link-Überprüfung, oder die aktuelle Implementierung (die seit 1.5 sicher nicht gleich geblieben ist) ist mies, wasweiß ich. Jedenfalls kann man über Zusammenhänge und technische Details möglicher Ursachen streiten, über Beobachtungen in der Form und Fakten nicht. Mit 2.X gab es keine derartigen Probleme, mit 3.X sind sie da, wenn man Prefetching nicht deaktiviert.

Hänger beim Laden von Seiten stelle ich nur fest, wenn man mies geschriebene Plugins im Einsatz hat, die die Seite bei jedem Aufruf vollständig parsen. Z.b. wenn man eine unnötig lange AdBlock Filterliste hat, dann dauerts eben.

Wie gesagt, nicht beim Laden, sondern einfach bei der Bedienung des Browsers. z.B. beim Tippen im Webmail-Formular oder bei anderen "events" wie mouseover. Es ist nachvollziehbar, daß das Prefetching-Versuche sein können, die ja angeblich stattfinden, wenn der browser idle ist. Was da in Wirklichkeit passiert, wenn es keine verwendbaren Links auf den offenen Seiten gibt, weiß der Kuckuck, aber ich kann's mir gut vorstellen.

Re(5): Ich tendiere jetzt auch zu MSIE ...

Dr. Watson — Sat, 26 Jul 2008 10:41:53 GMT

ist nicht nur eine Einrückung, außerdem hat z.B. die Redaktion keinen
Zugriff auf die Stylesheets.

Was hat denn der Quelltext mit eurer Redaktion zu tun? Normalerweise sollte es vordefinierte Stile geben und das wars, jemand der sich um die Inhalte kümmer braucht also keinen Zugriff auf Stylesheets. Oder anders rum - wäre ich Redakteur, wären technische Dinge wie der Quelltext das letzte, um das ich mich kümmern will.

Viel kompakter geht es nicht, daher benötigen 1000e Postings auch kaum
Ladezeit (~30KB komprimiertes HTML).

Die Hälfte der Attribute und Klassen könnte man durch geschickte CSS Selektoren einsparen, und eine blank-Grafik bedarf keines weiteren Kommentars. Alleine das müsste der Browser 1000x rendern, und das ist es, was die Wartezeit beim User ausmacht. Wenn ich z.b. mit dem Notebook im Stromsparbetrieb surfe, also die CPU nicht so darf wie sie könnte, macht sich das bemerkbar.

Tabellen sind da, um tabellarische Inhalte darzustellen. Für Produktauflistungen geschaffen, für Forenpostings missbraucht.

Die Bilder werden i.d.R. gecacht, also liegst du falsch.

Damit die Bilder überhaupt mal gecached werden können, müssen sie erst mal zum Client kommen. Davon abgesehen, dürfte der Autor eures Javascripts selbst erkannt haben, welch ein Krampf es ist, Bilder dynamisch im IE zu erzeugen, weil er sich üblicherweise weigert, jene zu laden, die nicht im Cache liegen. "Boo MSIE"

Da irrst du dich wieder, das Feature bremst den FF gewaltig ein, auch wenn es
von der Seite nicht genutzt wird. Ich habe mich davon überzeugt und es ist
tatsächlich so, die Langsamkeit des FF, die diesen Thread begründete, ist nach
dem Tipp, prefetching abzudrehen, nicht mehr vorhanden. Zumindest auf meinem
(zeitgemäßen) System und beim üblichen Browsen (mit oft 30+ offenen Fenstern).
Das war auch die Ursache für 1-2 Sekunden dauernde Hänger, die ich lange
gesucht habe (konnte mir auch nicht vorstellen, daß dieses Prefetching so mies
implementiert ist)...

Das nehme ich dir beim besten Willen nicht ab. Ich habe das Prefetching aus Paranoia auf unterschiedlichen Rechnern aktiviert / deaktiviert, und stelle keine Unterschiede in der Performance auch. Auch wärst du scheinbar der erste, bei dem das der Fall wäre.

Übrigens: Prefetching ist bereits seit Firefox 1.x implementiert, und war über viele Versionen hinweg defaultmäßig aktiviert (so wie jetzt in 3.x), nur hat man es damals nicht wirklich bekannt gemacht. Du warst also möglicherweise schon ständig damit unterwegs. Und wie gesagt, ohne zutun des Seitenbetreibers hat Prefetching keine Auswirkungen.

Hänger beim Laden von Seiten stelle ich nur fest, wenn man mies geschriebene Plugins im Einsatz hat, die die Seite bei jedem Aufruf vollständig parsen. Z.b. wenn man eine unnötig lange AdBlock Filterliste hat, dann dauerts eben.

Re(5): Ich tendiere jetzt auch zu MSIE ...

Dr. Watson — Sat, 26 Jul 2008 10:41:53 GMT

ist nicht nur eine Einrückung, außerdem hat z.B. die Redaktion keinen
Zugriff auf die Stylesheets.

Viel kompakter geht es nicht, daher benötigen 1000e Postings auch kaum
Ladezeit (~30KB komprimiertes HTML).

Die Bilder werden i.d.R. gecacht, also liegst du falsch.

Damit die Bilder überhaupt mal gecached werden können, müssen sie erst mal zum Client kommen. Davon abgesehen, dürfte der Autor eures Javascripts selbst erkannt haben, welch ein Krampf es ist, Bilder dynamisch im IE zu erzeugen, weil er sich üblicherweise weigert, nicht zu laden, die nicht im Cache liegen. "Boo MSIE"

Da irrst du dich wieder, das Feature bremst den FF gewaltig ein, auch wenn es
von der Seite nicht genutzt wird. Ich habe mich davon überzeugt und es ist
tatsächlich so, die Langsamkeit des FF, die diesen Thread begründete, ist nach
dem Tipp, prefetching abzudrehen, nicht mehr vorhanden. Zumindest auf meinem
(zeitgemäßen) System und beim üblichen Browsen (mit oft 30+ offenen Fenstern).
Das war auch die Ursache für 1-2 Sekunden dauernde Hänger, die ich lange
gesucht habe (konnte mir auch nicht vorstellen, daß dieses Prefetching so mies
implementiert ist)...

Re(4): Ich tendiere jetzt auch zu MSIE ...

mjy@geizhals.at — Sat, 26 Jul 2008 10:06:13 GMT

Wenn ich mir den Quelltext einiger Seiten durchsehe, sehe ich unzählige redundante Einträge, Byte für Byte wird da verschwendet, und muss bei jedem Request übertragen werden. Es ist nicht mehr zeitgemäß, Einrückungen durch unzählige s zu erledigen, wenn ein simples CSS Attribut das ganze im Stylesheet regeln kann, welches nicht ständig angefordert werden muss.

ist nicht nur eine Einrückung, außerdem hat z.B. die Redaktion keinen Zugriff auf die Stylesheets.

Wir verschwenden wirklich nicht viel Platz, keine Sorge. Aber vielleicht regst du dich weiter unten darüber auf, daß quotes fehlen.

Unter "sauber" verstehe ich keine Anbetung der W3 Standards, sondern eine optimale (im Sinne der Ladezeit, Renderzeit) Gestaltung des Quelltextes. Dazu gehört es auf jeden Fall nicht, Tabellen 5x und mehr zu verschachteln, das verursacht nur Traffic und Wartezeit beim Benutzer.

Für/wider Tabellen gibt es viele Diskussionen zum Nachlesen. Die Quelltexte sind bez. Ladezeit optimiert, bez. Renderzeit fallweise, aber da ändert sich auch alles bei jeder neuen Browserversion.

Aber wenn sämtliche Vorschaubilder geladen werden müssen, ist sowieso die Verbindung des Users der Flaschenhals, die paar Millisekunden beim Erzeugen der Bilder machen das Kraut nicht fett.

Die Bilder werden i.d.R. gecacht, also liegst du falsch.

Kann ich nicht, weil ich keines kenne. Aber auch in dem Fall ist Fakt - der Quelltext ist voll von Zeilen und Spalten, die wiederum gespickt sind mit Class Attributen.

Der Quellcode eines Postings ja, aber nicht der des ganzen Threads.

Ein nicht aufgeklapptes Posting sieht so aus, dazwischen ist bei einem langen Thread nichts:


<p class="Posting"><img src="/images/blank.gif" align="left" 
alt="..................." width="290" height="1" vspace="1"/>
<img align="absmiddle" alt="" src="/ng/sibling.gif"/> <a 
href="t47708,235301.html#235301"> Re(19): Zweisprachige Ortstafeln, was 
haltet ihr davon???</a> 	( <a href="/userinfo.jsp?id=101">airboy</a> 
am 21.12.2001 01:53:04 )

Viel kompakter geht es nicht, daher benötigen 1000e Postings auch kaum Ladezeit (~30KB komprimiertes HTML).

Wenn man hier umstellen würde auf eine Kombination aus Tabellen / Layern (für antike Browser wie IE <=6), und den Rest per CSS lösen würde, hat man pro Post ein gewisses Einsparpotential, dass sich bei längeren Threads n-mal wiederholt.

Niemand klappt alles auf (bei threads mit 1000+ Postings), wie ein einziges Posting dargestellt wird, ist daher ziemlich egal.

Du scheinst das Feature nicht zu kennen, denn ohne dein zutun tut der FF nämlich genau gar nichts - ohne entsprechende Tags "prefetched" der FF nix, und auch dann gibts gewisse Limits (64KB).

Da irrst du dich wieder, das Feature bremst den FF gewaltig ein, auch wenn es von der Seite nicht genutzt wird. Ich habe mich davon überzeugt und es ist tatsächlich so, die Langsamkeit des FF, die diesen Thread begründete, ist nach dem Tipp, prefetching abzudrehen, nicht mehr vorhanden. Zumindest auf meinem (zeitgemäßen) System und beim üblichen Browsen (mit oft 30+ offenen Fenstern). Das war auch die Ursache für 1-2 Sekunden dauernde Hänger, die ich lange gesucht habe (konnte mir auch nicht vorstellen, daß dieses Prefetching so mies implementiert ist)...

Re(4): Ich tendiere jetzt auch zu MSIE ...

mjy@geizhals.at — Sat, 26 Jul 2008 10:06:13 GMT

Wenn ich mir den Quelltext einiger Seiten durchsehe, sehe ich unzählige redundante Einträge, Byte für Byte wird da verschwendet, und muss bei jedem Request übertragen werden. Es ist nicht mehr zeitgemäß, Einrückungen durch unzählige s zu erledigen, wenn ein simples CSS Attribut das ganze im Stylesheet regeln kann, welches nicht ständig angefordert werden muss.

"nbsp; ist nicht nur eine Einrückung, außerdem hat z.B. die Redaktion keinen Zugriff auf die Stylesheets.

Wir verschwenden wirklich nicht viel Platz, keine Sorge. Aber vielleicht regst du dich weiter unten darüber auf, daß quotes fehlen.

Unter "sauber" verstehe ich keine Anbetung der W3 Standards, sondern eine optimale (im Sinne der Ladezeit, Renderzeit) Gestaltung des Quelltextes. Dazu gehört es auf jeden Fall nicht, Tabellen 5x und mehr zu verschachteln, das verursacht nur Traffic und Wartezeit beim Benutzer.

Für/wider Tabellen gibt es viele Diskussionen zum Nachlesen. Die Quelltexte sind bez. Ladezeit optimiert, bez. Renderzeit fallweise, aber da ändert sich auch alles bei jeder neuen Browserversion.

Aber wenn sämtliche Vorschaubilder geladen werden müssen, ist sowieso die Verbindung des Users der Flaschenhals, die paar Millisekunden beim Erzeugen der Bilder machen das Kraut nicht fett.

Die Bilder werden i.d.R. gecacht, also liegst du falsch.

Kann ich nicht, weil ich keines kenne. Aber auch in dem Fall ist Fakt - der Quelltext ist voll von Zeilen und Spalten, die wiederum gespickt sind mit Class Attributen.

Der Quellcode eines Postings ja, aber nicht der des ganzen Threads.

Ein nicht aufgeklapptes Posting sieht so aus, dazwischen ist bei einem langen Thread nichts:


<p class="Posting"><img src="/images/blank.gif" align="left" 
alt="..................." width="290" height="1" vspace="1"/>
<img align="absmiddle" alt="" src="/ng/sibling.gif"/> <a 
href="t47708,235301.html#235301"> Re(19): Zweisprachige Ortstafeln, was 
haltet ihr davon???</a> 	( <a href="/userinfo.jsp?id=101">airboy</a> 
am 21.12.2001 01:53:04 )

Viel kompakter geht es nicht, daher benötigen 1000e Postings auch kaum Ladezeit (~30KB komprimiertes HTML).

Wenn man hier umstellen würde auf eine Kombination aus Tabellen / Layern (für antike Browser wie IE <=6), und den Rest per CSS lösen würde, hat man pro Post ein gewisses Einsparpotential, dass sich bei längeren Threads n-mal wiederholt.

Niemand klappt alles auf (bei threads mit 1000+ Postings), wie ein einziges Posting dargestellt wird, ist daher ziemlich egal.

Du scheinst das Feature nicht zu kennen, denn ohne dein zutun tut der FF nämlich genau gar nichts - ohne entsprechende Tags "prefetched" der FF nix, und auch dann gibts gewisse Limits (64KB).

Re(4): Ich tendiere jetzt auch zu MSIE ...

mjy@geizhals.at — Sat, 26 Jul 2008 10:06:13 GMT

Wenn ich mir den Quelltext einiger Seiten durchsehe, sehe ich unzählige redundante Einträge, Byte für Byte wird da verschwendet, und muss bei jedem Request übertragen werden. Es ist nicht mehr zeitgemäß, Einrückungen durch unzählige s zu erledigen, wenn ein simples CSS Attribut das ganze im Stylesheet regeln kann, welches nicht ständig angefordert werden muss.

Unter "sauber" verstehe ich keine Anbetung der W3 Standards, sondern eine optimale (im Sinne der Ladezeit, Renderzeit) Gestaltung des Quelltextes. Dazu gehört es auf jeden Fall nicht, Tabellen 5x und mehr zu verschachteln, das verursacht nur Traffic und Wartezeit beim Benutzer.

Für/wider Tabellen gibt es viele Diskussionen zum Nachlesen. Die Quelltexte sind bez. Ladezeit optimiert, bez. Renderzeit fallweise, aber da ändert sich auch alles bei jeder neuen Browserversion.

Aber wenn sämtliche Vorschaubilder geladen werden müssen, ist sowieso die Verbindung des Users der Flaschenhals, die paar Millisekunden beim Erzeugen der Bilder machen das Kraut nicht fett.

Die Bilder werden i.d.R. gecacht, also liegst du falsch.

Kann ich nicht, weil ich keines kenne. Aber auch in dem Fall ist Fakt - der Quelltext ist voll von Zeilen und Spalten, die wiederum gespickt sind mit Class Attributen.

Der Quellcode eines Postings ja, aber nicht der des ganzen Threads.

Ein nicht aufgeklapptes Posting sieht so aus, dazwischen ist bei einem langen Thread nichts:


<p class="Posting"><img src="/images/blank.gif" align="left" 
alt="..................." width="290" height="1" vspace="1"/>
<img align="absmiddle" alt="" src="/ng/sibling.gif"/> <a 
href="t47708,235301.html#235301"> Re(19): Zweisprachige Ortstafeln, was 
haltet ihr davon???</a> 	( <a href="/userinfo.jsp?id=101">airboy</a> 
am 21.12.2001 01:53:04 )

Viel kompakter geht es nicht, daher benötigen 1000e Postings auch kaum Ladezeit (~30KB komprimiertes HTML).

Wenn man hier umstellen würde auf eine Kombination aus Tabellen / Layern (für antike Browser wie IE <=6), und den Rest per CSS lösen würde, hat man pro Post ein gewisses Einsparpotential, dass sich bei längeren Threads n-mal wiederholt.

Niemand klappt alles auf (bei threads mit 1000+ Postings), wie ein einziges Posting dargestellt wird, ist daher ziemlich egal.

Du scheinst das Feature nicht zu kennen, denn ohne dein zutun tut der FF nämlich genau gar nichts - ohne entsprechende Tags "prefetched" der FF nix, und auch dann gibts gewisse Limits (64KB).

Re(4): Ich tendiere jetzt auch zu MSIE ...

mjy@geizhals.at — Sat, 26 Jul 2008 10:06:13 GMT

Wenn ich mir den Quelltext einiger Seiten durchsehe, sehe ich unzählige redundante Einträge, Byte für Byte wird da verschwendet, und muss bei jedem Request übertragen werden. Es ist nicht mehr zeitgemäß, Einrückungen durch unzählige s zu erledigen, wenn ein simples CSS Attribut das ganze im Stylesheet regeln kann, welches nicht ständig angefordert werden muss.

Unter "sauber" verstehe ich keine Anbetung der W3 Standards, sondern eine optimale (im Sinne der Ladezeit, Renderzeit) Gestaltung des Quelltextes. Dazu gehört es auf jeden Fall nicht, Tabellen 5x und mehr zu verschachteln, das verursacht nur Traffic und Wartezeit beim Benutzer.

Für/wider Tabellen gibt es viele Diskussionen zum Nachlesen. Die Quelltexte sind bez. Ladezeit optimiert, bez. Renderzeit fallweise, aber da ändert sich auch alles bei jeder neuen Browserversion.

Aber wenn sämtliche Vorschaubilder geladen werden müssen, ist sowieso die Verbindung des Users der Flaschenhals, die paar Millisekunden beim Erzeugen der Bilder machen das Kraut nicht fett.

Die Bilder werden i.d.R. gecacht, also liegst du falsch.

Kann ich nicht, weil ich keines kenne. Aber auch in dem Fall ist Fakt - der Quelltext ist voll von Zeilen und Spalten, die wiederum gespickt sind mit Class Attributen.

Der Quellcode eines Postings ja, aber nicht der des ganzen Threads.

Ein nicht aufgeklapptes Posting sieht so aus, dazwischen ist bei einem langen Thread nichts:


<p class="Posting"><img src="/images/blank.gif" align="left" alt="..................." width="290" height="1" vspace="1"/>
<img align="absmiddle" alt="" src="/ng/sibling.gif"/> <a href="t47708,235301.html#235301"> Re(19): Zweisprachige Ortstafeln, was haltet ihr davon???</a> 	( <a href="/userinfo.jsp?id=101">airboy</a> am 21.12.2001 01:53:04 )

Viel kompakter geht es nicht, daher benötigen 1000e Postings auch kaum Ladezeit (~30KB komprimiertes HTML).

Wenn man hier umstellen würde auf eine Kombination aus Tabellen / Layern (für antike Browser wie IE <=6), und den Rest per CSS lösen würde, hat man pro Post ein gewisses Einsparpotential, dass sich bei längeren Threads n-mal wiederholt.

Niemand klappt alles auf (bei threads mit 1000+ Postings), wie ein einziges Posting dargestellt wird, ist daher ziemlich egal.

Du scheinst das Feature nicht zu kennen, denn ohne dein zutun tut der FF nämlich genau gar nichts - ohne entsprechende Tags "prefetched" der FF nix, und auch dann gibts gewisse Limits (64KB).

Re(3): Ich tendiere jetzt auch zu MSIE ...

Dr. Watson — Sat, 26 Jul 2008 09:32:51 GMT

Ansichtssache, er gehört auf jeden Fall zum Kompaktesten und Schnellsten.

Tut mir leid, aber das ist nicht Ansichtssache, das sind einfach Fakten. Wenn ich mir den Quelltext einiger Seiten durchsehe, sehe ich unzählige redundante Einträge, Byte für Byte wird da verschwendet, und muss bei jedem Request übertragen werden. Es ist nicht mehr zeitgemäß, Einrückungen durch unzählige s zu erledigen, wenn ein simples CSS Attribut das ganze im Stylesheet regeln kann, welches nicht ständig angefordert werden muss.

Was verstehst du unter "sauber"?

Unter "sauber" verstehe ich keine Anbetung der W3 Standards, sondern eine optimale (im Sinne der Ladezeit, Renderzeit) Gestaltung des Quelltextes. Dazu gehört es auf jeden Fall nicht, Tabellen 5x und mehr zu verschachteln, das verursacht nur Traffic und Wartezeit beim Benutzer.

Da irrst du dich gewaltig, gerade die Lösung mit den Vorschaubildern hängt
stark von der JS-Implementierung (DOM-Manipulation) ab.

Gut, das ist einer von wenigen fällen, wo es hier intensiv auf die JS Performance ankommt. Aber wenn sämtliche Vorschaubilder geladen werden müssen, ist sowieso die Verbindung des Users der Flaschenhals, die paar Millisekunden beim Erzeugen der Bilder machen das Kraut nicht fett.

Ein Forum-Thread mit 1000 Postings ist kaum optimierbar. Zeig mir ein Forum,
das so etwas platzsparender mit Threading, ohne JS-Pflicht darstellt.

Kann ich nicht, weil ich keines kenne. Aber auch in dem Fall ist Fakt - der Quelltext ist voll von Zeilen und Spalten, die wiederum gespickt sind mit Class Attributen. Wenn man hier umstellen würde auf eine Kombination aus Tabellen / Layern (für antike Browser wie IE <=6), und den Rest per CSS lösen würde, hat man pro Post ein gewisses Einsparpotential, dass sich bei längeren Threads n-mal wiederholt.

Das Feature scheint ziemlich kaputt zu sein... FF wirkt deutlich schneller mit
GH, wenn man es deaktiviert.

Du scheinst das Feature nicht zu kennen, denn ohne dein zutun tut der FF nämlich genau gar nichts - ohne entsprechende Tags "prefetched" der FF nix, und auch dann gibts gewisse Limits (64KB).

Re(3): Ich tendiere jetzt auch zu MSIE ...

Dr. Watson — Sat, 26 Jul 2008 09:32:51 GMT

Ansichtssache, er gehört auf jeden Fall zum Kompaktesten und Schnellsten.

Was verstehst du unter "sauber"?

Da irrst du dich gewaltig, gerade die Lösung mit den Vorschaubildern hängt
stark von der JS-Implementierung (DOM-Manipulation) ab.

Ein Forum-Thread mit 1000 Postings ist kaum optimierbar. Zeig mir ein Forum,
das so etwas platzsparender mit Threading, ohne JS-Pflicht darstellt.

Das Feature scheint ziemlich kaputt zu sein... FF wirkt deutlich schneller mit
GH, wenn man es deaktiviert.

Du scheinst das Feature nicht zu kennen, denn ohne dein zutun tut der FF nämlich genau gar nichts - ohne entsprechende Tags tut der FF nämlich genau nix, und auch dann gibts gewisse Limits (64KB).

Re(3): Ich tendiere jetzt auch zu MSIE ...

Dr. Watson — Sat, 26 Jul 2008 09:32:51 GMT

Ansichtssache, er gehört auf jeden Fall zum Kompaktesten und Schnellsten.

Was verstehst du unter "sauber"?

Da irrst du dich gewaltig, gerade die Lösung mit den Vorschaubildern hängt
stark von der JS-Implementierung (DOM-Manipulation) ab.

Ein Forum-Thread mit 1000 Postings ist kaum optimierbar. Zeig mir ein Forum,
das so etwas platzsparender mit Threading, ohne JS-Pflicht darstellt.

Kann ich nicht, weil ich keines kenne. Aber auch in dem Fall ist Fakt - der Quelltext ist voll von Zeilen und Spalten, die widerum gespickt sind mit Class Attributen. Wenn man hier umstellen würde auf eine Kombination aus Tabellen / Layern (für antike Browser wie IE <=6), und den Rest per CSS lösen würde, hat man pro Post ein gewisses Einsparpotential, dass sich bei längeren Threads n-mal wiederholt.

Das Feature scheint ziemlich kaputt zu sein... FF wirkt deutlich schneller mit
GH, wenn man es deaktiviert.

Du scheinst das Feature nicht zu kennen, denn ohne dein zutun tut der FF nämlich genau gar nichts - ohne entsprechende Tags tut der FF nämlich genau nix, und auch dann gibts gewisse Limits (64KB).

Re(2): Ich tendiere jetzt auch zu MSIE ...

mjy@geizhals.at — Sat, 26 Jul 2008 09:08:30 GMT

Euer Quelltext gehört mit zum Schlimmsten, was man im WWW heutzutage noch finden kann, bei Seiten dieser Größenordnung.

Ansichtssache, er gehört auf jeden Fall zum Kompaktesten und Schnellsten.

ch will gar nicht wissen, wie viel performanter GH sein könnte, wenn man das Layout gleichbehält, und nur den Quelltext optimiert (sauber neu schreibt), und ernsthaft mit Stylesheets arbeitet

Was verstehst du unter "sauber"?

Speziell beim Forum, Themen ab 1000 Beiträgen werden unlesbar lahm, dabei scheiterts nur am gigantischen Overhead durch den Quelltext.

Ein Forum-Thread mit 1000 Postings ist kaum optimierbar. Zeig mir ein Forum, das so etwas platzsparender mit Threading, ohne JS-Pflicht darstellt.

Punkto Javascript hat sich der FF3 extrem verbssert, merkt man auf GH eher nicht. Wobei das als Pluspunkt zu sehen ist.

Da irrst du dich gewaltig, gerade die Lösung mit den Vorschaubildern hängt stark von der JS-Implementierung (DOM-Manipulation) ab.

Grade auf GH würde es sich auch anbieten, das Link Prefetching vom FF zu
nutzen. Ich denke, den ersten Artikel einer Produktsuche könnte man immer
bereits im voraus laden, weil er ziemlich sicher angeklickt wird.

Das Feature scheint ziemlich kaputt zu sein... FF wirkt deutlich schneller mit GH, wenn man es deaktiviert.

Re(2): Ich tendiere jetzt auch zu MSIE ...

mko — Sat, 26 Jul 2008 09:04:43 GMT

Speziell beim Forum, Themen ab 1000 Beiträgen werden unlesbar lahm, dabei
scheiterts nur am gigantischen Overhead durch den Quelltext.

Wobei selbst das mit dem FF3 viel schneller geworden ist, warum auch immer...

Re: Ich tendiere jetzt auch zu MSIE ...

Dr. Watson — Sat, 26 Jul 2008 08:54:38 GMT

Vielleicht liegt's ja auch an unserem HTML

Re: Ich tendiere jetzt auch zu MSIE ...

Dr. Watson — Sat, 26 Jul 2008 08:54:38 GMT

Vielleicht liegt's ja auch an unserem HTML

Vielleicht?

Euer Quelltext gehört mit zum Schlimmsten, was man im WWW heutzutage noch finden kann, bei Seiten dieser Größenordnung.

Ich will gar nicht wissen, wie viel performanter GH sein könnte, wenn man das Layout gleichbehält, und nur den Quelltext optimiert (sauber neu schreibt), und ernsthaft mit Stylesheets arbeitet.

Speziell beim Forum, Themen ab 1000 Beiträgen werden unlesbar lahm, dabei scheiterts nur am gigantischen Overhead durch den Quelltext.

Wie auch immer, ich konnte keine Unterschiede zwischen FF2 und FF3 spüren, und bin hier oft unterwegs. Punkto Javascript hat sich der FF3 extrem verbssert, merkt man auf GH eher nicht. Wobei das als Pluspunkt zu sehen ist.

[edit2]
Grade auf GH würde es sich auch anbieten, das Link Prefetching vom FF zu nutzen. Ich denke, den ersten Artikel einer Produktsuche könnte man immer bereits im voraus laden, weil er ziemlich sicher angeklickt wird.

Re: Ich tendiere jetzt auch zu MSIE ...

Dr. Watson — Sat, 26 Jul 2008 08:54:38 GMT

Vielleicht liegt's ja auch an unserem HTML

Re(4): Ich tendiere jetzt auch zu MSIE ...

RoHS — Fri, 25 Jul 2008 22:21:03 GMT

Also blinkende Gifs sind ja fast schon nostalgisch

da hilft aber auch die hosts datei weiter!

Re: Ich tendiere jetzt auch zu MSIE ...

cuoca — Fri, 25 Jul 2008 20:57:45 GMT

das prefetching schon ausgeschaltet?

Re: Ich tendiere jetzt auch zu MSIE ...

MG — Fri, 25 Jul 2008 20:16:01 GMT

Bei mior fühlt sich der 3er viel flotter an als der 2er.

Re(2): Ich tendiere jetzt auch zu MSIE ...

Alkestis — Fri, 25 Jul 2008 18:18:59 GMT

selbes hier festgestellt. Verwende den FF3 auf all meinen PC's und auch auf meinem MacBook, dazu noch Foxmarks und ein paar andere nützliche AddOns wie Adblocker Plus, deutsches und englisches Wörterbuch und Flashblock.

Ich kann mit dem IE überhaupt nix anfangen und der Opera gefällt mir auch nicht wirklich.

Re: Ich tendiere jetzt auch zu MSIE ...

hellbringer — Fri, 25 Jul 2008 18:04:26 GMT

FF3 ist gegenüber FF2 richtig schnell geworden. Ist bei mir sogar schneller als IE7 und Safari. Deswegen seh ich keinen Grund, warum ich einen anderen Browser als FF3 verwenden sollte.

Re: Ich tendiere jetzt auch zu MSIE ...

hellbringer — Fri, 25 Jul 2008 18:04:26 GMT

FF3 ist gegenüber FF2 richtig blitzschnell geworden. Ist bei mir sogar schneller als IE7 und Safari. Deswegen seh ich keinen Grund, warum ich einen anderen Browser als FF3 verwenden sollte.

Re: Ich tendiere jetzt auch zu MSIE ...

User6465 — Fri, 25 Jul 2008 17:56:26 GMT

ich kommt eigentlich keinen unterschied auf der gh-site im bezuf auf geschwindigkeit von ff2 zu ff3 erkennen.

Re: Ich tendiere jetzt auch zu MSIE ...

juwb — Fri, 25 Jul 2008 17:06:59 GMT

Komisch, bei mir ist FF 3.0 deutlich schneller geworden, im Vergleich zu FF 2. Gibt allerdings einige andere Sachen die mir nicht gefallen, z.B. das neue Verhalten von 'Open All in Tabs', oder die neuen https-Warnungen.

Re: Ich tendiere jetzt auch zu MSIE ...

Srv-02 — Fri, 25 Jul 2008 17:02:56 GMT

Beim AvantBrowser kannst auch gezielt Skripte, Java Applets, ActiveX, Flash & Co deaktivieren.

Re(3): Ich tendiere jetzt auch zu MSIE ...

Diabolo2000 — Fri, 25 Jul 2008 17:02:35 GMT

Ich seh auch viele blinkende .gif^^

Re(3): Ich tendiere jetzt auch zu MSIE ...

Diabolo2000 — Fri, 25 Jul 2008 17:02:35 GMT

Ich seh auch viele blinkende .gif^^
Und die Bildverbergefunktion ist sehr angenehm: Zwei Klicks und ein Bild ist weg.

Re(2): Ich tendiere jetzt auch zu MSIE ...

mjy@geizhals.at — Fri, 25 Jul 2008 17:02:14 GMT

Kein Adblockplus? (<- Mein Hauptgrund für den FF)

nö ... die meisten Werbungen sind ja JS, das erledigt NoScript also automatisch.

Re: Ich tendiere jetzt auch zu MSIE ...

Diabolo2000 — Fri, 25 Jul 2008 17:00:59 GMT

FF-AddOns

Kein Adblockplus? (<- Mein Hauptgrund für den FF)
Außerdem funktioniert das Webinterface der Dreambox 800 nicht mit dem IE.

Ich spür zwischen dem IE und dem FF keinen Geschwindigkeitsunterschied, ich hab auch nie darauf geachtet. Und Verzögerungen unter einer Sekunde sind mir wohl wurscht.

Ich tendiere jetzt auch zu MSIE ...

mjy@geizhals.at — Fri, 25 Jul 2008 16:57:56 GMT

Es ist erstaunlich, wie lahm FF 3.0 geworden ist, richtige Bloatware... Vielleicht liegt's ja auch an unserem HTML (FF => standardkonformer Modus), aber MSIE ist deutlich schneller beim Anzeigen der Seiten, auch Opera hat keine Chance. Vor allem wenn JS/DHTML involviert ist, wie z.B. wenn wir unsere Banner-IFRAMEs dynamisch verkleinern...

Nur NoScript und "Web Developer 1.x" würde ich schmerzlich vermissen, die ganzen anderen verspielten FF-AddOns können mir gestohlen bleiben.