noch ne frage

[TeKO]

wie kann man bei verweisen mit grafik, die linie wegmachen die das ganze umgibt?

Danke TeKO

[Fabian Transchel]

Hi

wie kann man bei verweisen mit grafik, die linie wegmachen die das ganze umgibt?

style="border:0px solid;"

Fabian

[Thomas Meinike]

Hallo,

wie kann man bei verweisen mit grafik, die linie wegmachen die das ganze umgibt?

style="border:0px solid;"

style="border: none;"

MfG, Thomas

[Fabian Transchel]

Hi Thomas,

wie kann man bei verweisen mit grafik, die linie wegmachen die das ganze umgibt?
style="border:0px solid;"
style="border: none;"

war mir klar, dass das kommt. ;-))

Ist es relevant, welche Angabe man nimmt? IMO nicht.

Fabian

[Thomas Meinike]

Hallo,

Ist es relevant, welche Angabe man nimmt? IMO nicht.

Ist es relevant, was/dass ich hier schreibe? ;-)

MfG, Thomas

[emu]

Hallo!

wie kann man bei verweisen mit grafik, die linie
wegmachen die das ganze umgibt?
style="border:0px solid;"
style="border: none;"
war mir klar, dass das kommt. ;-))

Ist es relevant, welche Angabe man nimmt? IMO nicht.

Wenn man an CSS die gleichen Maßstäbe an logischer Auszeichnung anle-
gen würde wie an HTML, ja.

emu
[half-scnr]

[Fabian Transchel]

Hi emu,
lange nicht mehr hier gesehen, schön, dass du dich mal wieder blicken lässt =)

Ist es relevant, welche Angabe man nimmt? IMO nicht.

Wenn man an CSS die gleichen Maßstäbe an logischer Auszeichnung anle-
gen würde wie an HTML, ja.

CSS ist nunmal aber nicht für Logik, sondern für Formatierung zuständig. (Man könnte sich jetzt über logische Formatierung streiten, aber bei CSS ist allein relevant, wie es aussieht, und ob es jeder Browser einigermaßen anzeigen kann, nicht _wie_ das erreicht wird - im Gegensatz zu (validem) (X)HTML)

emu
[half-scnr]

Fabian
[ebenfalls pseudo-scnr] ;-)

[Thomas J.S.]

Hallo Fabian,

Ist es relevant, welche Angabe man nimmt? IMO nicht.

Wenn man an CSS die gleichen Maßstäbe an logischer Auszeichnung anle-
gen würde wie an HTML, ja.

CSS ist nunmal aber nicht für Logik, sondern für Formatierung zuständig. (

Das mag für Anwendung vom CSS stimmen, aber keines Wegs auf die Aufbau von CSS Zuweisungen und auf die Sprache selbst: denke nur an Regeln wie
p > p
#myID .subID a[href=blabla.html]
Das sind alle logische Zuweisungen.
Aber auch abgesehen von dieser Logik, was erschient dir logischer, wenn ich keinen border um ein Element haben will?
[ ] dem Element einen border von 0px Breite und durchgängig zuzuweisen (border: 0px solid), oder
[ ] gleich sagen, dass ich keinen border haben will (border:none)

Grüße
Thomas

[Fabian Transchel]

Hi

Das mag für Anwendung vom CSS stimmen, aber keines Wegs auf die Aufbau von CSS Zuweisungen und auf die Sprache selbst: denke nur an Regeln wie
p > p
#myID .subID a[href=blabla.html]
Das sind alle logische Zuweisungen.

korrekt, deswegen nannte ich es ja auch "pseudo-logisch" >;)

Aber auch abgesehen von dieser Logik, was erschient dir logischer, wenn ich keinen border um ein Element haben will?
[ ] dem Element einen border von 0px Breite und durchgängig zuzuweisen (border: 0px solid), oder
[ ] gleich sagen, dass ich keinen border haben will (border:none)

[X] dem Element einen border von 0px Breite und durchgängig zuzuweisen (border: 0px solid), weil dann ein Browser, der "none" nicht kennt immerhin eine 0px Border anzeigt, was den gleichen Effekt hat, während bei border:none IMHO bei CSS-armen Browsern (z.B. N4.x, bei dem jede Version alles anders macht...) nur _so_ nichts angezeigt wird.

Fabian

[Thomas J.S.]

Hallo Fabian,

[X] dem Element einen border von 0px Breite und durchgängig zuzuweisen (border: 0px solid), weil dann ein Browser, der "none" nicht kennt immerhin eine 0px Border anzeigt, was den gleichen Effekt hat, während bei border:none IMHO bei CSS-armen Browsern (z.B. N4.x, bei dem jede Version alles anders macht...) nur _so_ nichts angezeigt wird.

Dann machst du es doppelt falsch: logisch gesehen und der NS 4.x versteht viel öfter ein border:none, als ein borer:0px solid. :-)

Grüße
Thomas

[Orlando]

Hi Thomas,

der NS 4.x versteht viel öfter ein border:none, als ein borer:0px solid. :-)

das ist für mich Grund genug, über border:none nachzudenken, obwohl mir als Geizkragen border:0 (was am vernünftigsten wäre) natürlich viel sympathischer ist. "0px solid" bedeutet dagegen eine sinnlose Verschwendung von 8 Zeichen, IMHO.

Stellt sich nur die Frage: Soll ich *ihn* berücksichtigen?

LG Roland .oO(Cyx23 und Thomas J.S. in der Nähe wähnend...) >;)

[molily]

Roland,

[...] obwohl mir als Geizkragen border:0 (was am vernünftigsten wäre) natürlich viel sympathischer ist.

Warum? border:none ist IMHO das logischste, oder meinetwegen auch vernünftigste. border:0 ist das ökonomischste, oder nützlichste.

Wenn man jedoch bezüglich CSS-Codegestaltung mit Nützlichkeit argumentiert, dann darf man bei HTML nicht mit den Vorteilen von semantischem Hypertext argumentieren, denn ökonomisch wäre der Verzicht auf aussagereiches strukturierendes Markup.

<q cite="http://www.w3.org/TR/REC-xml#sec-origin-goals">
The design goals for XML are:
[...]
6. XML documents should be human-legible and reasonably clear.
[...]
10. Terseness in XML markup is of minimal importance.
</q>

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

Soll überhaupt ein
          Rahmen angezeigt werden?
                    |
           +--------+----------+
           |                   |
          Ja                 Nein
           |                   |
           |               border:none
           |                   |
     Welche Art von Rahmen     #
     soll angezeigt werden?
               |
      +--------+--------+
      |        |        |
    solid    double  dotted/dashed/...
      |        |        |
      +--------+--------+
               |
       Wie dick soll der
         Rahmen sein?
               |
     +-------------------+
     |           ______  |
     |  Wert    |______| |
     |           ______  |
     |  Einheit |______| |
     |                   |
     +-------------------+
               |
               #

Die generell Anzeige des Rahmens (aktiviert/deaktiviert) wird logischerweise über den border-style geregelt, deshalb ist border:0px solid gleich zweifach "unnatürlich", denn Null (Nichts) hat keine Einheit, weiterhin gilt es, den Rahmen auszuschalten, nicht einem vorhandenen Rahmen die Größe Null zuzuordnen. Aus diesem Grund ist auch border:0 irreführend, da eine Rahmenbreite border-width für einen nicht vorhandenen Rahmen vergeben wird, es wird also vermutet, dass der Rahmen aktiviert ist, um im Nachhinein im logisch dritten Schritt des Flussdiagramms Größen zu vergeben, welche unnötig wären, wenn man im ersten Schritt die Anzeige des Rahmens unterbunden hätte. Vergleiche die XML-Variante:

Variante 1:

<rahmen>
<!-- implizit: <anzeige>ja</anzeige>    -->
<!-- implizit: <stil>durchgehend</stil> -->
<breite>0</breite>
<!-- implizit: <farbe>schwarz</farbe>   -->
</rahmen>

Variante 2:

<rahmen>
<anzeige>nein</anzeige>
</rahmen>

Beide Varianten würden ohne Frage auf dasselbe herauskommen, dennoch ist alleinig die zweite Variante logisch ("reasonably clear" bzw. "formal and concise"). Mit border:0 poltert man durch die Hintertür herein, *logisch* wäre hingegen ausschließlich border:none. 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.

Grüße,
Mathias

[Orlando]

Hi Mathias,

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

[...] obwohl mir als Geizkragen border:0 (was am vernünftigsten wäre) natürlich viel sympathischer ist.

Warum? border:none ist IMHO das logischste, oder meinetwegen auch vernünftigste.

ACK

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

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

Wenn man jedoch bezüglich CSS-Codegestaltung mit Nützlichkeit argumentiert, dann darf man bei HTML nicht mit den Vorteilen von semantischem Hypertext argumentieren, denn ökonomisch wäre der Verzicht auf aussagereiches strukturierendes Markup.

Hm, das hängt dann doch davon ab, wie man "Ökonomie" definiert. Am Transfervolumen sicht nicht, im Sinne einer möglichst hohen Benutzbarkeit ist sparsames Markup höchst ineffizient. Wobei sich der zusätzliche Code durch Verwendung eines Layouts, das weitreichende Benutzbarkeit erst ermöglicht (CSS) arg in Grenzen hält, meist kommt man sogar mit weniger aus.

6. XML documents should be human-legible and reasonably clear.
7. Terseness in XML markup is of minimal importance.

Wir sind einer Meinung.

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

[...]

Im Grunde korrekt, aber wie arbeiten Browser intern? Ich kann mir gut vorstellen, dass bei der verkürzten Schreibweise "border:" die Werte "none" und "0" gleichwertig eine Abbruchbedingung darstellen. Tja, bei Mozilla könnte man eventuell im Code nachsehen. Nein, ich nicht ;)

Die generell Anzeige des Rahmens (aktiviert/deaktiviert) wird logischerweise über den border-style geregelt, deshalb ist border:0px solid gleich zweifach "unnatürlich", denn Null (Nichts) hat keine Einheit,

Sagte ich bereits, ja.

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. Aber "0" mag die zweite Abbruchbedingung sein, ok ;)

Aus diesem Grund ist auch border:0 irreführend, da eine Rahmenbreite border-width für einen nicht vorhandenen Rahmen vergeben wird, es wird also vermutet, dass der Rahmen aktiviert ist, um im Nachhinein im logisch dritten Schritt des Flussdiagramms Größen zu vergeben, welche unnötig wären, wenn man im ersten Schritt die Anzeige des Rahmens unterbunden hätte.

Das mag in einem Flussdiagram korrekt sein, in der Praxis ist es das eventuell nicht. Ich weiß es nicht. Selbst wenn, wäre der effektive "Zeitverlust" zu vernachlässigen. Aber darum geht's hier nicht.

Vergleiche die XML-Variante:

[...]

Auch hier hast du im Grunde Recht, aber es ist durchaus erlaubt, die Definitionen des Rahmens in beliebiger Reihenfolge zu notieren, was den ganzen Ablauf über den Haufen wirft. Wir sprechen hier vom worst case, ich weiß. Aber wie sieht's aus, wenn ich

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

mit

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

vergleiche? Im Endeffekt "kostet" beides das gleiche.

Beide Varianten würden ohne Frage auf dasselbe herauskommen, dennoch ist alleinig die zweite Variante logisch ("reasonably clear" bzw. "formal and concise").

Nochmal: ja

Mit border:0 poltert man durch die Hintertür herein, *logisch* wäre hingegen ausschließlich border:none.

Einmal noch: ACK

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. 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 ;)

LG Roland

[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

[Christian Seiler]

Hallo Mathias,

(bevor es Christian verlinkt ;))

Hey, was denskt Du denn? (ja, ich weiß, Dir ist sicherlich noch </archiv/2002/11/30668/#m165945> im Hinterkopf...)

(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. ;))

Jetzt sind es fünf. ;-P

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

Um die Zeit, als Du ins Bett bist, war ich schon eine Stunde wieder wach. ;-)

Grüße,

Christian

[Tim Tepaße]

Hallo Mathias,

Soll überhaupt ein
          Rahmen angezeigt werden?
                    |
           +--------+----------+
           |                   |
          Ja                 Nein
           |                   |

wo gibt es das Script, das solche schönen Flußdiagramme erzeugt? Ich weiger mich zu glauben, daß Du das jetzt gerade selbst gestaltet hast. ;-)

• Tim

[molily]

Hallo, Tim,

Soll überhaupt ein
          Rahmen angezeigt werden?
                    |
           +--------+----------+
           |                   |
          Ja                 Nein
           |                   |

wo gibt es das Script, das solche schönen Flußdiagramme erzeugt? Ich weiger mich zu glauben, daß Du das jetzt gerade selbst gestaltet hast. ;-)

Doch, na klar, und nicht nur das, denn zuerst hatte ich sogar sternförmige Abzweigungen benutzt, ungefähr folgendermaßen:

/   /  |  \   \          /    /   |   \    \        /     /    |    \     \      /      /     |     \      \

Dann habe ich aber noch einmal alles verworfen... ("Man hat ja sonst nichts zu tun"[tm]... ;))
Im Übrigen schreibe beziehungsweise zeichne ich solche Diagramme immer im MS-DOS Editor, das heißt edit.com, denn dieser ist der einzige mir bekannte Editor, welcher es erlaubt, in eine beliebige Spalte zu springen und dort ein Zeichen unterzubringen, auch wenn keine Leerzeichen bis zu dieser Spalte existieren, diese werden vom Editor dann passend hinzugefügt. Ein [Down]-Tastendruck führt folglich dazu, dass in derselben Spalte geblieben wird, anstatt zu Spalte 1 in der folgenden leeren Zeile gesprungen wird. Gepaart mit aktiviertem [INS]ert (Einfügen-Modus) lassen sich wunderbar "Bildpixel" setzen.

Mit Sicherheit gibt es auch irgendwo in den Tiefen des Netzes(tm) ein ASCII-Flussdiagrammgenerator, schließlich wurden diese nicht erst mit der Einführung von XWindows oder ähnlichen grafischen Anzeigesystemen und Oberflächen erfunden, wobei damals[tm] eher vieles analog von technischen Zeichnern erledigt wurde. Die naheliegendste Art, es digital zu verbreiten, war dennoch eine textbasierte Grafik, wobei ich nicht unterrichtet bin, wann die Möglichkeit pixelbasierter Anzeige gegeben war, doch sicher nicht schon in den ersten Tagen des Arpanets... ;) Danach waren das Usenet beziehungsweise Mailboxsysteme populär, welche beide nicht Ausschließen, dass binäre Pixelgrafiken getauscht und angezeigt werden konnten. War es Amiga oder Apple Macintosh, welcher die erste GUI für Personalcomputer beziehungsweise ähnliche Plattformen besaß?
Oh, wer suchet, der findet, es war wohl eher der Mac: http://toastytech.com/guis/, dann auf Timeline (Fraaaaames :-/).

Grüße,
Mathias

[Calocybe]

Gruesse!

Dann habe ich aber noch einmal alles verworfen... ("Man hat ja sonst nichts zu tun"[tm]... ;))

Oh mann, so viel Zeit moechte ich mal wieder haben...

Im Übrigen schreibe beziehungsweise zeichne ich solche Diagramme immer im MS-DOS Editor, das heißt edit.com, denn dieser ist der einzige mir bekannte Editor, welcher es erlaubt, in eine beliebige Spalte zu springen und dort ein Zeichen unterzubringen, auch wenn keine Leerzeichen bis zu dieser Spalte existieren, diese werden vom Editor dann passend hinzugefügt.

http://textpad.com/ -> Configure -> Preferences -> Editor: [ ] Constrain the cursor to the text

So long

[emu]

Hallo!

Wenn man an CSS die gleichen Maßstäbe an logischer Auszeichnung
anlegen würde wie an HTML, ja.

^^^^^

CSS ist nunmal aber nicht für Logik, sondern für Formatierung
zuständig.

[_] Du kannst differenzieren zwischen Indikativ und irrealem Konjunk-
tiv

Nebenbei: Bastelt das neue Forum eigenmächtig Leerzeilen nach Zitaten?

emu
[...]

[Fabian Transchel]

Hi

Wenn man an CSS die gleichen Maßstäbe an logischer Auszeichnung
anlegen würde wie an HTML, ja.
              ^^^^^
CSS ist nunmal aber nicht für Logik, sondern für Formatierung
zuständig.
[_] Du kannst differenzieren zwischen Indikativ und irrealem Konjunk-
tiv

[x] kann ich.

Nebenbei: Bastelt das neue Forum eigenmächtig Leerzeilen nach Zitaten?

[x] tut es.

Fabian

[Einbecker]

Moin!

Nebenbei: Bastelt das neue Forum eigenmächtig Leerzeilen nach Zitaten?
[x] tut es.

Wo? Ich hab das nirgendwo entdecken koennen - ausser in der Vorschau und der Bestätigungsseite...

Viele Gruesse,

Einbecker