dedlfix: Zwischenüberschriften im SELF-WIKI

Hi!

Mir ist aufgefallen, dass es in der (automatisch erstellten) Zusammenfassung (TOC) - ähm - unschön aussieht, wenn solche Absätze wie Beispiel, Erläuterung und Beachten Sie als Überschrift (dritter Ordnung) ausgezeichnet sind. Christian Seilers Testseite:

1 Zeilenumbruch erzwingen
    1.1 Beispiel:
    1.2 Erläuterung:
    1.3 Beachten Sie:
  2 Automatischen Zeilenumbruch verhindern
    2.1 Beispiel:
    2.2 Erläuterung:
    2.3 Beachten Sie:
  [...]

Abgesehen von den Doppelpunkten wird deren Auflistung noch weniger nützlich, wenn mehrere solcher Absätze pro Thema auftauchen. Siehe beispielsweise Doku:HTML/Textauszeichnung:

1 Elemente und Tags in HTML
    1.1 Beispiel
    1.2 Erläuterung:
    1.3 Beachten Sie:
    1.4 Beispiel:
    1.5 Erläuterung:
    1.6 Beachten Sie:
  2 Verschachtelung von Elementen
    [...]

Ein Vorteil der Auszeichnung als Überschrift wäre "lediglich", dass es einen separat bearbeitbaren Abschnitt ergibt. Eine optische Abgrenzung vom vorhergehenden Fließtext könnte man auch mit einer Vorlagen-Box erledigen (ThomasJS' Beispiele - welche Farbgebung angebracht ist, kann man ja noch diskutieren). Besonders der Überschrift "Beispiel" folgt ja auch oft eine Box, so dass man das als Vorlage kombinieren könnte.

Wie kann man es besser machen?

Wenn die Überschriften bleiben sollen, könnte man den Text um eine Kurzzusammenfassung (Caption) erweitern, damit in der TOC auch ein Mehrwert entsteht. Aber: Bei Beispielen mag das noch gehen, doch bei Erläuterung und Beachten Sie stelle ich mir das Finden eines kurzen prägnanten Textes mindestens als schwer vor. Es soll ja auch nicht durch einen zu langen Text die TOC gesprengt werden.
Gibt es einen Zusatz (vielleicht ein nicht gelistetes Magic Word oder ähnliches), das eine Aufnahme in die TOC verhindert? Oder sollte man eine Überschrift vierter Ordnung nehmen, und die generell von der TOC-Erstellung ausschließen? In solchen Fällen generell die TOC zu deaktivieren kann sicher nicht die Lösung sein.

Wie wäre es, "Erläuterung" wegzulassen und den Text ohne Zwischenüberschrift dem Beispiel folgen zu lassen. Solange kein neues Thema (gekennzeichnet durch eine neue Überschrift zweiter Ordnung) folgt, sollte man doch auch so davon ausgehen können, dass sich der dem Beispiel folgende Fließtext auf eben dieses Beispiel bezieht. Zudem bekommt man es auch nicht mit, wenn nach der Erläuterung des Beispiels "normaler Fließtext" folgt oder ob einfach nur in der Erläuterung ein neuer Absatz beginnt.
Alternativ könnte man die Beispiel-Box zu einem zweiteiligen Kasten erweitern, in dessen unterem Teil der Erläuterungstext steht. Allerdings finde ich ein Übermaß an Boxen auch nicht gerade übersichtsfördernd, so dass mein Votum dem Fließtext gilt, besonders wenn man noch "Beachten Sie" in die Betrachtung einbezieht.

Für ein "Beachten Sie" plädiere ich für eine Vorlagen-Box, da solch ein Text eine Hervorhebung verdient.

Insgesamt sollten die Boxen meiner Meinung nach aber eher eine dezente, dem restlichen Design angepasste Farbgebung bekommen und eine "knalligere" Farbe solchen Boxen wie der ToDo und anderen Meta-Hinweisen vorbehalten bleiben.

Lo!

  1. Gibt es einen Zusatz (vielleicht ein nicht gelistetes Magic Word oder ähnliches), das eine Aufnahme in die TOC verhindert? Oder sollte man eine Überschrift vierter Ordnung nehmen, und die generell von der TOC-Erstellung ausschließen? In solchen Fällen generell die TOC zu deaktivieren kann sicher nicht die Lösung sein.

    In der Wikipedia gibt es Vorlagen zu Überschriftensimulation - diese werden, weil keine echten Überschriften, nicht ins TOC aufgenommen, sind aber ansonsten gleichwertig.

    http://de.wikipedia.org/wiki/Vorlage:Überschriftensimulation_1 usw.

    Wie wäre es, "Erläuterung" wegzulassen und den Text ohne Zwischenüberschrift dem Beispiel folgen zu lassen.

    Wie wäre es, eine vorlage für "Erläuterung" und "Beispiel" zu erstellen, damit es später einfacher wird, den Begriff überall auszutauschen?

    Weiters möchte ich anmerken: die Doppelpunkte nach den Überschriften gehören nicht in den Inhalt sondern ins CSS :)

    1. http://de.wikipedia.org/wiki/Vorlage:Überschriftensimulation_1 usw.

      Nachtrag: die sollte man natürlich nur 1:1 übernehmen, weil sie hardcodiert auf das default-Skin angepasst sind, das ist natürlich uncool :)

    2. Hi!

      In der Wikipedia gibt es Vorlagen zu Überschriftensimulation - diese werden, weil keine echten Überschriften, nicht ins TOC aufgenommen, sind aber ansonsten gleichwertig.
      http://de.wikipedia.org/wiki/Vorlage:Überschriftensimulation_1 usw.
      die sollte man natürlich nur 1:1 übernehmen, weil sie hardcodiert auf das default-Skin angepasst sind, das ist natürlich uncool :)

      Dann müsste jemand die Stylesheets erweitern: h3, div.h3 {...}
      Solche Simulationen sind sicher keine schlechte Idee für allgemeine noch nicht vorhersehbare Zwecke, wo die Erstellung einer speziellen Vorlage unsinnig/unnötig erscheint.

      Wie wäre es, "Erläuterung" wegzulassen und den Text ohne Zwischenüberschrift dem Beispiel folgen zu lassen.
      Wie wäre es, eine vorlage für "Erläuterung" und "Beispiel" zu erstellen, damit es später einfacher wird, den Begriff überall auszutauschen?

      Und damit bei Bedarf auch die Formatierung. Dass ich für das Beispiel eine Vorlage (dargestellt als Box) bevorzuge, sagte ich ja schon, mein Punkt hier bei der Erläuterung war eher der, ob man diese Zwischenüberschrift ganz einsparen kann.

      Weiters möchte ich anmerken: die Doppelpunkte nach den Überschriften gehören nicht in den Inhalt sondern ins CSS :)

      Nää, dagegen! Dann braucht man nämlich noch eine Unterscheidung zwischen Überschriften mit Doppelpunkten und welchen ohne. Lieber ganz weglassen, sie bringen keine Vorteile.

      Lo!

      1. Nää, dagegen! Dann braucht man nämlich noch eine Unterscheidung zwischen Überschriften mit Doppelpunkten und welchen ohne. Lieber ganz weglassen, sie bringen keine Vorteile.

        Wer auf Doppelpunkte abfährt, kann sie ohnehin in seinen Nutzerstylesheet (in MediaWiki ja problemlos möglich) einfügen.

        1. Hello,

          Wer auf Doppelpunkte abfährt, kann sie ohnehin in seinen Nutzerstylesheet (in MediaWiki ja problemlos möglich) einfügen.

          *aaahhh*
          Jetzt weiß ich endlich, wofur die Doppelpunkte im Macho-Net stehen
          Darauf fahre ich natürlich total ab :-))

          Dann muss ich mir wohl mal ein paar "Nutzer-Style-Shirts" anschaffen.

          *scnr*
          Liebe Grüße aus dem schönen Oberharz

          Tom vom Berg

          --
           ☻_
          /▌
          / \ Nur selber lernen macht schlau
          http://bergpost.annerschbarrich.de
      2. Hallo,

        Weiters möchte ich anmerken: die Doppelpunkte nach den Überschriften gehören nicht in den Inhalt sondern ins CSS :)
        Nää, dagegen! Dann braucht man nämlich noch eine Unterscheidung zwischen Überschriften mit Doppelpunkten und welchen ohne. Lieber ganz weglassen, sie bringen keine Vorteile.

        hinter einer echten Überschrift hat ein Doppelpunkt IMO nichts verloren! Ein Doppelpunkt steht nach der Ankündigung einer Aufzählung oder nach einem Präfix wie "Beachten Sie". Aber sobald diese Textteile einen Doppelpunkt bekommen, sind sie nach meiner Einschätzung keine Überschriften mehr, sondern gehören zum Fließtext (und gehören somit auch nicht in ein TOC).

        So long,
         Martin

        --
        Die letzten Worte der Challenger-Crew:
        Lasst doch mal die Frau ans Steuer!
  2. Hi!

    Damit man sich das was mir so vorschwebt auch mal betrachten kann, habe ich einen Layout-Vorschlag erstellt, aus dem man die Vorlagen bilden kann.

    Lo!

    1. Damit man sich das was mir so vorschwebt auch mal betrachten kann, habe ich einen Layout-Vorschlag erstellt, aus dem man die Vorlagen bilden kann.

      +1 by reading

      Sollte aber auf eine Vorlage umgebaut werden, die den Wiki-Parser fürden Code-Bereich verwendet (vorangestelltes Leerzeichen muss manuell gesetzt werden). Weiteres sollte die Vorlage über eine Editsection verfügen, damit der die Bereiche direkt bearbeitet werden können.

      Syntax:
      {{Beispiel|Erklärung|
       // code goes here
      }}

      {{Beachten Sie|Erklärung}}

      1. Hi!

        Sollte aber auf eine Vorlage umgebaut werden, die den Wiki-Parser fürden Code-Bereich verwendet (vorangestelltes Leerzeichen muss manuell gesetzt werden).

        Momentan hab ich den Code-Bereich in <nowiki> eingerahmt. Das dürfte weniger gut sein, weil man nun keine Styles oder sonstige Wiki-Features verwenden kann, richtig? Mit vorangestelltem Leerzeichen fügt es aber einen Code-Block ein, inklusive Formatierung mit eigenem Kasten drum und eingerückt. Das beißt sich ja dann mit meinem Layout-Vorschlag.

        Weiteres sollte die Vorlage über eine Editsection verfügen, damit der die Bereiche direkt bearbeitet werden können.

        Was genau meinst du mit Editsection? Fügt man nicht einfach anstelle von "Erklärung" und "// code goes here" seinen Text ein und fertig ist?

        Syntax:
        {{Beispiel|Erklärung|
        // code goes here
        }}

        {{Beachten Sie|Erklärung}}

        "Erklärung" wäre dann der Fließtext in der Box, beziehungsweise beim Beispiel in der unteren Box? Wenn ja, müsste die Beispiel-Erklärung dem Code folgen, was ja aber nicht das Problem sein sollte.

        Lo!

        1. Hi!

          Sollte aber auf eine Vorlage umgebaut werden, die den Wiki-Parser fürden Code-Bereich verwendet (vorangestelltes Leerzeichen muss manuell gesetzt werden).

          Momentan hab ich den Code-Bereich in <nowiki> eingerahmt. Das dürfte weniger gut sein, weil man nun keine Styles oder sonstige Wiki-Features verwenden kann, richtig? Mit vorangestelltem Leerzeichen fügt es aber einen Code-Block ein, inklusive Formatierung mit eigenem Kasten drum und eingerückt. Das beißt sich ja dann mit meinem Layout-Vorschlag.

          Ich war so frei und hab das mal als Vorlage gebaut - ohne nowiki wird ein Codebereich draus, allerdings mit Formatierung - die müsste man allgemein entfernen.

          Automatisch ein nowiki darumwickeln haben ich in der vorlage auch probiert, allerdings erzeugt der parser dann ein p-Element welches sich ebenfalls mit deiner Foramtierung beisst - wenigstens spart man sich aber das händische einrücken.

          In beiden Fällen muss das CSS angepasst werden.

          Was genau meinst du mit Editsection?

          Ein "knöpfchen" damit man nur diesen Abschnitt des Artikels (mit der Vorlage) bearbeiten kann - is bequemer. Ist aber scheinbar nicht Built-In und muss ergänzt werden in MediaWiki. Vergiss das vorerst.

          Fügt man nicht einfach anstelle von "Erklärung" und "// code goes here" seinen Text ein und fertig ist?

          Natürlich.

          "Erklärung" wäre dann der Fließtext in der Box, beziehungsweise beim Beispiel in der unteren Box? Wenn ja, müsste die Beispiel-Erklärung dem Code folgen, was ja aber nicht das Problem sein sollte.

          Ja, hab ich auch gerade gemerkt :)

          1. Hi!

            Ich war so frei und hab das mal als Vorlage gebaut - ohne nowiki wird ein Codebereich draus, allerdings mit Formatierung - die müsste man allgemein entfernen.

            Gut.

            Automatisch ein nowiki darumwickeln haben ich in der vorlage auch probiert, allerdings erzeugt der parser dann ein p-Element welches sich ebenfalls mit deiner Foramtierung beisst - wenigstens spart man sich aber das händische einrücken.

            <nowiki> kann nicht die Lösung sein, denn das Formatieren (besonders Färben) des Codes sollte schon gewährleistet sein.

            Was genau meinst du mit Editsection?

            Ein "knöpfchen" damit man nur diesen Abschnitt des Artikels (mit der Vorlage) bearbeiten kann - is bequemer. Ist aber scheinbar nicht Built-In und muss ergänzt werden in MediaWiki. Vergiss das vorerst.

            Ach der Bearbeiten-Link. Ich weißnicht, ich finder, der muss da nicht sein. Man kann ruhig den Abschnitt im Ganzen vor sich haben inklusive Beispiel- und Beachten-Sie-Boxen. Irgendwie gehört das ja alles zusammen, weswegen ich da gegen Beispiel und Beachten-Sie als Überschriften bin, schließlich sind diese Abschnitte vom Informationsgehalt quasi nicht allein lebensfähig.

            Lo!

            1. Gut.

              <nowiki> kann nicht die Lösung sein, denn das Formatieren (besonders Färben) des Codes sollte schon gewährleistet sein.

              Da sollte man ohnehin eine Plugin verwenden, welches den Code abfängt und an einen Highlighter weitergibt - GeSHi z.B.

              Ach der Bearbeiten-Link. Ich weißnicht, ich finder, der muss da nicht sein. Man kann ruhig den Abschnitt im Ganzen vor sich haben inklusive Beispiel- und Beachten-Sie-Boxen. Irgendwie gehört das ja alles zusammen, weswegen ich da gegen Beispiel und Beachten-Sie als Überschriften bin, schließlich sind diese Abschnitte vom Informationsgehalt quasi nicht allein lebensfähig.

              Bei umfangreicheren Artikel geht das aber auf den Traffic und der Inhalt des Quelltextfeldes wird teilweise relativ lang :) kleine Häppchen sind da angenehmer.

              Aber es funzt ohnehin nicht - mit einem simulierten Abschnitt zum Bearbeiten kann man die Vorlage bearbeiten :D

              1. Hi!

                <nowiki> kann nicht die Lösung sein, denn das Formatieren (besonders Färben) des Codes sollte schon gewährleistet sein.
                Da sollte man ohnehin eine Plugin verwenden, welches den Code abfängt und an einen Highlighter weitergibt - GeSHi z.B.

                Ja, schon, aber wir wollen ja hier nicht nur einfach Code zeigen, sondern oftmals anhand dieses Codes irgendetwas zeigen, so dass es in solchen Fällen von Vorteil ist, nicht nur eine automatische Färbung zu haben, sondern manuell eingreifen und hervorheben zu können. Siehe meine Färbung bei der HTML-Elemente-Verschachtlungs-Reihenfolge oder die Anführungszeichen-Markierung im Kontextwechsel-Artikel. In solchen Fällen würde eine automatische Färbung vielleicht sogar kontraproduktiv sein, weil sie die Aufmerksamkeit nicht gezielt lenken kann.

                Lo!

                1. Ja, schon, aber wir wollen ja hier nicht nur einfach Code zeigen, sondern oftmals anhand dieses Codes irgendetwas zeigen, so dass es in solchen Fällen von Vorteil ist, nicht nur eine automatische Färbung zu haben, sondern manuell eingreifen und hervorheben zu können. Siehe meine Färbung bei der HTML-Elemente-Verschachtlungs-Reihenfolge oder die Anführungszeichen-Markierung im Kontextwechsel-Artikel. In solchen Fällen würde eine automatische Färbung vielleicht sogar kontraproduktiv sein, weil sie die Aufmerksamkeit nicht gezielt lenken kann.

                  Verstanden - also das automatische nowiki-ing raus, das automatische umschließen mit einem code-Element bleibt aber?

                  1. Hi!

                    Verstanden - also das automatische nowiki-ing raus, das automatische umschließen mit einem code-Element bleibt aber?

                    Was hat das für Auswirkungen?

                    Irgendwie ist das momentan nicht zufriedenstellend. Du hast ja meinen Anwendungsversuch zu deiner Vorlage schon entdeckt. Aber mein Versuch mit

                    {{Beispiel|
                      Hier '''fetter''' und <span style="color:blue;">bunter</span> Code.
                      |Erklärung dazu}}

                    geht in die Hose, solange das <span> ein style-Attribut hat, denn das ergibt

                    Beispiel
                      Erklärung dazu
                      {{{2}}}

                    Gibt es dazu eine Erklärung, außer dass der Mediawiki-Code ... ?

                    Wenn man das <nowiki> weglässt, kann man zwar formatieren, aber keine Code-Einrückung nehmen, denn das erzeugt wegen den Leerzeichen am Anfang einen eigenen Block. Wenn man stattdessen geschützte Leerzeichen nimmt, leidet die Übersichtlichkeit des Code-Quelltextes enorm.

                    {{Beispiel|(ohne nowiki, dafür aber mit geschützten Leerzeichen (&nbsp;))
                    &lt;html>
                    &nbsp;&nbsp;&lt;head>
                    &nbsp;&nbsp;&nbsp;&nbsp;&lt;title>Beschreibung der Seite&lt;/title>
                    &nbsp;&nbsp;&lt;/head>
                    &nbsp;&nbsp;&lt;body>

                    &nbsp;&nbsp;&lt;/body>
                    &lt;/html>
                    |
                    Erläuterungstext
                    }}

                    Außerdem hätte ich gern eine trim()-Funktion in die Vorlage eingebaut, so dass man Zeilenumbrüche vor und nach den Abschnitt trennenden | einfügen kann, ohne dass sie im Ergebnis Leerraum hinterlassen.

                    Was gibt es denn da noch für Möglichkeiten?

                    Ich finde ja schon Wiki-Code schon nicht sehr angenehm. Wenn man den auch noch mit HTML-Code mischt und am Ende damit HTML-Code darstellen will, ist das syntaktische Chaos perfekt.

                    Lo!

                    1. Gibt es dazu eine Erklärung, außer dass der Mediawiki-Code ... ?

                      Ich hab keine Erklärung dafür, so genau hab' ich mir den Template-Parser noch nicht angesehen.

                      Was gibt es denn da noch für Möglichkeiten?

                      Ich würde das eben allgemein mit einem Plugin lösen

                      Außerdem hätte ich gern eine trim()-Funktion in die Vorlage eingebaut, so dass man Zeilenumbrüche vor und nach den Abschnitt trennenden | einfügen kann, ohne dass sie im Ergebnis Leerraum hinterlassen.

                      {{#if:1|{{{1|}}}}}

                      Ich finde ja schon Wiki-Code schon nicht sehr angenehm. Wenn man den auch noch mit HTML-Code mischt und am Ende damit HTML-Code darstellen will, ist das syntaktische Chaos perfekt.

                      Darum keinen HTML-Code verwenden :)

                      1. Hi!

                        Was gibt es denn da noch für Möglichkeiten?
                        Ich würde das eben allgemein mit einem Plugin lösen

                        Gut, kennst du da schon eins oder Seiten, wo man eins finden könnte? Ansonsten werde ich mich da mal auf die Suche nach einer Lösung begeben.

                        Außerdem hätte ich gern eine trim()-Funktion in die Vorlage eingebaut, so dass man Zeilenumbrüche vor und nach den Abschnitt trennenden | einfügen kann, ohne dass sie im Ergebnis Leerraum hinterlassen.

                        {{#if:1|{{{1|}}}}}

                        Sieht gut aus.

                        Ich finde ja schon Wiki-Code schon nicht sehr angenehm. Wenn man den auch noch mit HTML-Code mischt und am Ende damit HTML-Code darstellen will, ist das syntaktische Chaos perfekt.
                        Darum keinen HTML-Code verwenden :)

                        O.k., aber wie geht Bunt ohne style=...?

                        Lo!

                        1. Gut, kennst du da schon eins oder Seiten, wo man eins finden könnte? Ansonsten werde ich mich da mal auf die Suche nach einer Lösung begeben.

                          Das GeSHi-Plugin hab ich ja bereits verlinkt - ich denke nicht, dass ein eigenes Plugin so viel komplizierter wäre.

                          O.k., aber wie geht Bunt ohne style=...?

                          Da bin ich auch noch am rätseln - was mir aber nicht in den Schädel geht, warum der Parser streikt, sobald man ein span-Element mit style-Attribut einbaut.

                          1. Da bin ich auch noch am rätseln - was mir aber nicht in den Schädel geht, warum der Parser streikt, sobald man ein span-Element mit style-Attribut einbaut.

                            success:
                            http://wiki.selfhtml.org/wiki/Benutzer:Dedlfix/Strukturiervorlagenanwendung

                            Die Frage ist, ob man nun jetzt für die Farben eine Vorlage anlegt (namentlich) oder ob man ihnen generische Namen verpasst - z.B. "highlight1", "highlight2" usw.

                            1. Hi!

                              Die Frage ist, ob man nun jetzt für die Farben eine Vorlage anlegt (namentlich) oder ob man ihnen generische Namen verpasst - z.B. "highlight1", "highlight2" usw.

                              Ich habe eine allgemeine Farbvorlage erstellt und bin auch mit der Beispiel-Vorlage etwas weitergekommen, für die ich mir zum Testen eine eigene angelegt habe. Sieht nicht schlecht aus, finde ich. Jetzt hätte ich gern nur noch einen Ersatz für das <nowiki>. Mit schwebt da ein <nur_wiki_aber_kein_html> vor.

                              Lo!

                              1. Mit schwebt da ein <nur_wiki_aber_kein_html> vor.

                                wie wäre es mit "<htmlspecialchars />" oder "<cdata />" als pseudo-Element und ein kleines plugin, welches das übernimmt?

                                1. Hi!

                                  Mit schwebt da ein <nur_wiki_aber_kein_html> vor.
                                  wie wäre es mit "<htmlspecialchars />" oder "<cdata />" als pseudo-Element und ein kleines plugin, welches das übernimmt?

                                  Ja, ich werde mich mal schlau machen, wie man sowas erstellen kann. Im Grunde genommen muss/darf da ja nur Inline-Formatierung wirken. Block-Formatierung wie Listen und Leerzeichen am Anfang darf nicht wirken, das ist bei Code-Beispielen ja nicht nur unnötig sondern hinderlich.

                                  Lo!

                                  1. Ja, ich werde mich mal schlau machen, wie man sowas erstellen kann.

                                    Ich hab mir graden Code des GeSHi-Plugins angesehen - ich kann aber an keiner Stelle entdecken, warum die Vorlageneinbindung ignoriert wird.

                                    Im Grunde genommen muss/darf da ja nur Inline-Formatierung wirken. Block-Formatierung wie Listen und Leerzeichen am Anfang darf nicht wirken, das ist bei Code-Beispielen ja nicht nur unnötig sondern hinderlich.

                                    Im Grunde genommen muss nur sowas funktionieren - tut's aber nicht:

                                    {{Beispiel||
                                    <source lang="text">{{Farbe|red|<p>}}</p></source>
                                    |Das Start-Tag öffnet ein Element}}

    2. Damit man sich das was mir so vorschwebt auch mal betrachten kann, habe ich einen Layout-Vorschlag erstellt, aus dem man die Vorlagen bilden kann.

      Ein "Beachten Sie" sollte nicht wie eine knallrote giftige Beere aussehen. Das würde ich schon eher einem "Warning: Selfdestruktion within nexty 10 seconds" vorbehalten.

      Ein "beachten Sie" sollte visuell nicht die Strukturierung durch Überschriften demontieren. Angebrachter wäre hier wirklich:

      <strong>Beachten Sie:</strong> Hier steht etwas wichtiges aber nicht lebensgefährliches, als ein Absatz.

      mfg Beat

      --
      ><o(((°>           ><o(((°>
         <°)))o><                     ><o(((°>o
      Der Valigator leibt diese Fische
      1. Hi!

        Ein "Beachten Sie" sollte nicht wie eine knallrote giftige Beere aussehen. Das würde ich schon eher einem "Warning: Selfdestruktion within nexty 10 seconds" vorbehalten.

        Gut, je nach Gefährlichkeit kann man da ja andere Farben nehmen (nicht mehr als 2 oder 3, knallbunt ist auch doof). Vielleicht für das ungefährliche "Beachten Sie" einen freundlicheren Orange-Ton? Und das Rot für sicherheitskritische Dinge.

        Die Gestaltung in Boxen (zusätzlich zum Beispiel) sollte schon für einigermaßen wichtige Dinge vorbehalten sein. "Normale" Beschreibungen können in den Fließtext, da auch gern mit Zwischenüberschriften, wenn es sinnvoll ist. Die sollten aber etwas über den Inhalt sagen und auch in einem TOC eine gute Figur abgeben.

        Ein "beachten Sie" sollte visuell nicht die Strukturierung durch Überschriften demontieren.

        Naja, Beispiele stehen in Büchern in der Regel auch nicht in extra Kapiteln. Struktur bekommt man auch mit anderen Mitteln als Überschriften hin.

        Angebrachter wäre hier wirklich:
        <strong>Beachten Sie:</strong> Hier steht etwas wichtiges aber nicht lebensgefährliches, als ein Absatz.

        Gut, das wäre auch eine Möglichkeit, nur ein <strong> und die rote, sicherheitskritische Box. Andererseits, was ist denn zwar beachtenswert, aber dann doch wieder so unwichtig, dass man es auch überlesen kann?

        Lo!

        1. Gut, das wäre auch eine Möglichkeit, nur ein <strong> und die rote, sicherheitskritische Box. Andererseits, was ist denn zwar beachtenswert, aber dann doch wieder so unwichtig, dass man es auch überlesen kann?

          Ist es nicht so, dass das "Beachten Sie" im Grunde auf jeden Buchstaben der Web-Gesetze anzuwenden ist?
          Aber nicht alles ist gleich wichtig (einflussreich).
          Zum Beispiel verdient der Einfluss, der eine DOCTYPE Angabe auf die CSS Interpretation ausübt, der Hervorhebung. Aber irgendwelche Details wie ein Browser dies nun handhabt, dann wiederum nicht.

          Die Lösung wäre visuell, dass man mit Eye-Candy (zum Beispiel ein Icon) arbeitet, statt dem Auge ermüdende gleichartige Boxen vorzusetzen.

          mfg Beat

          --
          ><o(((°>           ><o(((°>
             <°)))o><                     ><o(((°>o
          Der Valigator leibt diese Fische
          1. Hi!

            Die Lösung wäre visuell, dass man mit Eye-Candy (zum Beispiel ein Icon) arbeitet, statt dem Auge ermüdende gleichartige Boxen vorzusetzen.

            Ist ein Argument. Um auch wichtige Dinge, die über mehrere Absätze gehen, kennzeichnen zu können, kann man ja eine Einrückung vornehmen und einen (unaufdringlichen) Streifen am linken Rand platzieren

            Lo!

            1. Hi!

              Die Lösung wäre visuell, dass man mit Eye-Candy (zum Beispiel ein Icon) arbeitet, statt dem Auge ermüdende gleichartige Boxen vorzusetzen.

              Ist ein Argument. Um auch wichtige Dinge, die über mehrere Absätze gehen, kennzeichnen zu können, kann man ja eine Einrückung vornehmen und einen (unaufdringlichen) Streifen am linken Rand platzieren.

              Einen Vorschlag (ohne Icon) habe ich unterhalb der roten Beachten-Sie-Box angehängt.

              Lo!

              1. Droboy tume!

                Einen Vorschlag (ohne Icon) habe ich unterhalb der roten Beachten-Sie-Box angehängt.

                Gefällt mir sehr gut. Die würde ich wirklich für die üblichen »Beachten Sie«-Hinweise nehmen, wie z.B. »Browser xy versteht den Wert quz nicht«, und die auffälligere mit dem roten Rahmen für wirklich kritische Dinge wie »Browser xy stürzt in diesem Fall ab« oder Hinweise auf SQL-Injections o.ä.

                Viele Grüße vom Længlich

                --
                Mein aktueller Gruß ist:
                Romani (Sinti)
                1. Gefällt mir sehr gut. Die würde ich wirklich für die üblichen »Beachten Sie«-Hinweise nehmen, wie z.B. »Browser xy versteht den Wert quz nicht«, und die auffälligere mit dem roten Rahmen für wirklich kritische Dinge wie »Browser xy stürzt in diesem Fall ab« oder Hinweise auf SQL-Injections o.ä.

                  +1

                2. Hi!

                  Einen Vorschlag (ohne Icon) habe ich unterhalb der roten Beachten-Sie-Box angehängt.

                  Gefällt mir sehr gut. Die würde ich wirklich für die üblichen »Beachten Sie«-Hinweise nehmen, wie z.B. »Browser xy versteht den Wert quz nicht«, und die auffälligere mit dem roten Rahmen für wirklich kritische Dinge wie »Browser xy stürzt in diesem Fall ab« oder Hinweise auf SQL-Injections o.ä.

                  Es gibt jetzt eine Beachten-Sie-Vorlage für diese weniger kritischen Hinweise. Im Einsatz kann man sie sich auf jenen Seiten ansehen.

                  Auch die Beispiel-Vorlage habe ich noch ein wenig verfeinert und dokumentiert. (Seiten, die sie verwenden) Hinzugekommen ist eine optionale Titel-Ergänzung, so dass das Wort Beispiel in der oberen Zeile um eine Kurzinformation ergänzt werden kann. Außerdem ist der Erläuterungstext optional.

                  Lo!

                  1. Arru!

                    Es gibt jetzt eine Beachten-Sie-Vorlage für diese weniger kritischen Hinweise. Im Einsatz kann man sie sich auf jenen Seiten ansehen.

                    Auch die Beispiel-Vorlage habe ich noch ein wenig verfeinert und dokumentiert. (Seiten, die sie verwenden) Hinzugekommen ist eine optionale Titel-Ergänzung, so dass das Wort Beispiel in der oberen Zeile um eine Kurzinformation ergänzt werden kann. Außerdem ist der Erläuterungstext optional.

                    Prima! Dann werde ich mich als nächstes dranmachen, den border-Artikel damit zu überarbeiten. Zuerst hatte ich ihn nur übernommen und dabei die Hinweise auf Netscape 4 gekickt und den outline-Teil in einen eigenen Artikel ausgelagert. Da fehlen aber noch die ganzen Beispiele, ordentliche Formatierung, und die ganzen neuen Sachen wie border-radius, border-image, outline-offset usw.
                    Ich hoffe, ich habe am Sonntag genug Zeit dafür.

                    Viele Grüße vom Længlich

                    --
                    Mein aktueller Gruß ist:
                    Arabunna (gesprochen in Australien)
                    1. Prima! Dann werde ich mich als nächstes dranmachen, den border-Artikel damit zu überarbeiten.

                      Ich kümmer mich am Wochenende weiter um den Listen-Artikel.

                      Was mir aufgefallen ist - die Konsistenz bei den Überschriften mangelt etaws:

                      list-style-type (Darstellungstyp)

                      und

                      Rahmendicke (border[-top, -right, -bottom, -left]-width)

                      Ist bei den alten Artikeln aber auch nicht anders - gibts hier schon eine Richtline ob die Eigenschaft oder die beschreibung vorne stehen soll? Wenn nicht, meine stimme für "Eigenschaft zuerst".

                      1. Ka fo!

                        Was mir aufgefallen ist - die Konsistenz bei den Überschriften mangelt etaws:

                        list-style-type (Darstellungstyp)

                        und

                        Rahmendicke (border[-top, -right, -bottom, -left]-width)

                        Ist bei den alten Artikeln aber auch nicht anders - gibts hier schon eine Richtline ob die Eigenschaft oder die beschreibung vorne stehen soll? Wenn nicht, meine stimme für "Eigenschaft zuerst".

                        Hast recht, das ist mir auch aufgefallen. Ob »list-style-type (Darstellungstyp)« oder »Darstellungstyp (list-style-type)« ist mir offen gestanden schnuppe. Ich möchte aber gerne »[-top, -right, -bottom, -left]« rausschmeißen, da das IMHO zu chaotisch aussieht, und diese lieber als ersten Textabsatz dazuschreiben.

                        By the way, wie würdet Ihr border-radius übersetzen? »Rahmenradius« klingt bekloppt. »Rahmenabrundung«? Und für outline-radius dann entsprechend »Außenlinienabrundung«?

                        Viele Grüße vom Længlich

                        --
                        Mein aktueller Gruß ist:
                        Boboda (gesprochen in Burkina Faso und Mali)
                        1. Hi!

                          By the way, wie würdet Ihr border-radius übersetzen? »Rahmenradius« klingt bekloppt. »Rahmenabrundung«? Und für outline-radius dann entsprechend »Außenlinienabrundung«?

                          Bitte nicht übertreiben mit den Übersetzungen! border-radius ist meiner Meinung nach schon im Englischen ein nicht ganz eindeutig gewählter Begriff, denn es ist der Ecken-Radius und nicht der vom Rand im Allgemeinen. Das liegt sicher daran, dass man ihn namentlich in der Nähe der anderen border-Eigenschaften haben wollte. Ich würde einfach im Text beschreiben, was die Eigenschaft macht und dann hauptsächlich von der border-radius-Eigenschaft sprechen.

                          Lo!

                          1. Wemasoga!

                            By the way, wie würdet Ihr border-radius übersetzen? »Rahmenradius« klingt bekloppt. »Rahmenabrundung«? Und für outline-radius dann entsprechend »Außenlinienabrundung«?

                            Bitte nicht übertreiben mit den Übersetzungen! border-radius ist meiner Meinung nach schon im Englischen ein nicht ganz eindeutig gewählter Begriff, denn es ist der Ecken-Radius und nicht der vom Rand im Allgemeinen. Das liegt sicher daran, dass man ihn namentlich in der Nähe der anderen border-Eigenschaften haben wollte. Ich würde einfach im Text beschreiben, was die Eigenschaft macht und dann hauptsächlich von der border-radius-Eigenschaft sprechen.

                            Wenn es nach mir persönlich geht, können wir auf solche Übersetzungen zu 100% pfeifen und _immer_ den Eigenschaftennamen genau so verwenden, wie er in CSS heißt. Auf der anderen Seite soll das eben die _deutsch_sprachige Doku zu dem Thema werden, was dem zugegebenermaßen widerspricht.
                            Mir geht es hier jetzt um die Überschriften, die (zumindest nach dem derzeitigen Stand) immer den Original-CSS-Namen und eine deutsche Bezeichnung enthalten. Also müssen wir IMHO entweder dieses Schema aufgeben, oder die neuen Eigenschaften analog zu den bisherigen übersetzen – eine inkonsistente Mischung halte ich für die blödeste Option.

                            Für die Übersetzung in der Überschrift spricht, daß sich dann vermutlich auch Anfänger leichter zurechtfinden, die zwar wissen, was sie erreichen wollen, aber nicht, wie die passende Eigenschaft heißt. Im Text würde ich immer den Eigenschaftennamen verwenden, denn da (nach der Überschrift) kann man ja beide Varianten als bekannt voraussetzen.

                            Wenn wir übersetzen, sollten wir das aber auch ordentlich tun; deswegen meine Frage. Ich habe ja schon eigenmächtig den Begriff »Außenlinie« eingeführt, weil ich es sehr irritierend fand, daß »Rahmen« doppelt verwendet wurde.

                            Viele Grüße vom Længlich

                            --
                            Mein aktueller Gruß ist:
                            Njebi (gesprochen in Gabun)
                            1. Hi!

                              Wenn es nach mir persönlich geht, können wir auf solche Übersetzungen zu 100% pfeifen und _immer_ den Eigenschaftennamen genau so verwenden, wie er in CSS heißt. Auf der anderen Seite soll das eben die _deutsch_sprachige Doku zu dem Thema werden, was dem zugegebenermaßen widerspricht.
                              Mir geht es hier jetzt um die Überschriften, die (zumindest nach dem derzeitigen Stand) immer den Original-CSS-Namen und eine deutsche Bezeichnung enthalten. Also müssen wir IMHO entweder dieses Schema aufgeben, oder die neuen Eigenschaften analog zu den bisherigen übersetzen – eine inkonsistente Mischung halte ich für die blödeste Option.

                              Du hast Recht. Für die Überschriften, die ja kurz und prägnant sein sollen, sollten wir einen deutschen Begriff zum Thema finden. Ich schlage Eckenradius für border-radius vor. Es geht um die Ecken, also Ecken... Dass das die Ecke vom Rahmen ist, geht ja aus der übergeordneten Kapitelüberschrift (Rahmen) hervor. Ansonsten wäre da noch das sperrigere Rahmeneckenradius.

                              Lo!

                              1. Kiun jachšy!

                                Du hast Recht. Für die Überschriften, die ja kurz und prägnant sein sollen, sollten wir einen deutschen Begriff zum Thema finden. Ich schlage Eckenradius für border-radius vor. Es geht um die Ecken, also Ecken... Dass das die Ecke vom Rahmen ist, geht ja aus der übergeordneten Kapitelüberschrift (Rahmen) hervor. Ansonsten wäre da noch das sperrigere Rahmeneckenradius.

                                Streng genommen ist Radius ja auch falsch, denn man kann zwei angeben, also eine Viertelellipse für jede Ecke, und Ellipsen haben keine Radii, sondern Halbachsen. Also lautet die gesuchte Überschrift »Rahmeneckenellipsenhalbachsen«. :D

                                Naja, ich schwanke noch zwischen »Rahmenabrundung« und »Eckenradius«. Man wird sehen. Da ich nicht Gott bin, kann ich im Zweifel auch würfeln. ^^

                                Viele Grüße vom Længlich

                                --
                                Mein aktueller Gruß ist:
                                Karaim (gesprochen in Litauen und der Ukraïne)
                  2. Auch die Beispiel-Vorlage habe ich noch ein wenig verfeinert und dokumentiert.

                    Ich war so frei und hab die Doku überarbeitet, da sie noch Beispiele enthielt, die für die Vorlage in deinem Namensraum gedacht waren - zudem hab ich gleich Beispiele mit Vorschau eingefügt.

                    1. Hi!

                      Auch die Beispiel-Vorlage habe ich noch ein wenig verfeinert und dokumentiert.
                      Ich war so frei und hab die Doku überarbeitet, da sie noch Beispiele enthielt, die für die Vorlage in deinem Namensraum gedacht waren - zudem hab ich gleich Beispiele mit Vorschau eingefügt.

                      Sieht sehr schön aus, danke fürs Korrigieren.

                      Was mich jetzt noch stört ist das <nowiki>, das würde ich gern, wie schon erwähnt, noch gegen was anderes tauschen, das nur die Inline-Formatierung berücksichtigt, aber keine Blöcke erstellt. Denn das derzeitige mit display:block; zur Box erhobene <code> sorgt für Probleme, wenn darin Block-Elemente auftauchen. Die Lösung dazu wird vermutlich ein neues Tag werden, und dafür muss ich mir erst einmal Wissen aneignen. Das wird also vorläufig eine mindestens mittelfristige Baustelle bleiben.

                      Nun ist es noch so, dass der CSS-Code inline angegeben ist. Das hat zwar den unschlagbaren Vorteil, dass es jeder anpassen kann, muss aber stets für jede Anwendung neu übertragen werden. Wenn der CSS-Code ausgelagert wird, haben nach meinem Wissen nur noch Administratoren die Möglichkeit ihn zu ändern. Ich denke, das ist der Kompromiss, den man dabei eingehen muss. Zur Not kann man ja immer noch über Änderungswünsche diskutieren und im persönlichen Namensraum Ideen testen und präsentieren.

                      Lo!

                      1. Die Lösung dazu wird vermutlich ein neues Tag werden, und dafür muss ich mir erst einmal Wissen aneignen. Das wird also vorläufig eine mindestens mittelfristige Baustelle bleiben.

                        Natürlich, aber die aktuell Lösung sieht recht brauchbar aus - zudem hängt die mittelfristige Lösung ohnehin davon ab, wie die anklickbaren Quelltextbeispiele aussehen werden bzw. wie diese gewartet werden sollen. Wichtig ist ermal, dass überall diese Vorlage verwandt wird, damit sich dann spätere alles massenhaft ändern lässt.

                        Was mir allerdings etwas gegen den Strich geht, sind die Erläuterungen zum Code - wenn das länger wird, ist es schnell etwas unpraktisch, das beides gemeinsam in einer Vorlage zu haben. Die Sache ggf. doch unabhängig als eigenständigen Text außerhalb der Vorlage darunter zu platzieren ist ggf. sinnvoller (bzw. mit einer eigenen Vorlage für Erläuterungen).

                        1. Hi!

                          Was mir allerdings etwas gegen den Strich geht, sind die Erläuterungen zum Code - wenn das länger wird, ist es schnell etwas unpraktisch, das beides gemeinsam in einer Vorlage zu haben. Die Sache ggf. doch unabhängig als eigenständigen Text außerhalb der Vorlage darunter zu platzieren ist ggf. sinnvoller (bzw. mit einer eigenen Vorlage für Erläuterungen).

                          Ich denke, wir sollten erst einmal schauen, wie sich der Bedarf dazu entwickelt.

                          Lo!