Frage zum Wiki-Artikel „padding“

[nix]

inherit als Angabe zu padding ist anscheinend keineswegs erlaubt: padding inherit 10cm 50cm inherit wird hier ignoriert!

[Gunnar Bittersmann]

@@nix

inherit als Angabe zu padding ist anscheinend keineswegs erlaubt:

Natürlich ist es das.

padding inherit 10cm 50cm inherit wird hier ignoriert!

Das Schlüsselwort inherit darf in der Sammeleigenschaft padding aber nicht mit anderen Werten kombiniert werden.

Da müsstest du die Einzeleigenschaften padding-(top|right|bottom|left) bzw. padding-(block|inline)(-(start|end))? verwenden. Guckst du hier.

🖖 Живіть довго і процвітайте

[Rolf B]

Hallo nix,

Es steht auch im wiki, dass das nicht geht.

Und direkt bei inherit nochmal:

Hierzu wird einer Eigenschaft das Schlüsselwort „inherit“ (englisch: „erben“) als einziger Wert zugeordnet.

Ich mach das nachher mal fett. Aber das kann man nur zentral erklären, nicht in jeder einzelnen CSS Eigenschaft. Oder?

Rolf

[Auge]

Hallo

Es steht auch im wiki, dass das nicht geht.

Und direkt bei inherit nochmal:

Hierzu wird einer Eigenschaft das Schlüsselwort „inherit“ (englisch: „erben“) als einziger Wert zugeordnet.

Ich mach das nachher mal fett. Aber das kann man nur zentral erklären, nicht in jeder einzelnen CSS Eigenschaft. Oder?

Das ist mMn problematisch. Besucher kommen im Zweifelsfall über eine Suchmaschine direkt auf eine Seite mit der Beschreibung einer bestimmten Eigenschaft. Wenn dort nicht vermerkt ist, dass bestimmte Einschränkungen bestehen, werden sie es nicht erfahren.

Da die Doku mittlerweile an vielen Stellen sowieso eher einem Glossar entspricht ^[1], ist ein sich wiederholender Hinweis auf eine Einschränkung mMn kein Problem.

Tschö, Auge

---

1. Das ist eine Entwicklung weg von einer Beschreibenden Doku, die ich für einen Rückschritt halte ^[2]. ↩︎

2. Ich weiß, dass ich so gut wie nichts zur Doku beigetragen habe und daher das Maul nicht allzu weit aufreißen sollte. ↩︎

[Rolf B]

Hallo Auge,

Da die Doku mittlerweile an vielen Stellen sowieso eher einem Glossar entspricht…

Fußnoten zu Fußnoten, lieber Auge, du liest zu viele PTerry-Bücher 😉

Aber erklär bitte mal, wie Du das meinst.

Wenn es Dir darum geht, dass es grundsätzlich zwei Kategorien von Artikeln gibt, nämlich Referenz und Tutorial, dann könnte man höchstens darüber nachdenken, aus der Referenz heraus klarer auf die relevanten Tutorials zu verlinken. Im "Siehe auch" mag das untergehen.

Rolf

[Auge]

Hallo

Da die Doku mittlerweile an vielen Stellen sowieso eher einem Glossar entspricht…

Fußnoten zu Fußnoten, lieber Auge, du liest zu viele PTerry-Bücher 😉

Naja, viele Bücher, die ich noch nicht gelesen habe, sind nicht mehr übrig. Nachschub kommt ja nicht mehr. 😔

Aber erklär bitte mal, wie Du das meinst.

Früher™️ waren die Artikel zu HTML-Elementen oder CSS-Eigenschaften sehr viel beschreibender als heute. Heute muss ich nach der Lektüre von fast nichts ^[1] oft mehreren Links folgen, um mir die benötigten Infos zusammenzusuchen. Und oft ^[2] ist es dann erst der dritte oder vierte Link, der mich zur benötigten Zusatzinfo (zum Beispiel erlaubte Werte für Attribut XY) führt.

Die alte Doku mag in dieser Hinsicht sehr geschwätzig gewesen sein und diverse Infos wieder und wieder aufgeführt haben, aber dafür habe ich – im Normalfall – alle notwendigen Informationen auf einer Seite gefunden.

Heute sind solche ausführlicheren Texte in die Tutorials ausgelagert. Die sind aber an nicht wenigen Stellen nicht prominent verlinkt. Also suche ich nach Informationen über Attribut XY des Elements Z und muss dann, wenn ich Pech habe, noch einmal, von der Startseite des Bereichs aus aus, das passende Tutorial (auf)suchen.

Beispiel: Ich suche Informationen zu Werten in value eines input vom Typ date. Ich gehe in die HTML-Referenz und suche mir die Seite für input heraus. Um an die Attribute zu kommen, muss ich an den Zwischenüberschriften „Siehe auch“ und „Weblinks“ vorbeiscrollen um unter der letzteren die Liste der erlaubten Attribute zu finden ^[3]. Ich benutze den Link für das Attribut type. Dort finde ich eine Tabelle mit allen möglichen Werten in einer kommaseparierten Liste. Dann ist schluss. Ok, ich könnte dem Link zur MDN folgen oder dem, der mich zum Artikel für input zurück bringt. Aber weiter geht's nicht. Ich kann mich aber daran erinnern, dass es mal eine kurze Beschreibung jedes einzelnen möglichen Werts gab.

Ich vermute, dieser Inhalt ist in ein Tutorial eingegangen. Für mich ist er aber dorthin verschwunden, denn einen Link zum passenden Tutorial finde ich auf der Seite nicht und auch auf der Übersichtsseite der Tutorials zu Formularen finde ich erst auf den zweiten Blick eines, das mich anspringt und sagt „Hier findest du die von dir benötigten Infos!“. Wobei es mich äußerst verwirrt, dass ich dieses Tutorial zu input nicht unter der Überschrift „HTML/Tutorials/Formulare“ finde, sondern unter der Kette von der Zwischenüberschrift „Siehe auch“, über die Unterüberschrift „Tutorials“ zur Unterunterüberschrift „HTML“.

Das war jetzt nur ein Beispiel und ich habe die Doku nicht durchgeackert, um weitere solche oder auch Gegenbeispiele, bei denen die Wege sehr viel klarer sind, zu finden. Das ist auch nichts, was man mal so eben ändert, zumal wenn das einem einmal gefassten Konzept widerspricht oder man selbst dieses Konzept nicht in seinen Einzelheiten kennt. Ich denke, da gibt es Diskussions- und Änderungsbedarf.

Wenn es Dir darum geht, dass es grundsätzlich zwei Kategorien von Artikeln gibt, nämlich Referenz und Tutorial …

Ersetze bitte den von mir gewählten Begriff „Glossar“ durch „Referenz“. Das ist der viel besser passende Begriff, der mir vorhin nicht einfiel.

… dann könnte man höchstens darüber nachdenken, aus der Referenz heraus klarer auf die relevanten Tutorials zu verlinken. Im "Siehe auch" mag das untergehen.

Ja, ein Anfang wäre mMn, wenn Links zu Tutorials grundsätzlich einen beschreibenden Text haben, wie es beim Tutorial zu input unter „Siehe auch“ beim Link zu „Was ist ein Webformular?“ zu sehen ist ^[4]. Das ist zwar auch nicht ideal, weil für mich dieser Link als hierarchischer Unterpunkt des Links zu „HTML/Tutorials/Formulare“ ein wenig untergeht, aber besser als ein nackter Link, der „nur“ mit einem Seitentitel beschriftet ist, ist es allemal.

---

So, genug ausgekotzt. Bitte nicht falsch verstehen, ich benutze die Doku seit über 20 Jahren und im Prinzip immer noch gern, auch wenn sie für mich „nur noch“ andere Quellen flankiert. Manchmal scheitere ich halt an für mich ungeeignet aufbereiteten, aufgeteilten und sortierten Inhalten; beileibe nicht nur bei SelfHTML. Hier kann ich es aber ansprechen und mich dabei in meiner Muttersprache ausdrücken. Das ist immer noch ein sehr großer Pluspunkt.

Tschö, Auge

---

1. „Fast nichts“ im Sinne von sehr wenig zusätzlichen Infos, die auf den Seiten von Elementen oder Eigenschaften selbst zu finden sind. ↩︎

2. „Oft“ im Sinne von „machmal“, jedoch nicht im Sinne von „selten“. ↩︎

3. Das ist für mich eine unerwartete Stelle für diese Tabelle. ↩︎

4. Auch hier gilt, dass ich die Doku nicht akut durchgeschaut habe, um weitere und Gegenbeispiele zu finden. ↩︎

[Rolf B]

Hallo Auge,

bei input brauchst Du diesen Artikel: https://wiki.selfhtml.org/wiki/HTML/Tutorials/Formulare/input

Und ja, da müsste vielleicht bei den Referenzartikeln ganz oben ein Zusatzlink zu den Tutorials hin. Das ist dann wieder eine Fleißarbeit 😟

Rolf

[Matthias Scharwies]

Servus!

Hallo Auge,

Bin grad unterwegs, deshalb nur kurz:

Man bräuchte in der Referenz-Vorlage einen Parameter shorthand. Wenn der zutrifft, würde inherit durch einen Zusatz in Klammern ergänzt. Die „normalen“ Eigenschaften brauchen das nicht.

Und ja, da müsste vielleicht bei den Referenzartikeln ganz oben ein Zusatzlink zu den Tutorials hin. Das ist dann wieder eine Fleißarbeit 😟

Es spricht ja nichts dagegen, die Vorlage dahingehend zu ändern, dass der Inhalt von „Siehe auch“ z.B. oben rechts oder als <marquee blink> stünde.

Am Donnerstag mehr dazu!

Herzliche Grüße

Matthias Scharwies

[Matthias Scharwies]

Guten Morgen,

Früher™️ waren die Artikel zu HTML-Elementen oder CSS-Eigenschaften sehr viel beschreibender als heute.

Jein, ich hab' in der alten Doku geschaut. Da gab's bei CSS ein Intro und dann die Seiten mit allen Eigenschaften untereinander. Viel Beschreibung gab's da nicht. Treppenstufen durch floats ,bzw. den Clearfix gab's dann wohl nur im Forum.

Heute muss ich nach der Lektüre von fast nichts ^[1] oft mehreren Links folgen, um mir die benötigten Infos zusammenzusuchen. Und oft ^[2] ist es dann erst der dritte oder vierte Link, der mich zur benötigten Zusatzinfo (zum Beispiel erlaubte Werte für Attribut XY) führt.

Das war auch die Kritik an den beschreibenden Wiki-Seiten und sollte ja eigentlich mit den Referenzen gelöst worden sein.

Dort hat man im Idealfall eine kurze Beschreibung und dann die Attribute oder Werte aufgelistet.

Ein "Siehe_auch" leitet dann auf die Tutorials weiter. (sollte es jedenfalls)

So sollte eigentlich jede Seite aufgebaut sein:

Die alte Doku mag in dieser Hinsicht sehr geschwätzig gewesen sein und diverse Infos wieder und wieder aufgeführt haben, aber dafür habe ich – im Normalfall – alle notwendigen Informationen auf einer Seite gefunden.

Das wäre wünschenswert!

Heute sind solche ausführlicheren Texte in die Tutorials ausgelagert. Die sind aber an nicht wenigen Stellen nicht prominent verlinkt. Also suche ich nach Informationen über Attribut XY des Elements Z und muss dann, wenn ich Pech habe, noch einmal, von der Startseite des Bereichs aus aus, das passende Tutorial (auf)suchen.

Ich verspreche, dass ich noch mal durchgehe. Auch an anderer Stelle wurde gewünscht, die Links auf die Tutorials durch Teasertexte zu ergänzen.

Beispiel: Ich suche Informationen zu Werten in value eines input vom Typ date. Ich gehe in die HTML-Referenz und suche mir die Seite für input heraus.

Touché! Das input-Element mit seinen vielen Typen sprengt da die Ziele der Referenz!

Um an die Attribute zu kommen, muss ich an den Zwischenüberschriften „Siehe auch“ und „Weblinks“ vorbeiscrollen um unter der letzteren die Liste der erlaubten Attribute zu finden ^[3].

Das ist unschön. Als wir die oberen Parameter von Tabelle auf dl umgestellt hatten, blieb diese Tabelle unten. Das hab' ich grad gefixt - vor "Siehe auch"

Ich benutze den Link für das Attribut type. Dort finde ich eine Tabelle mit allen möglichen Werten in einer kommaseparierten Liste. Dann ist schluss.

Mist, nur ein l auf die Element-Referenz. Ich habe hier Links zu den entsprechenden Tutorials eingefügt.

Ich vermute, dieser Inhalt ist in ein Tutorial eingegangen. Für mich ist er aber dorthin verschwunden, denn einen Link zum passenden Tutorial finde ich auf der Seite nicht

Ja, schade! Ist hier gefixt - ich schau' die Tage, ob das noch woanders fehlt und trage das nach!

und auch auf der Übersichtsseite der Tutorials zu Formularen finde ich erst auf den zweiten Blick eines, das mich anspringt und sagt „Hier findest du die von dir benötigten Infos!“. Wobei es mich äußerst verwirrt, dass ich dieses Tutorial zu input nicht unter der Überschrift „HTML/Tutorials/Formulare“ finde, sondern unter der Kette von der Zwischenüberschrift „Siehe auch“, über die Unterüberschrift „Tutorials“ zur Unterunterüberschrift „HTML“.

Wir haben nach 2018 die vielen Einzeltutorials zu Kursen oder Reihen zusammengefügt. Spätestens bei 6-8 Kapiteln ist aber Schluss mit der Übersicht.

Da müsste hier stärker herausgearbeitet werden, dass …

a. HTML/Tutorials/Formulare erklärt, wie Formulare funktionieren und wie sie gestaltet werden

b. in HTML/Tutorials/Formulare/input die einzelnen Typen vorgestellt werden

Das war jetzt nur ein Beispiel und ich habe die Doku nicht durchgeackert, um weitere solche oder auch Gegenbeispiele, bei denen die Wege sehr viel klarer sind, zu finden.

Bitte helf' uns und tu das!

Das ist auch nichts, was man mal so eben ändert, zumal wenn das einem einmal gefassten Konzept widerspricht oder man selbst dieses Konzept nicht in seinen Einzelheiten kennt. Ich denke, da gibt es Diskussions- und Änderungsbedarf.

… dann könnte man höchstens darüber nachdenken, aus der Referenz heraus klarer auf die relevanten Tutorials zu verlinken. Im "Siehe auch" mag das untergehen.

Ja, ein Anfang wäre mMn, wenn Links zu Tutorials grundsätzlich einen beschreibenden Text haben, wie es beim Tutorial zu input unter „Siehe auch“ beim Link zu „Was ist ein Webformular?“ zu sehen ist ^[4]. Das ist zwar auch nicht ideal, weil für mich dieser Link als hierarchischer Unterpunkt des Links zu „HTML/Tutorials/Formulare“ ein wenig untergeht, aber besser als ein nackter Link, der „nur“ mit einem Seitentitel beschriftet ist, ist es allemal.

Ich glaube, dass das Konzept der „schnellen-Überblicksseiten“ und der darauf aufbauenden Tutorials-Reihen gut ist. Es muss halt immer wieder überprüft und vor allem auf gute Verlinkung geachtet werden!

---

So, genug ausgekotzt.

Tschö, Auge

Danke für die Rückmeldung! Du hast einen Fehler gefunden, den wegen Deines Feedbacks andere nicht mehr machen müssen!

Herzliche Grüße

Matthias Scharwies

---

1. „Fast nichts“ im Sinne von sehr wenig zusätzlichen Infos, die auf den Seiten von Elementen oder Eigenschaften selbst zu finden sind. ↩︎

2. „Oft“ im Sinne von „machmal“, jedoch nicht im Sinne von „selten“. ↩︎

3. Das ist für mich eine unerwartete Stelle für diese Tabelle. ↩︎

4. Auch hier gilt, dass ich die Doku nicht akut durchgeschaut habe, um weitere und Gegenbeispiele zu finden. ↩︎

[Auge]

Hallo

Früher™️ waren die Artikel zu HTML-Elementen oder CSS-Eigenschaften sehr viel beschreibender als heute.

Jein, ich hab' in der alten Doku geschaut. Da gab's bei CSS ein Intro und dann die Seiten mit allen Eigenschaften untereinander. Viel Beschreibung gab's da nicht. Treppenstufen durch floats ,bzw. den Clearfix gab's dann wohl nur im Forum.

Klar, die Beschreibung war, wenn nötig, lang aber auch mal kurz. Bei CSS wohl eher letzteres. Und dass solche Sachen wie die Float-Treppen „nur“ im Forum (beziehungsweise dessen Archiv) standen, sollte anhand des Umstands, dass sie erst in der praktischen Anwendung in Spezialfällen auftraten, nicht wundern.

Heute muss ich nach der Lektüre von fast nichts oft mehreren Links folgen, um mir die benötigten Infos zusammenzusuchen. Und oft ist es dann erst der dritte oder vierte Link, der mich zur benötigten Zusatzinfo (zum Beispiel erlaubte Werte für Attribut XY) führt.

Das war auch die Kritik an den beschreibenden Wiki-Seiten und sollte ja eigentlich mit den Referenzen gelöst worden sein.

Mir ist die Referenz in nicht wenigen Fällen zu kurz. Damit leben kann ich dennoch. Nur die richtigern Links mit einer verständlichen Benennung am richtigen Platz zu haben, halte ich für immens wichtig.

Dort hat man im Idealfall eine kurze Beschreibung und dann die Attribute oder Werte aufgelistet.

Ein "Siehe_auch" leitet dann auf die Tutorials weiter. (sollte es jedenfalls)

So sollte eigentlich jede Seite aufgebaut sein:

Prinzipiell sind sie das – Ausnahmen wie ein nach einer Bearbeitung am falschen Platz befindlicher Abschnitt ausgenommen.

Auch an anderer Stelle wurde gewünscht, die Links auf die Tutorials durch Teasertexte zu ergänzen.

Das hatte ich weiter unten ja auch angeregt. Wie lang so ein Teaser sein muss, sei mal dahingestellt. Ich vermute, meist reicht ein kurzer Satz.

und auch auf der Übersichtsseite der Tutorials zu Formularen finde ich erst auf den zweiten Blick eines, das mich anspringt und sagt „Hier findest du die von dir benötigten Infos!“. Wobei es mich äußerst verwirrt, dass ich dieses Tutorial zu input nicht unter der Überschrift „HTML/Tutorials/Formulare“ finde, sondern unter der Kette von der Zwischenüberschrift „Siehe auch“, über die Unterüberschrift „Tutorials“ zur Unterunterüberschrift „HTML“.

Wir haben nach 2018 die vielen Einzeltutorials zu Kursen oder Reihen zusammengefügt. Spätestens bei 6-8 Kapiteln ist aber Schluss mit der Übersicht.

Was ich ansprechen wollte, war der Umstand, dass es unterhalb der Struktur „HTML/Tutorials/Formulare“ die Überschriftenstruktur „Siehe auch“=>„Tutorials“=>„HTML“ gibt, die einem Teil der Struktur Hauptüberschrift ähnelt. Das war für mich verwirrend.

Da müsste hier stärker herausgearbeitet werden, dass …

a. HTML/Tutorials/Formulare erklärt, wie Formulare funktionieren und wie sie gestaltet werden

b. in HTML/Tutorials/Formulare/input die einzelnen Typen vorgestellt werden

Keine Ahnung, ob man die Siehe-auch-Sektion durchgängig in Links mit direktem Bezug zum aktuell geladenen Dokument und weiteren Links mit indirektem Bezug gliedern kann, ohne andere Nutzergruppen zu verwirren.

Das war jetzt nur ein Beispiel und ich habe die Doku nicht durchgeackert, um weitere solche oder auch Gegenbeispiele, bei denen die Wege sehr viel klarer sind, zu finden.

Bitte helf' uns und tu das!

Das werde ich ohne Gewähr auf Vollständigkeit (😉) tun.

---

So, genug ausgekotzt.

Danke für die Rückmeldung! Du hast einen Fehler gefunden, den wegen Deines Feedbacks andere nicht mehr machen müssen!

Na denn … 😀

Tschö, Auge

[nix]

Es steht da? Nun, man muß da schon drüber nachdenken — und es danach doch noch mal ausprobieren. Mir ist bei dem Text jedenfalls nicht gerade klar, daß z. B. ein padding: 20px 3em 2cm 10% nicht durch ein padding: inherit 1em inherit 1cm (oder wie auch immer) „beerbt werden kann“.

[Rolf B]

Hallo nix,

wenn da steht

• 1 bis 4 Längen
• 1 bis 4 Prozente
• inherit

Dann ist das mistverständlich!? Hm...

Rolf

[Gunnar Bittersmann]

@@Rolf B

wenn da steht

• 1 bis 4 Längen
• 1 bis 4 Prozente
• inherit

Dann ist das mistverständlich!?

Das nicht, aber richtig ist es auch nicht.

Man kann ja auch Längen und Prozente mischen: padding: 2em 20% 0 2px.

Und außer inherit sind noch etliche andere Schlüsselwörter erlaubt.

🖖 Живіть довго і процвітайте

[Rolf B]

Hallo Gunnar,

ja, die Mischmöglichkeit muss ich einbauen.

Inherit nehme ich raus, denn das wird eh durch die Vorlage eingesteuert.

Rolf

[nix]

Abgesehen von den Werten: was sieht da nicht nach einem klaren Erbverhältnis aus:

.Opa { padding: Wert1 Wert2 Wert3 Wert4; }
.Kid { padding: Wert5 inherit inherit Wert6; }

Wert5 überschr…übe? Wert1, Wert6 den Wert4 — und Wert2 und Wert3 würden geerbt. Aber das CSS-Erbschaftsrecht spielt halt nicht mit.

[Rolf B]

Hallo nix,

Aber das CSS-Erbschaftsrecht spielt halt nicht mit.

Das Erbschaftsrecht schon, aber die CSS Syntax nicht. Bei Padding mag es noch funktionieren, es gibt aber auch Sammeleigenschaften, wo die Reihenfolge der Elemente variiert werden kann und dann weißt Du nicht mehr, wofür inherit steht. Deshalb hat die Spec dort nur ein "erbe alles – oder nichts" vorgesehen.

Einzelvermächtnisse sind dennoch möglich, man muss sie nur einzeln aufführen. Musst Du beim Notar auch. Klar, es ist umständlicher, aber es ist – denke ich – ein seltener Anwendungsfall und die CSS Autoren dürften da die 80/20 Regel angewendet haben: Die letzten 20% des Funktionsumfangs (alle Sonderlocken und Spezialfälle) machen 80% der Entwicklungsarbeit aus. Heißt: Wenn es einen Weg gibt, die Spezialfälle durch einfachere Konstrukte zu ersetzen, sollte man das tun.

.Opa {
   padding: Wert1 Wert2 Wert3 Wert4;
}
.Kid {
  padding-top: Wert5;
  padding-left: Wert6;
}

Rolf

[nix]

Ja, ich hab’s jetzt schon verstanden: inherit gilt nicht für einzelne Werte sondern für den ganzen Sazt von Eigenschaften, die davon ggf. betroffen sind.

Und: das/mein Verständnisproblem ist, ein Wenig, der optischer Gestaltungen von Aufstellungen geschuldet, die, wie z. B. in diesem Fall: meint die erste Zeile mit „1 bis 4“ alle nachfolgenden Optionen, ist die Aufstellung eine „oder“-Aufstellung (und ist dann ein „normales“ oder ein mathematisches Oder gemeint), sind es nur optisch zwei Zeilen, denen ihre Box nun mal einen Zeilenumbruch aufgezwungen hat …?

[Rolf B]

Hallo nix,

ja gut. Hast Du einen Vorschlag, wie man das besser layouten könnte?

Kleine Schwierigkeit: Der Teil ab "Vererbung steuernde Werte" wird von der Vorlage eingesteuert. Im Artikel steht das nicht. Und nun hat man manche Eigenschaften, wo für die Werte eine Auflistung gemacht wird, und andere, wo das nicht der Fall ist. Deshalb kann dieser Vererbungsanhang nicht grundsätzlich als Listenelement formatiert werden, und auf einen Schalter in der Vorlage, mit dem man den Anhang wahlweise als Liste formulieren könnte, hab ich auch keine Lust. Mediawiki-Vorlagen sind ein exquisites Spielzeug für Masochisten.

Rolf

[nix]

Einen Vorschlag? Na ja, einen kleinen. Mit etwas Schielen auf Dinge, die mehr aus der Vergangenheit bekannt sind, vielleicht nicht gleich bis auf die einzelnen Zeichen heruntergebrochen … und einer leicht zu findenden Legende, damit man querlesen kann.

Damit wäre zumindest klar, daß das zu Lesende nicht beliebiger Text sein kann. Beliebiger Text bringt ja schon, gleich an der ersten Ecke, Probleme wie „ist das oder jetzt „if(a) return 1; if(b) return 1;“ oder „if(a) return(!b); return(b);“ – ist es jetzt … oder? Ab in die Rekursion!

Oder, damit es mehr ins Auge sticht: optisch vom Rest abheben. Eine Art auf die Seite gelegtes Diagramm? Man steigt links ein und nur Wege, die nach rechts durchgegangen werden können, liefern zueinander passende, gemeinsam verwendbare, Optionen.

[Rolf B]

Hallo nix,

Backus Naur haben wir bisher eigentlich vermieden, weil es sehr abstrakt ist. Ich würde dann eher die Notation verwenden, die in den Specs verwendet wird (was ein modifiziertes BN ist).

Eisenbahndiagramme (railroad diagrams), wie sie bspw. Douglas Crockford in "JavaScript, the good parts" verwendet, sind auch eine Möglichkeit. Aber dafür müsste ich mir die Finger wundmalen…

Nassi Shneidermänner hab ich 1988 in meiner Abschlussprüfung malen müssen. Sind DIE tatsächlich ideal für Syntaxdiagramme? Hmmm.

Ich thematisiere das mal beim nächsten Stammtisch. Wenn Du so nett bist wie in diesem Thread, bist Du ebenfalls herzlich willkommen 😉

Rolf

[nix]

Nun, BNF hätte ich ja auch nicht bis auf die einzelnen Zeichen heruntergebrochen sehen wollen. Da verläuft man sich dann ja auch. Und so richtig malen? Nein, es sollte schon einigermaßen einfacher Code sein, der das bewerkstelligt. Und die „nassen Schneider“? Wie schon geschrieben, „auf links gedreht“ (aber nicht wie es die Schneider den Waschmaschinen empfehlen) und mit Gruppierungen und schrägen Linien eine optische Unterstreichung für, vmtl. hauptsächlich, eine Art switch(parameter) case(value) dies case(valueset) das … Einfach dem Auge eine kleine Unterstützung geben, so daß man beim Stöbern in den einzelnen Ausführungen nicht die Orientierung verliert.

Ah: so ähnlich wie beim case-Beispiel, nur die Blöcke nicht mit (so viel) Treppe drin.

Von den da erwähnten Editoren würde sich wg. JS sbide fast aufdrängen wollen – und die Leute da könnten, würde ich meinen, Hilfe beim HTML brauchen: “please check the …” Aua, meine Augen! Mixed Pixel (Layout oder so). Vielleicht doch Struktog mit Python und wenig Hilfsbedürfnis? Aber: wer programmiert das um? (Doch die Hilfsbedürftigen?) Denn soweit ich das auf die Schnelle gesehen habe: einen HTML-Output haben die, wenn überhaupt, dann versteckt.