nicht angemeldet
Gunnar Bittersmann
Der Martin
Gunnar Bittersmann
Der Martin
Auge
molily
Auge
Gunnar Bittersmann
Auge
molily
hi,
geht mir das alleine so, oder gibt es Leidensgenossen?
Es geht um "Thread als gelesen markieren"; teilweise kommt es auch vor, dass ich die Verzeichnisse, die zum zuklappen der Threads gedacht sind, alle nicht angezeigt bekomme, nach einem reload dann einige, manchmal alle, so ziemlich willkürlich das ganze.
Will vor dem debuggen ausschliessen, dass es an mir liegt, da es auf meinem Normalen Rechner und auch auf meinem Notebokk vorkommt, Firefox 3.5.
mfg
hi,
geht mir das alleine so, oder gibt es Leidensgenossen?
Ja, bisher dachte ich jedoch immer, das liegt am Browser oder am Proxy, hab dann immer gleich den IE genommen und da war alles da.
Hotte
@@Malcolm Beck´s:
nuqneH
geht mir das alleine so, oder gibt es Leidensgenossen?
+1
Qapla'
Hallo,
geht mir das alleine so, oder gibt es Leidensgenossen?
ich auch, ich auch!
Nee, ehrlich: Die von src.selfhtml.org gezogenen Bilder scheinen manchmal, aber wirklich nur manchmal, mit erheblicher Verzögerung zu kommen, manchmal auch gar nicht (oder mit so großer Verzögerung, dass der Browser den Request als Timeout abschreibt). Nach einem Reload ist dann plötzlich wieder alles gut.
Welche Bilder davon genau betroffen sind, variiert von Mal zu Mal. Gelegentlich sehe ich auch anstatt des SELFHTML-Logos oben das "Broken-Image"-Symbol.
Aber so wie du es in deinem Screenshot zeigst, habe ich es noch nicht erlebt. Wenn mein Browser ein Bild laden konnte, werden auch alle seine Vorkommen auf der Seite korrekt angezeigt. Oder andersrum: Wenn's fehlt, dann fehlt es überall auf der Seite.
Es geht um "Thread als gelesen markieren"
Es geht ebenso häufig um "Thread ausblenden" oder "Thread als interessant markieren".
Will vor dem debuggen ausschliessen, dass es an mir liegt, da es auf meinem Normalen Rechner und auch auf meinem Notebokk vorkommt, Firefox 3.5.
Ich konnte auch noch keine Browser- oder Rechnerabhängigkeit feststellen.
So long,
Martin
hi Martin,
Aber so wie du es in deinem Screenshot zeigst, habe ich es noch nicht erlebt. Wenn mein Browser ein Bild laden konnte, werden auch alle seine Vorkommen auf der Seite korrekt angezeigt.
Eben aus diesem Grund hielt ich diesen Bug für ein Lokales Problem, nur auf meinen Rechnern.
Es geht um "Thread als gelesen markieren"
Es geht ebenso häufig um "Thread ausblenden" oder "Thread als interessant markieren".
Ja, stimmt, jetzt wo du es sagst. Mir fielen im Zuge der Problembeschreibung nur die beiden auf, die letzten Tage hatte ich aber durchaus mit allen Buttons Probleme.
mfg
Hallo,
geht mir das alleine so, oder gibt es Leidensgenossen?
geht mir genauso. Nur das komische daran:
_Alle_ Bilder werden korrekt angezeigt außer eines jedes mal. Und dieses eine Bild ist entweder das auf deinem Bild oder ein anderes der drei Symbole. Kein anderes Bild ist davon betroffen(ja ok, so viel verschiedene Bilder gibts nun wirklich nicht, aber egal...)
MfG. Christoph Ludwig
hi,
(ja ok, so viel verschiedene Bilder gibts nun wirklich nicht, aber egal...)
17 an der Zahl sind nicht unbedingt wenig, Gross oder Klein mal aussen vor.
mfg
hi,
geht mir das alleine so, oder gibt es Leidensgenossen?
Schön, ich bin nicht allein! ;)
Vorschlag: ich helfe gerne, die Forum-Hauptseite zu überarbeiten, mit CSS-Sprites, dann wird nur ein Bild geladen und gut ist.
Natürlich nur, wenn es erwünscht ist.
Eine überarbeitung wäre sicherlich nicht schlecht, für das Simple Layout hier werden sage und schreibe 17 Grafiken geladen.
mfg
Moin!
Vorschlag: ich helfe gerne, die Forum-Hauptseite zu überarbeiten, mit CSS-Sprites, dann wird nur ein Bild geladen und gut ist.
Ich hab mir die HTTP-Requests mal angesehen, die der Browser beim Reload der Startseite so erzeugt.
Dabei ist mir als allererstes aufgefallen, dass die eingebundenen Javascript-Dateien immer explizit neu geladen werden. Der Versuch, dagegen etwas zu tun, ist aber leider im Endeffekt gescheitert.
Das Problem ist, dass die Browser beim expliziten Reload (und wer drückt hier im Forum nicht F5?) immer Requests schicken, die irgendwelche Caches ausschalten. Warum nun ausgerechnet der Host src.selfhtml.org die Request nach den Grafiken mit 304 beantwortet, es mir aber für die Javascript-Dateien auf forum.de.selfhtml.org nicht gelungen ist (oder nur teilweise), ist noch zu untersuchen. Ich vermute einen Zusammenhang mit mod_deflate bzw. GZip-Transfer-Encoding.
Jedenfalls: Die Grafiken werden, sofern vorhanden, nicht nochmal neu geladen, aber dummerweise spart sich der Browser beim Reload halt nicht den Request.
Außerdem fällt auf, dass die letzten drei Grafiken, die geladen werden, erst nach einer etwas unerklärlichen Kunstpause fertig sind. Das ist unter bestimmten Umständen wohl auch die Grafik für die Interessant-Markierung.
Unbelassen dieser Umstände ist die gesamte Struktur des Forums-HTML tatsächlich verbesserungswürdig. Beispielsweise gehören Einbindungen von Javascript - außer dort wird document.write verwendet - an das Ende der HTML-Seite, denn Javascript verlangsamt den parallelen Ladeprozess von Ressourcen.
Und ohne Frage werden ziemlich viele Requests verbraten, um ziemlich kleine Grafiken zu laden, oftmals mit der Antwort "304", was nicht schön ist. Und dies wird dummerweise meist durch den manuellen Browser-Reload verursacht. Würde man alternativ die Seite neu durch Aktivieren der URL-Eingabezeile im Browser plus Return neu laden, oder durch Klicken auf einen Link, der zurück auf dieselbe Seite zeigt, wäre dieses Problem tatsächlich umgehbar.
Natürlich nur, wenn es erwünscht ist.
Ich bin absolut nicht abgeneigt - die Frage ist dann, in welcher Form wir deine Überarbeitung in die bestehenden Forums-Templates integrieren können. So wie's aussieht, lagern zumindest die fraglichen Einbindungen der Grafiken in der Threadauflistung alle friedlich als explizites <img> in einem Template.
Vielleicht saugst du dir einfach eine Seitenversion der Startseite, speicherst die zweimal, arbeitest an der einen Version, und schickst beide Dateien ein. Dann kriegen wir durch das Diff raus, was sich geändert hat, und suchen dann dessen Position in den Templates.
- Sven Rautenberg
@@Sven Rautenberg:
nuqneH
So wie's aussieht, lagern zumindest die fraglichen Einbindungen der Grafiken in der Threadauflistung alle friedlich als explizites <img> in einem Template.
Auf die Schnelle: Ersetze
<img src="http://src.selfhtml.org/xopen.gif" width="16" height="16" alt="Thread aufgeklappt" />
durch
Thread zuklappen
Die Formatierung (Verschieben des Textes nach außerhalb des Viewports, CSS-Sprite als Hintergrundbild) für die Klasse "link-thread-zuklappen".
Für die anderen analog.
Qapla'
Moin!
So wie's aussieht, lagern zumindest die fraglichen Einbindungen der Grafiken in der Threadauflistung alle friedlich als explizites <img> in einem Template.
Auf die Schnelle: Ersetze
<img src="http://src.selfhtml.org/xopen.gif" width="16" height="16" alt="Thread aufgeklappt" />
durch
Thread zuklappenDie Formatierung (Verschieben des Textes nach außerhalb des Viewports, CSS-Sprite als Hintergrundbild) für die Klasse "link-thread-zuklappen".
Tja, hm... eine Lösung "auf die Schnelle" bringt's nicht unbedingt, und die würde ich auch nicht einfach so einbauen.
Ich denke, Malcolm Beck's kriegt da schon was brauchbares hin. Im Zweifel und zum detaillierten Daten- und Infoaustausch würde ich allerdings EMail vorziehen.
- Sven Rautenberg
@@Sven Rautenberg:
nuqneH
Tja, hm... eine Lösung "auf die Schnelle" bringt's nicht unbedingt,
„Auf die Schnelle“ wollte ich auch nicht auf die Lösung, sondern auf meine Beschreibung bezogen wissen: Ich hatte mir nur eins von 17(?) Bildern rausgepickt.
Qapla'
Hallo Sven,
Jedenfalls: Die Grafiken werden, sofern vorhanden, nicht nochmal neu geladen, aber dummerweise spart sich der Browser beim Reload halt nicht den Request.
das ist -zumindest von meiner Seite als Nutzer- durchaus gewollt. Ich stelle meine Browser so ein, dass sie *immer* mit einem Conditional Request (mit If-Modified-Since-Header) nachfragen, ob die Version im Cache noch gültig ist. Und wenn der Server das dann mit einem 304 beantwortet, is' ja gut. Nach meiner Erfahrung cachen die meisten Browser nämlich mehr als gut wäre.
Außerdem fällt auf, dass die letzten drei Grafiken, die geladen werden, erst nach einer etwas unerklärlichen Kunstpause fertig sind.
Ja. Das deckt sich mit meiner Beobachtung - allerdings gilt diese Kunstpause manchmal auch für alle 15 Grafiken (wie Malcolm Beck's auf 17 kommt, weiß ich nicht, bei mir sind's 15).
Das ist unter bestimmten Umständen wohl auch die Grafik für die Interessant-Markierung.
Eine dieser drei letzten ist bei mir meistens das Logo links oben.
Und ohne Frage werden ziemlich viele Requests verbraten, um ziemlich kleine Grafiken zu laden, oftmals mit der Antwort "304", was nicht schön ist.
Wäre es da nicht schlau, man würde zumindest denjenigen Nutzern, die sowieso einen Testserver "in Reichweite" haben, die Verwendung eines lokalen Mirrors für src.selfhtml.org nahelegen? Der Vorschlag wurde ja schon gelegentlich geäußert, und der Datenbestand dieses Hosts als zip-Archiv zur Verfügung gestellt. Das ist aber wahrscheinlich nicht mehr aktuell, oder?
Das könnte zumindest die Zahl der Requests auf src.selfhtml.org signifikant reduzieren.
Und dies wird dummerweise meist durch den manuellen Browser-Reload verursacht. Würde man alternativ die Seite neu durch Aktivieren der URL-Eingabezeile im Browser plus Return neu laden, oder durch Klicken auf einen Link, der zurück auf dieselbe Seite zeigt, wäre dieses Problem tatsächlich umgehbar.
Ja, je nach Browserkonfiguration.
So long,
Martin
hi,
Dabei ist mir als allererstes aufgefallen, dass die eingebundenen Javascript-Dateien immer explizit neu geladen werden. Der Versuch, dagegen etwas zu tun, ist aber leider im Endeffekt gescheitert.
Auch die Javascript-CSS wird immer neu geladen. Es scheint, als ob http://forum.de.selfhtml.org falsch konfiguriert ist, da alles, was von http://src.selfhtml.org/ kommt auch gecached wird.
Ich weiss nicht, ob dass für euch in Frage kommt, aber Minify ist in der hinsicht Empfehlenswert.
Minify Komprimiert die Dateien soweit es geht (je nachdem, was verfügbar ist, GZip oder Deflate) und schickt auch die richtigen header mit raus, 304 wenn bereits im Cache.
Ich vermute einen Zusammenhang mit mod_deflate bzw. GZip-Transfer-Encoding.
Ich habe mir mal die JQuery-Lib von SELFHTML runtergeladen und bei mir hoch geladen:
Nicht modifiziert -- Mein Server kann JS-Dateien leider nicht GZippen, aber die Header werden Korrekt gesendet.
Content-Length: 54297
Minifiziert -- Mit Minify wird das ganze gezippt und auch die Header werden richtig gesetzt.
Content-Length: 14540
http://forum.de.selfhtml.org/jquery-1.2.1-slightly-minified.js
Content-Length: 16203
Was noch leicht ausgebessert werden kann:
Struppi<FilesMatch "\.(jpg|jpeg|gif|png|css|js|ico)$">
ExpiresActive On
## Da sich die Statischen Ressourcen eh nicht ändern
ExpiresDefault "access plus 10 years"
FileETag MTime Size
Header set Cache-Control "public, no-transform"
</FilesMatch>
Vielleicht saugst du dir einfach eine Seitenversion der Startseite, speicherst die zweimal, arbeitest an der einen Version, und schickst beide Dateien ein. Dann kriegen wir durch das Diff raus, was sich geändert hat, und suchen dann dessen Position in den Templates.
Werde mich heute Abend an die Arbeit machen.
mfg
Ich habe mir mal die JQuery-Lib von SELFHTML runtergeladen und bei mir hoch geladen:
Es war Absicht, dass hier nicht die Standard-Minified-Version von jQuery eingesetzt wird. Nachdem Fehler in der Lib auftraten, wurde die »slightly minified«-Variante eingesetzt, um Debugging zu ermöglichen. Mittlerweile könnte man wohl wieder auf die Standard-Version zurück, nachdem die Benutzer lange keine Fehler gemeldet haben.
Minify für JavaScript würde ich übrigens nicht empfehlen. jQuery bietet wie gesagt eine gute minified Version von Haus aus. Darüber hinaus sollte man einen Minifier mit echtem ECMAScript-Tokenizer verwenden, i.e. YUI Compressor.
Mathias
hi,
Minify für JavaScript würde ich übrigens nicht empfehlen. jQuery bietet wie gesagt eine gute minified Version von Haus aus. Darüber hinaus sollte man einen Minifier mit echtem ECMAScript-Tokenizer verwenden, i.e. YUI Compressor.
Danke für den Hinweis, werde mir den YUI Compressor nochmal genauer ansehen (hatte ich schon gemacht, nur ist die verwendung von YUI Compressor alles andere als angenehm oder leicht).
mfg
nur ist die verwendung von YUI Compressor alles andere als angenehm oder leicht
Gibt es auch als Online-Dienste:
http://refresh-sf.com/yui/
http://yui.2clics.net/
Mathias
hi,
Gibt es auch als Online-Dienste:
http://refresh-sf.com/yui/
http://yui.2clics.net/
Danke für die Links, sind gebookmarked; allerdings brauche ich einen "On the fly"-Kompressor, der das ganze auch gleich Zipped, so wie Minify, da auf meinem Server mod_deflate nicht verfügbar ist, leider.
Ich könnte das ganze auch Manuell zippen und per Rewrite für die UAs, die Gzip verstehen, umleiten, aber dass ist auch schon wieder aufwendig.
Wobei, die Javascripts könnte ich durchaus so Handhaben, da gehe ich eh nicht mehr dran.
mfg
hi,
Es war Absicht, dass hier nicht die Standard-Minified-Version von jQuery eingesetzt wird. Nachdem Fehler in der Lib auftraten, wurde die »slightly minified«-Variante eingesetzt, um Debugging zu ermöglichen.
Ich hatte die Frage vor kurzem schon mal gepostet, nur hat sich da keiner gemeldet, daher frage ich dich jetzt direkt (da du ja auch hier zu den Javasript-Gurus zählst).
Was spricht denn gegen die einbindung der JQuery-Lib über Google?
28 KB (94 KB unkomprimiert)
Gibt es übrigens auch Minifiziert.
16 KB (53 KB unkomprimiert)
Ich wollte mir über diesen dienst das SWF-Objekt einbinden, nur bin ich derzeit nicht Kompatiblel mit der neuen Version, da die Helden von Longtail den Code geändert haben und jetzt mit body onload="()" arbeiten, und das kann ich derzeit nicht integrieren bzw. habe ich keine grosse Lust auf body onload.
mfg
Was spricht denn gegen die einbindung der JQuery-Lib über Google?
Aus meiner Sicht nichts - allerdings könnte dann auch gleich die neueste Version verwendet werden. Die alte wurde absichtlich verwendet, weil neuere einen für die Forumshauptseite fatalen Bug hatten, der nun behoben ist.
Es sind m.W. ohnehin nur ein paar Zeilen trivialer JS-Code, der hier auf jQuery basiert. Wenn man groß auf Performanceoptimerung macht, wäre es effektiver, diesen Code ohne jQuery in Plain DOM umzuschreiben. Wer jQuery für User-Scripte braucht, müsste es dann selbst einbinden.
Mathias
hi,
Aus meiner Sicht nichts -
Ok, das hat mich nur interessiert.
Bei meiner Recherche zu diesem Dienst bin ich auf viel Kritik gestossen, meistens Verfolgungswahn, daher hatte mich eure Meinung dazu interessiert.
Leider war niemand auf den Thread eingegangen -- zumindest nicht ernsthaft.
allerdings könnte dann auch gleich die neueste Version verwendet werden. Die alte wurde absichtlich verwendet, weil neuere einen für die Forumshauptseite fatalen Bug hatten, der nun behoben ist.
Das ist euer buisness, für mich ist Javascript nach wie vor Voodoo ;)
Es sind m.W. ohnehin nur ein paar Zeilen trivialer JS-Code, der hier auf jQuery basiert. Wenn man groß auf Performanceoptimerung macht, wäre es effektiver, diesen Code ohne jQuery in Plain DOM umzuschreiben. Wer jQuery für User-Scripte braucht, müsste es dann selbst einbinden.
Eine möglichkeit wäre auch, den Google-Loader zur verfügung zu stellen, dann kann jeder seine bevorzugte Lib/Libs benutzen.
mfg
Bei meiner Recherche zu diesem Dienst bin ich auf viel Kritik gestossen, meistens Verfolgungswahn, daher hatte mich eure Meinung dazu interessiert.
Naja, dir ist aber schon klar, dass dadurch google noch mehr Daten erhält?
Insofern halte ich das nicht für Wahn, sondern es ist ein Fakt. Es ist halt nur so, dass google ja niemanden schadet (behaupten sie). Allerdings würde ich mir über deren vielfältigen Möglichkeiten den Internetuser zu beobachten schon Gedanken machen.
Struppi.
hi,
Naja, dir ist aber schon klar, dass dadurch google noch mehr Daten erhält?
Insofern halte ich das nicht für Wahn, sondern es ist ein Fakt. Es ist halt nur so, dass google ja niemanden schadet (behaupten sie). Allerdings würde ich mir über deren vielfältigen Möglichkeiten den Internetuser zu beobachten schon Gedanken machen.
Wieviel kann Google dadurch schon ausspionieren? Ein Request bzw. zwei, wenn man das favicon mitzählt, mehr wird nicht vermittelt.
Google weiss nun eine IP (sofern die Lib nicht aus dem Cache geladen wurde) und die aufgerufene Seite, weiss aber weder, was der User dort sucht oder vielleicht schon gefunden hat.
Auch die Header, die die Libs senden sind korrekt (304 Not Modified wenn im Cache, keine Cookies u.s.w.).
Wenn ich mit den ganzen Addons, die ich hier auf meinem FF habe, Seiten aufrufe, werden diese Infos auch an diverse Dienste gesendet; Alexa-Pageranktool, Delicious-Bookmarkfunktion, Google-suche oben rechts in meinem Browser, fire.fm sendet zu teilen Live was auf meinem Browser vor sich geht.
Der Grundgedanke ist doch, dass wenn viele Publisher diesen Dienst nutzen, sehr viele User diese Libs schon beim betreten der Seite in ihrem Cache haben; es könnte ja durch aus sein, dass Google, trotz der vielen Intrigen, auch mal was gutes für das Netz tun will.
Mich würde mal interessieren, wieviel Google im schlimmsten Fall auf diese Weise ausspionieren könnte, weisst du da näheres?
mfg
Mich würde mal interessieren, wieviel Google im schlimmsten Fall auf diese Weise ausspionieren könnte, weisst du da näheres?
Du denkst zu kurz. Natürlich ist diese eine Sache relativ belanglos und dürfte relativ wenig informationsgehalt haben.
Aber google hat auch die IPs (fast) aller Suchender, gmail, google Ads und youtube Nutzer (es gibt sicher noch mehr Dienste). Und jede IP ist in dem Moment eindeutig und wenn du einen Dienst wie gmail nutzt, dann bist du für google sogar leicht persönlich identifizierbar. Wunderbar!
Ich kann mir aufgrund der Datenflut zwar auch kaum vorstellen was die damit machen, aber ich bin nur ein kleines Licht und muss auch nicht Millionen für irgendwelche Aktionäre verdienen.
Struppi.
hi,
Du denkst zu kurz. Natürlich ist diese eine Sache relativ belanglos und dürfte relativ wenig informationsgehalt haben.
Was heisst kurz, ich habe mir zu diesem Thema schon zahlreiche Gedanken gemacht, die alle auf das gleiche hinauslaufen; Google stellt hier einen Dienst zur verfügung, von dem es Grundsätzlich nichts hat -- vielleicht einfach nur aus dem Grund, weil Google die Kapazitäten besitzt, so einen Dienst Kostenlos zur verfügung zu stellen.
Aber google hat auch die IPs (fast) aller Suchender, gmail, google Ads und youtube Nutzer (es gibt sicher noch mehr Dienste). Und jede IP ist in dem Moment eindeutig und wenn du einen Dienst wie gmail nutzt, dann bist du für google sogar leicht persönlich identifizierbar. Wunderbar!
Eben, Google bekommt Detailliertere Infos von den Nutzern "Freiwillig eingereicht", da werden die Paar IPs, die Google "Eventuell" durch die Einbindung der Scripte ermittelt, belanglos sein.
Und ich spreche hier ausschliesslich von den Libs, keinen der anderen Dienste.
aber ich bin nur ein kleines Licht und muss auch nicht Millionen für irgendwelche Aktionäre verdienen.
Und da sehe ich die einzige Motivation der Grossen Suchmaschinen, mit allen Mitteln das Web schneller zu machen. Ein schnelles Netz, schnelle Informationsbeschaffung, denn jede Sekunde, die ich damit verbringe, dass eine Seite ladet, ist verschwendet; wenn man das auf ein Paar Millionen User hochrechnet, summiert sich das auf Stunden, Tage und Wochen, die User mit warten verbringen, wo sie doch auch weiter suchen könnten.
mfg
Aber google hat auch die IPs (fast) aller Suchender, gmail, google Ads und youtube Nutzer (es gibt sicher noch mehr Dienste). Und jede IP ist in dem Moment eindeutig und wenn du einen Dienst wie gmail nutzt, dann bist du für google sogar leicht persönlich identifizierbar. Wunderbar!
Eben, Google bekommt Detailliertere Infos von den Nutzern "Freiwillig eingereicht", da werden die Paar IPs, die Google "Eventuell" durch die Einbindung der Scripte ermittelt, belanglos sein.
Und ich spreche hier ausschliesslich von den Libs, keinen der anderen Dienste.
Wie gesagt, die hängen alle zusammen.
Du loggst dich bei gmail ein um deine Mail zu checken - jetzt hat google eine IP mit deinem Namen. Danach loggst du dich aus und willst dich ein wenig entspannen und suchst nach 'porno' dann weiß google, aha der Malcolm hat nach porno gesucht. Und wenn der Anbieters dann die Bib eingebunden hat, hat google ein wichtigen Baustein für ein Werbeprofil. Damit kann google dann seine Werbung für dich entsprechend aufarbeiten. Wenn dir das keine Sorgen macht (ich kenne auch Leute die sagen Werbung ist ja Information), dann ist es ok.
Mir ist das Suspekt und ich will das nicht, deshalb blocke ich sowas, wann immer es geht.
Man kann diese Sache natürlich auch weiterspinnen. Was ist wenn jemals eine Regierung auf die Idee käme, diese Daten irgendwie zu verwenden? Aktuell sehe ich da die Rechenkapazitäten nicht, aber wenn sie vorhanden wäre, ein Horrorszenario. Aber das fällt wohl unter den Begriff Verfolgungswahn
Struppi.
hi,
Du loggst dich bei gmail ein um deine Mail zu checken - jetzt hat google eine IP mit deinem Namen. Danach loggst du dich aus und willst dich ein wenig entspannen und suchst nach 'porno' dann weiß google, aha der Malcolm hat nach porno gesucht.
Meine IP hat Google ja eh, so oder so, soweit ich weiss filtert Google ja eh nach IP-Blöcken, nach dem Mottto "die ecke um Herne steht vermehrt auf Porno".
Und wenn der Anbieters dann die Bib eingebunden hat, hat google ein wichtigen Baustein für ein Werbeprofil. Damit kann google dann seine Werbung für dich entsprechend aufarbeiten.
Das ist ein Argument; wobei, so gesehen ist das doch auch in Ordnung -- wenn ich schon Werbung vorgesetzt bekomme, dann doch lieber massgeschneiderte statt einer willkürlichen.
Wenn dir das keine Sorgen macht (ich kenne auch Leute die sagen Werbung ist ja Information), dann ist es ok.
Sorgen nicht unbedingt, wobei ich Werbung nicht als Information bezeichnen würde, dass geht dann doch zu weit ;)
Mir ist das Suspekt und ich will das nicht, deshalb blocke ich sowas, wann immer es geht.
Ich bin auch kein Google-Fan, ich nutze lediglich die Suche, Adsense und habe neulich festgestellt, dass ich einen Channel bei Youtube habe, von dem ich bis vor kurzem nichts wusste ;)
Ansonsten wird bei mir auch alles geblockt, was da so kommt.
Aber das fällt wohl unter den Begriff Verfolgungswahn
Staatliche Verschwörung; dafür bin ich leicht zu begeistern ;)
mfg
Meine IP hat Google ja eh, so oder so, soweit ich weiss filtert Google ja eh nach IP-Blöcken, nach dem Mottto "die ecke um Herne steht vermehrt auf Porno".
LOL. Viele Grüße aus Bochum. ;)
Mathias
hi,
Meine IP hat Google ja eh, so oder so, soweit ich weiss filtert Google ja eh nach IP-Blöcken, nach dem Mottto "die ecke um Herne steht vermehrt auf Porno".
LOL. Viele Grüße aus Bochum. ;)
Ja, ich weiss, Bochum steht auch auf Porno -- ach was, Bochum ist Porno ;)
Viele Grüsse zurück.
mfg
Hallo
Das ist euer buisness, für mich ist Javascript nach wie vor Voodoo ;)
Business, nicht buisness, auch wenn es so gesprochen wird.
*scnr*
Tschö, Auge
hi,
also ich habe es soweit Fertig, nur gibt es einige Schwierigkeiten, Markup-Technisch.
Ich habe es jetzt soweit ohne grössere Eingriffe ins Markup gelöst bekommen, nur konnte ich dementsrechend leider nicht alle Bilder auslagern, da einige Klassen bzw. IDs für einzelne Elemente fehlen, Aktueller Stand:
http://dj-tut.de/z_test/selfhtml/forum/ -- Zum testen Styles deaktivieren
CSS steht im Dokument, nur durch das Markup sieht das CSS alles andere als schön aus; ich habe auch, um es Übersichtlich zu halten, nicht gruppiert, dass heisst, da kann ich noch Optimieren.
Erfolgreich getestet unter den Browsern (WinXP SP 2):
Firefox 3.5
Opera 9.64
SeaMonkey 1.1.9 ## Newslinks ein bisschen versetzt
Google Chrome 2.0.172.33
Safari 3.0.4
IE 7 (Standalone)
IE 6, 5.5 (Multiple)
Jetzt weiss ich nicht, ob ihr Lust habt, ins Markup einzugreifen.
Wenn ja, würde ich da auch gerne helfen, insbesondere der Gesamte Head-Bereich könnte überholt werden und auf einen Zeitgemässen Stand gebracht werden.
mfg
Hallo
Ich habe es jetzt soweit ohne grössere Eingriffe ins Markup gelöst bekommen, nur konnte ich dementsrechend leider nicht alle Bilder auslagern, da einige Klassen bzw. IDs für einzelne Elemente fehlen, Aktueller Stand:
http://dj-tut.de/z_test/selfhtml/forum/ -- Zum testen Styles deaktivieren
Auch wenn das deinem Ansatz widerspricht: Ich bin der Meinung, dass Grafiken, die Links repräsentieren, auch im HTML-Quelltext Grafiken bleiben sollen. Dementsprechend sollten neben der "interessant"-, "ausblenden"- und "gelesen"-Markierung auch die auf- bzw. zugeklappt-Markierung als Grafik im HTML-Quelltext ausgeführt werden.
Da du aber schon die Grafiken für die Texte der Links zum Ticketsystem per CSS einfügst, kannst du das eigentlich auch für die Links zur FAQ, Hilfe, Charta, und Suche machen. Dort dienen die Grafiken zur Ergänzung der Linktexte, sind aber sebst nicht anklickbar. Bei dem in deiner Beispielseite enthaltenen Tip des Tages (Wie formatiert man hier Links?) ist der Link zur Hilfe -- sozusagen eine kleine Inkonsistenz -- im Übrigen mitsamt Grafik klickbar.
Tschö, Auge
Ich bin der Meinung, dass Grafiken, die Links repräsentieren, auch im HTML-Quelltext Grafiken bleiben sollen.
Warum?
Mathias
Hallo
Ich bin der Meinung, dass Grafiken, die Links repräsentieren, auch im HTML-Quelltext Grafiken bleiben sollen.
Warum?
Warum nicht? ;-)
Gerade die von mir aufgezählten Grafiken, für die ich das so belassen wollte, stellen funktionelle grafische "Buttons" dar. Deshalb würde ich *diese* Grafiken als <a><img /></a> belassen, weil die Grafiken dort eben nicht zierende Elemente sind, sondern die Funktion der Links repräsentieren.
Es macht für mich eben einen Unterschied, ob einem Link eine Grafik vorangestellt ist oder folgt, die dem Benutzer sagt, ob sich das Linkziel z.B. auf einer anderen Domain (externer Link) oder im eigenen Angebot (interner Link) befindet (die den Linktexten vorangestellten Grafiken im Kopf der Forumshauptseite (FAQ, Suche etc.)), oder ob das Bild eine grafische Repräsentation der Funktion des Links (ein Piktogramm oder Icon => Button) ist.
Der Alternativtext stellt schlussendlich die Funktionalität für nicht grafikfähige bzw. -willige Clients sicher. Das wäre bei einer CSS-Lösung natürlich auch gegeben.
Tschö, Auge
@@Auge:
nuqneH
Warum nicht? ;-)
Den Text "Thread aufklappen" findet man über die Suche auf der Seite (Ctrl+F); 
mit Alternativtext "Thread aufklappen" findet man nicht.
Qapla'
Hallo
Warum nicht? ;-)
Den Text "Thread aufklappen" findet man über die Suche auf der Seite (Ctrl+F);
Dessen Alternativtext lautet ja auch "Thread zugeklappt". "Thread aufklappen" gehört als title-Attribut zum Link. Entsprechendes gilt für xopen.gif und den zugehörigen Link. :-)
Was wäre an der Stelle gewonnen, wenn nichts weiter getan würde, als die Grafik des Links in das CSS zu verlegen?
Tschö, Auge
@@Auge:
nuqneH
Was wäre an der Stelle gewonnen, wenn nichts weiter getan würde, als die Grafik des Links in das CSS zu verlegen?
(1) Dass man nach dem Text suchen kann.
(2) Dass man CSS-Sprites (eine Grafik, die alle Icons enthält) einsetzt.
Qapla'
Hallo
Was wäre an der Stelle gewonnen, wenn nichts weiter getan würde, als die Grafik des Links in das CSS zu verlegen?
(1) Dass man nach dem Text suchen kann.
(2) Dass man CSS-Sprites (eine Grafik, die alle Icons enthält) einsetzt.
Ja und ja. Allerdings stellt sich mir bei den diskutierten Links die Frage, wer sucht solche -zig bis hunderte Male vorkommende Texte?
Dann haben wir, meiner Frage entsprechend, folgenden Quelltext (ohne die evtl. nötige Kapselung des Linktextes):
<a href="..." title="Thread zuklappen">Thread aufgeklappt</a>
Das wäre natürlich Unfug, da der Linktext nichts über die Funktion des Links aussagt. Also den Inhalt des title-Attributs als Linktext. Damit fällt aber der momentane Status des Threads weg. Muss man nur noch wissen, ob man das will (sollte ja kein Beinbruch sein, obwohl gerade dann die Frage bleibt, warum diese Information *jetzt* vermittelt wird).
Tschö, Auge
@@Auge:
nuqneH
Allerdings stellt sich mir bei den diskutierten Links die Frage, wer sucht solche -zig bis hunderte Male vorkommende Texte?
Ich hab mir die Möglichkeit schon manches Mal gewünscht, wenn ich ein Posting von mir finden wollte, das in einem zugeklappten Thread steckt. Dann könnte man einfach von zugeklapptem Thread zu zugeklapptem Thread springen.
<a href="..." title="Thread zuklappen">Thread aufgeklappt</a>Das wäre natürlich Unfug, da der Linktext nichts über die Funktion des Links aussagt. Also den Inhalt des title-Attributs als Linktext.
Sag ich doch. @title ist dann allerdings überflüssig.
obwohl gerade dann die Frage bleibt, warum diese Information *jetzt* vermittelt wird).
Der Alternativtext gibt das an, was das Icon darstellt (dazu ist er ja da), die Aktion steht in @title.
Qapla'
Hallo
Allerdings stellt sich mir bei den diskutierten Links die Frage, wer sucht solche -zig bis hunderte Male vorkommende Texte?
Ich hab mir die Möglichkeit schon manches Mal gewünscht, wenn ich ein Posting von mir finden wollte, das in einem zugeklappten Thread steckt. Dann könnte man einfach von zugeklapptem Thread zu zugeklapptem Thread springen.
Ok, das ist nachvollziehbar.
Sag ich doch. @title ist dann allerdings überflüssig.
Du stehst mit der Forensoftware, bzw. deren Erweiterungen, auf Kriegsfuß? ;-)
(Dein Link geht nach/zu "http://")
Tschö, Auge
@@Auge:
nuqneH
Sag ich doch. @title ist dann allerdings überflüssig.
Du stehst mit der Forensoftware, bzw. deren Erweiterungen, auf Kriegsfuß? ;-)
(Dein Link geht nach/zu "http://")
Ich versuch’s nochmal: https://forum.selfhtml.org/?t=188754&m=1256946
Na bitte, geht doch. ;-)
Qapla'
Warum nicht? ;-)
Weil man grundlos auf CSS Sprites verzichtet und damit der Performance-Optimierung grundlos Grenzen setzt.
stellen funktionelle grafische "Buttons" dar. Deshalb würde ich *diese* Grafiken als
<a><img /></a>belassen, weil die Grafiken dort eben nicht zierende Elemente sind, sondern die Funktion der Links repräsentieren.
Auch die Icons bei Links sind nicht zierend, sondern Teil des Inhalts. Eine Grafik kommuniziert eine Information und steht für ein Textäquivalent. Also durchaus funktional.
<a href=""><img alt="Thread ausblenden"></a>
kann man meiner Meinung nach einfach durch
<a href="">Thread ausblenden</a>
ersetzen und die Ersetzung des Textes durch ein Icon per CSS vornehmen.
Es macht für mich eben einen Unterschied, ob einem Link eine Grafik vorangestellt ist oder folgt, die dem Benutzer sagt, ob sich das Linkziel z.B. auf einer anderen Domain (externer Link) oder im eigenen Angebot (interner Link) befindet (die den Linktexten vorangestellten Grafiken im Kopf der Forumshauptseite (FAQ, Suche etc.)), oder ob das Bild eine grafische Repräsentation der Funktion des Links (ein Piktogramm oder Icon => Button) ist.
Selbst wenn man da einen qualitativen Unterschied sieht, warum folgt daraus, dass man das Icon beim Link mit mit CSS einfügen sollte? Einzig das macht aus technischen Gründen Sinn.
Der Unterschied ist m.E. marginal. In dem einen Fall ersetze ich den gesamten Text und drücke ihn stattdessen mit einem Icon aus, in dem anderen Fall nur den halben:
<a><span>Thread ausblenden</span></a>
<a><span>Externer Link:</span> Häufig gestellte Fragen</a>
span hier jeweils als Element, das den zu ersetzenden Text notiert.
Der Alternativtext stellt schlussendlich die Funktionalität für nicht grafikfähige bzw. -willige Clients sicher.
Wenn ich davon ausgehe, dass letztlich alles auf Text zurückfällt und ich mit img, object oder CSS möglichst äquivalente grafische Repräsentationen einbinde, so sehe ich kein Problem dabei, gerade grafische Schaltflächen komplett mit CSS Sprite umzusetzen. Welchen praktischen Vorteil hätte es, hier eine Ausnahme zu machen?
Mathias
Hallo
Wenn ich davon ausgehe, dass letztlich alles auf Text zurückfällt und ich mit img, object oder CSS möglichst äquivalente grafische Repräsentationen einbinde, so sehe ich kein Problem dabei, gerade grafische Schaltflächen komplett mit CSS Sprite umzusetzen. Welchen praktischen Vorteil hätte es, hier eine Ausnahme zu machen?
Wenn du davon ausgehst, "dass letztlich alles auf Text zurückfällt", brauchst du im Inhalt, also in HTML, keinerlei Bilder. Für mich, wie ich bereits ausführte, gibt es den gewissen qualitativen Unterschied[1], der für mich darauf hinausläuft, es so, wie von mir beschrieben, zu handhaben.
[1] Ich weiß und schrieb auch schon, dass auch ein Teil Grafiken, die ich durch CSS ersetzen würde, Inhalt transportiert. Ich sehe da trotzdem den "gewissen" Unterschied.
Tschö, Auge
Hallo!
Wenn du davon ausgehst, "dass letztlich alles auf Text zurückfällt", brauchst du im Inhalt, also in HTML, keinerlei Bilder.
Jein. Das klingt missverständlich. So, als würde ich img aus auf Teufel komm raus dem HTML verbannen wollen. Das ist nicht der Fall. So gelesen stimmts: Ich *brauche* nicht zwangsläufig Bilder im HTML, da ich keinen Standpunkt einnehme, wie du es tust. Ich *kann* unter der o.g. Voraussetzung jedes Bild auch mit CSS Image Replacement einbinden. Ob ich das auch tue, hängt davon ab, ob es mir im Einzelfall sinnvoll erscheint. Es gibt auf einer Site Grafiken, da ist ein CSS Image Replacement, welches Hand in Hand mit Sprites geht, vorteilhaft. Zum Beispiel bei einem Set an ähnlichen Icons, die sehr häufig wiederverwendet werden.
Mathias
Hallo
Wenn du davon ausgehst, "dass letztlich alles auf Text zurückfällt", brauchst du im Inhalt, also in HTML, keinerlei Bilder.
Jein. Das klingt missverständlich. So, als würde ich img aus auf Teufel komm raus dem HTML verbannen wollen.
Öhhm, missverständlich tritt's. So wollte ich auch nicht verstanden werden. mir ging es um Links, die, anstatt mit Text, mit Bildern versehen sind.
Ich *kann* unter der o.g. Voraussetzung jedes Bild auch mit CSS Image Replacement einbinden. Ob ich das auch tue, hängt davon ab, ob es mir im Einzelfall sinnvoll erscheint.
Das mache ich doch auch so. Ich erachte im Einzelfall nur andere Sachen für sinnvoll, als du.
Es gibt auf einer Site Grafiken, da ist ein CSS Image Replacement, welches Hand in Hand mit Sprites geht, vorteilhaft. Zum Beispiel bei einem Set an ähnlichen Icons, die sehr häufig wiederverwendet werden.
Ich würde das nicht an der Häufigkeit der Verwendung festmachen wollen. Caching funktioniert auch bei mit HTML eingebundenen Bildern und das Verschieben von mit HTML eingebundenen Bildern innerhalb eines Elements, um nur einen Ausschnitt desselben zu zeigen, geht ebenfalls (obwohl ich das zugegebenermaßen irgendwie für hochgradig albern halte[1]).
[1] Ausnahmen, die mir grad nicht einfallen wollen, mögen diese Regel bestätigen.
Tschö, Auge
PS: "Der Text enthält drei oder mehr gleiche Zeichen hintereinander oder enthält keine Satzzeichen (-2.00 Punkte). Sind Sie sicher, dass Sie das Posting so abschicken wollen?"
*grmpf* ja was denn sonst?!? >;-)
hi,
Ich bin der Meinung, dass Grafiken, die Links repräsentieren, auch im HTML-Quelltext Grafiken bleiben sollen.
Ja, aber du siehst ja an diesem Thread, welche folgen es haben kann, wenn man es so macht.
Da du aber schon die Grafiken für die Texte der Links zum Ticketsystem per CSS einfügst, kannst du das eigentlich auch für die Links zur FAQ, Hilfe, Charta, und Suche machen.
Habe ich ja gemacht, siehe hier.
Nur erfordert diese Variante einen tiefergehenden Eingriff in die Templates (je nachdem, woher der Content kommt und wie er zusammengebaut wird).
Und für die Thread-Funktionen (Interessant markieren usw.) müsste auch das Template angepasst werden; da ich nicht weiss, ob das durch kommt, habe ich es erstmal beim alten belassen.
Hier müsste man sich Sinnvolle Klassenbezeichner für die jeweiligen links einfallen lassen und diese dann Konsequent mit diesen Klassen auszeichnen. Mein Ansatz für Klassenbezeichner war so, dass ich die Benennung der Grafiken als Linkklasse verwendet habe, also:
<a href="#"><img width="15" height="10" alt="Seite" src="index-Dateien/dok.gif"/></a>
Wurde
<a class="dok-link" href="#"></a>
Jetzt können wir ganz Pingelig sein und neben den Requests, die wir hier für Bilder einsparen, auch noch ein Paar Bits im HTML entfallen aufzählen, so wie unzählige DOM-Elemente, die hier für jedes Bild erzeugt werden (es sei denn, man umschliessst den Text mit <span></span>, dann zählt das letzte Argument nicht).
mfg
Hallo
Ich bin der Meinung, dass Grafiken, die Links repräsentieren, auch im HTML-Quelltext Grafiken bleiben sollen.
Ja, aber du siehst ja an diesem Thread, welche folgen es haben kann, wenn man es so macht.
Ich sehe keine "Folgen", nur die Diskussion, ob das wirklich sinnvoll ist oder eben doch mit per CSS eingeblendeten Grafiken gelöst werden sollte.
Da du aber schon die Grafiken für die Texte der Links zum Ticketsystem per CSS einfügst, kannst du das eigentlich auch für die Links zur FAQ, Hilfe, Charta, und Suche machen.
Habe ich ja gemacht, siehe hier.
Nur erfordert diese Variante einen tiefergehenden Eingriff in die Templates (je nachdem, woher der Content kommt und wie er zusammengebaut wird).
Und für die Thread-Funktionen (Interessant markieren usw.) müsste auch das Template angepasst werden; da ich nicht weiss, ob das durch kommt, habe ich es erstmal beim alten belassen.
Du wolltest einen *Vorschlag* erarbeiten, da darfst du machen, was du willst[tm]. :-)
Was davon übernommen oder in veränderter Form umgesetzt wird, ist dann ein anderer Schuh.
Hier müsste man sich Sinnvolle Klassenbezeichner für die jeweiligen links einfallen lassen und diese dann Konsequent mit diesen Klassen auszeichnen.
<a class="dok-link" href="#"></a>
So halte ich das auch für sinnvoll. Klassen z.B. für Verweise zur Doku, zum "Forumszubehör" (z.B. FAQ, Hilfe, Charta, Suche) oder nach draußen.
Tschö, Auge
hi,
Ich sehe keine "Folgen", nur die Diskussion, ob das wirklich sinnvoll ist oder eben doch mit per CSS eingeblendeten Grafiken gelöst werden sollte.
Ich meinte folgen auch nicht im Negativen Sinne, nur ist dass halt eines der Nachteile, wenn man so viele Bilder nur für das Design einbindet. Wenn mal ein Bild länger braucht zum laden, hält dass den Gesamten Verkehr auf, für, so gesehen, etwas völlig Triviales.
Mit meinem Vorschlag wird ein Bild geladen und das war's. Aber es ist natürlich wichtig, dass alles hier auszudiskutieren; schade, dass nicht mehr Ideen hier einfließen, so dass wir am Ende hier ein wirklich Sinnvolles Konzept vorliegen hätten.
Wenn ich mir mal ansehe, wie viel geballte Kompetenz in allen Fachrichtungen hier im Forum aufeinander trifft.
Du wolltest einen *Vorschlag* erarbeiten, da darfst du machen, was du willst[tm]. :-)
Was davon übernommen oder in veränderter Form umgesetzt wird, ist dann ein anderer Schuh.
Das ist ein Wort; das Problem ist, dass ich nicht weiß, wie ich vorgehen soll. Ich habe noch nie an so einem Projekt gearbeitet, daher auch keine Erfahrungen in der Richtung.
Ich weiss auch nicht, ob ich mich Per Mail an die Admins wenden soll, oder ein Update in Richtung Markup überhaupt erwünscht ist; schliesslich haben die Admins hier alle Hände voll mit SELFHTML 9 zutun.
mfg
Hallo
Ich sehe keine "Folgen", nur die Diskussion, ob das wirklich sinnvoll ist oder eben doch mit per CSS eingeblendeten Grafiken gelöst werden sollte.
Ich meinte folgen auch nicht im Negativen Sinne, ...
Gut, dann sind ja alle Klarheiten beseitigt. :-)
Mit meinem Vorschlag wird ein Bild geladen und das war's. Aber es ist natürlich wichtig, dass alles hier auszudiskutieren; schade, dass nicht mehr Ideen hier einfließen, so dass wir am Ende hier ein wirklich Sinnvolles Konzept vorliegen hätten.
Nicht so ungeduldig, junger Yeti! Es gibt ja im Leben auch noch anderes (nicht nur die unten erwähnte Entwicklung der Doku). :-)
Wenn ich mir mal ansehe, wie viel geballte Kompetenz in allen Fachrichtungen hier im Forum aufeinander trifft.
Du wolltest einen *Vorschlag* erarbeiten, da darfst du machen, was du willst[tm]. :-)
Was davon übernommen oder in veränderter Form umgesetzt wird, ist dann ein anderer Schuh.Das ist ein Wort; das Problem ist, dass ich nicht weiß, wie ich vorgehen soll. Ich habe noch nie an so einem Projekt gearbeitet, daher auch keine Erfahrungen in der Richtung.
Mache deinen Vorschlag und kümmere dich erstmal nicht darum. Wie gesagt, es ist dein Entwurf und in dem darfst du nach Belieben rumexperimentieren. Wenn der vollständig[1] steht, kann immer noch gesagt werden, hier oder dort bestehe Verbesserungsbedarf.
Es sprechen sich hier viele für dein Vorgehen mit den Sprites aus, also verfolge und vervollständige das auch. Zu dem Thema "vervollständigen" ist mir bei deinem Sprite-Bild aufgefallen, dass z.B. die Icons für "Antworten nicht möglich" und "Thread wird nicht archiviert" oder auch "Thread wieder einblenden" fehlen. Wenn das grundsätzliche Konzept steht, ist das aber nur noch Fleißarbeit, sowas nachzutragen.
Zudem ist mir im HTML_Quelltext eine Sache aufgefallen (Firebug 1.3.3 im FF 3.0.11).
<form method="post" action="http://suche.de.selfhtml.org/" id="kopf_suche">
<p>
<strong>
<label for="suchausdruck">Suche nach</label>
</strong>
<input name="suchausdruck" id="suchausdruck" size="10" maxlength="50" type="text" />
<!-- Hidden-Felder -->
</p>
</form>
Anstatt des <form>-Elements wird der darin befindliche Absatz mit margin ausgestattet, um die Abstände nach oben und unten zu regeln. Ich würde das andersherum erwarten. Das Element <strong> ist irgendwie displatziert. Wenn ich in der Quelltextansicht des Firebug das Element hovere, wird es in der Ansicht rechts über dem Text "Suche" dargestellt. Das darin enthaltene <label for="suchausdruck"> sitzt wiederum an der richtigen Stelle.
Ob das aus dem vorhandenen Quelltexten übernommen ist, oder ob du daran (also an dieser Stelle) "herumformatiert" hast, weiß ich natürlich nicht. Was Firebug als CSS anzeigt, betrifft für keines der Elemente die Positionierung und über die WDT habe ich irgendwie nichts zu #kopf_suche gefunden.
Ich weiss auch nicht, ob ich mich Per Mail an die Admins wenden soll, oder ein Update in Richtung Markup überhaupt erwünscht ist; schliesslich haben die Admins hier alle Hände voll mit SELFHTML 9 zutun.
Zumindest Sven und molily haben sich hier schon geäußert, womit du davon ausgehen kannst, dass sie das lesen und sich auch melden werden, wenn sie es für nötig halten.
[1] Vielleicht kommt ja schon vorher eine Rückmeldung, damit du dich nicht verrennst.
Tschö, Auge
hi,
Ich meinte folgen auch nicht im Negativen Sinne, ...
Gut, dann sind ja alle Klarheiten beseitigt. :-)
Gut, und wenn doch noch irgend etwas Klar sein sollte, dann schreiben, damit wir auch das unklären können ;)
Es gibt ja im Leben auch noch anderes (nicht nur die unten erwähnte Entwicklung der Doku). :-)
Was gibt es denn wichtigeres als das SELF?
Nehmt mir mein letztes Hemd aber nicht das Forum! ;)
Mache deinen Vorschlag und kümmere dich erstmal nicht darum. Wie gesagt, es ist dein Entwurf und in dem darfst du nach Belieben rumexperimentieren. Wenn der vollständig[1] steht, kann immer noch gesagt werden, hier oder dort bestehe Verbesserungsbedarf.
Du hast es geschafft! Ich werde die Gesamte CSS und zu teilen das HTML überarbeiten; wird zwar ein Paar Tage in anspruch nehmen, aber Lust habe ich alle male.
Ich fange bei der Default-Ansicht an und arbeite mich dann bis zum /my/ vor.
Zu dem Thema "vervollständigen" ist mir bei deinem Sprite-Bild aufgefallen, dass z.B. die Icons für "Antworten nicht möglich" und "Thread wird nicht archiviert" oder auch "Thread wieder einblenden" fehlen. Wenn das grundsätzliche Konzept steht, ist das aber nur noch Fleißarbeit, sowas nachzutragen.
Wie gesagt, da ich mir nicht Sicher war, ob ein tiefer Chirurgischer Eingriff erwünscht ist, hatte ich es so gelassen; ich habe dabei das SELF völlig aus den Augen verloren -- einfach machen ;)
Anstatt des
<form>-Elements wird der darin befindliche Absatz mit margin ausgestattet, um die Abstände nach oben und unten zu regeln. Ich würde das andersherum erwarten.
Das war ich nicht, ich schwör! Ich habe versucht, so wenig wie irgend möglich ins HTML einzugreifen, aber Danke für den Vorschlag, werde es bei der nächsten Version berücksichtigen.
Dieses Element bekommt die Default-Werte des Browsers für margin, das lässt sich leicht ändern ;)
[1] Vielleicht kommt ja schon vorher eine Rückmeldung, damit du dich nicht verrennst.
Nun, ein Stop wird jetzt nicht mehr viel bringen, ich zieh dass jetzt einfach durch, und zwar in Strict-SELF ;)
mfg
Hallo
Es gibt ja im Leben auch noch anderes (nicht nur die unten erwähnte Entwicklung der Doku). :-)
Was gibt es denn wichtigeres als das SELF?
Herrje, das erinnert mich an diesen Blogeintrag. Dazu auch mein Kommentar, den ich hier, hätte ich ihn nicht schon dort gebracht, zwingend anbringen müsste. :-)
Du hast es geschafft! ...
Ich fange bei der Default-Ansicht an und arbeite mich dann bis zum /my/ vor.
Unterscheidet die sich in der Struktur (ohne die diversen Einstellungsmöglichkeiten (übrigens: viel Spaß dabei)) so dermaßen?
Anstatt des
<form>-Elements wird der darin befindliche Absatz mit margin ausgestattet, um die Abstände nach oben und unten zu regeln. Ich würde das andersherum erwarten.Dieses Element bekommt die Default-Werte des Browsers für margin, ...
Hach, daran habe ich ja nun garnicht gedacht. Wie gesagt, in den CSS-Dateien habe ich nichts dazu gefunden und mich nur etwas gewundert.
*btw* <form> als Blockelement hat keine Browservorgaben für margin (unterschiedlich von 0)? Komisch.
Nun, ein Stop wird jetzt nicht mehr viel bringen, ich zieh dass jetzt einfach durch, und zwar in Strict-SELF ;)
Jawollja! :-)
Tschö, Auge
hi,
Herrje, das erinnert mich an diesen Blogeintrag.
Du weißt aber schon, was SELF bedeutet? ;)
Schöner Artikel -- erinnert mich an mich, wenn ich gerade irgendwo Sport treibe oder auf Sauftour bin (ansonsten komme ich hier auch nie weg).
Dazu auch mein Kommentar, den ich hier, hätte ich ihn nicht schon dort gebracht, zwingend anbringen müsste. :-)
Nennst du dich immer Auge? ich muss mir auch mal endlich einen festen Nick zulegen, dass ständige switchen macht kein Spaß mehr.
Unterscheidet die sich in der Struktur (ohne die diversen Einstellungsmöglichkeiten (übrigens: viel Spaß dabei)) so dermaßen?
Nein, nur dann habe ich das grobe schon mal formatiert und kann dann in der /my/-Ansicht ins Detail gehen.
*btw*
<form>als Blockelement hat keine Browservorgaben fürmargin(unterschiedlich von 0)? Komisch.
Der Browser verpasst dem umschliessenden <p>-Element im <form> das margin; ein Grund mehr, für solche angelegenheiten <fieldset> oder <div> zu nutzen.
mfg
Hallo
Nennst du dich immer Auge?
Nicht immer, nicht überall. Aber, wenn ich es recht bedenke, zumindest oft.
*btw*
<form>als Blockelement hat keine Browservorgaben fürmargin(unterschiedlich von 0)? Komisch.Der Browser verpasst dem umschliessenden
<p>-Element im<form>das margin; ein Grund mehr, für solche angelegenheiten<fieldset>oder<div>zu nutzen.
"umschlossen", nicht "umschließend", aber auch <fieldset> und <div> haben Standardstyles, die überschrieben werden sollten. Es hatte mich nur gewundert, dass das (in diesem Kontext) äußerste Element nicht die Abstände zu den Nachbarn regelt, sondern ein inneres Element.
Tschö, Auge
hi,
"umschlossen", nicht "umschließend",
Hehe, ich habe es aus der Sicht der innenliegenden vom <p> umschlossenen Elemente betrachtet, dann ist es ein umschliessendes Element.
Es hatte mich nur gewundert, dass das (in diesem Kontext) äußerste Element nicht die Abstände zu den Nachbarn regelt, sondern ein inneres Element.
Oh, sorry, habe da was übersehen:
#kopf-menue #newslink,
#kopf-menue form, /* Das ist das betroffene Form */
#kopf-menue #quicklinks {
margin:0 0 1em;
}
Und, au weia -- ja, das war doch ich ;)
Das habe ich nun von meinen zur Gewohnheit gewordenen "browser reset" à la *{margin:0;padding:0;outline:0}, ich komme mit normalen Stylesheets nicht mehr klar.
mfg
Du hast es geschafft! Ich werde die Gesamte CSS und zu teilen das HTML überarbeiten; wird zwar ein Paar Tage in anspruch nehmen, aber Lust habe ich alle male.
Vielleicht solltest du dir erst überlegen, was genau du damit anstrebst. Z.B. die Performance merklich erhöhen, den Code kürzer machen oder die Anpassbarkeit über Benutzer-Stylesheets verbessern. »Einfach alles überarbeiten« ist ja schön, aber ob sich der Aufwand gelohnt hat, ist eine andere Frage. Denn du wirst einiges damit »kaputtmachen«, weil zahlreiche User-Scripte und -Stylesheets auf dem gegenwärtigen Code basieren. Du solltest dir daher auch überlegen, welche Bezeichner und Strukturen du bewusst übernimmst. Schön wäre auch eine Dokumentation der neuen Struktur, so wie ich sie für die alte mal vor langer Zeit begonnen hatte.
Übrigens bin ich kein SELFHTML-Developer mehr, sondern wie du ein normaler Forumsnutzer, und kann bei der Umsetzung deiner Entwürfe nicht mitwirken.
Mathias
hi,
Danke für den Hinweis!
Vielleicht solltest du dir erst überlegen, was genau du damit anstrebst. Z.B. die Performance merklich erhöhen, den Code kürzer machen oder die Anpassbarkeit über Benutzer-Stylesheets verbessern.
Eigentlich war die Idee lediglich die Hauptseite mit CSS-Sprites umzusetzen; Eventuell noch den Forumskopf von den Tabellen befreien, sonst gibt es ja nichts zu bemängeln.
Denn du wirst einiges damit »kaputtmachen«, weil zahlreiche User-Scripte und -Stylesheets auf dem gegenwärtigen Code basieren.
Ja, stimmt, daran hatte ich gar nicht Gedacht. Im Grunde ist ja das HTML, zumindest was die auflistung der Threads angeht in Ordnung, bzw. wüsste ich nicht, was ich da noch ausbessern könnte.
Also läuft es im Prinzip nur noch auf CSS-Sprites und den Forumskopf aus, da kann ich dann wohl auch nicht sehr viel kaputtmachen.
Du solltest dir daher auch überlegen, welche Bezeichner und Strukturen du bewusst übernimmst. Schön wäre auch eine Dokumentation der neuen Struktur, so wie ich sie für die alte mal vor langer Zeit begonnen hatte.
Das sieht doch gut aus, werde es mir durchlesen und versuchen, alle ID und Klassenbezeichner soweit beizubehalten.
Übrigens bin ich kein SELFHTML-Developer mehr, sondern wie du ein normaler Forumsnutzer, und kann bei der Umsetzung deiner Entwürfe nicht mitwirken.
Das ist Schade, ich weiss nämlich nicht, wie hier die Javascripte funktionieren, wirken die sich in irgend einer Form auf den Forumskopf aus?
Ich weiss, dass am Ende der Hauptseite noch ein Filter versteckt ist, ich weiss aber nicht, wo der Link ist, mit dem man diesen Filter einblenden kann.
mfg
Hallo.
Hier müsste man sich Sinnvolle Klassenbezeichner für die jeweiligen links einfallen lassen und diese dann Konsequent mit diesen Klassen auszeichnen.
<a class="dok-link" href="#"></a>So halte ich das auch für sinnvoll. Klassen z.B. für Verweise zur Doku, zum "Forumszubehör" (z.B. FAQ, Hilfe, Charta, Suche) oder nach draußen.
Wozu? Die Raute ist doch hier nur ein Platzhalter für einen Attributwert, den man in einem CSS-Selektor abfragen kann. Und das URI-Schema von SelfHTML macht es einem da doch sogar verhältnismäßig einfach.
MfG, at
Hallo
<a class="dok-link" href="#"></a>So halte ich das auch für sinnvoll. Klassen z.B. für Verweise zur Doku, zum "Forumszubehör" (z.B. FAQ, Hilfe, Charta, Suche) oder nach draußen.
Wozu? Die Raute ist doch hier nur ein Platzhalter für einen Attributwert, den man in einem CSS-Selektor abfragen kann. Und das URI-Schema von SelfHTML macht es einem da doch sogar verhältnismäßig einfach.
Wenn das alle gängigen Browser auch so sähen, würde ich dir ohne Einschränkung zustimmen. So bleibt die Einschränkung, dass der Anbieter abwägen muss, ob die Grafiken derartig wichtig sind, dass sie überall angezeigt werden müssen, oder ob man darauf bei unfähigen Browsern verzichten kann und will.
Tschö, Auge
@@Auge:
nuqneH
Wozu? Die Raute ist doch hier nur ein Platzhalter für einen Attributwert, den man in einem CSS-Selektor abfragen kann.
Wenn das alle gängigen Browser auch so sähen, würde ich dir ohne Einschränkung zustimmen.
Alle aktuellen Browser sehen das so. Für die anderen gibt es CSS-Expressions (falls man sie überhaupt noch unterstützen will).
Qapla'
Hallo
Wozu? Die Raute ist doch hier nur ein Platzhalter für einen Attributwert, den man in einem CSS-Selektor abfragen kann.
Wenn das alle gängigen Browser auch so sähen, würde ich dir ohne Einschränkung zustimmen.Alle aktuellen Browser sehen das so. Für die anderen gibt es CSS-Expressions (falls man sie überhaupt noch unterstützen will).
Ok, ab IE 7 unterstützt auch Microsofts Browser Attributselektoren. Bleibt also die Frage, ob man sich Anpassungen für den IE 6 antun will.
Tschö, Auge
@@Auge:
nuqneH
Bleibt also die Frage, ob man sich Anpassungen für den IE 6 antun will.
Na so schwer isses ja nicht:
a[href^=http\3A \2F \2F example\2E net]
{
background: url(example.png) no-repeat;
padding-left: 42px;
}
* html a
{
background-image: expression( [code lang=javascript](new Function("element", "element.style.backgroundImage = (element.href && element.href.indexOf('http://example.net') == 0 ? 'url(example.png)' : 'none');"))(this)
~~~ );
background-repeat: no-repeat;
padding-left: expression( `(new Function("element", "element.style.paddingLeft = (element.href && element.href.indexOf('http://example.net') == 0 ? '42px' : '0');"))(this)`{:.language-javascript} );
}[/code]
Qapla'
--
Alle Menschen sind klug. Die einen vorher, die anderen nachher. (John Steinbeck)
Hello,
geht mir das alleine so, oder gibt es Leidensgenossen?
Ich habe da bisher noch nie ein Problem gehabt. Das liegt bestimmt daran, dass ihr dauernd Eure Browser wechselt (Updatet). So ein neuer Brower muss dann imer erst wieder von vorne lernen ;-))
Aber Scherz beiseite. Mir passiert es nur gelegentlich, dass ich die Seite ganz CSS-frei angezeigt bekomme. Das sieht dann lustig aus.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
hi,
Ich habe da bisher noch nie ein Problem gehabt. Das liegt bestimmt daran, dass ihr dauernd Eure Browser wechselt (Updatet). So ein neuer Brower muss dann imer erst wieder von vorne lernen ;-))
Ich steh auf Updates ;) Daher Update ich ja auch Permanent meine Seiten, Pausenlos ;)
Aber Scherz beiseite. Mir passiert es nur gelegentlich, dass ich die Seite ganz CSS-frei angezeigt bekomme. Das sieht dann lustig aus.
Aber eins muss man eingestehen, dass Forum ist auch ohne Styles sehr gut nutzbar, dass ist schon einiges Wert.
mfg
hi,
mir ist Gestern ein kleiner Fehler unterlaufen bei meinem Markup-Vorschlag; die verlinkte Version war IE-inkompatibel, ist jetzt ausgebessert, allerdings habe ich einen IE-Bug gefunden, den ich in dieser Form nicht kenne.
Screenshot IE 6
Der rechts markierte Link bekommt mittels CSS ein Hintergrundbild zugewiesen, wie man aber sehen kann, wird dieser nicht angezeigt, wenn ein Zeilenumbruch innerhalb des Links vorliegt; ein [link:http://forum.de.selfhtml.org/archiv/2006/8/t135205/#m877457@title=white-space:nowrap;] zwingt den Link zwar in die nächste Zeile, aber das Hintergrundbild ist trotzdem nicht zu sehen.
Wenn man den Viewport verkleinert ist alles in Butter, wie heisst dieser Bug?
Screenshot IE 6
mfg
Hallo.
Der rechts markierte Link bekommt mittels CSS ein Hintergrundbild zugewiesen, wie man aber sehen kann, wird dieser nicht angezeigt, wenn ein Zeilenumbruch innerhalb des Links vorliegt; ein
[link:http://forum.de.selfhtml.org/archiv/2006/8/t135205/#m877457@title=white-space:nowrap;]zwingt den Link zwar in die nächste Zeile, aber das Hintergrundbild ist trotzdem nicht zu sehen.Wenn man den Viewport verkleinert ist alles in Butter, wie heisst dieser Bug?
Archiv-Ignoranz.
MfG, at
hi,
Wenn man den Viewport verkleinert ist alles in Butter, wie heisst dieser Bug?
Du verlinkst hier einen Artikel, den ich in meinem Posting bereits verlinkt hatte.
wahsaga, 21. 08. 2006, 13:05
Du könntest dafür sorgen, dass Linktexte nicht umgebrochen werden.
Malcolm Beck´s, 15. Juli 2009, 05:10
ein white-space:nowrap; zwingt den Link zwar in die nächste Zeile, aber das Hintergrundbild ist trotzdem nicht zu sehen.
Ich habe mich wohl falsch ausgedrückt -- die frage sollte lauten: gibt es mittlerweile eine Lösung für dieses Problem, ohne das Markup zu verschandeln?
IE überrascht ja gerne mal mit neuen Bugs, die andere Bugs beheben.
mfg
Hallo.
Du verlinkst hier einen Artikel, den ich in meinem Posting bereits verlinkt hatte.
Das tut mir leid, entschuldige bitte.
Ich habe mich wohl falsch ausgedrückt -- die frage sollte lauten: gibt es mittlerweile eine Lösung für dieses Problem, ohne das Markup zu verschandeln?
Ja, IE-Auto-Update.
IE überrascht ja gerne mal mit neuen Bugs, die andere Bugs beheben.
Das eigentlich nur dann, wenn die Fehlfunktion eine unter bestimmten Bedingungen erwünschte ist. Wenn du also nicht dem Umgehen von Quirksmode- oder Has-Layout-Triggern keinen Erfolg hast, sehe ich schwarz für eine Lösung. Allerdings halte ich das Problem auch für zu vernachlässigen, da es in einem immer seltener werdenden Browser ohnehin nur selten auftritt.
MfG, at
hi,
Du verlinkst hier einen Artikel, den ich in meinem Posting bereits verlinkt hatte.
Das tut mir leid, entschuldige bitte.
Ich habe mir nochmal alles durchgelesen, weil ich dachte, das ich etwas übersehen hatte.
Aber halb so Wild.
Ja, IE-Auto-Update.
Auf einer Privaten Seite sicherlich kein Problem, den IEs den Stecker zu ziehen, nur hier sind auch viele User, die mit den Firmenrechnern surfen -- die haben wohl überwiegend den 6er im Betrieb.
Wenn du also nicht dem Umgehen von Quirksmode- oder Has-Layout-Triggern keinen Erfolg hast, sehe ich schwarz für eine Lösung.
Glücklicherweise ist es keine wichtige Funktion, daher ist es auch denke ich mal kein Problem -- ich wollte nur auf Nummer sicher gehen, dass es mit CSS alleine nicht funktioniert.
Ich habe die erste Hürde schon geschafft, das Layout wird mit nur einem Hintergrundbild geladen, das zu dem auch kleiner ist, als die Grafiken, die hier geladen werden.
http://dj-tut.de/z_test/selfhtml/forum/head
Jetzt muss ich noch schauen, wie ich die alten IDs zu grossen teilen beibehalten kann und das ganze Dokumentieren.
mfg
Hallo.
Auf einer Privaten Seite sicherlich kein Problem, den IEs den Stecker zu ziehen, nur hier sind auch viele User, die mit den Firmenrechnern surfen -- die haben wohl überwiegend den 6er im Betrieb.
Ja, und sobald IE7 und FF3.0.x keine Rolle mehr spielen -- Opera 9 spielt die ja schon jetzt kaum --, wird man das Problem auch vernünftig angehen können.
Mich tangiert es allerdings ohnehin nicht, da mein Masochismus nicht so weit geht, mir in diesem Forum Grafiken anzeigen zu lassen.
Jetzt muss ich noch schauen, wie ich die alten IDs zu grossen teilen beibehalten kann und das ganze Dokumentieren.
Ich wünsche dir weiterhin viel Spaß.
MfG, at