nicht angemeldet
Hallo, Orlando.
du armer Tropf.
*lol* Diese Formulierung war mir bisher unbekannt.
Schreibst so einen schönen Aufsatz und keiner will dir dafür einen Stern in's Heft kleben.
Es muss ja nicht gleich Lob sein...
<img src="http://www.ellerau.de/ju/bilder/stern-l.gif" border="0" alt=""> ;)
Süß[tm]! Ich werde ihn unter "AWARDS" abheften... (Manche haben tatsächlich solche Bereiche auf ihren Seiten... Jetzt sage nicht, du auch; tief unten in deinem Giftschrank, wo deine Frameseiten lauern... ;))
CIAO!
Föllig flash! *THX* muss das heißen, besser noch *THX Ultra* für die Audiophilen unter uns.
Wenn du mein erstes Posting im Selfforum liest (Schande über mein Haupt... <derherrseimeinerarmenseelegnaedig />), weißt du, warum ich zumindest nicht "Seeya!" verwendet habe...
welche der am obersten Fensterrand fest positionierte Bereich im ungünstigsten Fall einnimmt.
Was heißt "im ungünstigsten Fall"? Der fixierte Bereich (px) *ist* so groß wie definiert, oder nicht?
"Fixiert" bezog sich natürlich nur auf die feste Positionierung, nicht die feste Größe.
Bei einer relativen (auch Schrift-)Größeneinheit ist die Höhe des Bereiches eben nicht bestimmbar...
Wenn man die Höhe in 'em' angibt, sind Hopfen und Malz verloren, weil man dann die nötigen 'px' nicht eruieren kann - und 'em' sind IMHO für position:fixed zwingend nötig, damit der Inhalt beim Skalieren der Schrift nicht das DIV sprengt...
Ich bin vollkommen deiner Meinung; dieses Paradoxon ist mir leider hinlänglich bekannt; war das jetzt ein mitfühlendes Klagen oder sollte das ein konkreter Vorschlag werden, wie man dem Teufelskreis entfliehen kann...? ;)
Übrigens sah ich mich gezwungen, für den fest positionierten Bereich des Artikels absolute Einheiten anzugeben, bis hin zur line-height, genau aus dem von dir beschriebenen Grund. Kurioserweise ist es sogar auf 800x600 optimiert. *schäm*
"Was tun?"[tm] So oder so kommt man nicht darum hin, mehr oder weniger feste Größen vorzugeben, bei position:(absolute|fixed) lässt sich leider nicht der natürliche Fluss ausnutzen, welcher die Skalierbarkeit ausmacht. Fünfzehn Prozent für eine Menüspalte kann fatal sein, wenn der Browser die Schrift, aber nicht die Längen- und Breitenverhältnisse skaliert <wirwollenjakeinenamennennen /> und dadurch alle Spalten zugleich auf einer Bildschirmbreite angezeigt werden, die Spalten je nur eineinhalb Wörter pro Zeile beinhalten und sich alles überlappt...
über ein link-Element auf eine externe Stylesheet-Adresse referenziert
-> über ein link-Element ein externes Stylesheet referenziert (Vorschlag, da "auf etwas referenzieren" etwas holprig klingt ;) )
Urg, ja. [bangheadhere] Scheint aber ein weit verbreiteter "Fehler" zu sein... im (deutschen) Duden finde ich nichts, im Fremdwörterbuch auch nichts...
darüber nachgedacht werden beispielsweise
darüber nachgedacht werden, beispielsweise
Aber nur weil mit "darüber" explizit auf die zu-Konstruktion gezeigt wird und sie obligat ist...? ;)
body > h2 { ... }
Damit's den M$IE5 nicht aus dem Tritt bringt, der ist da empfindlich.
Klar, du hast es schon mehrfach gesagt, ich habe es aber aus Gewohnheit noch nicht verinnerlicht.
verweist, sich ebenso der Methode scrollBy()bedient werden,
-> felt hir was? ;)
Autsch. Das liegt daran, dass ich "man" nicht verwenden will, sondern ob es passt oder nicht (auf Gedeih und Verderb[tm]) eine Passivkonstruktion verwende... mitunter entstehen beim nachträglichen Ändern solche Fehler.
weshalb nicht verlässlich ist, ob ... vor oder nach dem Anspringen
-> weshalb nicht verlässlich ist, dass ... erst nach dem Anspringen
Das verstehe ich nicht, es geht doch nicht nur um "vor dem Anspringen" oder nur um "nach dem Anspringen", sondern um entweder-oder, deshalb "ob"...
"Es ist nicht verlässlich, dass der Funktionsaufruf vorher ausgeführt wird."
Klar, "dass", es geht darum, ob der Fall verlässlich eintritt oder nicht. Wohingegen:
"Es ist nicht verlässlich, ob der Funktionsaufruf vorher oder nachher ausgeführt wird."
*Dass* etwas passiert ist mehr oder weniger unstrittig, aber *was* von den Möglichkeiten passiert, ist doch entscheidend... Genauso: "Man weiß nicht, ob x oder y eintritt." oder "Es ist nicht bestimmbar, ob x oder y eintritt." Oder irre ich?
.oO(Ist etwa Germanistenvolk anwesend? ;))
if (window.document.getElementsByTagName && !window.opera) {
-> Warum darf Opera 7 nicht mitmachen? Dazu aber später mehr.
Gute Frage - alles kleiner als Version 7 liefert zumindest einen falschen Wert bei getAttribute, nämlich die gegenwärtige URL ohne Anker. Mit Opera 7 habe ich es ehrlich gesagt noch nicht getestet (*knirsch* ich bin froh, wenn ich überhaupt einen funktionsfähigen Browser zum laufen bekomme, mit Mozilla kann man nicht arbeiten, K-Meleon ist zu minimal, Opera 6.05 spinnt und Opera 7 hängt seinen Betastatus heraus, nebeneinander rasten sowieso beide aus).
Wie du siehst, ist es auch ohne DOM schwer, alle Browser zum Mitmachen zu bewegen. Opera tanzt auch bei hyperlinks[i].href aus der Reihe (siehe die Tabelle im Entwicklungsmurks). Insofern bin ich froh, dass wenigstens die Version ohne DOM läuft. Wenn für Opera 7 die zweite Methode problemlos funktioniert, sehe ich keinen Grund, eine zweite Abfrage einzubauen, um Opera 7 von Opera <7 zu unterscheiden. Oder geht es mit der Abfrage navigator.userAgent.indexOf('Opera 7')>-1...? Aufwärtskompatibel ist das nicht, soll ich mich mit Regulären Ausdrücken quälen oder mehrfach verschachtelte Abfragen verwenden... och nee.
gescrollt werden soll, angibt,
-> gescrollt werden soll angibt,
Wieso?
"...
dadurch ist auch der zweite Parameter,
welcher die Anzahl der Pixel,
um welche vertikal nach oben gescrollt werden soll,
angibt,
in vielen Fällen nicht eindeutig festlegbar."
Oder meinst du, dass auch das Komma nach "Pixel" weg müsste...?
unterstützen, und deren eindeutigen
-> unterstützen und deren eindeutigen
Wieso? :) Verkürzt:
"Ein Algorithmus wäre denkbar,
welcher anhand eines ständig aktuellen Katalogs von Benutzeragenten,
welche <code>position:fixed</code> unterstützen,
und deren eindeutigen Merkmalen
[...]
die beschriebene Funktion <code>initialise()</code> selektiv einbindet."
Hmpf, meine Augen brennen ;)
Danke vielmals für die Fehlersuche... Ich sollte den Artikel einige Wochen ruhen lassen und ihn dann noch einmal gegenlesen, am besten auf Papier.
Deine Schlussfolgerung, dass man serverseitig den Client ermitteln muss, um zu entscheiden, ob man die JS-Lösung einsetzen kann, oder nicht, kann ich nicht so recht nachvollziehen. Da du position:fixed ohnehin per Selektor einbindest (und das musst du ja), kannst du natürlich per DOM herausfinden, ob es der Browser gefunden hat, oder nicht.
Daran dachte ich auch schon. Ich werde es einmal ausprobieren.
Zwischen "der Browser interpretiert Kindselektoren" und "der Browser unterstützt position:fixed" beziehungsweise "der Browser wendet es erfolgreich an" (z.B. Benutzerstylesheets? Zugegeben, damit kann man nicht zielstrebig position:fixed ausschalten, aber möglich ist es) besteht meiner Vermutung nach keine zuverlässige Verbindung... ich werd's prüfen (nicht dass es jemand interessieren würde *fg*).
if(document.getElementById("header").style.position == "fixed") { ...
Auf die Idee bin ich natürlich nicht gekommen, beziehungsweise ich hielt sie nicht für sehr zuverlässig, ich dachte eher daran, die top- oder left-Parameter abzufragen, sozusagen der "computed value"... oder so, da müsste es doch irgendwo ein Unterscheidungskriterium geben. Das ist aber auf den zweiten Blick Kappes.
Ich habe leider nur Opera und Mozilla, das heißt, dass ich über IE5/Mac und Konqueror keine Aussagen machen kann (ich dachte ja vielleicht, dass ... aber wohl nicht).
Müsste doch funktionieren, oder bilde ich mir das jetzt nur ein? Sieht so einfach aus ;)
Genau das denke ich auch... ich schaue es mir beizeiten genau an.
BTW, ich schreibe im Moment selbst eine kleine Funktion, die alle internen Links umbiegt (genauer, einen Parameter mit dem aktuellen Stylesheet anhängt),
Du wagst es, dich gegen das Wort des Herrn[tm] zu stellen!?! Das erste Gebot lautet: Vertraue nie auf JavaScript!
um meinen Styleswitcher auch für Folgeseiten die nötigen Daten mitgeben zu können.
Du kennst Sessions...? :)
Cookies sind mir nicht zuverlässig genug - und ich mag sie nicht.
Du argumentierst mit Zuverlässigkeit, benutzt aber JavaScript um Aufgaben zu lösen, welche nicht einmal in den Bereich "Problem" fallen, sondern mehr oder weniger nur eine Spielerei sind...?
[->]