Beiträge von Volker75

Ja, relativ komplex. Macht aber Spaß Vom Umfang des Quellcodes sind es über 1/2 Millionen Zeilen.

Soll auch keiner. Ich wollte damit nur das "automatisch umeditieren" kommentieren. So leicht geht es eben leider nicht.

Weil es nicht um eine einzige Tabelle geht, sondern um etwa 200 verschiedene Tabellen. Und bei einigen wird border=1 benötigt und bei anderen nicht. So einfach automatisch geht das nicht. Das muss ich dann wohl per Hand machen...

Ein Teil der Tabellen könnte ihr hier sehen:

https://salsa.debian.org/debia…ngine/timetableexport.cpp

Ja, sorry. xhtml 1.0 strict meinte ich.

Hoffe ich auch, kenne mich aber in dem Bereich nicht so aus. Ich hatte nur mal letztens gelesen, dass ftp von einem Browser nicht mehr unterstützt wird. Da könnte ich mir auch vorstellen, dass irgendwann das border Attribut nicht mehr unterstützt wird.

Ich teste es mal kommende Woche auf den alten Anzeigetafeln.

Es scheitert daran, dass ich genau den html-Text, welche ich an Browser schicke, auch an den Drucker schicke. Den Drucker spreche ich mit Qt an. Qt unterstützt aber nur einen Teil von html und css. Leider nicht border per css:-(

(Und auch kein right-to-left bei tabllen nur bei normalen Text.)

Ich könnte in Qt die aktuelle Chromium-Engine einfügen. Damit würde es dann natülich funktionieren. Leider geht das nur unter Windows und nicht unter Linux und MacOS

Insofern sitze ich etwas zwischen den Stühlen. Entweder lasse ich meine Webseiten bei validem xhtml 4 oder ich update auf html 5, aber lebe dann eben mit diesem "obsolt" Fehler (welcher im Moment scheinbar noch nicht "schlimm" ist).

hmm... Daher hätte ich evtl. gerne mal so eine Aussage von den Webbrowserherstellern gesehen; bin aber nicht fündig geworden.

Hallo,

ich überprüfe gerade mit dem Validator https://validator.w3.org/ meine Seite.

Habe jetzt bis auf einen obsoleten Fehler (Der allerdings sehr oft wiederholt vorkommt) alles korrekt.

Ich benutze noch das Attribut "border" in table-Elementen.

Dummerweise benötige ich es und es gibt für mich nur 3 Möglichkeiten:

- darauf hoffen, dass die Browserhersteller es nicht entfernen

- meine html-Ausgabe zwei mal schreiben (was leider mehrere 100 Zeilen Quellcode erfordern würde. Das ist natürlich nicht sehr wartungsunfreundlich und zeitaufwändig.).

- hoffen, dass anderen Phraser bald die neue Varianten per css unterstützen (Was ich leider für sehr unwahrscheinlich einstufe. Zumindest nicht in den nächsten 5 Jahren)

Ich frage mich daher: Gibt es eine Seite/Übersicht, auf der aufgelistet ist ab wann die aktuellen üblichen Browserhersteller osolet gekennzeichnete Dinge nicht mehr unterstützen werden?

sieht für mich ok aus. Aber probier doch mal eine der folgenden Varianten aus:

https://www.websmith.de/blog/w…direct-mit-javascript-21/

PS: der Teil hinter return wird nie ausgeführt.

Danke! Probiere ich aus.

Ich denke die Scollerbar am rechten Rand ist durchaus sinnvoll. So kann man bei längeren Tabellen schnell erkennen, ob man (wahrscheinlich) gerade beim "heute" oder "morgen" ist (Die meisten lassen 2 Tabellen mit "Heute" und "Morgen" (vertikal) darstellen). Außerdem kann ich so das Neuladen der Seite immer genau dann anstoßen, wenn man ganz oben (oder ganz unten) angekommen ist. (Aber evtl. kann man das bei der Animation auch abfragen. Ich versuche mich mal dort weiter einzuarbeiten.)

Vielen Danke erstmal soweit. Habe hier sehr gute Tipps bekommen

Das Flackern muss wohl an meinem Grafikkartentreiber liegen. Habe es mittlerweile mit einem neueren (aber auch schon 7 Jahr alten) Laptop unter Windows ausprobiert. Da flackert es nicht.

Das externe Skript wird min. für den alten Internetexplorer benötigt. (Und der ist leider noch auf dem Anzeigegerät drauf).

Deine Variante gefällt mir insofern sehr gut, da der Text ununterbrochen dargestellt wird und es elegant geschrieben ist.

Leider sind dort zwei kleine Probleme, sodass ich wohl erstmal bei meiner Lösung bleiben werde:

a) Die Laufschriften sind nicht fixiert. Bei meiner Variante habe ich ja noch einen dritten Scroller mit dem Text im Hintergrund und die Laufschriften dürfen davon nicht weggescrollt werden und es darf auch kein Bereich verdeckt bleiben (siehe mein erstes Post mit dem Ausgangsproblem 2. und 3. . Leider weiß ich immer noch nicht wie man das eleganter lösen kann und würde es mit deiner Laufschrift genau so umständlich lösen wie bei meiner Variante.

b) Die Variante ist leider noch "zu modern"; Ich muss im Moment noch ältere Versionen sinnvoll unterstützen. Ich gucke mir jetzt mal dieses nachgeladene Skript an. Evtl. kann ich das sinnvoll kürzen.

Ich habe mir deine Variante für später in meinen TODO Ordner gepackt, da ich sie vom Prinzip schöner finde.

Bleiben noch meine Ausgangsfrage für beide Varianten bestehen: Wie kann ich das so fixieren, dass der andere Text beim hoch und runterscrollen nicht verdeckt wird (so wie bei meiner Variante, aber ohne den Text 3 mal schreiben zu müssen; ok. es geht auch nur mit den 2 zusätzlichen div-Elementen (ohne Text), aber nur, wenn der Text nur einzeilig ist. Bei meiner Variante kann ich es dadurch auch mit mehreren Zeilen machen.).

Ja, funktioniert auch ohne das Skript (zumindest unter Linux mit Firefox 81 und Chrome 85).

Das ist schonmal sehr gut.

Ich werde es aber auf einem recht alten Windowsrechner (der Anzeigetafel) noch testen müssen.

Was mir bisher auffällt: Die Laufschrift flackert bei hohen Geschwindigkeiten (etwas stärker als bei meiner Version).

Kann man das noch irgendwie verhindern? Kann evtl. irgendwie einen "ScreenBuffer" einschalten um das Flackern zu verhindern?

Mag auch an meiner Grafikkarte liegen (ist eine uralte onboard-Karte (AMD HD 4250)), andererseits sind mir solche Rucker auf anderen Webseiten bisher noch nie aufgefallen)

Danke! Das sieht sehr interessant aus. Muss ich noch einmal in Ruhe lesen, weil ich jede Zeile komplett verstehen möchte. Was mich im Moment etwas stört ist, dass dort so ein langes Skript nachgeladen wird. Ich werde mal ausprobieren dein Beispiel zu kürzen.

tk1234: Danke. Hilft aber nicht der Ausgangfrage. Die Option es statisch zu machen habe ich schon seit über 7 Jahren. (z.B. wenn ich es drucke)

Ganz ohne "Dynamik" geht es hier aber nicht. Am Bildschirm muss es aber irgendwie automatisch gescrollt (oder umgeblättert) werden, weil da keiner ist, der den Text mit einer Maus oder ähnlichem hoch und runter bewegen kann. Das ist eine Anzeigetafel. Dort gibt es kein manuelles "scrollen" von einem Benutzer.

Kleine Korrektur: Im JavaScript-Teil muss es zwei mal "bottomScroller" statt "bottomScrollerInvisible" lauten. (Sonst fängt die untere Laufschrift nicht wieder neu an)

Nur mit CSS habe ich es mit Animationen ausprobiert.

EINE Beispieldatei habe ich damit auch hinbekommen.

Problematisch wurde es einfach, da die Ticker-Texte unterschiedlich lang sind und sich auch mit der Zeit ändern.

Meine statische css Seite, die ganz toll aussah, hatte dann zwei Probleme:

a) da mit CSS die Animationen in Sekunden angegeben wird hatte zur Folge, dass bei kurzen Texten die Animation viel zu langsam war und bei langen Texten viel zu schnell.

b) die "Berechnung" der Breite war mir nicht möglich. Daher wurde der Text dann entweder nicht ganz raus oder rein gescrollt

Daher war ich auf JavaScript ausgewichen.

Zu "inline": Ja, ist mir klar. Aber es ist erstmal eine Testversion, die von einem c++ Programm erstellt wird. Ich schreibe das nicht immer per Hand. Dort ist "inline" sehr einfach. Alles andere macht es dort komplizierter. Werde ich also erst dann ändern, wenn ich mit der Version zufrieden bin.

Zu "gleiche Css Typen zusammen": Stimmt. Sourcecleanup muss ich noch machen. Einrücken könnte ich auch besser. Hilft aber nicht bei meiner Ausgangsfrage. Sourcecleanup wollte ich machen, sobald ich mit dem grundsätzlichen Vorgehen zufrieden bin.

Frage: Kann ich in css den die beiden oben beschriebenen Probleme vermeiden?

Hallo,

bin neu hier. Bin mir leider nicht sicher wohin mein Betrag genau gehört. Eher CSS, JavaSript oder html. Trifft irgendwie alles zu.

Ich habe eine Seite erstellt, die Laufschriften enthält.

Vom Prinzip bin ich damit recht zufrieden, aber ich vermute es geht etwas besser.

Meine Laufschriften habe ich nämlich 3 mal.

1. die sichtbare Laufschrift.

2. die Lautschrift, aber im Grunde nur um eine Hintergrundfarbe durchgängig zu bekommen (Also auch vor und nach dem Text. Nach dem Text hätte ich auch durch ändern von width ohne diesen Text hinbekommen, aber leider habe ich es davor nicht geschafft.)

3. die Laufschrift, aber nur damit genügend Platz ist um nicht zu weit hoch und runter zu scrollen und der ganze Text sichtbar ist.

Ich vermute, dass ich auf 2. und 3. verzichten kann, wenn ich die Rahmen selbst richtig anlege. Leider kenne ich die Größe nicht genau vorher, da der html Quelltext von meinem Programm erstellt wird und ich nicht weiß, wie ich es selbst errechnen kann. Bein Versuche sind bisher leider gescheitert mit margin, padding und border sind leider gescheitert.

Kann mir jemand einen genaueren Tipp geben, wie ich auf 2. und 3. verzichten kann. Ich vermute irgendwie mit CSS oder JavaScript. Bei JavaScript sollte die Lösung aber so aussehen, dass es nur einmal "berechnet" wird und nicht ständig.

Ich freue mich über konkrete Vorschläge.

Danke