Pseudologische Formatierungssprachen wie CSS

[molily]

Hallo, Roland, (besser wieder "klassisch" ;))

Roland,

Damit schießt du aber jetzt endgültig den Vogel ab *g* Irgendwie hat diese Anrede, hm, schwer zu beschreiben, etwas "Väterliches", ist rein gefühlsmäßig ein freundschaftlicher Rempler in's Kreuz bei gleichzeitiger, liebevoller Zurechtrückung des frischgewaschenen Scheitels. "Sohnemann", voll Stolz, sprach er... Aber ich mag's puristisch, so werden Klassiker geboren :)

*lol* Made my day... Ja, ich muss zugeben, es fordert diese Konnotatioen heraus, aber... uargh, mir graust es, eine sehr absurde Vorstellung. "Mein Sohnemann! Ist schon fast erwachsen! Ganz der Vater! <knuff />" und all diese Phrasen... *fg*
Väterlich wollte ich sicherlich nicht wirken (du hast die Situation aber sehr treffend beschrieben ;)). Eigentlich ging es auf http://forum.de.selfhtml.org/archiv/2002/10/25857/#m141830 zurück (bevor es Christian verlinkt ;)), ich habe es nur einmal angetestet, beziehungsweise eher nicht bewusst.
(Das Posting lässt sich übrigens sehr einfach wiederfinden, wenn man das Archiv nach "Melancholie" durchsucht, findet man nur drei Einträge in vier Jahren. ;))

border:0 ist das ökonomischste, oder nützlichste.

ACK, da sich der "Geizkragen" auf die Arbeit im Editor bezog.

Drei Zeichen Ersparnis, wow. ;)

Die Reihenfolge der Fragen, die man sich stellt, ist folgende:
[...]

Im Grunde korrekt, aber wie arbeiten Browser intern?

Das ist sicher ein wichtiger Aspekt, für meine Argumentation aber ein irrelevanter, da ich stregstens vermeiden wollte, pragmatisch zu analysieren... ;)

Ich kann mir gut vorstellen, dass bei der verkürzten Schreibweise "border:" die Werte "none" und "0" gleichwertig eine Abbruchbedingung darstellen.

An irgendeinem Punkt muss es eine Abfrage geben, ob border-width>0 und border-style:!none ist...

Tja, bei Mozilla könnte man eventuell im Code nachsehen. Nein, ich nicht ;)

http://lxr.mozilla.org/seamonkey/source/layout/html/style/src/nsCSSRendering.cpp#411 DrawSide
http://lxr.mozilla.org/seamonkey/source/content/html/style/src/nsComputedDOMStyle.cpp#3416 GetBorderStyleFor
http://lxr.mozilla.org/seamonkey/source/content/html/style/src/nsComputedDOMStyle.cpp#3283 GetBorderWidthFor (hier wird border-stle auf none geprüft... die eine Richtung ist also bewiesen!)
http://lxr.mozilla.org/seamonkey/source/content/html/style/src/nsComputedDOMStyle.cpp#3002 GetStyleData
http://lxr.mozilla.org/seamonkey/source/layout/base/src/nsPresContext.cpp#939 ResolveStyleContextFor
http://lxr.mozilla.org/seamonkey/source/content/base/src/nsStyleSet.cpp#1089 ResolveStyleFor
Der CSS-Parser ist wahrscheinlich nsCSSParser... ;)
http://lxr.mozilla.org/seamonkey/source/content/html/style/src/nsCSSParser.cpp#4466 ParseBorderSide
http://lxr.mozilla.org/seamonkey/source/content/html/style/src/nsCSSStyleRule.cpp#2017 MapMarginForDeclaration

Eigentlich geht es um die Zuweisung "wenn border-width==0, dann border-style=none", und diese kann ich nicht finden, höchstens http://lxr.mozilla.org/seamonkey/source/content/base/src/nsRuleNode.cpp#3458.

weiterhin gilt es, den Rahmen auszuschalten, nicht einem vorhandenen Rahmen die Größe Null zuzuordnen.

Auch logisch, aber wie sieht's bei verkürzter Notation aus? Ich definiere ja weder -style noch -color, sondern lediglich -width:0. Ein hochoptimierte Engine *muss* hier IMHO abbrechen, wenn der Selektor geschlossen wird.

Es geht nicht um die Parsing-Engine, denn die parst brav und sortiert sicher auch problemlos ein (erkennt die Zahl als border-width und verteilt sie auf border-(top|left|bottom|right)-width), es geht um das Berechnen der Vererbungen und Überlappungen (ResolveStyleContextFor?). Kurz gesagt: Um ein Element zu visualisieren, müssen alle Parameter des Rahmens bekannt sein, das heißt, sie müssen explizit aus der geparsten border-Deklaration gelesen werden (GetStyleData?) oder von anderen Regeln im selbem oder anderen Stylesheets beziehungsweise dem Default-Stylesheet übernommen werden.
Ich kann im Code zumindest nichts finden, das darauf hinweist, dass wenn border-width:0 bekannt ist, die anderen Parameter nicht berechnet/in Erfahrung gebracht werden, aber das muss nichts heißen. Offensichtlich werden diese Berechnungen nicht in jedem Fall durchgeführt, sodass das Interpretieren von border:0 theoretisch ausreichen würde, um das Zeichnen des Rahmens abzubrechen.

border-style:none solid solid none;
 border-width:1px;

border-style:solid;
 border-width:0 1px 1px 0;

Im Endeffekt "kostet" beides das gleiche.

Ja, schon... ich finde es nur leider nicht im Code. Das Problem beschränkt sich im Endeffekt nur darauf, ob border-*-style:none oder border-*-width:0 entscheidend sind, das Parsing ist AFAIK nicht entscheidend. Weiterhin stellt sich die Frage, ob noch einmal explizit die jeweils anderen border-Parameter anhand der Vererbungen etc. berechnet werden, wenn der Rahmen sowieso nicht angezeigt wird.

Abstrahiert gesehen wäre sogar border:none auch die ökonomischere Variante, da eine interpreterende Software die Abarbeitung der Rahmendeklaration nach anzeige=nein beenden könnte.

Kann sie bei border:0 auch - und ich glaube, die Browser machen es auch.

Das hatte ich natürlich auch im Sinn. Angesichts der Tatsache, dass das Problem nicht beim Parser liegen wird und möglicherweise ein nicht angegebener Parameter unnötigerweise bestimmt wird, ist meine Annahme nicht nahe an der Realität. Verallgemeinert muss es natürlich eine solche Abbruchbedingung geben, der Parser selbst kann jedoch nicht von border:0; direkt auf border:0 none $wasweißich; schließen, da erst der Murks drumherum berechnet werden muss, wodurch durch Benutzerstylesheets und !important durchaus etwas anderers herauskommen kann.

Egal, aus Rücksicht auf Netscape 4 (ich habe von Bugs in dieser Richtung gehört), werde ich auf "none" umstellen, wenn auch ungern. Du darfst mir widersprechend zustimmen ;)

disagree:none; ;)

Jetzt muss ich aber ins Bett, ich muss stundenlang im Code herumgewühlt haben, urgs...
Mathias