nicht angemeldet
Die Archivierungsdrohnen sind mir zuvorgekommen :), darum möchte ich durch Neueinspeisung die Diskussion oder besser den Meinungsaustausch (f. alle anderen Forumsteilnehmer: zwischen meiner Person und molily, s. Link) fortsetzen.
http://forum.de.selfhtml.org/archiv/2004/1/69096/
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.
Naja, auf dem Mond ist das Leben sicherlich auch nicht zu verachten.
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. [...] Der Großteil der Verwendung von Hacks hat mit Pixelgenauigkeit eigentlich nichts zu tun.
Ich habe jetzt zwei Deiner Sätze zusammengestellt, damit meine Antwort im Zusammenhang klarer ersichtlich wird.
Nach dem derzeitigen Einsatz von CSS-Hacks im Netz gibt es drei grobe Arten für deren Anwendung:
- Um die Benutzbarkeit in alten Browsern (NC4 & Konsorten) sicherzustellen, wobei mit Benutzbarkeit zumeist nur Lesbarkeit der Texte und halbwegs angedachte Darstellung der Inhalte gemeint ist.
- Um die Lesbarkeit bei flexiblem Layout sicherzustellen (s. ems/Prozentangaben/Keywords)
- Um die gleiche Darstellung auf dem überwiegenden Teil der neueren graphischen Browser zu erreichen. Du weist auf Deiner Site zu Recht auf User-Stylesheets hin, doch es geht mir in diesem Fall zumeist darum, alles erdenkliche getan zu haben, dass der User meine angedachte graphische Aufbereitung zu sehen bekommt (an die Forumsteilnehmer: Bitte keine Vorschlaghämmer mit unterschiedlicher Auflösung/Farbdarstellung etc. - ist mir bewusst) und wenn nicht, dann nicht. Ist in seiner Macht. Aber ich habe es versucht. Nicht umsonst heißt der Boxmodel-Hack Boxmodel-Hack. Im Grunde müsste man sein Layout doch so auslegen, dass es egal ist ob das padding und die border miteingerechnet wird oder nicht. Die 10 Pixel auf oder ab...
Insofern hat ppk wieder Recht.
Man darf mich nicht falsch verstehen, ich bin ein treuer Anhänger von CSS-Hacks, schon alleine deshalb weil sie weitaus sicherer sind als sämtliche Browserdefinitionen, die man vorab, ob nun per JS oder per PHP anfertigt. Ich wollte nur, auf wienerisch sagt man, "auf g'scheit" eine andere Sichtweise (die ppks) auf den erschütternd großen 7*-Hack (f. 2 Pixel) darlegen, die ich durchaus anerkenne, selbst aber nur sehr selten praktisch nachvollziehe.
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.
Vorneweg: Interessant ist im Zshg. mit Opera bei http://centricle.com/ref/css/filters/tests/star-7/ auch, dass er die Anweisung im Fall von
html*#test-span und
html* #test-span ignoriert, jedoch
html *#test-span und
html * #test-span interpretiert, ebenso gleiches Verhalten, wenn man id in Klasse umwandelt, nicht jedoch bei
html *span
Hier müssen beide Tags durch ein Leerzeichen vom Selektor getrennt werden. Es mag sein, dass die Grundüberlegung im W3C die Notationsweise dazu war:
Klassen werden mit . definiert, ids mit #
Also beugte man um Verwechslungen zu vermeiden der Schreibweise *span vor
Ich kann leider nicht viel mit der von Dir notierten Grammatik anfangen, damit habe ich mich noch nie auseinandergesetzt. Aber was nicht ist kann ja noch werden, die Archivseite ist schon mal auf meiner Festplatte gelandet.
Ein Gedanke kam mir abschließend noch: Wenn Du nochmals auf http://www.w3.org/TR/CSS2/selector.html#descendant-selectors nachschaust, sind beide Beispiele mit whitespace verfasst und es wird auch explizit darauf hingewiesen: "Note the whitespace on either side of the "*"." Vielleicht ist die grundsätzliche Notationsweise (die Grammatik) von CSS wie ich es oben andachte der Grund und Opera als bislang einziger verlässlicher Interpreter?!
---------------------------------------------------------------------
Nebenbei: Ich habe mich wunderbar amüsiert über Deine bemerkenswerten und köstlichen Wörter http://molily.de/lit-woerter und hab' dabei auch 'blomquist' gelesen. Vielleicht wäre dann auch die norwegische Schifahrerin Trine Bakke etwas für die Liste? Oder eher reüssieren?
Gute Nacht, e.