nicht angemeldet
Hallo Christian,
Eine Bildlaufleiste kann auch kein Pseudoelement sein, da sie sich nicht aus dem Markup herleiten lässt -
Doch - sie erscheint nur, wenn »zu viel« Inhalt vorhanden ist.
Das lässt sich weder aus dem Markup noch aus den Styles zwangsläufig herleiten, es kann lediglich eine Mutmaßung sein, weil die Ausgabeumstände meist hinreichend bekannt sind, um eine wahrscheinliche Prognose abzugeben. Erst wenn das Dokument auf die individuellen systemeigenen Umgebungsumstände trifft, wird »zu viel Inhalt« ein Grund um Scrollmechanismen anzubieten.
auf welchen Teil der Definition http://www.w3.org/TR/CSS21/selector.html#x22 würdest du dich beziehen,
Ganz einfach:
| Pseudo-elements create abstractions about the document tree beyond those specified by the document language.
»About the document tree« heißt für mich, dass sie anhand der vorhandenen Elementstruktur neue Elemente erfinden, welche im Markup untergebracht werden könnten (deshalb: Pseudoelemente).
Mit den »fictional tag sequences« ist dies anschaulich erklärt: http://www.w3.org/TR/CSS21/selector.html#x50. Alle CSS2- und künftige CSS3-Pseudoelemente lassen sich durch fictional tag sequences, gemäß welchen dann die Styles vergeben werden, darstellen beziehungsweise umsetzen (natürlich hängt die Umsetzung von den Umgebungsparametern ab).
Ich weiß nicht, wie eine Bildlaufleiste ein Pseudoelement sein sollte, denn wenn überhaupt wäre eine scrollbar-Pseudoelement ein das Wurzelelement umschließendes Element, was aber sinnlos wäre.
(der Rest steht als Beispiel (»for instance«) dort)
Vom Pseudoelement first-line zu einem möglichen Pseudoelement scrollbar ist ein weiter Weg.
Deiner Argumentationsweise nach wäre auch eine Eigenschaft sinnig, welche dem Browserinterface ein Hintergrundbild verpasst.
Warum? Eine Scrollleiste wird von einem Dokument, das zu lang/breit ist, hervorgerufen, das Browser-UI nicht.
Eine Scrolleiste befindet sich außerhalb des Viewports, in welchem das Dokument und seine Elemente angezeigt werden. Viewport ist klar definitiert: http://edition-w3c.de/TR/1998/REC-CSS2-19980512/kap09.html#heading-9.1.1. Alles, was außerhalb des umschließenden Ausgangsblocks (dem Wurzelelement) liegt, ist nicht durch CSS manipulierbar.
Der (äußerste) Mechanismus zum Blättern ist nicht Teil des Dokuments, er ist eine Technik des Hypertext-Browsing-Programmes, welches ein Dokument nur in Teilen ausgeben kann und deshalb eine Blättertechnik anbietet. Wenngleich overflow:scroll etc. existiert, ist es alleine Sache des Browsers, wie er dieses Blättern umsetzt (beispielsweise, aber nicht zwangsläufig durch eine Scrollbar) und ob er es beachtet.
Hier finde ich vor allem das »through« bedeutend: »... a viewport (a window or other viewing area on the screen) through which users consult a document« - und wenn man durch etwas etwas anders sieht, kann das sichtbare sicherlich keinen Einfluss auf den Rahmen haben, durch welchen man es sieht. Meiner Definition/Auslegung nach.
Das Dokument ruft an sich überhaupt nichts hervor, es wird vom Browser nur unter bestimmten Voraussetzungen gerendert. Im Markup oder im Stylesheet können diese externen Grundparameter nicht festgelegt werden, jedoch begrenzt werden, indem Höhe und Breite des Wurzelelements festgelegt werden. Dennoch entscheiden weiterhin die externen Umgebungsparameter, ob Blättertechniken nötig sind, und auch der Benutzeragent alleine entscheidet, wie die Scrollmechanismen aussehen. Die momentanen Microsoft-Eigenschaften für Scrollbars passen nur auf UI-Elemente von Windows, aber nicht auf andere grafische Oberflächen - es würde also höchstens interoperabel sein, eine oder zwei Farben vorzugehen, anhand welchen der Browser gemäß der aktuellen UI Schattenfarben usw. berechnet.
Oder eine Eigenschaft, welche bewirkt, dass sich ein Hyperlink in einem neuen Fenster öffnet, wie hier oft vorgeschlagen wurde.
Die Grenzen sind nicht scharf umrissen, :hover sei hier mal als Beispiel genannt. (wie wären sonst CSS-Menüs mit Untermenüs möglich?)
Ja, schon. Aber :hover kennzeichnet einen mehr oder weniger nachvollziehbaren Status eines Elements (wenngleich beispielsweise :focus allgemeingültiger ist). Ein Blättermechanismus liegt komplett außerhalb des Dokuments.
Ich kann prima ein gültiges HTML-Dokument schreiben, das garantiert keine Scrollleisten produziert - ich muss nur einen einzigen Buchstaben in einen Absatz in <body> setzen und sowohl body als auch p alle Abstände mit CSS wegnehmen, denn dann würden jegliche Scrolleisten mehr Platz als der Inhalt verbrauchen, wenn man das Fenster wirklich so klein macht. (ich müßte natürlich eine Schriftgröße nicht über 16px wählen) Die Scrollleisten werden also vom Dokument selbst »hervorgerufen«,
Das kannst du aber nicht direkten Einfluss nennen, schließlich sind dir die Ausgabebedingungen in dem Fall bekannt, sodass du exakt weißt, was du machen musst, um die Scrollleisten zu steuern. Ansonsten siehe oben. Dass du ein Dokument so präparieren kannst, dass es in den meisten Fällen keine Scrollleiste hervorruft, beweist noch lange nicht, dass das Dokument die Notwendigkeit eines Scollmechanismus' zuverlässig und allgemeingültig determinieren kann.
auch wenn man sie im Markup nicht direkt ansprechen kann. (wie auch :first-line, das richtet sich ja auch nach der Browserfenstergröße, wenn man es nicht gerade auf einen Block mit bekannter Größe anwendet)
Pseudoelemente sind zwar flexibel und richten sich zum Teil nach den Umgebungsparametern, aber dennoch kann meiner Auffassung nach wie oben beschrieben die Scrollbar kein Pseudoelement sein, weil es sich nicht dynamisch in ein Markup-Element umsetzen lässt. Dann wäre eher eine scrollbar-Eigenschaft für das Wurzelelement logischer (wie im Microsoft-Konzept), da es sich streng genommen um den »overflow« dieses Elements handelt.
Grüße,
Mathias (Bibelforscher)