Hi,
ich glaube, die Prüfung auf "negative tagcount" in commandref_join.pl ist nicht ganz korrekt. Das hier wird bei mir angemeckert:
<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äche sieht auf verschiedenen Geräten
[...]
nach untereinander angeordnet. D.h. die Zellen ä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
Zitat von: Thorsten Pferdekaemper am 14 November 2019, 22:19:22
Hi,
ich glaube, die Prüfung auf "negative tagcount" in commandref_join.pl ist nicht ganz korrekt. Das hier wird bei mir angemeckert:
<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äche sieht auf verschiedenen Geräten
[...]
nach untereinander angeordnet. D.h. die Zellen ä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
<div />
Zitat von: CoolTux am 14 November 2019, 22:27:53
Versuche mal bitte
<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
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.
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.....>
Zitat von: CoolTux am 14 November 2019, 22:27:53
Versuche mal bitte
<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.
Zitat von: CoolTux am 14 November 2019, 22:34:31
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.
Zitat von: HeikoGr am 15 November 2019, 08:37:36
"<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
ZitatKann 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.
Zitat von: rudolfkoenig am 15 November 2019, 09:11:55
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
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.
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
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:
<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öße und Position. D.h. die Oberfläche sieht auf jedem Gerät gleich aus und passt sich im Prinzip nicht an das Browserfenster an. (Auß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:
<div style="padding-left:2em"> Das ist meiner Meinung nach "richtiger" und wird immer gleich gerendert.
Gruß,
Thorsten
ZitatAls 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.
ZitatDas 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.
Zitat von: rudolfkoenig am 20 November 2019, 20:16:05
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...)
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.
Thx. Bei "meinen" Modulen war übrigens doch nichts auffälliges dabei, aber da kommt mindestens ein Autor, der derzeit auch häufige updates eincheckt...
Mal schauen, vielleicht kann ich die gesparte Zeit ja nutzen für einen patch :) .
Ansonsten scheint das Problem nicht zu groß zu sein, da sind bei den Warnungen auch ein paar Module bei, bei denen schon länger nichts passiert ist. Vielleicht würde es Sinn machen, dazu eine Ankündigung zu machen mit z.B. 3 Wochen, um das zu fixen?
So Ihr lieben nun komme ich mal dazu mir meine Sachen an zu schauen. Mein Problem
<table border="1">
Wie kann ich sowas verwenden ohne eine Fehlermeldung zu bekommen?
ZitatWie kann ich sowas verwenden ohne eine Fehlermeldung zu bekommen?
Man wandelt es um in sowas wie <table class="XXX">, wobei XXX nicht die Realisierung, sondern den Anwendungsfall beschreibt.
Der Style-Maintainer muss die Klasse XXX in der .css Datei passend gestalten.
Wir sollten irgendwo (hier?) die Klassennamen festlegen.
Hallo Rudi
Heist also das ich da aktuell gar nichts machen kann?
Grüße
Doch, uns verraten, warum man border="1" braucht, dafuer einen Klassennamen erfinden, und border="1" durch class="XXX" austauschen.
Zitat von: rudolfkoenig am 24 November 2019, 19:30:10
Doch, uns verraten, warum man border="1" braucht, dafuer einen Klassennamen erfinden, und border="1" durch class="XXX" austauschen.
Es sah schick aus mit border=1 ;D Ich schaue mal ob es anders geht.
@cooltux
weil du weather erwähnst: das kam beim gestrigen update. Nicht tragisch, aber schon ein vorher noch nicht gesehener kleiner "Erschrecker" während eines Updates (noch dazu kam es nicht so hübsch eingeordnet wie jetzt und auch noch andersfarbig) ;)
2019.12.04 18:42:36 1: Calling /usr/bin/perl ./contrib/commandref_join.pl -noWarnings, this may take a while
2019.12.04 18:45:44 1: *** EN SISPM line 543: div with attributes (apart from class) is not allowed
2019.12.04 18:45:44 1: *** EN Weather line 991: table with attributes (apart from class) is not allowed
2019.12.04 18:45:44 1: *** EN Weather line 1019: table with attributes (apart from class) is not allowed
2019.12.04 18:45:44 1: *** EN Weather line 1033: table with attributes (apart from class) is not allowed
2019.12.04 18:45:44 1: *** EN WifiLight line 3975: table with attributes (apart from class) is not allowed
2019.12.04 18:45:44 1: *** DE Weather line 1165: table with attributes (apart from class) is not allowed
2019.12.04 18:45:44 1: *** DE Weather line 1195: table with attributes (apart from class) is not allowed
2019.12.04 18:45:44 1: *** DE Weather line 1210: table with attributes (apart from class) is not allowed
2019.12.04 18:45:44 1: *** DE WifiLight line 4620: table with attributes (apart from class) is not allowed
Steht auf meiner Liste ;)
Ab sofort beachtet commandref_join.pl die noWarnings Option bei dieser Meldung
Sobald CoolTux seine Änderungen drin hat, wäre die Frage, ob man den precommit-hook scharf schaltet, oder?
Ansonsten sind es nur noch ganz überwiegend Module, die schon länger nicht mehr im svn updates erfahren haben, die noch Meldungen werfen...
Und ab sofort ist die Pruefung aktiviert im SVN pre-commit :)