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