Tags in der Doku

[rudolfkoenig]

Es ist mir gerade aufgefallen, dass ab dem Modul Plugwise die Doku eingerueckt ist, ganz am Ende schaut es ganz schlimm aus. Ich vermute, dass dafuer offene <table> Tags verantwortlich sind. Ich habe deswegen das SVN pre-commit und contrib/commandref_join.pl mit den tags td/tr/table erweitert, man bekommt beim Aufruf von commandref_join.pl jetzt folgendes:

Code Auswählen Erweitern

EN FHEM/95_Alarm.pm: Unbalanced tr (-1, last line ok: 856)
EN FHEM/57_Calendar.pm: Unbalanced table (-3, last line ok: 1259)
EN FHEM/98_CustomReadings.pm: Unbalanced tr (1, last line ok: 163)
EN FHEM/98_CustomReadings.pm: Unbalanced td (3, last line ok: 163)
EN FHEM/36_EC3000.pm: Unbalanced tr (1, last line ok: 187)
EN FHEM/36_EC3000.pm: Unbalanced td (1, last line ok: 187)
EN FHEM/36_EMT7110.pm: Unbalanced tr (1, last line ok: 232)
EN FHEM/36_EMT7110.pm: Unbalanced td (1, last line ok: 232)
EN FHEM/36_EleroDrive.pm: Unbalanced tr (1, last line ok: 290)
EN FHEM/36_EleroDrive.pm: Unbalanced td (1, last line ok: 290)
EN FHEM/72_FB_CALLLIST.pm: Unbalanced tr (1, last line ok: 1041)
EN FHEM/72_FB_CALLLIST.pm: Unbalanced td (-3, last line ok: 1061)
EN FHEM/72_FB_CALLMONITOR.pm: Unbalanced tr (1, last line ok: 1746)
EN FHEM/72_FB_CALLMONITOR.pm: Unbalanced td (1, last line ok: 1746)
EN FHEM/36_LaCrosse.pm: Unbalanced tr (1, last line ok: 547)
EN FHEM/36_LaCrosse.pm: Unbalanced td (1, last line ok: 547)
EN FHEM/36_Level.pm: Unbalanced tr (1, last line ok: 208)
EN FHEM/36_Level.pm: Unbalanced td (1, last line ok: 208)
EN FHEM/00_MAXLAN.pm: Unbalanced tr (1, last line ok: 868)
EN FHEM/00_MAXLAN.pm: Unbalanced td (1, last line ok: 868)
EN FHEM/36_PCA301.pm: Unbalanced tr (1, last line ok: 291)
EN FHEM/36_PCA301.pm: Unbalanced td (1, last line ok: 291)
EN FHEM/73_PRESENCE.pm: Unbalanced tr (1, last line ok: 1059)
EN FHEM/73_PRESENCE.pm: Unbalanced td (1, last line ok: 1059)
EN FHEM/45_Plugwise.pm: Unbalanced tr (1, last line ok: 1372)
EN FHEM/45_Plugwise.pm: Unbalanced td (1, last line ok: 1372)
EN FHEM/40_RFXCOM.pm: Unbalanced tr (1, last line ok: 381)
EN FHEM/40_RFXCOM.pm: Unbalanced td (1, last line ok: 381)
EN FHEM/51_RPI_GPIO.pm: Unbalanced table (-4, last line ok: 705)
EN FHEM/49_SSCam.pm: Unbalanced table (2, last line ok: 1517)
EN FHEM/49_SSCam.pm: Unbalanced td (8, last line ok: 1520)
EN FHEM/34_SWAP.pm: Unbalanced tr (1, last line ok: 1261)
EN FHEM/34_SWAP.pm: Unbalanced td (1, last line ok: 1261)
EN FHEM/35_SWAP_0000002200000003.pm: Unbalanced tr (1, last line ok: 385)
EN FHEM/35_SWAP_0000002200000003.pm: Unbalanced td (1, last line ok: 385)
EN FHEM/35_SWAP_0000002200000008.pm: Unbalanced tr (1, last line ok: 78)
EN FHEM/35_SWAP_0000002200000008.pm: Unbalanced td (1, last line ok: 78)
EN FHEM/42_SYSMON.pm: Unbalanced table (-1, last line ok: 5074)
EN FHEM/42_SYSMON.pm: Unbalanced td (-66, last line ok: 4982)
EN FHEM/45_TRX.pm: Unbalanced tr (1, last line ok: 411)
EN FHEM/45_TRX.pm: Unbalanced td (1, last line ok: 411)
EN FHEM/73_km200.pm: Unbalanced td (-28, last line ok: 2985)
EN FHEM/95_remotecontrol.pm: Unbalanced td (-1, last line ok: 409)
DE FHEM/57_Calendar.pm: Unbalanced table (-3, last line ok: 1465)
DE FHEM/72_FB_CALLLIST.pm: Unbalanced tr (1, last line ok: 1237)
DE FHEM/72_FB_CALLLIST.pm: Unbalanced td (-3, last line ok: 1258)
DE FHEM/72_FB_CALLMONITOR.pm: Unbalanced tr (1, last line ok: 1897)
DE FHEM/72_FB_CALLMONITOR.pm: Unbalanced td (1, last line ok: 1897)
DE FHEM/98_HMinfo.pm: Unbalanced tr (1, last line ok: 2888)
DE FHEM/98_HMinfo.pm: Unbalanced td (1, last line ok: 2888)
DE FHEM/73_PRESENCE.pm: Unbalanced tr (1, last line ok: 1302)
DE FHEM/73_PRESENCE.pm: Unbalanced td (1, last line ok: 1302)
DE FHEM/51_RPI_GPIO.pm: Unbalanced table (-4, last line ok: 898)
DE FHEM/42_SYSMON.pm: Unbalanced table (-1, last line ok: 5736)
DE FHEM/42_SYSMON.pm: Unbalanced td (-66, last line ok: 5644)
DE FHEM/73_km200.pm: Unbalanced td (-28, last line ok: 3176)
DE FHEM/95_remotecontrol.pm: Unbalanced td (-1, last line ok: 495)

Ich moechte die Verantwortlichen bitten, das entsprechend zu fixen. Generell moechte ich bitten von Tabellen, soweit moeglich, Abstand zu halten, da es auf kleineren Bildschirmen zu Problemen fuehrt.

[Markus Bloch]

funktioniert das auch mit Argumenten in den Tags?

Code Auswählen Erweitern

<table class="...">

<td colspan="2">

Momentan kann ich FB_CALLLIST deswegen nicht einchecken, obwohl die Tags alle richtig sind.

Gruß
Markus

[rudolfkoenig]

Mag sein, dass das nicht tut, allerdings sollten solche "Features" eh nicht verwendet werden.
Urspruenglich sollte die Doku "pod" sein.

[Markus Bloch]

Du redest im Konjunktiv. Heist das, es soll irgendwann auf Pod umgestellt werden oder nicht mehr (aufgrund der Vielzahl)?

Ich glaube jedenfalls nicht, dass ich der einzige bin, der ein Tag mit Argumenten in der commandref hat. Ich schlage daher angehangene Änderung vor.

Gruß
Markus

[rudolfkoenig]

Heist das, es soll irgendwann auf Pod umgestellt werden

Nein, urspruenglich war pod geplant, aber wir haben dann HTML beschlossen.

Ich glaube jedenfalls nicht, dass ich der einzige bin, der ein Tag mit Argumenten in der commandref hat.

DAS ist kein Grund. Ich habe das "Problem" vor (gefuehlt) 2 Jahren beim UL schon unterbunden, weil manche Autoren angefangen haben mit Farben zu experimentieren, und das wurde mir zu bunt. Ich haette gerne nur Text, mit so wenig Dekorationen wie moeglich. Ich lass mich natuerlich ueberstimmen, aber nur mit sinnvollen Argumenten.

[DS_Starter]

Hallo Rudi,

habe die Doku von SSCam gefixt und eingecheckt.

Grüße
Heiko

[betateilchen]

Ich haette gerne nur Text, mit so wenig Dekorationen wie moeglich.

Meine vollste Unterstützung für diesen Wunsch!

[Dr. Boris Neubert]

Hallo Rudi,

in commandref_join muss Zeile 94 so was wie

Code Auswählen Erweitern

          $tagcount{$tag} +=()= ($l =~ /<$tag( [^>])*>/gi);

sein, damit auch öffnende Tags mit Attributen erkannt werden (ungetestet).

Grüße
Boris

[rudolfkoenig]

DAS ist mir schon klar, es geht in dieser Diskussion gerade darum, dass ich keine Attribute sehen will.

Sonst fangen die Leute mit "style='color:light-blue;font-size:48px'" und Vergleichbares an. Das habe ich fuer ul vor (gefuehlt) 2 Jahren einmal schon unterbunden, jetzt folgte nur table & co, da ich damals nicht auf die Idee kam, das man table in der Doku verwenden koennte.

[Dr. Boris Neubert]

Für mich sind Tabellen mit Rahmendeutlich besser lesbar als Tabellen ohne Rahmen und diese sind deutlich besser lesbar als Listen.

[justme1968]

eigentlich ist das ja ein typischer anwendungsfall für die trennung von inhalt und darstellung.

ob die tabelle farben und schnörkelchen hat sollte der anwender per stylesheet entscheiden dürfen.

ob es eine tabele gibt der entwickler/erstellter.

wie wäre es eine hand voll css klassen vorzugeben und als einziges zu erlauben?

damit könnte man auch lange beispiele aus- und einblenden.

[Dr. Boris Neubert]

Finde ich gut!

Brauchen wir für die Doku dann eigene Klassen für Tabellen, Listen, ...? Derzeit wir mMn ja schon das Stylesheet drübergezogen, dass für FHEMWEB auch sonst verwendet wird.

[herrmannj]

find ich auch gut. Das mit den vorgegeben Klassen und auch ein- und ausblenden. Der Profi schaut auf die man page type doku und der ambitionierte Anwender findet zusätzlichen Input.

vg
joerg

[betateilchen]

Damit macht man meines Erachtens das Erstellen der commandref-Teilen innerhalb eines Moduls gerade für neue Entwickler noch schwieriger als es bisher schon ist.

Ausserdem machen die Klassen keinerlei Sinn, wenn man "help <command>" in telnet verwendet. Was dann wieder an Klimmzügen notwendig wird, um die Attribute wieder wegzuregexen, mag ich mir heute nicht vorstellen.

[justme1968]

warum macht man es einem einsteiger schwerer wenn man ihm eine hand voll feste regeln vorgibt?

gerade dann sind die klassen sinnvoll weil dann eben keine formatierungs anweisungen/attribute entfernt werden müssen sondern nur ein einziges class attribut mit fest erlaubtem inhalt.

natürlich ist es etwas aufwändiger als 7bit ascii. aber aus der zeit sind wir inzwischen raus.

[betateilchen]

wenn man ihm eine hand voll feste regeln vorgibt?

Weil sich in fhem schon jetzt kaum jemand (nichtmal altgediente Entwickler!) an bereits seit langem geltende, simpelste Regeln hält. Bestes Beispiel: Die von Rudi festgelegte 80-Zeichen Begrenzung in CHANGED.

[justme1968]

weil man diese festen regeln dann im commit überprüfen kann. das wäre für die 80 zeichen übrigens auch besser als sich jedes mal drüber zu ärgern.

[betateilchen]

es steht Dir frei, einen entsprechenden pre-commit hook bereitzustellen, den Rudi dann sicher gerne einbaut.

[Markus Bloch]

Anbei ein Patch um die 80 chars/line Regel auf gewünschte Files zu prüfen (aktuell nur CHANGED). Allerdings ungetestet.

Viele Grüße

Markus

[rudolfkoenig]

@Markus: Danke, habs eingecheckt, aktiviert, gefixt, dann einige uralte CHANGED Zeilen gefixt, und dann nochmal eingecheckt.

[hexenmeister]

könnt mich hauen, aber ich sehe keinen Fehler...
In dieser Tabelle (war im SYSMON-Doku) sollen table und td 'unbalanced' sein.

Code Auswählen Erweitern

EN FHEM/42_SYSMON.pm: Unbalanced table (-1, last line ok: 4693)
EN FHEM/42_SYSMON.pm: Unbalanced td (-66, last line ok: 4443)

Aber wo?? Nach dem Entfernen zweier solchen Tabellen (DE und EN) konnte ich einchecken...
Bin ich blind, oder hat die Prüfmmethode einen Fehler?

Code Auswählen Erweitern

      <table style="border: 1px solid black;">
         <tr>
            <td style="border-bottom: 1px solid black;">
               <div>cpu_freq</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>900</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>2013-11-27 00:05:36</div>
            </td>
         </tr>
         <tr>
            <td style="border-bottom: 1px solid black;">
               <div>cpu_temp</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>49.77</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>2013-11-27 00:05:36</div>
            </td>
         </tr>
         <tr>
            <td style="border-bottom: 1px solid black;">
               <div>cpu_temp_avg</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>49.7</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>2013-11-27 00:05:36</div>
            </td>
         </tr>
         <tr>
            <td style="border-bottom: 1px solid black;">
               <div>eth0</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>RX: 2954.22 MB, TX: 3469.21 MB, Total: 6423.43 MB</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>2013-11-27 00:05:36</div>
            </td>
         </tr>
         <tr>
            <td style="border-bottom: 1px solid black;">
               <div>eth0_diff</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>RX: 6.50 MB, TX: 0.23 MB, Total: 6.73 MB</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>2013-11-27 00:05:36</div>
            </td>
         </tr>
         <tr>
            <td style="border-bottom: 1px solid black;">
               <div>fhemuptime</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>11231</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>2013-11-27 00:05:36</div>
            </td>
         </tr>
         <tr>
            <td style="border-bottom: 1px solid black;">
               <div>fhemuptime_text&nbsp;&nbsp;</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>0 days, 03 hours, 07 minutes</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>2013-11-27 00:05:36</div>
            </td>
         </tr>
         <tr>
            <td style="border-bottom: 1px solid black;">
               <div>idletime</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>931024 88.35 %</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>2013-11-27 00:05:36</div>
            </td>
         </tr>
         <tr>
            <td style="border-bottom: 1px solid black;">
               <div>idletime_text</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>10 days, 18 hours, 37 minutes (88.35 %)</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>2013-11-27 00:05:36</div>
            </td>
         </tr>
         <tr>
            <td style="border-bottom: 1px solid black;">
               <div>loadavg</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>0.14 0.18 0.22</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>2013-11-27 00:05:36</div>
            </td>
         </tr>
         <tr>
            <td style="border-bottom: 1px solid black;">
               <div>ram</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>Total: 485 MB, Used: 140 MB, 28.87 %, Free: 345 MB</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>2013-11-27 00:05:36</div>
            </td>
         </tr>
         <tr>
            <td style="border-bottom: 1px solid black;">
               <div>swap</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>n/a</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>2013-11-27 00:05:36</div>
            </td>
         </tr>
         <tr>
            <td style="border-bottom: 1px solid black;">
               <div>uptime</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>1053739</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>2013-11-27 00:05:36</div>
            </td>
         </tr>
         <tr>
            <td style="border-bottom: 1px solid black;">
               <div>uptime_text</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>12 days, 04 hours, 42 minutes</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>2013-11-27 00:05:36</div>
            </td>
         </tr>
         <tr>
            <td style="border-bottom: 1px solid black;">
               <div>wlan0</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>RX: 0.00 MB, TX: 0.00 MB, Total: 0 MB</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>2013-11-27 00:05:36</div>
            </td>
         </tr>
         <tr>
            <td style="border-bottom: 1px solid black;">
               <div>wlan0_diff</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>RX: 0.00 MB, TX: 0.00 MB, Total: 0.00 MB</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>2013-11-27 00:05:36</div>
            </td>
         </tr>
         <tr>
            <td style="border-bottom: 1px solid black;">
               <div>fs_root</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>Total: 7404 MB, Used: 3533 MB, 50 %, Available: 3545 MB at /</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>2013-11-27 00:05:36</div>
            </td>
         </tr>
         <tr>
            <td style="border-bottom: 1px solid black;">
               <div>fs_boot</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>Total: 56 MB, Used: 19 MB, 33 %, Available: 38 MB at /boot</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>2013-11-27 00:05:36</div>
            </td>
         </tr>
         <tr>
            <td style="border-bottom: 1px solid black;">
               <div>fs_usb1</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>Total: 30942 MB, Used: 6191 MB, 21 %, Available: 24752 MB at /media/usb1&nbsp;&nbsp;</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>2013-11-27 00:05:36</div>
            </td>
         </tr>
         <tr>
            <td style="border-bottom: 1px solid black;">
               <div>stat_cpu</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>10145283 0 2187286 90586051 542691 69393 400342&nbsp;&nbsp;</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>2013-11-27 00:05:36</div>
            </td>
         </tr>
         <tr>
            <td style="border-bottom: 1px solid black;">
               <div>stat_cpu_diff</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>2151 0 1239 2522 10 3 761&nbsp;&nbsp;</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>2013-11-27 00:05:36</div>
            </td>
         </tr>
         <tr>
            <td style="border-bottom: 1px solid black;">
               <div>stat_cpu_percent</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>4.82 0.00 1.81 93.11 0.05 0.00 0.20&nbsp;&nbsp;</div>
            </td>
            <td style="border-bottom: 1px solid black;">
               <div>2013-11-27 00:05:36</div>
            </td>
         </tr>
         <tr>
            <td>
               <div>stat_cpu_text</div>
            </td>
            <td>
               <div>user: 32.17 %, nice: 0.00 %, sys: 18.53 %, idle: 37.72 %, io: 0.15 %, irq: 0.04 %, sirq: 11.38 %&nbsp;&nbsp;</div>
            </td>
            <td>
               <div>2013-11-27 00:05:36</div>
            </td>
         </tr>
      </table>

[Markus Bloch]

siehe Zitat:

DAS ist mir schon klar, es geht in dieser Diskussion gerade darum, dass ich keine Attribute sehen will.

Sonst fangen die Leute mit "style='color:light-blue;font-size:48px'" und Vergleichbares an. Das habe ich fuer ul vor (gefuehlt) 2 Jahren einmal schon unterbunden, jetzt folgte nur table & co, da ich damals nicht auf die Idee kam, das man table in der Doku verwenden koennte.

<td>, <table>, <tr> dürfen keine Attribute haben.

[hexenmeister]

Aha!  Danke!

[Sailor]

Moin zusammen

<td>, <table>, <tr> dürfen keine Attribute haben.

Aha! Danke!

Gruss
    Sailor

[Dr. Boris Neubert]

Hallo,

irgendwie war doch hier die vorherrschende Meinung, dass wir in der commandref Attribute in Tags erlauben sollen. Dann kam aber keine Aktion mehr dazu.

Die Unbalanced-Meldungen können m.E. so nicht bleiben, zumal sie dem Anwender bei jedem Update angezeigt werden.

Viele Grüße
Boris

[betateilchen]

Die Unbalanced-Meldungen können m.E. so nicht bleiben, zumal sie dem Anwender bei jedem Update angezeigt werden.

Spätestens beim nächsten Update eines betroffenen Moduls löst sich das von selbst, da es solange nicht eingecheckt werden kann, solange es unbalanced Meldungen gibt. Und das finde ich auch gut so 

Dass "ja zu Attributen" eine vorherrschende Meinung gewesen sein soll, kann ich übrigens nicht nachvollziehen.

[Dr. Boris Neubert]

Habe ich das was überlesen? Es gab hier mehrere Stimmen, die sich für Attribute ausgeprochen haben. Gibt es jetzt einen precommit check?

Das einzige Gegenargument, das ich gesehen habe, war die Übersetzung von HTML nach Plaintext. Und dazu fällt es mir schwer zu glauben, dass es sich dabei um ein Problem handelt, dass Du nicht lösen könntest.

Viele Grüße
Boris

[herrmannj]

bin auch dafür.

Schlussendlich aber Rudis Kompetenzbereich, und der hat nö gesagt. Muss man akzeptieren, geht ja auch so.

vg
joerg

[betateilchen]

Habe ich das was überlesen? ... Gibt es jetzt einen precommit check?

Ja, offenbar hast Du da was überlesen.
Ja, es gibt jetzt einen pre-commit hook.

Schlussendlich aber Rudis Kompetenzbereich, und der hat nö gesagt.

*gefällt mir*

[Dr. Boris Neubert]

Ja, offenbar hast Du da was überlesen.
Ja, es gibt jetzt einen pre-commit hook.

Bitte zeige mir den Beitrag. Ich habe Tomaten auf den Augen.

[Dr. Boris Neubert]

bin auch dafür.

Schlussendlich aber Rudis Kompetenzbereich, und der hat nö gesagt. Muss man akzeptieren, geht ja auch so.

Tabellen mit Rahmen sind für mich leserlicher als Tabellen ohne Rahmen. Ich habe nichts dagegen, die HTML-Attribute zu entfernen, wenn wir die Style-Sheets so aufbohren, dass Tabellen Rahmen haben.

Gravierender finde ich, dass wir mal angefangen haben <ul> missbräuchlich für Einrückungen zu verwenden. Und dass jeder Autor seinen eigenen Stil für die Darstellung wählt. Ich befürworte daher die Vorgabe von Styleguides und/oder die Nutzung von <div class="get"> oder so für Markup. Oder wir stellen die Doku gleich auf xml um 

[betateilchen]

Bitte zeige mir den Beitrag. Ich habe Tomaten auf den Augen.

Beispielsweise hier: http://forum.fhem.de/index.php/topic,47035.msg387832.html#msg387832

(es gibt übrigens noch mehr neue pre-commit hooks, beispielsweise Zeilenlänge in CHANGED oder pm-Dateien ohne $Id)

[Dr. Boris Neubert]

Also keine Ankündigung des Hooks - der Beitrag zeigt nur das Symptom und auch nur, wenn man ihn liest, was ich nicht getan habe.

Die Ankündigung zu den Zeichen findet sich in diesem Thema. Die Ankündigung zu den Tags nicht.

Ich möchte so nicht arbeiten.

[betateilchen]

Boris, schau doch mal genau nach: Rudi hat am 01.01. hier im Thread eindeutig kundgetan, dass er die Attribute in Tabellenelementen nicht mehr zulässt:

Sonst fangen die Leute mit "style='color:light-blue;font-size:48px'" und Vergleichbares an. Das habe ich fuer ul vor (gefuehlt) 2 Jahren einmal schon unterbunden, jetzt folgte nur table & co, da ich damals nicht auf die Idee kam, das man table in der Doku verwenden koennte.

[Dr. Boris Neubert]

Hallo,

das habe ich so gelesen, dass er es nicht wünscht, und commandref_join.pl daher meckern lässt. Dass das Gemeckere ein Einchecken verhindert, kann ich daraus nicht ablesen.

Wie sieht jetzt eine Konsenslösung für das Markup aus?

Viele Grüße
Boris

[betateilchen]

Auf welche Weise er das unterbindet, ist doch Rudis Sache.

Wie sieht jetzt eine Konsenslösung für das Markup aus?

Für mich unmissverständlich von Rudi kommuniziert: Keine Attribute in html tags.

[Dr. Boris Neubert]

Das ist eine Lösung aber keine Konsenslösung.

Wo hat man denn schon mal davon gehört, dass eine Dokumentation nur Tabellen ohne Rahmen enthalten darf?

Die saubere Lösung wurde ja schon vorgeschlagen: Styleguide und CSS-Klassen, oder gleich XML zur Trennung von Content und Darstellung. Mit XLST kommt dann jedes gewünschte Format dabei raus, HTML, Plaintext, RTF...

[betateilchen]

Das ist eine Lösung aber keine Konsenslösung.

Das ist eine königliche Entscheidung. Eine Monarchie ist nunmal keine Demokratie 

[justme1968]

ich denke rudi würde jede der vorgeschlagenen alternativen gerne als patch entgegennehmen .

aber im ernst: die meldungen ohne aussicht auf besserung sind wirklich unbefriedigend. da habe ich lieber deine doku bei der nicht alles identisch formatiert ist.

es wäre besser gewesen das eincheck verbot zu aktivieren und commandref join beim update erst nach einer weile zu verschärfen.

[rudolfkoenig]

Meiner Ansicht nach haben Tabellen in dem commandref nichts zu suchen, genauso wie Farbangaben und Buchstabengroessen. Ich moechte keinen Wettbewerb, wer seine Doku am schoensten bauen kann, sondern was Einheitliches, was auf vielen Frontends angezeigt werden kann.

Wenn ich mich nicht irre, macht es wenig Sinn CSS Klassen zuzulassen, weil dann alle Module angepasst werden muessen, und solange das nicht erfolgt, ist die Doku unleserlich. Wenn das nicht der Fall sein sollte, dann bin ich offen.

Der Haken mit XML+XSLT ist, dass es viel Arbeit bei der Umstellung bedeutet, und vielen Anfaengern nicht zumutbar ist. Weiterhin erfordert es eine zentrale Generierung der commandref.html (wovon ich weg will) oder eine aufwendigere Client-Installation wg. XSLT.

es wäre besser gewesen das eincheck verbot zu aktivieren und commandref join beim update erst nach einer weile zu verschärfen.

Verstehe ich nicht: ist das Problem, dass man Module nicht einchecken kann, oder dass man beim update Meldungen hat? Letzteres haben nur Benutzer, die FHEM auch per SVN updaten, also vermutlich nur wenige.

[rudolfkoenig]

Sorry, habs schon vergessen: commandref_join.pl wird ausgeliefert...
Ich kann das gerne in commandref_join.pl wieder auskommentieren, wenn das gewuenscht wird.

[justme1968]

die meldungen die die endanwender beim update durch das lokale bauen der doku erhalten.

d.h. alles was der endanwender sieht erst aktivieren nach dem die entwickler zeit zum fixen hatten.

d. h. eincheck verbot und die neuen commandref join meldungen für entwickler aber nicht beim lokalen bauen nach update.

[justme1968]

zu lagsam...

nicht ausbauen aber für den aufruf nach dem update deaktivieren.

[Dr. Boris Neubert]

Meiner Ansicht nach haben Tabellen in dem commandref nichts zu suchen, genauso wie Farbangaben und Buchstabengroessen. Ich moechte keinen Wettbewerb, wer seine Doku am schoensten bauen kann, sondern was Einheitliches, was auf vielen Frontends angezeigt werden kann.

Es geht mir nicht um schön sondern um gut lesbar. Für eine strukturierte gut lesbare Darstellung gibt es Tabellen. Wir haben mal entschieden, dass die Doku HTML ist. HTML kann Tabellen. Warum das jetzt verbieten? Ich kenne keinen HTML-Renderer, der Tabellen nicht beherrscht. Selbst in Man-Pages gibt es Tabellen (siehe man perl).

Ich bin auch für Einheitlichkeit. Die haben wir aber sicher derzeit nicht. Und das liegt nicht an Tabellen sondern an Kraut und Rüben bei der Formatierung. Daher das Votum für einen Styleguide. Darin verbieten wir Unterstreichungen (typographische Totsünde), Farben (nicht barrierefrei), von der Norm abweichende Schriftgrößen, Blinken, etc.

Weiterhin erfordert es eine zentrale Generierung der commandref.html (wovon ich weg will) oder eine aufwendigere Client-Installation wg. XSLT.

Warum lässt Du die commandref nicht wie zentral vor der Bereitstellung des Update generieren? Welche Vorteile bringt es, die Generierung nach dem Update beim Benutzer anzuwerfen?

Viele Grüße
Boris

[justme1968]

der grund war das damit das datenvolumen vom updateserver deutlich reduziert wird und aussderdem die doku für module aus anderen quellen auch generiert wird.

gruss
  andre

[Markus Bloch]

Hallo,

das habe ich so gelesen, dass er es nicht wünscht, und commandref_join.pl daher meckern lässt. Dass das Gemeckere ein Einchecken verhindert, kann ich daraus nicht ablesen.

Wie sieht jetzt eine Konsenslösung für das Markup aus?

Viele Grüße
Boris

Zwar etwas spät meine Antwort, aber lies dir mal den aller ersten Beitrag dieses Threads durch

[justme1968]

mit dem angehängten patch bekommt commandref_join.pl einen optionalen -noWarnings parameter der beim aufruf nach dem update verwendet wird.

[rudolfkoenig]

Habs kurz getestet und eingecheckt.

[Prof. Dr. Peter Henning]

Gerade ist das beim Einchecken von 95_Alarm.pm wieder hochgepoppt. Da hatte ich nämlich in der Commandref eine Tabelle, mit der die Ausgabe des Moduls erläutert wird:

Code Auswählen Erweitern

=<table>
                            <tr style="height:1ex">
                                <td style="width:1ex;background-color:green"></td>
                                <td style="width:1ex;background-color:green"></td>
                                <td style="width:1ex;background-color:red"></td>
                                <td style="width:1ex;background-color:green"></td>
                                <td style="width:1ex;background-color:green"></td>
                                <td style="width:1ex;background-color:green"></td>
                                <td style="width:1ex;background-color:green"></td>
                                <td style="width:1ex;background-color:green"></td>
                            </tr>
                        </table>


Diese "Mini-Tabelle" im Commandref ist kein buntes Experimentieren, sondern sehr instruktiv - und blockiert nun aber das Einchecken. Zumindest an einer Stelle wurde hier also das Kind mit dem Bade ausgeschüttet

LG

pah

[rudolfkoenig]

div hat in der Liste der geprueften Tags gefehlt, mit dem Ergebnis, dass 60_allergy.pm die deutsche Doku (commandred_DE.html) beeindruckend verhunzt hat. Ich habe div jetzt hinzugefuegt, damit ist die Liste der beanstandeten Module auf 44 gewachsen.

Ausnahmsweise(!) habe ich 60_allergy.pm gefixt, da die Doku sonst unleserlich war. Ich habe auch ein fhemupdate.pl ausgefuehrt, damit der Fix auf fhem.de landet.

[Markus M.]

div hat in der Liste der geprueften Tags gefehlt, mit dem Ergebnis, dass 60_allergy.pm die deutsche Doku (commandred_DE.html) beeindruckend verhunzt hat. Ich habe div jetzt hinzugefuegt, damit ist die Liste der beanstandeten Module auf 44 gewachsen.

Ausnahmsweise(!) habe ich 60_allergy.pm gefixt, da die Doku sonst unleserlich war. Ich habe auch ein fhemupdate.pl ausgefuehrt, damit der Fix auf fhem.de landet.

Danke und sorry!
Der öffnende div Tag der deutschen Doku hatte gefehlt und ich habe gestern auch 3 Anläufe gebraucht, wohl weil ich sie nicht selbst geschrieben habe.
Da ich nichts kaputt machen möchte, bin ich ein grosser Fan von möglichst restriktiven Checks die mich das gar nicht erst lassen.

Gruss, Markus

[tupol]

Hallo Rudi,

Es gab in der Vergangenheit einige Bedienungsanleitungen mit Bildern, die auf einigen Browsern das innere Fenster extrem verbreitert haben, so dass die Texte nur durch weites Scrollen nach rechts angesehen werden konnten.
Dem konnte ich bisher mit einem style und width begegnen. Nun leider nicht mehr.
Wenn keine Styles mehr erlaubt sind, kannst Du dann vielleicht die Breite der commandref einschränken?

Gruß

tupol

[rudolfkoenig]

@tupol:
Solche Probleme sollten von vornherein vermieden, und nicht von jedes Modul einzeln behoben werden.
Kannst du mir ein konkretes Beispiel nennen?