commandref_join: Fehler bei Prüfung auf "negative tagcount"

[Thorsten Pferdekaemper]

Hi,
ich glaube, die Prüfung auf "negative tagcount" in commandref_join.pl ist nicht ganz korrekt. Das hier wird bei mir angemeckert:

Code Auswählen Erweitern


<div style="padding-left:2em">
Im Flex-Layout passen sich die Zellen in Position und Breite an den vorhandenen Platz an. D.h. die Oberfl&auml;che sieht auf verschiedenen Ger&auml;ten
[...]
nach untereinander angeordnet. D.h. die Zellen &auml;ndern sowohl ihre Breite als auch ihre Position.<br>
</div>

Wenn ich aber die style-Angabe aus dem <div> rausnehme, dann gibt die Prüfung Ruhe. Kann es sein, dass davon ausgegangen wird, dass die Tags keine Attribute haben?
Gruß,
   Thorsten

[CoolTux]

Hi,
ich glaube, die Prüfung auf "negative tagcount" in commandref_join.pl ist nicht ganz korrekt. Das hier wird bei mir angemeckert:

Code Auswählen Erweitern


<div style="padding-left:2em">
Im Flex-Layout passen sich die Zellen in Position und Breite an den vorhandenen Platz an. D.h. die Oberfl&auml;che sieht auf verschiedenen Ger&auml;ten
[...]
nach untereinander angeordnet. D.h. die Zellen &auml;ndern sowohl ihre Breite als auch ihre Position.<br>
</div>

Wenn ich aber die style-Angabe aus dem <div> rausnehme, dann gibt die Prüfung Ruhe. Kann es sein, dass davon ausgegangen wird, dass die Tags keine Attribute haben?
Gruß,
   Thorsten

Versuche mal bitte

Code Auswählen Erweitern


<div />


[Thorsten Pferdekaemper]

Versuche mal bitte

Code Auswählen Erweitern


<div />


Das verstehe ich jetzt nicht. Warum? Oben gehört das nicht hin, da ich ja noch Text zwischen den Anfang und das Ende schreiben will. ...und unten gehört das auch nicht hin, da ich dort einen schließendes </div> brauche.
Gruß,
   Thorsten

[CoolTux]

Das ist eine Form eines schließenden divs.
Ich glaube mich zu erinnern das selbe Problem gehabt zu haben und es so gelöst zu haben. Konnte glaube mein Modul damals nicht einchecken deswegen.

[CoolTux]

OK habe es gefunden. Es war das Weather Modul und zwar der table Tag. Müsste ich mit <table/> schließen wegen der Option beim <table.....>

[HeikoGr]

Versuche mal bitte

Code Auswählen Erweitern


<div />


"<div />" wäre m.E. auch definitv falsch gewesen, da es eine kurzschreibweise für <div></div> ist. Es würde also immer noch der schließende Tag vom oberen <div> fehlen.

[Thorsten Pferdekaemper]

Das ist eine Form eines schließenden divs.

Nein, ist es nicht. Das hat bei Dir wahrscheinlich deswegen funktioniert, weil "<div />" einfach ein leeres Div ist. D.h. es ist dasselbe wie <div></div>. Da gibt es für den Browser nichts anzuzeigen. Du hättest genauso das schließende Tag einfach löschen können. Natürlich schlägt da die "negative"-Prüfung nicht mehr zu, aber richtig wird es dadurch nicht.
Der Browser ergänzt dann automatisch die schließenden Tags am Ende oder halt da wo es einigermaßen passt.

"<div />" wäre m.E. auch definitv falsch gewesen, da es eine kurzschreibweise für <div></div> ist. Es würde also immer noch der schließende Tag vom oberen <div> fehlen.

Genau. Dafür gibt es aber anscheinend in der commandref_join.pl keine Prüfung. Die wäre auch gar nicht so einfach, da man dann tatsächlich auch die Tags mit "/>" und solche, die kein schließendes brauchen (wie <br>, <p>) behandeln müsste.

Gruß,
   Thorsten

[rudolfkoenig]

Kann es sein, dass davon ausgegangen wird, dass die Tags keine Attribute haben?

Ja, das ist sogar Absicht, weil vor Jahren manche Module angefangen haben Abschnitte farbig zu markieren, oder bestimmte Fonts zu verwenden, statt sowas dem CSS zu ueberlassen.
Wenn Styling im Modul festgeschrieben ist, dann kann man die Doku nicht ordentlich mit verschiedenen Styles betrachten.

[Thorsten Pferdekaemper]

Ja, das ist sogar Absicht, weil vor Jahren manche Module angefangen haben Abschnitte farbig zu markieren, oder bestimmte Fonts zu verwenden, statt sowas dem CSS zu ueberlassen.
Wenn Styling im Modul festgeschrieben ist, dann kann man die Doku nicht ordentlich mit verschiedenen Styles betrachten.

Ok, das ist zumindest mal ein sinnvolles Argument, auch wenn es schöner wäre, wenn die Prüfung dann das anmeckert und nicht ein </div> zu viel, welches es definitiv nicht gibt. Aber das ist dann ja nicht so wichtig, wenn man's weiß.
Allerdings...
Ich habe das mit dem style=... deshalb gemacht, weil ich keine andere "schöne" Möglichkeit gefunden habe, meinen Text zu strukturieren. Ich habe es erst mit <ul>, <li> und Ähnlichem probiert, aber das fügt für meinen Geschmack manchmal zu viel Platz ein. Außerdem ist die "Device specific help" nicht konsistent mit dem, was direkt bei den set/get bzw. Attributen angezeigt wird. Ich könnte es ja noch verstehen, wenn bei set/get/Attribut das ganze mehr "condensed" angezeigt wird, aber das Gegenteil ist der Fall.

Gibt es denn einen "style Guide" oder so etwas, wo beschrieben wird, welche Tags man für was verwenden soll/darf? (In https://wiki.fhem.de/wiki/Guidelines_zur_Dokumentation habe ich dazu nichts gefunden.) Z.B. welche Elemente soll man für Listen, eingerückte Texte, Hervorhebungen etc. nehmen?

Gruß,
   Thorsten

[rudolfkoenig]

Die richtige Loesung ist den Schluesselwort class zuzulassen, und in jedem der Styles (.css Dateien) dafuer zu sorgen, dass diese passend formatiert werden.
Jetzt fehlt nur noch jemand, der das alles definiert und umsetzt.

Ich biete an, class per commandref*.pl zuzulassen, und fertige CSS-Anweisungen in den von mir gepflegten Styles (f18 und default) einzubauen.
Jemand sonst muss die benoetigten Klassen und deren CSS Anweisungen definieren.

[Thorsten Pferdekaemper]

Hi,
ich glaube, dass man das nicht einmal bräuchte. Es gibt ja z.B. mit Sachen wie <h3>, <ul>, <li>, <dl>, <dt>, <dt>, <b> etc. schon so ziemlich alles, was man eigentlich braucht. Man müsste vielleicht nur mal darauf achten, dass die verschiedenen Tags auch überall dieselbe Wirkung haben.
Ich schaue mir das mal genauer an und mache dann ggf. einen Vorschlag oder schreibe etwas detaillierter auf, was mich stört.
Gruß,
   Thorsten

[Thorsten Pferdekaemper]

Hi,
wie versprochen...

Als erstes würde ich mir wünschen, dass commandref_join.pl in so einem Fall nicht "negative tagcount" ausgibt, sondern so etwas wie "tags with attributes are not allowed". Ansonsten sucht man erst einmal, wo denn da ein </div> zu viel sein soll.

Das zweite betrifft das <ul>. Ich weiß, dass es nicht wirklich korrekt ist, aber ich habe mir das bei anderen Modulen abgeschaut. Wenn man etwas eingerückt haben will, kann man <ul> verwenden, aber kein <li> innerhalb, sondern einfach normalen Text. Also in etwa so:

Code Auswählen Erweitern


<li><a name="layout">layout</a>: Grundlegendes Seitenlayout (Gridster oder Flexbox)<br>
Das Attribut <code>layout</code> kann zwei Werte annehmen: "gridster" oder "flex". Der Defaultwert ist "gridster".<br>
<b>Gridster-Layout</b><br>
<ul>
Im Gridster-Layout haben die einzelnen Zellen eine fixe Gr&ouml;&szlig;e und Position. D.h. die Oberfl&auml;che sieht auf jedem Ger&auml;t gleich aus und passt sich im Prinzip nicht an das Browserfenster an. (Au&szlig;er ggf. einem Zoomfaktor, der durch die Attribute <code>viewportInitialScale</code> und <code>viewportUserScalable</code> beeinflussbar ist.)
</ul>

In der "device specific help" sieht das dann auch ganz gut aus, aber in der Hilfe zum Attribut selbst werden dann Leerzeilen eingefügt, was mir nicht wirklich gefällt. (Siehe die beiden Screenshots.)
Deshalb habe ich hier mit div und style gearbeitet:

Code Auswählen Erweitern

<div style="padding-left:2em"> Das ist meiner Meinung nach "richtiger" und wird immer gleich gerendert.
Gruß,
   Thorsten

[rudolfkoenig]

Als erstes würde ich mir wünschen, dass commandref_join.pl in so einem Fall nicht "negative tagcount" ausgibt, sondern so etwas wie "tags with attributes are not allowed". Ansonsten sucht man erst einmal, wo denn da ein </div> zu viel sein soll.

Eingebaut. Deckt etlich Problemfaelle auf, die trickreiche Autoren damit kaschieren, dass sie das dazugehoerige End-Tag weglassen.
Ich bitte um Feedback: falls keine Einwaende, wuerde ich das auch beim pre-commit einbauen, um das Einchecken zu verhindern.

Das ist meiner Meinung nach "richtiger" und wird immer gleich gerendert.

Das stimmt sicher in diesem Fall, ich bin aber dafuer, dass wir solche Probleme sammeln, und nicht individuell mit style loesen, sondern mit CSS und class.

[Beta-User]

Ich bitte um Feedback: falls keine Einwaende, wuerde ich das auch beim pre-commit einbauen, um das Einchecken zu verhindern.

An sich gerne, ich habe nur die Befürchtung, dass ich mit zu den "trickreichen" gehöre (eher aus Unkenntnis und das Problem ggf. nur "geerbt" habe; v.a. die .*Timer-Module dürften da zu überarbeiten sein) und daraus dann Probleme entstehen, weil man Knall auf Fall nicht mehr Fixe einchecken kann und erst mal den Teil bereinigen muß.
Wäre es möglich, da sowas wie eine Vorwarnzeit vorzusehen? (Die Prüfung vorher schon mal ohne Not machen zu können, wäre auch nicht schlecht... Zusammen mit Guidelines, wie es besser geht...)

[rudolfkoenig]

Dann warte ich mit dem pre-commit, die Warnungen kann man mit perl contrib/commandref_join.pl anschauen.
Wg. "Guidelines": wir muessen Problemfaelle identifizieren, und dafuer in der .css Datei eine passende Klasse anlegen, die man vom Doku referenzieren kann.