färbige scrollbalken in mozilla und opera?

[Daniel]

hallo

weiss vielleicht wer von euch ob mozilla und opera auch färbige scrollbalken unterstützen wie der internet explorer? meine versionen sind: mozilla 1.01 und opera 6.05

danke

grüsse,
daniel

[Benjamin Wilfing]

Hallo Daniel,

weiss vielleicht wer von euch ob mozilla und opera auch färbige scrollbalken unterstützen wie der internet explorer? meine versionen sind: mozilla 1.01 und opera 6.05

leider ich muss dich enttäuschen, sie können es nicht darstellen.

Grüße aus Darmstadt,
Benjamin

[Thomas J.S.]

Hallo,

weiss vielleicht wer von euch ob mozilla und opera auch färbige scrollbalken unterstützen wie der internet explorer?

Nein.
Da die farbige Scrollbalken eine proprietäre Erweiterung des IEs sind, gibt es keinen Grund warum standardkonforme Browser diese unterstützen sollten.

Grüße
Thomas

[Armin G.]

Tach auch,

Da die farbige Scrollbalken eine proprietäre Erweiterung des IEs sind, gibt es keinen Grund warum standardkonforme Browser diese unterstützen sollten.

Favicons waren auch eine proprietaere Erweiterung des IE die meines Wissens in keinem Standard beschrieben sind. Inzwischen kann Mozilla dies besser als der IE. Weshalb in meinen Augen Dein Argument hinfaellig ist.

Gruss,
Armin

[Thomas J.S.]

Hallo Armin,

Da die farbige Scrollbalken eine proprietäre Erweiterung des IEs sind, gibt es keinen Grund warum standardkonforme Browser diese unterstützen sollten.

Favicons waren auch eine proprietaere Erweiterung des IE die meines Wissens in keinem Standard beschrieben sind. Inzwischen kann Mozilla dies besser als der IE. Weshalb in meinen Augen Dein Argument hinfaellig ist.

Nich wirklich. Würden alles Browser die Standards richtig unterstützen, würde ich solche Erweiterungen sogar begrüßen. Aber bis dahin ist es eben sinnlos an proprietäre Erweiterungen satt Standardfeatures zu basteln und das gilt nicht nur für den IE.

Grüße
Thomas

[Armin G.]

Tach auch,

Nich wirklich. Würden alles Browser die Standards richtig unterstützen, würde ich solche Erweiterungen sogar begrüßen. Aber bis dahin ist es eben sinnlos an proprietäre Erweiterungen satt Standardfeatures zu basteln und das gilt nicht nur für den IE.

OK, das Argument lasse ich gelten. Da kann ich Dir zustimmen. Nur schade dass sich die wenigsten (um nicht zu sagen keine) Browserhersteller wirklich daran halten.

Gruss,
Armin

[CarstenP]

Hallo Armin,

Favicons waren auch eine proprietaere Erweiterung des IE die meines Wissens in keinem Standard beschrieben sind. Inzwischen kann Mozilla dies besser als der IE. Weshalb in meinen Augen Dein Argument hinfaellig ist.

Im Gegensatz zu den farbigen Scrollbalken sorgt bei den Favicons der benötigte Code nicht dafür, daß das Dokument nicht mehr valide ist.

Die Verwendung von <link rel="shortcut icon" /> ist vom W3C abgesegnet, da die Liste auf http://www.w3.org/TR/html4/types.html#h-6.12 nicht abschließend ist und die Kreation weiterer Linktypen ausdrücklich erlaubt ist.

Viele Grüße
Carsten

[Armin G.]

Tach auch,

Im Gegensatz zu den farbigen Scrollbalken sorgt bei den Favicons der benötigte Code nicht dafür, daß das Dokument nicht mehr valide ist.

Was mir solange dadurch keine Probleme hervorgerufen werden ziemlich egal ist. Der Validitaetsfetischismus bis ins kleinste Detail geht mir ehrlich gesagt langsam sogar ein bisschen auf die Nerven.

Die Verwendung von <link rel="shortcut icon" /> ist vom W3C abgesegnet, da die Liste auf http://www.w3.org/TR/html4/types.html#h-6.12 nicht abschließend ist und die Kreation weiterer Linktypen ausdrücklich erlaubt ist.

Und was hindert das W3C in einer der naechsten Versionen von CSS die Moeglichkeit Scrollbars zu formatieren einzufuehren? Da Browser Sachen zu ignorieren haben die sie nicht kennen sehe ich da ueberhaupt kein Problem.

Gruss,
Armin

[CarstenP]

Hallo,

Der Validitaetsfetischismus bis ins kleinste Detail geht mir ehrlich gesagt langsam sogar ein bisschen auf die Nerven.

Du warst es, der gesagt hat, daß die Favicons Deines Wissens keinem bisherigen Standard entsprechen, also habe ich den Einwand geliefert, daß Favicons im Gegensatz zu farbigen Scrollbalken keinem Standard widersprechen.

Und was hindert das W3C in einer der naechsten Versionen von CSS die Moeglichkeit Scrollbars zu formatieren einzufuehren? Da Browser Sachen zu ignorieren haben die sie nicht kennen sehe ich da ueberhaupt kein Problem.

Wenn das W3C irgendwann farbige Scrollbalken in seine Standards aufnimmt, dann ist das schön für diejenigen, die farbige Scrollbalken benutzen wollen und nicht schlechter für die, die keine benutzen wollen. Solange dies aber nicht der Fall ist, halte ich mich an die bestehenden Regeln (was aber nicht heißt, daß ich sie benutzen würde, wenn sie tatsächlich mal erlaubt sind).

Viele Grüße
Carsten

[MudGuard]

Hi,

weiss vielleicht wer von euch ob mozilla und opera auch färbige scrollbalken unterstützen wie der internet explorer? meine versionen sind: mozilla 1.01 und opera 6.05

Glücklicherweise ist das im Mozilla nicht der Fall. Andernfalls müßte ich meine user.css entsprechend aufbohren, um diesen Unsinn zu unterdrücken...

cu,
Andreas

[Christian Seiler]

Hallo Andreas,

um diesen Unsinn zu unterdrücken...

Warum sollte das Unsinn sein? Man kann ja schließlich auch die Formularelemente personalisieren... IMHO wäre ein Pseudoelement à la ::scrollbar sinnvoll. (und dann noch ein paar weitere Eigenschaften)

Christian

[Thomas J.S.]

Hallo Christian,

Warum sollte das Unsinn sein?

Weill [pref:t=39417&m=216181]

Grüße
Thomas

[Christian Seiler]

Hallo Thomas,

Warum sollte das Unsinn sein?

Weill [pref:t=39417&m=216181]

Ich habe mich nicht auf die MS-Eigenschaften, sondern auf das Verändern von Scrollbalken allgemein bezogen. Aber außer Frage: Du hast natürlich Recht, die Standardumsetzung sollte wirklich Priorität haben.

Christian

[Michael Jendryschik]

um diesen Unsinn zu unterdrücken...

Warum sollte das Unsinn sein? Man kann ja schließlich auch die Formularelemente personalisieren...

Ja, leider.

Ich halte Formularelemente und Scrollbalken für einen wesentlichen Teil der GUI meines Benutzeragenten. Ich möchte nicht, dass die Darstellung dieser Elemente vom Webautoren beeinflusst werden können, da sie oftmals derart beeinflusst werden, dass ihre Bedienbarkeit beeinträchtigt wird.

MI

[Jan]

Hallo,

Ich halte Formularelemente und Scrollbalken für einen wesentlichen Teil der GUI meines Benutzeragenten.

Formularelement, im gegensatz zu den rollbalken, sind doch ganz normale html-elemente und solche können nun mal mit css formatiert werden.
warum sollte das für einzelnen elemente auf einmal nicht möglich sein?
dies wäre recht unsinnig und unlogisch.

Ich möchte nicht, dass die Darstellung dieser Elemente vom Webautoren beeinflusst werden können.

Das steht dir doch frei, dass zu verhindern zb über ein userstylesheet.
Nur weil mit unter die formatierung von formularelemente übertrieben wird ist dass noch kein grund dieses, vom standard her, zu unterbinden, denn dann kannst du css gleich wieder abschaffen da letztendlich alles so beeinflusst werden kann, dass es nicht mehr zu gebrauchen ist.

Gruss, Jan aus Dresden

[Michael Jendryschik]

Ich halte Formularelemente und Scrollbalken für einen wesentlichen Teil der GUI meines Benutzeragenten.

Formularelement, im gegensatz zu den rollbalken, sind doch ganz normale html-elemente und solche können nun mal mit css formatiert werden.

Formularelemente wie 'input', 'textarea' oder 'select' unterscheiden sich von anderen HTML-Elementen in dem Punkt, dass es Interaktionselemente sind, der Nutzer sie also bedienen, mit ihnen /interagieren/ soll. Die Bedienbarkeit sollte so einfach wie möglich gemacht werden, daher ist es sinnvoll, das gewohnte Aussehen dieser Elemente nicht zu verändern, da der Nutzer sich sonst von Seite zu Seite umstellen muss.

Du möchtest doch auch nicht, dass eine Website z.B. das Aussehen der Adressleiste oder der Standardschaltflächen deines Benutzeragenten beeinflusst, genau aus dem Grund, weil es die von dir gewohnten bzw. auf deine Bedürfnisse eingestellten Interaktionselemente dessen GUI sind. Warum hört das für dich bei Formularelemeten auf?

MI

[Jan]

Hallo,

Du möchtest doch auch nicht, dass eine Website z.B. das Aussehen der Adressleiste oder der Standardschaltflächen deines Benutzeragenten beeinflusst, genau aus dem Grund, weil es die von dir gewohnten bzw. auf deine Bedürfnisse eingestellten Interaktionselemente dessen GUI sind. Warum hört das für dich bei Formularelemeten auf?

Ich würde sagen, dass ist eine auffassungssache.
Für mich sind formularelemente in einer webseite kein bestandteil der anwendung >browser<
sondern ein bestandteil einer webseite und als solches prinzipiell gestaltbar.
Man kann jetzt natürrlich disskuiteren, ob es im technischen sinn auch so ist,
weis ich nicht und ist für mein verständnis auch nicht ausschlaggebend.

Das sich formularelemente von anderen, durch ihren gebrauch, unterscheiden ist
richtig aber es sind trotzdem html elemente wie andere auch und können somit
formatiert werden, dass das manchmal nicht von vorteil ist, ist unwidersprochen.
Aber darauf zu verzichten halte ich für übertrieben, es ist halt eine frage wie es
gemacht wird und wie sie innerhalb der seite präsentiert werden, den user von
vornherein als idioten beim erkennen von formularelementen hinzustellen ist abwegig.

Also ich persönlich kann mich da also deiner strikten meinung nicht anschleissen.
Und wer nun wirklich das standardformat für formularelemente haben will kann es
sich so einrichten, worauf du bei deinen überlegungen nicht eingehst, es wird niemandem, und das ist das schöne an css, das format unwiderruflich
aufgezwungen, man kann sich alles passend machen.

Gruss, Jan aus Dresden

[Christian Seiler]

Hallo Michael,

Ich halte Formularelemente und Scrollbalken für einen wesentlichen Teil der GUI meines Benutzeragenten. Ich möchte nicht, dass die Darstellung dieser Elemente vom Webautoren beeinflusst werden können,

Dann nagele Formularelemente doch auf eine bestimmte Darstellung mit Deinem Benutzerstylesheet fest.

Ich sehe es so: Warum sollte ein Webautor nicht bestimmte Elemente personalisieren dürfen, wenn ein Benutzer sich dagegen wehren kann, wenn es ihm nicht passt?

da sie oftmals derart beeinflusst werden, dass ihre Bedienbarkeit beeinträchtigt wird.

Beispiele? Warum sollte z.B. ein roter Rahmen die Benutzbarkeit eines Eingabefeldes beeinträchtigen?

Christian

[Michael Jendryschik]

Beispiele?

http://www.gulli.com/: Der Rollbalken rechts besteht aus dünnen roten Linien und zwei gelben Pfeilen. Ansonsten ist er an den schwarzen Hintergrund angepasst. Schwer zu sehen und dementsprechend auch schwer zu bedienen.

http://barrierefrei.e-workers.de/: Das Eingabefeld für den Suchbegriff auf der linken Seite ist genausowenig als solches zu erkennen wie der Button zum Absenden der Suchaufforderung.

Warum sollte z.B. ein roter Rahmen die Benutzbarkeit eines Eingabefeldes beeinträchtigen?

Kleinere optische Veränderungen schaden sicherlich nicht, Webdesigner neigen allerdings häufig zu Übertreibungen, die die Auffindbarkeit oder Bedienbarkeit solcher Interaktionsmöglichkeiten einschränken.

MI

[Christian Seiler]

Hallo Michael,

Kleinere optische Veränderungen schaden sicherlich nicht, Webdesigner neigen allerdings häufig zu Übertreibungen, die die Auffindbarkeit oder Bedienbarkeit solcher Interaktionsmöglichkeiten einschränken.

Und wegen Mißbrauchs entfernen wir gleich die gesamten Möglichkeiten? Wenn wird das Konsequent durchziehen, dann dürfen wir ja nur noch HTML4-Strict _ohne_ CSS schreiben...

Sorry, aber IMHO stellt dunkelgrauer Text auf schwarzem Hintergrund genauso einen Mißbrauch dar. Trotzdem darf man noch Vorder- und Hintergrundfarbe verstellen.

Christian

[molily]

Hallo Christian,

Warum sollte das Unsinn sein? Man kann ja schließlich auch die Formularelemente personalisieren... IMHO wäre ein Pseudoelement à la ::scrollbar sinnvoll.

»CSS [...] is a style sheet language that allows authors and users to attach style [...] to structured documents.«

Eine Bildlaufleiste ist nicht Teil des Dokuments. Eine Bildlaufleiste kann auch kein Pseudoelement sein, da sie sich nicht aus dem Markup herleiten lässt - auf welchen Teil der Definition http://www.w3.org/TR/CSS21/selector.html#x22 würdest du dich beziehen, »a way to assign style to content that does not exist in the source document«? Die content-Eigenschaft bezieht sich aber auf dem Dokument zugehörigen Inhalt.

Deiner Argumentationsweise nach wäre auch eine Eigenschaft sinnig, welche dem Browserinterface ein Hintergrundbild verpasst. Oder eine Eigenschaft, welche bewirkt, dass sich ein Hyperlink in einem neuen Fenster öffnet, wie hier oft vorgeschlagen wurde.
Da Microsoft ein völlig anderes CSS-Konzept verfolgt (siehe behaviour et cetera), passt die Anpassung der Bildlaufleisten in dieses Konzept, aber nicht in W3C-CSS (oder missachte ich CSS3-UI?).

Grüße,
Mathias

[Herbie]

Hi Mathias

Eine Bildlaufleiste ist nicht Teil des Dokuments.

Ich denke, die Scrollbar ("äußere" und "innere", in zB textarea und frames) ist ein Mittelding aus Dokument und UI. Sie ergibt sich aus Eigenschaften des Dokuments.
Und auch wenn du im strengen Sinne Recht hast - ich finde, es wäre trotzdem eine schöne Sache, wenn auch die Scrollbars irgendwie gestaltbar wären.

Herbie

[Christian Seiler]

Hallo Mathias,

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.

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.

(der Rest steht als Beispiel (»for instance«) dort)

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.

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

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«, 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)

Christian

[molily]

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)

[Christian Seiler]

Hallo Mathias,

[Pseudoelemente, Viewport, etc.]

Du hast ja vollkommen Recht... aber:

1. Ich selbst sehe kein Problem darin, die Scrollbar zu verändern, auch wenn das nur bestimmte Arten von Benutzeragenten umsetzen können, denn es gibt ja z.B. auch aureales CSS - das könnte im Moment kein einziger Benutzeragent auf meinem System umsetzen. (Mangels installiertem Soundkartentreiber)

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.

2. Nur weil es in der aktuellen CSS2-Spezifikation so drinnensteht, heißt das noch lange nicht, dass das 100% sinnvoll ist. Meiner Ansicht nach wäre - jetzt von der Struktur her gesehen und nicht von der Definition von Pseudoelementen her - ::scrollbar viel eleganter und flexibler als Eigenschaften, die man auf das Root-Element anwenden kann.

Christian

[molily]

Hallo, Christian,

1. Ich selbst sehe kein Problem darin, die Scrollbar zu verändern, auch wenn das nur bestimmte Arten von Benutzeragenten umsetzen können,

Schon klar, wir reden von einer Eigenschaft für den Medientyp screen - aber übrigens nicht generell für die Mediengruppe »visual«. Soweit wäre die Eigenschaft auch nicht auf andere visual-Medientypen übertragbar, da Browser dieser Medien wie ich sagte völlig unterschiedliche Mechanismen anbieten, um ein Dokument, welches nicht komplett auf die Ausgabefläche passt, zugänglich zu machen.

denn es gibt ja z.B. auch aureales CSS - das könnte im Moment kein einziger Benutzeragent auf meinem System umsetzen. (Mangels installiertem Soundkartentreiber)

Was willst du damit sagen?

Sofern du mir eine akustische CSS-Eigenschaft zeigst, welche Einstellungen jenseits des fiktiven übertragenen »Viewports« eines vorlesenden Browsers ändert, würde ich die Analogie verstehen, aber beispielsweise wird akustisches CSS keinesfalls die Vorleseparameter der browsereigenen Kontrollen, Mechanismen beziehungsweise Ausgaben ändern können. Auch hier besteht eine klare Trennung zwischen Dokument, auf dessen Ausgabe die Styles Auswirkungen haben und den browsereigenen Funktionen.

Natürlich muss ein Akustikbrowser keine visual/screen-Eigenschaften verstehen, wollte ich auch nie behaupten, aber wieso ist das ein Argument für eine Eigenschaft oder ein Pseudoelement, welche beziehungsweise welches die Formatierung der scrollbar erlaubt?

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.

2. Nur weil es in der aktuellen CSS2-Spezifikation so drinnensteht, heißt das noch lange nicht, dass das 100% sinnvoll ist.

Ich habe auch lediglich die inneren Strukturkonventionen interpretiert und vom Bestehenden und der Arbeit an CSS3 darauf geschlossen, wieso ein Pseudoelement hier fehl am Platz wäre.

Meiner Ansicht nach wäre - jetzt von der Struktur her gesehen und nicht von der Definition von Pseudoelementen her -

Welchen Sinn sollte das haben? Welche »Struktur«? Eine Scrollbar ist zwar eine spezielle Ausprägung beziehungsweise ein spezieller Unterteil eines Elements, aber wieso passt das Schema Element-Eigenschaft-Wert hier nicht?

Die Pseudoelemente sind in CSS eingeführt worden, um eine bestimmte Aufgabe zu erfüllen, und wie ich dargelegt habe, passt die Formatierung von Scrollleisten nicht in das momentane Konzept von Pseudoelementen. Ob dieses Konzept an sich sinnig beziehungsweise angemessen begrenzt ist, ist hier im Grunde genommen nicht die Frage, denn schließlich forderst du in bewusster Anlehnung an dieses bestehende Konzept ausdrücklich ein *Pseudoelement* ::scrollbar, obwohl es mit anderen bestehenden Pseudoelementen nichts gemein hat. Es sei denn, du willst in erter Linie das Pseudoelement-Konzept ausweiten beziehungsweise reformieren - in dem Falle ist dein Vorschlag nachvollziehbar (aber ich teile die Meinung nicht).

Einzig logisch scheint mir weiterhin, dem Wurzelelement direkt Styles für die Bildlaufleiste zuzuordnen, beziehungsweise dem Element, dessen übergroßer Inhalt durch Blättermechanismen zugänglich gemacht werden soll.

::scrollbar viel eleganter und flexibler als Eigenschaften, die man auf das Root-Element anwenden kann.

Das ist eine These, und bis jetzt hast du kein Argument genannt, sodass ich deine Position nicht verstehe.

Ob die Styles in einer Regel beispielsweise mit dem Selektor html oder html::scrollbar untergebracht werden, erscheint mir gleich, genauso bei anderen gewöhnlichen Elementen und Formularfeldern. (Sie lassen sich lediglich optisch trennen.) Ebenso denke ich, dass die Styles in der Regel untergebracht werden sollten, in welchem auch die jeweilige overflow-Deklaration untergebracht ist, beziehungsweise sie möglicherweise fehlt, aber implizit vorhanden ist und wirkt (Default-Wert auto: »should cause a scrolling mechanism to be provided for overflowing boxes.«).

Grüße,
Mathias

[Christian Seiler]

Hallo Mathias,

Natürlich muss ein Akustikbrowser keine visual/screen-Eigenschaften verstehen, wollte ich auch nie behaupten, aber wieso ist das ein Argument für eine Eigenschaft oder ein Pseudoelement, welche beziehungsweise welches die Formatierung der scrollbar erlaubt?

Dein Argument, auf das ich mich bezog, war, dass das nicht überall Interpretiert werden muss, da einige Browser andere Mechanismen für das Scrolling besitzen. Ich wollte lediglich darlegen, dass das ja in Ordnung so ist. Nur es gibt nun mal eine Gruppe von Browsern, die Scrollbars verwenden - und diese Gruppe ist nunmal sehr weit verbreitet.

Der CSS-Standard lässt das Verändern von Scrollleisten nicht zu, das hast Du dargelegt, aber meiner Ansicht nach gehören sie zum Element, zumindest in den Browsern, die Scrollleisten verwenden.

Welchen Sinn sollte das haben? Welche »Struktur«? Eine Scrollbar ist zwar eine spezielle Ausprägung beziehungsweise ein spezieller Unterteil eines Elements, aber wieso passt das Schema Element-Eigenschaft-Wert hier nicht?

Ganz einfach: Weil eine Scrollbar ein eigener »Bereich« ist, sie hat nichts direkt mit dem Element zu tun. Ich betrachte nunmal eine Scrollbar als »virtuelles Element«, ähnlich wie einen Button. Ist aber warscheinlich Auslegungssache.

Es sei denn, du willst in erter Linie das Pseudoelement-Konzept ausweiten beziehungsweise reformieren - in dem Falle ist dein Vorschlag nachvollziehbar

Genau darauf wollte ich hinaus. Meinetwegen kann man auch ein weiteres Konzept einführen, das drei statt zwei Doppelpunkte verwendet oder etwas anderes verwenden, das ich übersehen habe. Aber einfach Eigenschaften in das Element reinsetzen find ich unpassend.

::scrollbar viel eleganter und flexibler als Eigenschaften, die man auf das Root-Element anwenden kann.

Das ist eine These, und bis jetzt hast du kein Argument genannt, sodass ich deine Position nicht verstehe.

Vielleicht denke ich bloß einfach zu sehr wie ein GUI-Programmierer? - für mich ist nunmal eine Scrollbar etwas »Eigenständiges, was doch dazu gehört«.

Ob die Styles in einer Regel beispielsweise mit dem Selektor html oder html::scrollbar untergebracht werden, erscheint mir gleich, genauso bei anderen gewöhnlichen Elementen und Formularfeldern. (Sie lassen sich lediglich optisch trennen.)

Das verstehe ich jetzt nicht...

Christian