Probleme mit Ankern und position:fixed (Sitecheck! ;))

[molily]

Hallo !

ich hab´ne neue HP(\*) geuppt, macht mal nen SITECHECK, so alles durchtesten und so, ihr wisst schon !!! Hier mal schnell die URL: www://home.t-online.de/home/dj5nu/css-position-fixed.html

CIAO!
Mathias
(*) Werde ich jetzt abgemahnt? *fg*

Jetzt noch einmal ohne Ironie beziehungsweise mit verminderter Dosis...
Bei der Verwendung von position:fixed tritt das Problem auf, dass ein eventueller am Fensteroberrand fest positionierter Bereich einen dokumentinternen Anker (Elemente mit name- oder id-Attribut, beschränken wir uns vorerst auf a-Elemente) verdeckt, da dieser beim Anspringen ebenfalls direkt am Fensteroberrand gerückt wird. Für diesen Umstand bieten die Browser momentan keine Abhilfe, sodass man Anker und position:fixed zur Zeit nur unter Inkaufnahme des Konfliktes einsetzen kann.
Ich bin zwar kein sonderlicher Liebhaber von position:fixed, was mich aber nicht daran gehindert hat, einen Artikel zu verfassen, welcher einige Workarounds diskutiert. In den letzten Tagen habe diesen ausgebaut und auch einiges verworfen, sodass einige Stunden Arbeit nicht sonderlich fruchtbar im Hinblick auf das Ergebnis waren... wie auch immer.
Der Artikel soll verständlich sein (deshalb kaut er einiges dreimal durch und verliert mitunter mehr Worte als nötig), "praxisnah", also benutzbare Lösungen bieten und sich mit den behandelten Lösungsmethoden recht vollständig befassen, wobei ich die Entwicklung der zuletzt angesprochenen Browserweiche dem Leser überlasse... eine perfekte Lösung gibt es nunmal nicht, es wäre nicht meiner Meinung nach wenig hilfreich, eine Beispielimplementation anzubieten (was macht man nur beispielsweise mit "Armin Grewe was here"-Browsern...? ;)).
Lange Rede, wenig Sinn; hier das Werk: http://home.t-online.de/home/dj5nu/css-position-fixed.html, mit sicherlich unzähligen Fehlern, die ich auch nach mehrmaligen Durchlesen übersehen habe, da ich sie nicht als solche erkannt habe. Oder ist der ganze Artikel Murks? Man ist nach dem Lesen gewissermaßen so schlau wie zuvor. Vielleicht habt ihr Lust, ein paar Kommentare zu geben...
Der erste Teil des Artikels, das heißt die CSS-Lösung, wurde übrigens durch Orlando inspiriert. Ich weiß es zu würdigen:<img src="http://www.plauder-smilies.de/knuddel.gif" border="0" alt=""> (<- muss sein, er wird es verstehen *duck* ;))

Übrigens habe ich keine annehmbare CSS-Lösung für eine Startnummer bei nummerierten Listen http://www.w3.org/TR/html401/struct/lists.html#adef-start gefunden, deshalb momentan noch der Validatorfehler, ich werde den DOCTYPE auf 1.0 Transitional anpassen müssen.
Ich bin mir mehr oder weniger sicher, dass dies eine Aufgabe des Markups ist, ohne Styles ist die komplette Liste keine geordnete mehr, da die Relation Listenpunktnummer -> Listenpunktinhalt nicht länger existiert, somit wäre auch die Abfolge teilweise hinfällig, da der direkte Bezug auf einen vorigen oder nächsten Listenpunkt über seine Nummer unmöglich wäre... Oder geht man davon aus, dass eine Liste nicht unterbrochen werden darf? Ich finde es wichtig, dass man eine Liste in der Mitte trennen kann, ich wende es in folgender Konstruktion an:

<ul>
<li>1.</li>
<li>2.</li>
<li>3.</li>
</ul>
<p>Zusammenfassung 1-3</p>
<ul start="4">
<li>4.</li>
...

...denn <li>Zusammenfassung 1-3</li> wäre Murks.
Sicherlich könnte man argumentieren, dass diese Markupstruktur grundsätzlich suboptimal ist, aber bei Überschriften ergäbe sich dasselbe Problem. Folgendes Markup wäre mir zu schwammig:

<h>1.</h>
<h>2.</h>
<h>3.</h>
<h>[kein Counterwert] Zusammenfassung 1-3</h>
<h>4.</h>
<h>5.</h>
<h>[kein Counterwert] Zusammenfassung 4-5</h>
<h>6.</h>
...

Was denkt ihr; wie würdet ihr eine solche Struktur in Markup überführen? Auch im Hinblick auf automatische Nummerierung, angenommen man kann Counter uneingeschränkt verwenden, momentan also nur ein Gedankenexperiment. Meine Alternativideen:

<h>1-3</h>
 <section>
 <h>1.</h>
 <h>2.</h>
 <h>3.</h>
 </section>
<h>Zusammenfassung 1-3</h>
<h>4-X</h>
 <section>
 <h>4.</h>
...

1-X sollten jedoch auf derselben Ebene liegen, das heißt in derselben section, somit ist das strikt lineare Beispiel das einzig mögliche. Die Überschriften erster Ordnung sind hier eine Abstraktionsebene, welche ich vermeiden will, in der ursprünglichen Listenform war auch keine Verschachtelung nötig. Andererseits *werden* die einzelnen Punkte durch die Zusammenfassungen geteilt, somit ist diese höhere Ebene definitiv vorhanden, auch wenn sie sich nicht als Sektionsüberschrift artikulieren lässt. Oder gehört die Zusammenfassung in die section der Punkte, die sie zusammenfasst...

(<h>1-3</h>)?
 <section>
 <h>1.</h> ...
 <h>2.</h> ...
 <h>3.</h> ...
 <h>Zusammenfassung 1-3</h> ...
 (</section>)?
(<h>4-X</h>)?
 (<section>)?
 <h>4.</h> ...
...

...eigentlich nicht, denn sie ist kein Listenpunkt. Denn wenn man hier die hierarchisierenden Oberkategorien weglässt, wäre auch die Trennung der sections nicht mehr haltbar, dann wäre man wieder beim streng linearen Beispiel.
Sicherlich wäre eine konventionelle Hierarchie viel einfacher...

<h>I.</h>
 <section>
 <h>I.1</h>
 <h>I.2</h>
 <h>I.3</h>
 </section>
<h>Zusammenfassung I.</h>
<h>II.</h>
 <section>
 <h>II.1</h>
 <h>II.2</h>
 <h>II.3</h>
 </section>

Aber wird in diesem Fall deutlich, dass II.1 in einer Sequenz mit I.3 liegt...? Es geht mir um einen Fall, indem I. und II. selbst nicht als eigene thematisch unterscheidbare Rubriken existieren und die Zusammenfassung zwar einen Teil einer Sequenz behandelt, diese aber nur unterbricht, nicht beendet... Mir fällt die Unterscheidung schwer, ich bin ratlos. Was wäre die beste Lösung für meinen Artikel (um zu den Tatsache zurückkommen *fg*)? (Im Übrigen zweifle ich gerade daran, ob ich die Verwendung von h und section richtig verstanden habe...)

Ein weiteres Mal zurück zur CSS-Lösung für das start-Attribut ¶ ich mutmaße, dass eine passende Lösung ungefähr folgendermaßen aussieht:

li:before {
 display:marker;
 content:counter(counter, decimal) ". ";
 counter-increment:counter 1; /* explizit 1 zur Verdeutlichung */
}
ol > li:first-child:before {
 counter-increment:counter 5; /* Startwert */
}

Das lese ich zumindest aus http://www.w3.org/TR/REC-CSS2/generate.html#counters und http://www.w3.org/TR/REC-CSS2/generate.html#q11 heraus. Momentan unterstützt kein Browser display:marker, deshalb muss man sich mit ol {list-style-type:none; margin:0; padding:0;} durchwurschteln, um dann die Einrückung in den zweiten und folgenden Zeile mehr schlecht als recht nachzubilden, beispielsweise mit li {text-indent:-4em; padding-left:2em;}. li:first-line wäre naheliegend, das mag Opera nicht, den Mozilla-Plugin habe ich nicht ausprobiert. li:before kann man auch keine width zuordnen, solange es nicht display:marker ist, deshalb ist die text-indent-Lösung unzuverlässig. li:before {float:left;} geht auch nicht, wäre aber display:marker nicht unähnlich...

Was sagt CSS3 dazu...? Bereits öffentlich ist das Listenmodul http://www.w3.org/TR/css3-lists, das Modul "Generated and replaced content" ist noch nicht verfügbar, darüber kann foglich noch nicht gemutmaßt werden.

Anstatt li:before {display:marker;} wäre die CSS3-Entsprechung schlichtweg li::marker. Im Beispielstylesheet http://www.w3.org/TR/css3-lists/#html4 findet sich sogar explizit eine CSS-Entsprechung für das start-Attribut:

/* The start attribute on ol elements */
ol[start] { counter-reset: list-item attr(start, integer, 1); counter-increment: list-item -1; }

Nicht dass ich das vollkommen verstehe, aber ich glaube, mir geht ein Licht auf. Die Entsprechung wäre eher:

ol {
 counter-reset:counter 5; /* Startwert */
 counter-increment:counter -1;
}

Und siehe da, es funktioniert. Eine Lösung für mein Problem gibt es trotzdem nicht, schließlich muss man momentan ganz ohne :before, display:marker/::marker, content & counter(), counter-increment und counter-reset auskommen.
Vielleicht hat jemand Lust, meine Ideen weiterzuspinnen...

Nebenbei, das Ursprungsthema war der Artikel "Probleme mit Ankern und position:fixed", falls jemand vor lauter Abschweifungen den Überblick verloren hat... ;))
Die gestrichenen Passagen habe ich übrigens unter http://home.t-online.de/home/dj5nu/fanhost/position-fixed-murks.html zusammengescharrt, falls ihr eine verbesserter Lösungsmöglichkeit vorschlagt, schaut euch bitte die Version mit location.href=this.href und return false und deren Nachteile an. Ich kann beim besten Willen nicht sagen, welche Version tatsächlich zuverlässiger funktioniert, weil es in Anbetracht der Tatsache, dass man die Zuverlässigkeit mit Inkompatibilität bezahlt, mehr oder weniger auf dasselbe herauskommt. Eine zweite Browserweiche wäre nötig, haha; was wäre bloß die Herausforderung beim Webseitenbasteln, wenn man sich nicht mit den fehlerhaften Browsern herumschlagen müsste... *g*

Komische Bilder findet man, wenn man nach "Schluss jetzt" sucht... kurios, kurios, es passt aber:
<img src="http://www.ouk.de/issue_9/pictures/blablup.gif" border="0" alt="">

Grüße,
Mathias

[srob]

ich hab´ne neue HP(\*) geuppt, macht mal nen SITECHECK, so alles durchtesten und so, ihr wisst schon !!!

Hallo Mathias,

nachdem noch niemand antwortete, wage ich mich nur mit leichten Beklemmungen aus meinem Loch... Vielleicht nimmt man hier eine Nachricht mit dem Subject "Info" einfach nur zur Kenntnis, aber Du hast ja nach Site Check gefragt. Vielleicht war es aber auch ein bißchen zu viel Text - mir jedenfalls. Habe aber Zeit gefunden, auf die Seite zu schauen. Da Validität außer Frage steht und "position:fixed" in meinen HTML-Codierungen noch nie gebraucht wurde, ist meine emotionale Reaktion auf den Inhalt der Seite eher gedämpft. Dadurch wird der Blick auf ein gelungenes Detail Deines Designs frei: die die Schiefer-/Dolomitblauen Hintergründe sind absolut trendy! Das sind Töne aus den Paletten des "View Colour Planner" von Pantone für Frühling und Sommer des kommenden Jahres; nur wenigen Sehenden erschließt sich die reduzierte, ruhige und ätherische Wirkung dieser Farben. Ich habe unsere Site in den vergangenen Wochen auf eine ähnliche Palette umgestellt - gab das einen Ärger unter den Klicki-Bunti-Anhängern! Spätestens in einem Jahr wird das State-of-the-art sein.

Visionär!

Gruß

Robert

P.S.: Ich kann es nicht lassen: Jemand von außerhalb des Inner Circle hätte für die multiplen Fragezeichen mehr als einen virtuellen Tritt in die E**r bekommen(-; (Nur eine sachlich-neutrale Feststellung, ich möchte nicht polemisieren!)

[srob]

die die

die

Schiefer-/Dolomitblauen

schiefer-/dolomitblauen

Fragezeichen

Ausrufezeichen

Habe den Vorschaubutton nicht getroffen...

[Orlando]

Hi Mathias,

du armer Tropf. Schreibst so einen schönen Aufsatz und keiner will dir dafür einen Stern in's Heft kleben. Also hier isser:

<img src="http://www.ellerau.de/ju/bilder/stern-l.gif" border="0" alt=""> ;)

CIAO!

Föllig flash! *THX* muss das heißen, besser noch *THX Ultra* für die Audiophilen unter uns.

(*) Werde ich jetzt abgemahnt? *fg*

Ab in den Kerker, du Elch *g*

Lange Rede, wenig Sinn; hier das Werk:

Ah ja, endlich - hier geht's also weiter ;)

http://home.t-online.de/home/dj5nu/css-position-fixed.html

Hier mein Senf:

liegt es über Linkanker

-> liegt es über dem Linkanker

Der Inhalt des a-Element

-> Der Inhalt des a-Elements

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? 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...

genauso kann aber auch eine relative Einheit wie

-> genauso können ... Einheiten ...

auf alle Ankerelementen mit der Klasse anker wirken

-> auf alle Ankerelemente mit der Klasse anker wirken

ü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 ;) )

auf welche mit einem CSS-Klassenselektor referenziert wird

-> welche mit einem CSS-Klassenselektor referenziert wird (s. oben)

Da die Deaktivierung der Außenränder der Überschrifelemente

-> Da die Deaktivierung der Außenränder der Überschriftelemente

darüber nachgedacht werden beispielsweise

darüber nachgedacht werden, beispielsweise

body > h2 { ... }   body > p.lp { ... }

-> body>h2 { ... }     body>p.lp { ... }

Damit's den M$IE5 nicht aus dem Tritt bringt, der ist da empfindlich. Er versteht zwar den Selektor nicht, ist aber so verbuggt, das er mit Leerzeichen trotzdem falsch rendert...

den fest positionierten Bereich ... zuzuordnen

-> dem fest positionierten Bereich ... zuzuordnen

verweist, sich ebenso der Methode scrollBy()bedient werden,

-> felt hir was? ;)

weshalb nicht verlässlich ist, ob ... vor oder nach dem Anspringen

-> weshalb nicht verlässlich ist, dass ... erst nach dem Anspringen

falls von eine zu lange

-> falls man eine zu lange

oder 1000 Millisekunden

-> oder es sind 1000 Millisekunden

in einer zentralen Funktion auslagern

-> in eine zentrale Funktion auslagern

if (window.document.getElementsByTagName && !window.opera) {

-> Warum darf Opera 7 nicht mitmachen? Dazu aber später mehr.

angesprungen wurde oder erst viel später

-> angesprungen wurde, oder erst viel später

gescrollt werden soll, angibt,

-> gescrollt werden soll angibt,

unterstützen, und deren eindeutigen

-> unterstützen und deren eindeutigen

Hmpf, meine Augen brennen ;)

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. Kappsle das Hinzufügen der EventHandler einfach in

if(document.getElementById("header").style.position == "fixed") { ...

Müsste doch funktionieren, oder bilde ich mir das jetzt nur ein? Sieht so einfach aus ;)

Der erste Teil des Artikels, das heißt die CSS-Lösung, wurde übrigens durch Orlando inspiriert. Ich weiß es zu würdigen:<img src="http://www.plauder-smilies.de/knuddel.gif" border="0" alt=""> (<- muss sein, er wird es verstehen *duck* ;))

Danke und bitte, *wah!* <linksetzer>http://www.google.com/search?q=bannstrahl</linksetzer> ;)

BTW, ich schreibe im Moment selbst eine kleine Funktion, die alle internen Links umbiegt (genauer, einen Parameter mit dem aktuellen Stylesheet anhängt), um meinen Styleswitcher auch für Folgeseiten die nötigen Daten mitgeben zu können. Cookies sind mir nicht zuverlässig genug - und ich mag sie nicht. Serverseitig ist mir das zu aufwändig, ich müsste bei jedem Link etwas generieren lassen.

Übrigens habe ich keine annehmbare CSS-Lösung für eine Startnummer bei nummerierten Listen http://www.w3.org/TR/html401/struct/lists.html#adef-start gefunden, [...]

<ul>
<li>1.</li>
<li>2.</li>
<li>3.</li>
</ul>
<p>Zusammenfassung 1-3</p>
<ul start="4">
<li>4.</li>
...

[...] denn <li>Zusammenfassung 1-3</li> wäre Murks.

Was hältst du davon?

<ol> <!-- ja, genau :) -->
  <li>bla</li>
  <li>bla</li>
  <li>bla
    <ul>
      <li>Zusammenfassung 1-3</li>
    </ul>
  </li>
  <li>bla</li>
  <li>bla</li>
 </ol>

Ist korrekt verschachtelt, IMHO auch logisch und darüber hinaus auch ohne CSS genießbar.

Sicherlich könnte man argumentieren, dass diese Markupstruktur grundsätzlich suboptimal ist, aber bei Überschriften ergäbe sich dasselbe Problem. Folgendes Markup wäre mir zu schwammig:

Hardliner, du... ;)

<h>1.</h>
<h>2.</h>
<h>3.</h>
<h>[kein Counterwert] Zusammenfassung 1-3</h>
<h>4.</h>
<h>5.</h>
<h>[kein Counterwert] Zusammenfassung 4-5</h>
<h>6.</h>

Warum nur <h> und nicht <hx>? Damit wärst (und bist) du dieses Problem auf einen Schlag los.

Was denkt ihr; wie würdet ihr eine solche Struktur in Markup überführen?

<h1>Thema</h1>

<h2>bla 1</h2>
 <h2>bla 2</h2>
 <h2>bla 3</h2>

<h3>Falls du es immer noch nicht kapiert haben solltest, hier bla 1 bis 3 als Cartoon</h3>

Auch im Hinblick auf automatische Nummerierung, angenommen man kann Counter uneingeschränkt verwenden, momentan also nur ein Gedankenexperiment.

Ist mit obiger Variante Problemlos möglich. Kann halt nur Opera, aber das ist ja kein Hindernis, da du die Nummerierung auch mit <ol> hinbekommst.

Meine Alternativideen:

Interessant, ich fürchte aber, ich weiß nicht, worauf du hinaus willst. Könntest mir ja einen 1-bis-3-Cartoon malen *g*

Nebenbei, das Ursprungsthema war der Artikel "Probleme mit Ankern und position:fixed", falls jemand vor lauter Abschweifungen den Überblick verloren hat... ;))

Ich gebe zu, kurzfristig schwanden mir die Sinne ;)

was wäre bloß die Herausforderung beim Webseitenbasteln, wenn man sich nicht mit den fehlerhaften Browsern herumschlagen müsste... *g*

Was wäre das erst ein Spaß, würden Browser nur fehlerfreien Code anzeigen...

LG Roland

PS: Dass Opera 7 mit der hiesigen Textarea nicht zurechtkommt, liegt am umgebenden <tt>. Ich hab's als Bug gemeldet und musste für dieses Posting Mozilla starten. Ich hoffe, du weißt das zu schätzen ;)

[molily]

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...?

[->]

[molily]

[<-]

Serverseitig ist mir das zu aufwändig,

"Wenn du meinst"[tm]...
Ich habe auch vor, so etwas für meine Netzseite zu entwickeln, jedoch bin ich zu dem Schluss gekommen, dass es *ohne* serverseitige Technik Overkill wäre...

ich müsste bei jedem Link etwas generieren lassen.

Es ist auch nicht weniger aufwändig, jeden Link nachträglich mit JavaScript zu manipulieren, vor allem wird es auf dem clientrechner ausgeführt, dadurch wird die Seite lahm und fehleranfällig. <gebetsmuehle /> ;)
Wie wäre es, dass du das DOM serverseitig nutzt...? Vielleicht ist das leichter als ein output buffer und das Ändern der Links über Reguläre Ausdrücke... Schneller vielleicht nicht unbedingt. :)

Was hältst du davon?

<ol> <!-- ja, genau :) -->

'Tschuldigung, war ein Schreibfehler, natürlich meinte ich ol.

<li>bla</li>
  <li>bla</li>
  <li>bla
    <ul>
      <li>Zusammenfassung 1-3</li>
    </ul>
  </li>
  <li>bla</li>
  <li>bla</li>
</ol>

Ist korrekt verschachtelt, IMHO auch logisch und darüber hinaus auch ohne CSS genießbar.

Neeee <mecker:maul />, das gefällt mir ganz und gar nicht, denn wenn man das wieder abstrahiert, stände die Zusammenfassung in einer Sequenz mit 3.X. Die Zusammenfassung ist aber kein Kind von einem Listeneintrag, höchstens von 1-3, deshalb erfand ich eine section, welche 1-3 umfasst und die Zusammenfassung in eine Sequenz mit diesem Überknoten gestellt wird.

Sicherlich könnte man argumentieren, dass diese Markupstruktur grundsätzlich suboptimal ist, aber bei Überschriften ergäbe sich dasselbe Problem. Folgendes Markup wäre mir zu schwammig:

Hardliner, du... ;)

<infantil>Selber! Spiegel!</infantil> ;)

<h>1.</h>
<h>2.</h>
<h>3.</h>
<h>[kein Counterwert] Zusammenfassung 1-3</h>
<h>4.</h>
<h>5.</h>
<h>[kein Counterwert] Zusammenfassung 4-5</h>
<h>6.</h>

Warum nur <h> und nicht <hx>? Damit wärst (und bist) du dieses Problem auf einen Schlag los.

"Häh"? ;) h ist doch nur das XHTML 2-Äquivalent zu hX, ich hatte nur mit h und section gearbeitet, um die Sektionen abzugrenzen und die Zugehörigkeiten deutlicher zu machen. Ob ich jetzt nun hX oder h und section verwende, das eine lässt sich mehr oder weniger eindeutig in das andere überführen... Naja, die Transformation wäre nicht ohne Verlust der Semantik:

<section>
<h>...</h>         -->          <h2>...</h2>
<h>...</h>         -->          <h2>...</h2>
</section>
                                (hier fehlt jegliche Trennung)
<section>
<h>...</h>         -->          <h2>...</h2>
<h>...</h>         -->          <h2>...</h2>
</section>

Ich verstehe nicht, wieso hX das Problem löst:

<h2>1.</h2>
<h2>2.</h2>
<h2>3.</h2>
<h2>[kein Counterwert] Zusammenfassung 1-3</h2>
<h2>4.</h2>

Das ändert gar nichts an meinem Problem.... ;(

Was denkt ihr; wie würdet ihr eine solche Struktur in Markup überführen?

<h1>Thema</h1>

<h2>bla 1</h2>
<h2>bla 2</h2>
<h2>bla 3</h2>

<h3>Falls du es immer noch nicht kapiert haben solltest, hier bla 1 bis 3 als Cartoon</h3>

Toll, ;) aber die Zäsur, die du wohlwissentlich als Leerzeilen eingefügt hast, muss im Markup ihre Entsprechung finden, das tut es bei einem auf ein h2 folgendes h3, welches eine Zusammenfassung der drei vorigen h2-Abschnitte ist, eben nicht. Verallgemeinert gesehen hat jede section (hier der Bereich zwischen h2 und dem folgenden h2) weitere Kinder (sections - du siehst, damit lässt sich gedanklich besser als mit nicht verschachtelten hX-Elementen arbeiten), nämlich womöglich h3- und h4-Elemente.

Auch im Hinblick auf automatische Nummerierung, angenommen man kann Counter uneingeschränkt verwenden, momentan also nur ein Gedankenexperiment.

Ist mit obiger Variante Problemlos möglich. Kann halt nur Opera, aber das ist ja kein Hindernis, da du die Nummerierung auch mit <ol> hinbekommst.

Siehe oben, die Zusammenfassung ist nicht 3.1 beziehungsweise 3:last-child, sozusagen[tm]. Wie wird deutlich, dass es kein Kind von Punkt 3 ist...? Klar, man könnte eine Klasse vergeben, um diese Überschrift ohne Nummerierung anzuzeigen... Das löst aber ein Problem, welches durch das Markup gelöst werden sollte. (Mir geht es nicht um das Aussehen, ;) man könnte auch schlichtweg ein div-Element verwenden und es wie eine "Zusammenfassungsüberschrift" formatieren, semantisch wäre das aber wertlos...)

Meine Alternativideen:

Interessant, ich fürchte aber, ich weiß nicht, worauf du hinaus willst. Könntest mir ja einen 1-bis-3-Cartoon malen *g*

Vom Standpunkt der Usability wäre das sogar die beste Idee. Übrigens ist es im Artikel genauso, die Listenpunkte beschreiben theoretisch, was die Zusammenfassung als konkretes Beispiel liefert. Genau aus diesem Grund kommt meine Konstruktion sehr oft vor, weshalb ich über sie diskutieren möchte...

Nebenbei, das Ursprungsthema war der Artikel "Probleme mit Ankern und position:fixed", falls jemand vor lauter Abschweifungen den Überblick verloren hat... ;))

Ich gebe zu, kurzfristig schwanden mir die Sinne ;)

"Gotcha!" ;)
(Zwischen den Zeilen versteckten sich Kaufanweisungen und ähnliche unterschwellige Werbung... ;) Deswegen hat auch niemand geantwortet, alle waren paralysiert... *fg*)

was wäre bloß die Herausforderung beim Webseitenbasteln, wenn man sich nicht mit den fehlerhaften Browsern herumschlagen müsste... *g*

Was wäre das erst ein Spaß, würden Browser nur fehlerfreien Code anzeigen...

Ich persönlich kann gerne darauf verzichten, dass des Browsers XML-Parser bei jedem kleinsten Flüchtigkeitsfehler meine Seiten nicht anzeigen will... Ich bin imperfekt und bin "fucking proud of it"[tm] (bitte denglisch aussprechen, mit einem lächerlichen Maß an Pathetik).

Dass Opera 7 mit der hiesigen Textarea nicht zurechtkommt, liegt am umgebenden <tt>.

Für meinen Geschmack könnte man das ersatzlos aus der XHTML-Version des Forums streichen...

Ich hab's als Bug gemeldet

Ich glaube, dass die Wahrscheinlichkeit, dass Christian das <tt> aus der XHTML-Version herausnimmt, ist größer als dass Opera Software in naher Zukunft Opera 7 final veröffentlichen wird und der Bug gefixt ist... ;) Also hacke es gleich noch einmal in den hiesigen Butracker...

und musste für dieses Posting Mozilla starten. Ich hoffe, du weißt das zu schätzen ;)

Da ein Mozilla-Start bei mir sicher viel abenteuerlicher ist, muss ich dir gestehen, dass ich das nur bedingt schätzen kann, da ich mein Posting auch mit Mozilla (okay, K-Meleon, *hüstel*) im Schweiße meines Angesichts[tm] geschrieben habe, weil mein Opera 6.05 komischerweise im Leerlauf 80% Prozessorauslastung benötigt <malebenneuinstallier />, was das Tippen mehr oder weniger unmöglich macht... Ich schreibe zwar lange Postings im Texteditor, aber der letzte Schliff wird im Browser gemacht, da vieles erst bei der Vorschau auffällt (oder nicht einmal da). Im K-Meleon besteht wenigstens eine nachvollziehbare Verbindung zwischen einem Tastendruck und dem Auftauchen eines Zeichens im Eingabefeld.

Danke für dein Erbarmen... ;)
Mathias