Opera (7 + andere?) und Höhe von Inputfeldern

[ecklvo]

Ein zweites Hallo!
Hier im Forum sind ja einige Leute tätig, die sich eingehender (als meine Wenigkeit) mit Opera und dessen guten und schlechten Seiten auseinandergesetzt haben.
Bei den anderen beiden Hauptbrowsern dieser Welt ist es so, wenn ich einem Inputfeld eine font-size zuweise, machen sie es dementsprechend auch niedriger oder höher.
Opera folgt dem nicht, wäre mit height zwar zu beeinflussen - line-height hatte bei mir keinen Einfluss gezeigt, sollte es nach dem Standard auch nicht, doch man weiß ja nie - doch dann kotzen andere Browser völlig ab.
Gibt es eine browserunabhängige Möglichkeit dbzgl.?

Nachtrag: Bevor ich diese Nachricht abschicke, hab' ich nochmal nachgeprüft, es scheint ein Unterschied im Box-Model der Input-Felder zw. Opera, Moz. und IE vorzuliegen. Während Opera die border in die Höhe miteinbezieht, gehen IE und Moz dabei standardkonform vor.
An der DTD kann's nicht liegen, es ist der standards-compliant-Modus.

Dankeschön, e.

[molily]

Bei den anderen beiden Hauptbrowsern dieser Welt ist es so, wenn ich einem Inputfeld eine font-size zuweise, machen sie es dementsprechend auch niedriger oder höher.
Opera folgt dem nicht, wäre mit height zwar zu beeinflussen - line-height hatte bei mir keinen Einfluss gezeigt, sollte es nach dem Standard auch nicht, doch man weiß ja nie - doch dann kotzen andere Browser völlig ab.
Gibt es eine browserunabhängige Möglichkeit dbzgl.?

Meines Wissens nicht, daher wäre wohl eine unterschiedliche Bedienung über Selektorhacks notwendig. Indem padding auf 0 gesetzt wird, erreicht man schon einmal MSIE 6 und Gecko (MSIE 5.x kann ich momentan nicht testen, ältere Geckos muss ich auch noch testen) mit gleichen Werten, dann würde nur Opera aus der Reihe tanzen (Konqueror/KHTML weiß ich nicht).

Ich schaue es mir in den nächsten Tagen noch einmal genau an, bis dahin verweise ich auf eine Untersuchung der Eingabefeldgrößen unter verschiedenen Bedingungen (font-size, line-height, padding, border): http://home.t-online.de/home/dj5nu/fanhost/css-input-size.html. Dabei ist mir auch ein Bug Operas aufgefallen, der selbst in 7.5p1 noch nicht repariert ist: Nach dem Neuladen über F5 und nach Änderung der Fenstergröße werden die Eingabefelder plötzlich kleiner. Daher sind die Werte für die Operas doppelt angegeben, der Wert in Klammern jeweils ist der Ausgangswert vor dem Neuladen.

Die beiden Tabellen sind übrigens dieselben, nur um die Diagonale gespiegelt.

Nachtrag: Bevor ich diese Nachricht abschicke, hab' ich nochmal nachgeprüft, es scheint ein Unterschied im Box-Model der Input-Felder zw. Opera, Moz. und IE vorzuliegen.

Es gibt eigentlich kein offizielles Box-Modell für Eingabefelder.

Während Opera die border in die Höhe miteinbezieht, gehen IE und Moz dabei standardkonform vor.

Konform zu welchem Standard? CSS 2 verliert kein Wort darüber, in wieweit Boxeigenschaften auf das Innere von replaced inline elements anwendbar sind. Vgl. </archiv/2003/7/53862/#m299024>.

[ecklvo]

Meines Wissens nicht, daher wäre wohl eine unterschiedliche Bedienung über Selektorhacks notwendig.

Nun ja, nach Durchsuchen des CSS-Hacks-Universums scheint es nicht möglich zu sein Opera 6 + 7 explizit rauszufiltern ohne auch Geckos anzusprechen
http://centricle.com/ref/css/filters/

Indem padding auf 0 gesetzt wird, erreicht man schon einmal MSIE 6 und Gecko (MSIE 5.x kann ich momentan nicht testen, ältere Geckos muss ich auch noch testen) mit gleichen Werten, dann würde nur Opera aus der Reihe tanzen (Konqueror/KHTML weiß ich nicht).

Ja, das habe ich ohnehin vermutet und auch schon berücksichtigt, dass diese Angabe mehrere Browser dazu bewegt die Größe halbwegs gleich zu ziehen

Ich schaue es mir in den nächsten Tagen noch einmal genau an, bis dahin verweise ich auf eine Untersuchung der Eingabefeldgrößen unter verschiedenen Bedingungen (font-size, line-height, padding, border): http://home.t-online.de/home/dj5nu/fanhost/css-input-size.html.

Recht herzlichen Dank für die Mühe, das hat einiges Licht ins Dunkel gebracht - ist eine sehr schöne Auflistung.

Es gibt eigentlich kein offizielles Box-Modell für Eingabefelder.

Während Opera die border in die Höhe miteinbezieht, gehen IE und Moz dabei standardkonform vor.

Konform zu welchem Standard? CSS 2 verliert kein Wort darüber, in wieweit Boxeigenschaften auf das Innere von replaced inline elements anwendbar sind. Vgl. </archiv/2003/7/53862/#m299024>.

Ja, das tut mir leid, ich nahm' mir nicht die Zeit die W3-Dokumente durchzugehen, ich probierte ein Inputfeld mit height:13px; border-width:1px; und padding:0; aus und es hatte eine Höhe von 15 Pixeln, daher dachte ich, es spielen die Box-Models eine Rolle.
Ich traue mich auch zu wetten, dass der IE im quirks-mode eine Höhe von 13px anzeigt, oder sollte ich mich da täuschen?

Schönen Gruß und vielen Dank nochmal, e.

[molily]

Meines Wissens nicht, daher wäre wohl eine unterschiedliche Bedienung über Selektorhacks notwendig.

Nun ja, nach Durchsuchen des CSS-Hacks-Universums scheint es nicht möglich zu sein Opera 6 + 7 explizit rauszufiltern ohne auch Geckos anzusprechen
http://centricle.com/ref/css/filters/

Star 7: http://centricle.com/ref/css/filters/tests/star-7/ -> http://diveintomark.org/safari/csshacks/star7.html

Dreischritt über html* und Attributselektor, angenommen, das Eingabefeld soll mit border 20px hoch sein:

/* eventuell input.texteingabefeld */
input {border:1px solid black; padding:0;
      /* http://centricle.com/ref/css/filters/tests/sbmh/ */
      height:18px;
      \height:20px; /* MSIE <6 */
      he\ight:18px; /* MSIE 6 im standardkonformen Modus */
}
/* Opera 7 */ input[type="text"] {height:20px;}
/* Gecko */ html*[type="text"] {height:18px;}

width ließe sich entsprechend verteilen.

Ich habe http://home.t-online.de/home/dj5nu/fanhost/css-input-size.html noch einmal aktualisiert, Opera 7.5 preview 1 scheint sich wieder wie 7.02 zu verhalten (7.23 baut unlogischen Mist, wie du siehst). Insofern gilt die obige Regel für Opera für 7.02 und 7.5 aber nicht für 7.23 und wahrscheinlich die gesamte 7.2er-Reihe. Das ist natürlich ärgerlich.

Allerdings würde ich obiges Gefummle über mehrere Hacks sowieso nicht empfehlen, das wäre mir zu riskant und nicht nachhaltig, diese paar Pixel würde ich mir schenken.
Opera 6 würde ich vernachlässigen, vor dem müsste höchstens das border versteckt werden, vielleicht durch den Owen Hack, das wäre aber Overkill.

ich probierte ein Inputfeld mit height:13px; border-width:1px; und padding:0; aus und es hatte eine Höhe von 15 Pixeln, daher dachte ich, es spielen die Box-Models eine Rolle.

Das Box-Modell spielt schon eine Rolle, da sich die Browserhersteller daran orientieren, auch wenn es letztlich willkürlich ist, wie gesagt.

Ich traue mich auch zu wetten, dass der IE im quirks-mode eine Höhe von 13px anzeigt, oder sollte ich mich da täuschen?

Ja, MSIE 6 im Quirks-Mode und MSIE 5 verhalten sich wie Opera 7.02/7.5, width umfasst also auch die border.

[ecklvo]

Star 7: http://centricle.com/ref/css/filters/tests/star-7/ -> http://diveintomark.org/safari/csshacks/star7.html

Dreischritt über html* und Attributselektor, angenommen, das Eingabefeld soll mit border 20px hoch sein:

/* eventuell input.texteingabefeld */
input {border:1px solid black; padding:0;
      /* http://centricle.com/ref/css/filters/tests/sbmh/ */
      height:18px;
      \height:20px; /* MSIE <6 */
      he\ight:18px; /* MSIE 6 im standardkonformen Modus */
}
/* Opera 7 */ input[type="text"] {height:20px;}
/* Gecko */ html*[type="text"] {height:18px;}

Das erste was mir daraufhin einfällt: HARDCORE!
Peter-Paul Koch hat in einem seiner Artikel einmal richtig festgestellt, er selbst hat noch nie einen CSS-Hack eingesetzt (ich nehme an, dass er seine Seiten nicht größtmöglich pixelgenau designt (zweite Klammer: mir ist schon bewusst, das pixelgblablabla)), denn er fürchtet dass dann irgendwelche Versionen auftauchen, die den CSS-Hack plötzlich verstehen oder nur zwischendurch welche ihn verstehen (was gab' es bei Opera inzwischen: 7.XX: .21, .22, .23?) -> s. a. Deine Überprüfung unten.

Hast Du bei http://centricle.com/ref/css/filters/tests/star-7/ auch die Kommentare durchgelesen? Der Hack besteht auf einer Fehlinterpretation der W3C-Vorlagen, denn nach dem Element müsste normalerweise ein Leerzeichen stehen, dann versteht auch (mein) Opera 7 den Selektor.

Ich habe http://home.t-online.de/home/dj5nu/fanhost/css-input-size.html noch einmal aktualisiert, Opera 7.5 preview 1 scheint sich wieder wie 7.02 zu verhalten (7.23 baut unlogischen Mist, wie du siehst). Insofern gilt die obige Regel für Opera für 7.02 und 7.5 aber nicht für 7.23 und wahrscheinlich die gesamte 7.2er-Reihe. Das ist natürlich ärgerlich.

Woran diese grausame Reload-Verschiebung wohl liegt?
In meinem Opera 7.11/Windows sieht die Sache so aus, ohne dass ich das Reloadphänomen nachvollziehen konnte:
A) 152*22
B) 152*22
C) 152*22
D) 152*22
E) 152*22
F) 152*22
G) 204*44
H) 152*22

Allerdings würde ich obiges Gefummle über mehrere Hacks sowieso nicht empfehlen, das wäre mir zu riskant und nicht nachhaltig, diese paar Pixel würde ich mir schenken.

Ich danke Dir für den Hinweis, werde aber in diesem Fall ohnehin, obwohl ich mit dem gestalterischen Part nicht ganz zufrieden bin, lieber den leichteren Weg wählen.

Opera 6 würde ich vernachlässigen, vor dem müsste höchstens das border versteckt werden, vielleicht durch den Owen Hack, das wäre aber Overkill.

Gruß, e.

[molily]

Das erste was mir daraufhin einfällt: HARDCORE!
Peter-Paul Koch hat in einem seiner Artikel einmal richtig festgestellt, er selbst hat noch nie einen CSS-Hack eingesetzt

Ich kenne den Artikel. ppk lebt aber auf dem Mond. Der Unterschied von zwei Pixeln bei Texteingabefeldern ist tatsächlich vernachlässigbar, dazu ist ein Hack letztendlich mehr schädlich als nützlich. Was den Großteil der übrigen Szenarien angeht, in denen Hacks nötig bzw. sehr sinnvoll sind, so geht es darum, grundlegende Benutzbarkeit zu wahren.

(ich nehme an, dass er seine Seiten nicht größtmöglich pixelgenau designt (zweite Klammer: mir ist schon bewusst, das pixelgblablabla)),

Der Großteil der Verwendung von Hacks hat mit Pixelgenauigkeit eigentlich nichts zu tun.

denn er fürchtet dass dann irgendwelche Versionen auftauchen, die den CSS-Hack plötzlich verstehen oder nur zwischendurch welche ihn verstehen (was gab' es bei Opera inzwischen: 7.XX: .21, .22, .23?) -> s. a. Deine Überprüfung unten.

Hast Du bei http://centricle.com/ref/css/filters/tests/star-7/ auch die Kommentare durchgelesen? Der Hack besteht auf einer Fehlinterpretation der W3C-Vorlagen, denn nach dem Element müsste normalerweise ein Leerzeichen stehen, dann versteht auch (mein) Opera 7 den Selektor.

Ich weiß. Allerdings ist die normative formale Grammatik von CSS 2 nicht so eindeutig, anhand dessen kann ich nicht feststellen, dass dies verboten ist. Außerdem stammt es aus den CSS2-Textcases von David Baron: http://dbaron.org/css/test/univsel.
In der Grammatik steht nämlich:
selector
  : simple_selector [ combinator simple_selector ]*
  ;
simple_selector
  : element_name? [ HASH | class | attrib | pseudo ]* S*
  ;
combinator
  : '+' S* | '>' S* | /* empty */
  ;
element_name
  : IDENT | '*'
  ;
usw.

Hier verstehe ich nicht, wieso Whitespace nicht als Combinator aufgeführt wird. Descendant Selectors arbeiten mit Whitespace als Kombinatoren: »A descendant selector is made up of two or more selectors separated by whitespace.« Wieso wäre also der Selektor »html*« falsch? Es wäre ein simple_selector mit element_name ohne Whitespace dahinter, dann wieder ein simple_selector. nmchar legt ferner fest, dass »*« nicht gleichzeitig Teil des IDENT sein kann, somit müssen es zwei element_name sein.