letzter Beitrag von emulaThor am
Wie bereits geschrieben, das "Comet" Modem von Goog (http://www.commodoreserver.com) schafft 38,4 baud Datenrate. Es läuft bei mir problemlos.
Sorry, das Comet schafft 38,4 Kbaud, 38,4 baud wär dann doch lähmend 
Und zur Bitmap-Variante ist noch eine Frage offen, die mich interessieren würde.
Wenn das so ist, handelt es sich dann um einen reinen Reader oder werden Eingabezeilen, Links usw. trotzdem möglich sein?
Ich hatte schon an früherer Stelle gesagt, dass ich mich auf Wunsch des oder der Entwickler(s) auch ganz raushalten kann. Ich sehe das nicht als "mein" Projekt.
War doch nicht ganz mein Ernst mit der Peitsche. Ich hatte Dich schon so verstanden, dass Du hier etwas "anschubst", was nicht klar definiert ist. Da Du aber von Anfang an sehr intensiv in diesem Thread steckst und ganz schon 'ne knappe Milliarde Bytes dazu geschrieben hast (oder waren es mehr? 
), bin ich der Meinung, dass Du vermutlich den Besten Überblick hast. Irgendwo müssen ja erstmal die Fäden zusammenlaufen. Und bis sich jemand anders dazu erklärt die Fäden zu halten, hältst Du sie
Da kann man durchaus unterscheiden: Tabellen, die Daten übersichtlich darstellen sollen, könnte man noch recht gut retten, indem man der Ausgabe-"Sprache" (wenn ich bei meinem Konzept bleiben dürfte) Tabulatoren beibringen würde.
Ich meinte eher Tabellen mit Inhalten, die sich dann tatsächlich schwer in 40-80 Zeichen darstellen lassen. Aber das könnte man zur Not dann auch als Auflistung mit Einrückung o.ä. darstellen.
Wie bereits geschrieben, das "Comet" Modem von Goog (http://www.commodoreserver.com) schafft 38,4 baud Datenrate. Es läuft bei mir problemlos.
Wieviel schafft denn der c64 überhaupt?
Alles anzeigenVerstehe ich das richtig:
Der Proxy soll eine Seite aufrufen
daraus eine Bitmap, also eine Grafik erstellen,
diese in kleine Häppchen zerlegen und
scheibchenweise an den C64 senden,
der die Teile wieder zusammensetzt?
Wenn das so ist, handelt es sich dann um einen reinen Reader oder werden Eingabezeilen, Links usw. trotzdem möglich sein?
Ich denke schon, dass es mehr als ein Reader sein soll. Links müssen funktionieren, sonst funktioniert das Web nicht. Und Formulare etc. sollten wohl auch funktionieren, sonst wäre außer einer hübschen Optik gegenüber Contiki nichts gewonnen. Formulare müssen übrigens nicht unbedingt dort ausgefüllt werden, wo sie erscheinen. Safari/iPhone stellt z.B. Popup-Menüs, sobald man sie anklickt, ganz anders (Finger-optimierter) dar, als es die Webseite tun würde. Wenn man also vermeiden möchte, in der herunter geladenen Bitmap herumzumalen, dann könnte man für Eingaben auf eine spezielle Ansicht umschalten.
Im Grunde arbeitet das Wifi-Modem von Jammingsignal ähnlich. Da läuft ein Arduino drauf, er baut die Internetverbindung auf agiert als Master und über ein Terminalprogramm auf dem C64 kann man sich dann einloggen. Da man es in den Userport steckt, sehe ich da weniger das Problem, dass es nicht mehr das "pure" C64-Feeling ist. Im Grunde ist es egal, ob der Proxy die Arbeit irgendwo im Netz macht oder hinten am C64 dransteckt.
Für mich persönlich macht es schon einen Unterschied, ob der Proxy frei zugänglich im Netz liegt oder jeder seinen eigenen Proxy am C64 stecken hat. Zumal eine Lösung, die speziell für eine C64-Schnittstelle angepasst wurde, wenig universell ist. Mein Begehr wäre ja, Das Web allen schwachbrüstigen Hardwares zugänglich zu machen und nicht nur dem C64.
Außerdem hege ich die Hoffnung, dass ein frei zugänglicher Proxy einen gewissen Reiz ausüben würde, ihn auch zu nutzen. Wenn dann noch sehr günstige Hardware angeboten würde (Servant64 kostete was bei 20 €), wäre es für viele quasi ein Nobrainer, den Proxy zu nutzen und mal mit C64 und Co. ins Netz zu gehen. Auch die Bestands-Ethernet-Lösungen, die in 1541U und TC64 eingebaut sind (oder Lösungen für ganz andere Computer), wären mit einem externen Proxy nutzbar, während ein weiteres "Modul" diese LAN-Hardware unnütz erscheinen lassen würde.
das Comet schafft 38,4 Kbaud
Sorry, ich hatte mich da falsch erinnert und dachte kurz, nur der Nachfolger hätte diese Specs. Interessant wäre halt, wie viel davon der C64 wirklich verarbeiten kann (also, wäre die Anbindung der Flaschenhals oder das Endgerät?) und wie schnell andere, verbreitetere, Lösungen so sind. Wenn man jetzt wirklich auf Bitmap-Übertragung setzen sollte, dann wäre das ja schon interessant zu wissen.
Und mir ist nachträglich klarer geworden, dass Rapid Eraser nicht erst eine ganze C64-Bildschirmseite übertragen möchte, sondern die angesprochenen "Streifen" kleiner sind als ein Screen – und damit auch die Wartezeiten kürzer als von mir gedacht. Mein READ-Zeichensatz ist ja für 8 Pixel Zeilenabstand optimiert und so könnte man z.B. in 5 Schüben zu je 5 Text-Zeilen (40 Pixelzeilen) den ersten Screen aufbauen und dann soviel nachschieben, wie der Speicher verträgt.
Und bis sich jemand anders dazu erklärt die Fäden zu halten, hältst Du sie
Kann ich gerne machen, solange sich der/die Entwickler nicht daran stößt/stoßen. ich bin mal gespannt, ob sich Rapid Eraser schon in sein "Programmier-Kämmerchen" zurückgezogen hat und codetechnisch was ausheckt.
Die Idee mit dem Raspberry Pi als Proxy und "Modem" bzw Wifi/LAN-Interface kam mir auch schon... aber keine Ahnung wie das in der Community ankommen wuerde (wirkt schnell so, als wuerde das Raspberry Pi die eigentliche Arbeit machen - was ja zum Teil auch der Fall waere).
Und es hat ja auch durchaus seinen Sinn, das man intelligente HW baut. Hat Commodore selber schon vor Jahrzehnten gemacht. 
Und da wir ja nicht auf jeden Euro achten müssen möchte ich meinen: Je weniger Arbeit der C64 übernehmen muss desto besser.
Ich sehe es so: Wenn man einen Raspi zum Herunter rechnen nutzt, warum packt man da dann nicht gleich noch VICE dazu – dann braucht man diese hässliche braune Kiste nicht mehr als Tastatur-Ersatz davor stehen zu haben.
VICE kann derzeit sicherlich viel HW "unnütz" machen, z.B. alle Arten von Massenspeichern. Doch einen C64-Browser bekommst du dadurch trotzdem nicht.
Den RasPi hatte ich aber auch eher als plakatives Beispiel genannt. Dennoch, ich halte es nicht für angebracht von vornherein unnötige Constraints aufstellen zu wollen. Beispielsweise das Markdown verwendet werden und das der C64 die Seite selber rendern soll. Beides wird für den Anwender ohnehin völlig transparent sein, und da wir selber (oder ich zumindest) noch immer nicht wissen wie praktikabel diese Wünsche in der Praxis sein werden möchte ich mich da bislang noch auf nichts festlegen. Diese Entscheidungen würde ich ersteinmal vertagen wollen bis wir klarer sehen.
Ich hatte ja grob überschlagen, dass bei 9600 Baud eine C64-Bitmap rund 8 Sekunden brauchen würde. Mit Zusatzinfos (Imagemap für Links ...) sind es vielleicht 10 Sekunden. Und das bei jedem Weiterschalten (sofern es nicht im Hintergrund geschieht). 10 Sekunden können schon ganz schön lang sein, wenn man auf die Darstellung wartet.
Naja, 1KB Bitmapdaten pro Sekunde sind ja ca. 3 Zeilen à 8 Pixel. Da kommen die Texte doch schon schneller hereingerauscht als du sie lesen kannst. Warst wohl nie mit 300 Baud unterwegs, du Sohn der Ungeduld.
Was man noch erwähnen sollte: Markdown u.ä. eignen sich leider nicht für ein partielles Rendering. Falls so ein MD-Dokument größer ist als der Speicher der Clients dann reicht es nicht wenn der Client nur den nächsten Abschnitt des Dokuments vom Server anfordert; er müsste zum Weiterblättern wohl das Dokument von Anfang an neu beim Server anfordern, um den bereits gesehenen Teil zu interpretieren und dann wegzuwerfen. Das kann sicher auch leicht einige Sekunden extra in Anspruch nehmen.
Weiss jemand zufällig wie Contiki das handhabt?
Es müssten also schnellere Übertragungswege her und die scheint es ja zukünftig zu geben. Aber Bestandshardware (RR-Net...) wäre nicht schneller, oder?
Ehrlich gesagt habe ich nicht den blassesten Schimmer wie die Kommunikation in Netzwerken am C64 funktioniert. Ich weiss nur das ich damals ein Modem (natüüürlich vom Schwarz-Schilling abgesegnet...) am C64 und an der Telefonbuchse angeschlossen und mich dann per TelNr. in irgendeine Mailbox eingewählt habe. Wie läuft das denn heute? Braucht man immer noch dedizierte Rechner in die man sich mit so geringen Baudraten einwählen kann oder kann man einen 08/15 DSL-Anschluss verwenden? Wo würden dann solche Späße wie der TCP/IP oder DHCP gehandelt?
Wenn das so ist, handelt es sich dann um einen reinen Reader oder werden Eingabezeilen, Links usw. trotzdem möglich sein?
Klaro sollen Links, Eingabezeilen usw. trotzdem möglich sein. Die nötigen Infos dazu würden halt in den Metainformationen stecken welche zusätzlich zum Content der Seite übertragen werden.
Kann ich gerne machen, solange sich der/die Entwickler nicht daran stößt/stoßen. ich bin mal gespannt, ob sich Rapid Eraser schon in sein "Programmier-Kämmerchen" zurückgezogen hat und codetechnisch was ausheckt.
Sorry, nein, noch lange nicht, dazu ist die Aufgabe noch viel zu schwammig. Lass mal überlegen, wie könnte man anfangen
- die htmlseite "segmentieren" (aber nach welchen Kriterien?)
- ggf. Menus/Formulare/Bilder erkennen und separat behandeln
- unerwünschte Segmente herauswerfen (woran erkennt man die?)
- in den verbleibenden Segmenten nicht benötigtes/gewünschtes Html/CSS (woran erkennt man das?) löschen
- ggf. die verbleibenden Segmente vereinfachen (z.B. Layout zurechtrücken)
- das Dokument in ein noch zu definierendes Ausgabeformat, z.B. Markdown, wandeln (wie sieht die Abbildung von HTML auf Markdown aus?)
Unabhängig davon:
- wie kommuniziert der C64 mit dem Server? Über ein HTTP-Subset?
Beispielsweise das Markdown verwendet werden und das der C64 die Seite selber rendern soll.
Markdown: Siehe unten. Rendern am C64: Dafür.
Naja, 1KB Bitmapdaten pro Sekunde sind ja ca. 3 Zeilen à 8 Pixel. Da kommen die Texte doch schon schneller hereingerauscht als du sie lesen kannst.
Von den Bitmapdaten würde ich völlig weg gehen, da es ja auch plattformübergreifend sein/werden soll. Das geht dann ja einfach nicht. Dass die Daten 'on-the-fly' kommen (können), sollte selbst ja kein Problem darstellen.
Was man noch erwähnen sollte: Markdown u.ä. eignen sich leider nicht für ein partielles Rendering. Falls so ein MD-Dokument größer ist als der Speicher der Clients dann reicht es nicht wenn der Client nur den nächsten Abschnitt des Dokuments vom Server anfordert; er müsste zum Weiterblättern wohl das Dokument von Anfang an neu beim Server anfordern, um den bereits gesehenen Teil zu interpretieren und dann wegzuwerfen. Das kann sicher auch leicht einige Sekunden extra in Anspruch nehmen.
Markdown ist ja schon schön klein, muss dann aber komplett 'durchgescannt' werden, um HTML (oder eben das 8-Bit-Browserformat) zu erzeugen. Markdown ist halt nur freundlich für (reine) Text-Schreiber ausgelegt (so wie ich das verstanden habe). Es ist doch wohl nur eine reine Text-Datei. Es ist ja eben noch absolut NULL 'Code' enthalten (für die Formatierung etc.). Eben erst nach der Konvertierung zu HTML. Dann ist es aber eh wieder unbrauchbar. Gibt es denn (überhaupt) auch einen Konverter HTML -> Markdown? Keine Ahnung. Ich denke nicht. Geht wohl auch gar nicht und bringt ja auch eh nix.
- das Dokument in ein noch zu definierendes Ausgabeformat, z.B. Markdown, wandeln (wie sieht die Abbildung von HTML auf Markdown aus?)
Ach..., siehe davor.
Uebrigens gibt es noch einen weiteren Nachteil bei Bitmaps: Der C64 weiss gar nicht, was da geschrieben steht. Man kann also z.B. keine Suchfunktion einbauen oder sowas.
Und es hat ja auch durchaus seinen Sinn, das man intelligente HW baut. Hat Commodore selber schon vor Jahrzehnten gemacht.
Und da wir ja nicht auf jeden Euro achten müssen möchte ich meinen: Je weniger Arbeit der C64 übernehmen muss desto besser.
Beim letzten Punkt bin ich ja voll bei dir, sonst hätte ich ja nicht von Anfang an die Proxy-Idee favorisiert. Ob man dafür propritäre Hardware (neben einem Netzwerkanschluss) benötigt, muss erst noch geklärt werden. Und das mit dem Euro würde ich gerne im Auge behalten, denn ich wäre schon dafür den Gesamtaufwand (inkl. Kosten) – und damit die Einstiegsschwelle – möglichst gering zu halten. Sollte es z.B. 100 € kosten, mit dem C64 ins Web zu kommen, dann muss man den Usern schon was bieten, sonst lassen sie es bleiben. Bei 20 € würden viele sagen: Komm, das probieren wir einfach mal aus.
VICE kann derzeit sicherlich viel HW "unnütz" machen, z.B. alle Arten von Massenspeichern. Doch einen C64-Browser bekommst du dadurch trotzdem nicht.
Ich meinte eher, dass VICE den kompletten C64 ersetzen könnte. Wenn eh schon der ganze Browser-Job auf dem Raspi gemacht wird, was hindert einen daran, auch noch den C64 mittels VICE selbst darauf laufen zu lassen? – Dann würde man keine C64-Hardware mehr benötigen, aber dann wäre auch das Projekt selber ad absurdum geführt. ich wollte damit aufzeigen, dass man nicht beliebig viel Intelligenz außerhalb des c64 realisieren sollte, weil irgendwann dadurch das Projekt "kippt". Der C64 sollte meiner Meinung nach kein komplett dummes Terminal werden. Andere können das aber gerne anders sehen.
Den RasPi hatte ich aber auch eher als plakatives Beispiel genannt. Dennoch, ich halte es nicht für angebracht von vornherein unnötige Constraints aufstellen zu wollen. Beispielsweise das Markdown verwendet werden und das der C64 die Seite selber rendern soll.
Ich will keine Axiome festlegen, meine Vorschläge sind bitte auch nur als solche zu verstehen – es sind keine festen Vorgaben. ich bin froh, wenn in alle Richtungen gedacht wird, bevor man anfängt, irgendwas zu programmieren.
da wir selber (oder ich zumindest) noch immer nicht wissen wie praktikabel diese Wünsche in der Praxis sein werden möchte ich mich da bislang noch auf nichts festlegen. Diese Entscheidungen würde ich ersteinmal vertagen wollen bis wir klarer sehen.
Da bin ich deiner Meinung.
Naja, 1KB Bitmapdaten pro Sekunde sind ja ca. 3 Zeilen à 8 Pixel. Da kommen die Texte doch schon schneller hereingerauscht als du sie lesen kannst.
ich hatte ja selbst bei meinem späteren "5-Zeilen-Streifen"-Gedanken gemerkt, dass die Bitmap-Daten (bei ausreichend schneller LAN-Hardware) schnell genug wären. Allerdings muss man bedenken, dass (egal ob Bitmaps oder Text) nicht nur lesbarer Text auf dem Screen erscheint, sondern wahrscheinlich auch immer noch eine Menge Lücken/Flächen/Bildelemente, die eben nicht gelesen werden, sondern über die man evtl. schnell weg-scrollen möchte.
Was man noch erwähnen sollte: Markdown u.ä. eignen sich leider nicht für ein partielles Rendering.
Warum nicht? Gerade MD sollte sich eher als HTML dafür eignen, weil es bei MD keine schließenden Tags gibt, die evtl. am Anfang des Dokuments geöffnet werden und erst am Ende geschlossen.
Weiss jemand zufällig wie Contiki das handhabt?
Contiki muss ja komplexes HTML verarbeiten und wird wahrscheinlich bei einem Seitenwechsel wieder die ganze Seite laden – die Geschwindigkeit lässt das zumindest vermuten. Da Contiki aber OS ist, kann man die Infos bestimmt irgendwo finden – schlimmstenfalls im Quellcode.
Wie läuft das denn heute? Braucht man immer noch dedizierte Rechner in die man sich mit so geringen Baudraten einwählen kann oder kann man einen 08/15 DSL-Anschluss verwenden? Wo würden dann solche Späße wie der TCP/IP oder DHCP gehandelt?
Heutzutage hat man üblicherweise einen DSL-Router und der hängt im lokalen (W)LAN – und alle verbundenen Rechner gehen über den ins Internet. Hat man nur einen einzelnen Rechner, hängt der halt alleine (auch per LAN-Kabel oder WLAN) am DSL-Router. Heutzutage läuft, soweit ich weiß, alles interne, wie externe, über TCP/IP (notfalls getunnelt) ab. Ich bin aber wahrlich kein Netzwerk-Auskenner, da gibt es hier im Forum sicherlich bessere Expertise.
Was der C64 also können muss, damit er im LAN kommunizieren kann, ist TCP/IP. In Contiki ist z.B. ein entsprechender Stack enthalten (den wir sicherlich "entwenden" dürfen) aber es gibt auch C64-LAN-Hardware, die selbsttätig die Kommunikation übernimmt. Ich verstehe das so, dass dann der C64 selbst keinen TCP/IP-Stack benötigen würde. Wie das bei den schon vorhandnen LAN-Hardwares in TC64 und 1541U gelöst ist, müsste uns hier mal jemand erklären. Ich meine, beim Servant64 spricht man das Netzwerk mit OPEN-Befehlen so ähnlich an, wie übliche, serielle IEC-Geräte.
Man müsste also mal zusammenstellen, welche Hardware-Lösungen es schon gibt und welche Fähigkeiten (Protokolle, Übertragungsgeschwindigkeit) sie besitzen. Das ganze ist natürlich nur relevant, wenn man nicht direkt einen Raspi an den C64-Expansion-Port hängt.
Sorry, nein, noch lange nicht, dazu ist die Aufgabe noch viel zu schwammig. Lass mal überlegen, wie könnte man anfangen
Ich bin auch durchaus davon ausgegangen, dass das "Programmieren" anfangs hauptsächlich aus Lesen besteht.
Alles anzeigen- die htmlseite "segmentieren" (aber nach welchen Kriterien?)
- ggf. Menus/Formulare/Bilder erkennen und separat behandeln
- unerwünschte Segmente herauswerfen (woran erkennt man die?)
- in den verbleibenden Segmenten nicht benötigtes/gewünschtes Html/CSS (woran erkennt man das?) löschen
- ggf. die verbleibenden Segmente vereinfachen (z.B. Layout zurechtrücken)
- das Dokument in ein noch zu definierendes Ausgabeformat, z.B. Markdown, wandeln (wie sieht die Abbildung von HTML auf Markdown aus?)
Mein Problem besteht momentan darin, dass du mehr willst, als ich ursprünglich wollte. Es besteht meines Erachtens ein riesiger Unterschied, ob man komplexe Strukturen (DIVs etc.) erhalten/rendern will, um das Layout zu erhalten (nach meinem Verständnis dein Ansatz) oder ob man (mein Ansatz in Anlehnung an Lynx oder Links) einfach fast alle Strukturen ignoriert und entsorgt. Wenn du ansatzweise das Layout rüberretten willst (und sei es auch nur die Hintergrundfarbe), dann muss du auch ins CSS hinein (was ich vermeiden wollte).
Egal, wie man es angeht – der Schlüssel zum Erfolg ist sicherlich, nicht alles neu erfinden zu wollen, sondern vorhandene Tools zu verwenden und die (dank OpenSource) an die eigenen Wünsche anzupassen. Es macht meines Erachtens keinen Sinn, selbst das HTML zu rendern oder zu filtern, sondern man sollte entweder eine Browser-Engine (z.B. Webkit) darauf hin überprüfen, ob man sie als Proxy verwenden kann oder aber die hier schon oft verlinkten Tools (Lynx als Proxy, HTML-2-MD-Konverter ...) zum Filtern/Konvertieren von HTML verwenden.
Wenn du als Endergebnis des Proxys (egal ob der jetzt auf einem Raspi oder auf einem öffentlich erreichbaren Server läuft) Bilder bekommen möchtest, die in Ansätzen dem Original-Layout entsprechen, dann gibt es meines Erachtens nur die Lösung, dass du mit Webkit (o.ä.) einen Browser (für den Server) programmierst, der ein (virtuelles) Fenster in 320 x 200 Pixeln (für andere Systeme andere Maße) öffnet (darüber wahrscheinlich die mobile Ansicht vom Webserver geliefert bekommt, wenn vorhanden), die Texte mit meinem Pixelfont rendert und das Ergebnis dann als Bild (z.B. PNG ) herausgibt. Das kann man danach in C64-Hires umrechnen.
Wenn das Konvertieren erstmal als Proxy auf einem lokal aufgesetzten Server funktioniert (also komplexes HTML rein und irgendwas weniger komplexes raus), dann kann man mal gucken, an welchen Positionen man Stellschrauben ansetzen muss.
Mein Vorschlag wäre also, erst einmal irgendwas Proxy-ähnliches zum Laufen zu kriegen, egal was es tut. Vielleicht mit einem der schon vorhandenen Konverter als Basis. Egal, welche Lösung wir anstreben sollten, müssen ja Daten on-the-fly gefiltert/konvertiert werden. Den Proxy sollte man im lokalen Netz über seine IP-Adresse mit einem normalen Webbrowser aufrufen können und vielleicht in der Browser-Zeile die URL der anzuzeigenden Website übermitteln. ich denke, alles weitere kann man planen, wenn das erstmal läuft. Oder wie siehst du das?
Von den Bitmapdaten würde ich völlig weg gehen, da es ja auch plattformübergreifend sein/werden soll.
Obwohl ich ja auch kein Freund der Bitmap-Lösung war, sehe ich das nicht als zu großes Problem. Der Proxy darf dann eben nicht festgelegt werden auf eine Auflösung oder Farbtiefe, sondern muss für jeden Client was eigenes passend rendern. Das sollte möglich sein.
Markdown ist ja schon schön klein, muss dann aber komplett 'durchgescannt' werden, um HTML (oder eben das 8-Bit-Browserformat) zu erzeugen.
Wer will denn aus MD wieder HTML machen? Das ist zwar der gängigere Weg, weil MD eigentlich zum einfachen ERSTELLEN von formatiertem Text dient aber hier ist das gar nicht gefordert. MD soll ja das ZIEL-Format sein.
Es ist ja eben noch absolut NULL 'Code' enthalten (für die Formatierung etc.).
Jein. Der Code ist klartextlich zu erkennen. Es sind keine klassischen Tags in "spitzen Klammern" enthalten aber # leitet z.B. eine Überschrift ein, ## eine Unter-Überschrift und *text* macht den Text kursiv.
Gibt es denn (überhaupt) auch einen Konverter HTML -> Markdown? Keine Ahnung. Ich denke nicht. Geht wohl auch gar nicht und bringt ja auch eh nix.
Wir hatten bestimmt schon 3 bis 5 Lösungen hier gepostet und ausprobiert.
Wieso eigentlich MD?
Wäre das auf dem Endgerät soviel einfacher zu verarbeiten als ein klares <i>kursiv</i> oder <h1>überschrift</h1> ?
Reden wir hier überhaupt nur von einfachen HTML-Tags oder auch von style-Anweisungen im Quelltext a la <div style='font-weight:bold;'>fett</div> oder <p class='vollfett'>fett</p> ?
Obwohl ich ja auch kein Freund der Bitmap-Lösung war, sehe ich das nicht als zu großes Problem. Der Proxy darf dann eben nicht festgelegt werden auf eine Auflösung oder Farbtiefe, sondern muss für jeden Client was eigenes passend rendern. Das sollte möglich sein.
Auf die Art hat man auf der Zielmaschine aber keinen Einfluss mehr auf z. B. eine bevorzugte Schriftart, was ich schade fände. Und wie soll das bei einer gerenderten Bitmap mit den Button/Menüs funktionieren? Da müsste ja noch zusätzlicher Code übertragen werden und Koordinaten etc.. Bei diesen Dingen müsste die Zielmaschine ja eh noch in die Bitmap eingreifen/schreiben.
Wer will denn aus MD wieder HTML machen? Das ist zwar der gängigere Weg, weil MD eigentlich zum einfachen ERSTELLEN von formatiertem Text dient aber hier ist das gar nicht gefordert. MD soll ja das ZIEL-Format sein.
Bei MD gehen aber einige Befehle/Formatierungen verloren (zusammenhängende Absätze, erzwungener Zeilenumbruch, Aufzählungen etc.), die auf der Zielmaschine gebraucht werden könnten bzw. gebraucht würden. Zudem hat MD kein einheitlichen bzw. ja gar kein System bei den Befehlen entgegen HTML mit "<> </>". Gerade diese ankündigenden und beendenden TAGS fände ich wichtig beizubehalten. Zudem müssten ja auch noch die Farben untergebracht werden. Da bin ich wieder bei meinem "@@" als Befehls-Beispiel: @@cFF (Color Vorder-/Hintergrund); @@u: Underline etc.
Jein. Der Code ist klartextlich zu erkennen. Es sind keine klassischen Tags in "spitzen Klammern" enthalten aber # leitet z.B. eine Überschrift ein, ## eine Unter-Überschrift und *text* macht den Text kursiv.
Siehe oben ("kein System"). Der Text müsste umständlich nach verschiedensten Merkmalen durchforstet werden.
Wir hatten bestimmt schon 3 bis 5 Lösungen hier gepostet und ausprobiert.
Stimmt.
Immer noch mein Fazit: Übertragung in einer HTML-artigen Textdatei mit TAGS. Dann hat die Zielmaschine auch noch was zu tun und verkommt nicht zum Anzeigegerät. Und es brauchen eben nur 1K (+x) statt 8+1K (+x) übertragen werden.
Chagizzz: Dann sehen wir das ja ähnlich. Es kann aber sein, Retrofan meint das mit dem MD irgendwie anders und wir reden aneinander vorbei.
Wieso eigentlich MD?
Wäre das auf dem Endgerät soviel einfacher zu verarbeiten als ein klares <i>kursiv</i> oder <h1>überschrift</h1> ?
Warum MD, habe ich eigentlich schon mehrfach versucht zu erklären. Kurz: Es ist nicht mal halb so lang – ergo weniger Datenübertragung und weniger Speicherverbrauch. Und es gibt Konverter und es ist ein Standard und es kennen sich viele damit aus. Aber wie auch schon oft gesagt: Es ist nur eine Idee, nur ein Vorschlag, es kann auch gerne HTML, WML oder SGXMLPLUSV8;) sein – Hauptsache kompakt.
Reden wir hier überhaupt nur von einfachen HTML-Tags oder auch von style-Anweisungen im Quelltext a la <div style='font-weight:bold;'>fett</div> oder <p class='vollfett'>fett</p> ?
Was heißt in diesem Zusammenhang "reden"? Ja, das kann (wegen mir) weg, wie externes CSS auch. Bzw., solange eindeutig ist, wie die Auszeichnung aussehen soll (bei selbst vergebenen Klassennamen schwierig), kann man es durch entsprechende Codes (in MD wäre das **fett**) ersetzen.
Auf die Art hat man auf der Zielmaschine aber keinen Einfluss mehr auf z. B. eine bevorzugte Schriftart, was ich schade fände. Und wie soll das bei einer gerenderten Bitmap mit den Button/Menüs funktionieren? Da müsste ja noch zusätzlicher Code übertragen werden und Koordinaten etc.
Ja, es müsste natürlich zusätzlicher Code übertragen werden. Die Bitmap-Lösung sollte aber besser Rapid Eraser "verteidigen", ich finde sie interessant aber weniger zielführend als echten Text.
Uebrigens gibt es noch einen weiteren Nachteil bei Bitmaps: Der C64 weiss gar nicht, was da geschrieben steht. Man kann also z.B. keine Suchfunktion einbauen oder sowas.
Ja, das ist auch ein Problem von Bitmaps. Ich sehe es aber als noch problematischer an, dass man den Text nicht insgesamt oder in Auszügen kopieren/speichern kann. Vielleicht braucht man das aber alles auch gar nicht auf dem C64 – man sollte es aber im Hinterkopf behalten.
Bei MD gehen aber einige Befehle/Formatierungen verloren (zusammenhängende Absätze, erzwungener Zeilenumbruch, Aufzählungen etc.), die auf der Zielmaschine gebraucht werden könnten bzw. gebraucht würden.
Lies dir die Definitionen nochmal (z.B. auf Wikipedia) durch – da geht anscheinend mehr als du denkst. Und was nicht geht, kann man gerne hinzuerfinden, schließlich gibt es auch MD-Erweiterungen (z.B. für Tabellen)
Zudem hat MD kein einheitlichen bzw. ja gar kein System bei den Befehlen entgegen HTML mit "<> </>".
Dafür, dass es anscheinend "kein System" gibt, gibt es aber doch (schon vom Erfinder) wunderbare Tools, um HTML in MD und zurück zu wandeln. Ganz so systemlos wird es also nicht sein. Das ist ein Grund, warum ich es ausgewählt hatte – es ist ein Standard, er ist erweiterbar, es gibt dutzende von Tools, man muss das Rad nicht nochmal neu erfinden.
Zudem müssten ja auch noch die Farben untergebracht werden.
MD können wir nach Belieben erweitern. Schließlich würden die Browser so programmiert werden, dass sie "unseren" MD-Dialekt verstehen. Wir könnten also Farben im RGB-Farbraum übertragen (und dem Browser die Wandlung auf Systemfarben überlassen) oder mit 16 oder 64 oder 128 Farbnamen oder was auch immer.
Da bin ich wieder bei meinem "@@" als Befehls-Beispiel: @@cFF (Color Vorder-/Hintergrund); @@u: Underline etc.
Mir ist das egal – wenn es kurz ist, können wir auch gerne sowas nehmen. Der Nachteil ist halt, dass es keiner kennt, es keine Tools gibt und keinen Standard. Man muss dann halt alles selber machen. Aber ich will dem nicht im Weg stehen – wenn du einen PHP/Ruby-Konverter von HTML zu @@-Code programmierst, dann nehmen wir halt den.
Wobei meine Ausführungen zu Markdown natürlich nur relevant sind, wenn überhaupt Text – und nicht Grafik – übertragen werden soll. Da der ausführende Programmierer die Richtung vorgibt, sind wir aber erstmal bei Grafik-Output und nicht bei Text mit Tags.
Warum MD, habe ich eigentlich schon mehrfach versucht zu erklären. Kurz: Es ist nicht mal halb so lang – ergo weniger Datenübertragung und weniger Speicherverbrauch. Und es gibt Konverter und es ist ein Standard und es kennen sich viele damit aus. Aber wie auch schon oft gesagt: Es ist nur eine Idee, nur ein Vorschlag, es kann auch gerne HTML, WML oder SGXMLPLUSV8;) sein – Hauptsache kompakt.
Auf einzelne Bytes dürfte es dabei nicht ankommen, d.h. <b>fett</b> oder **fett** ist diesbezüglich sicher wurscht. Ein </b> ist allerdings vermutlich auf dem c64 einfacher umsetzbar - klar ** würde eben bei eingeschalteter Fettschrift auf normal umschalten und umgekehrt, also wäre sicher auch nicht schwerer. Allerdings werden Kombinationen wie fett und kursiv (wenn man dafür z.B. ***fett und kursiv*** oder ___fett und kursiv___ verwendet etwas mühsamer.
Formulare (ja, das wurde auch schon besprochen) müssten ebenfalls irgendwie übermittelt werden und da halte ich die reduzierte Original-HTML Version für sinnvoll.
Klar, alles was nicht dargestellt werden soll/kann, kann vorher rausgefiltert werden, dann bleibt an HTML ja nicht mehr soviel übrig.
Und ggf. könnte man auch im Browser einstellen ob man bestimmte Elemente angezeigt oder gefiltert bekommen möchte.
Ja, das kann (wegen mir) weg, wie externes CSS auch.
Ich nehme an, dass beruht auf Deine Profi-Wissen. Ich selbst nutze solche Krücken doch häufiger (zugegeben). Aber aufgrund der ohnehin eingeschränkten Darstellung auf dem Endgerät kann man das dann wohl wirklich unterschlagen.
Auf die Art hat man auf der Zielmaschine aber keinen Einfluss mehr auf z. B. eine bevorzugte Schriftart, was ich schade fände.
Ich sehe es aber als noch problematischer an, dass man den Text nicht insgesamt oder in Auszügen kopieren/speichern kann. Vielleicht braucht man das aber alles auch gar nicht auf dem C64 – man sollte es aber im Hinterkopf behalten.
Stimme zu.
Suche ist bei der geringen Datenmenge meiner Meinung nach eher zu vernachlässigen.
Also um grundsätzlich mit PHP den Quelltext um TAGS und Script/Style Teile zu reduzieren dürften ja nur wenige Zeilen erforderlich sein.
Ob das am Ende MD oder reduziertes HTML wird, ist auch relativ wurscht.
Was muss dann aber noch gemacht werden?
Splitten großer Seiten in mehrere abrufbare Elemente (vermutlich mit Sessions)
Formulardaten empfangen und übermitteln (da hab ich mal gerade keinen Plan)
Bilder umwandeln (hab ich gar keine Ahnung und halte es für sehr aufwendig)
Links weiterleiten (vielleicht eher direkt vom Endgerät aufgerufen)
Gerade MD sollte sich eher als HTML dafür eignen, weil es bei MD keine schließenden Tags gibt, die evtl. am Anfang des Dokuments geöffnet werden und erst am Ende geschlossen.
Vielleicht werden sie bei MD nicht End-Tags genannt, aber wenn ich das richtig erkannt habe verwendet z.B. deine Erweiterung für Formulare dieses Konzept. Für Menus werden wir das wohl ebenfalls benötigen. Bei den Steuerzeichen für Hervorhebung ("*" bzw. "_") ist's sogar noch schlimmer, dort kann man nur aufgrund des Kontextes zwischen Start und Ende unterscheiden. Mir sind noch ein paar weitere "potentiell kritische" Stellen bei MD aufgefallen, aber das mag vom jeweiligen Dialekt abhängen. Mal schauen wie wir das in den Griff bekommen. Den Browser für den C64 würde ich aber schon gerne so simpel wie nur möglich halten, sonst findet sich womöglich niemand der den kompletten Standart implementiert.
Ich meine, beim Servant64 spricht man das Netzwerk mit OPEN-Befehlen so ähnlich an, wie übliche, serielle IEC-Geräte.
Es wäre natürlich auch ein interessantes Konzept wenn der Server für jede Webseite ein Executable verschicken würde.
Mein Problem besteht momentan darin, dass du mehr willst, als ich ursprünglich wollte.
Stimmt, so sieht's aus. Wie bereits gesagt, surfen à la Lynx hatten wir ja vor 20 Jahren schon (und ehrlich gesagt hat es schon damals keinen großen Spaß gemacht). Einen grafischen Browser auf dem C64 sehe ich hingegen als noch offenes und relativ interessantes "Forschungsprojekt" an.
Mein Vorschlag wäre also, erst einmal irgendwas Proxy-ähnliches zum Laufen zu kriegen, egal was es tut. Vielleicht mit einem der schon vorhandenen Konverter als Basis. Egal, welche Lösung wir anstreben sollten, müssen ja Daten on-the-fly gefiltert/konvertiert werden. Den Proxy sollte man im lokalen Netz über seine IP-Adresse mit einem normalen Webbrowser aufrufen können und vielleicht in der Browser-Zeile die URL der anzuzeigenden Website übermitteln. ich denke, alles weitere kann man planen, wenn das erstmal läuft. Oder wie siehst du das?
Soweit könnte man das zwar leicht mit einem Perlscript erschlagen doch das wäre - naja - Pfuscharbeit (zumindest wenn ich das so zusammenhacken würde...). Eine solide Lösung sähe in meinen Augen anders aus. Doch wir können es ja mal so versuchen*.
Wir hatten bestimmt schon 3 bis 5 Lösungen hier gepostet und ausprobiert.
Aber wirklich "nur mal eben ausprobiert", um festzustellen ob "irgendetwas" herauskommt. Ich glaube keiner hier hat versucht seinen täglichen Surfbedarf auf diese Weise zu decken um Vor- und Nachteile der einzelnen Engines zu erkennen, um Unzulänglichkeiten und Verbesserungsmöglichkeiten benennen oder gar eine Empfehlung für eine bestimmte Engine abgeben zu können. Oder auch nur inwiefern die ganze Idee in der Surf-Praxis überhaupt einigermaßen tragfähig ist. Es dürfte ja irgendwo begründet sein, das man seinerzeit bei PDAs, J2ME-Phones etc. nicht einfach auf ein html2markdown- oder html2wap-Skript gesetzt sondern erheblich größeren Aufwand betrieben hat.
Und wie soll das bei einer gerenderten Bitmap mit den Button/Menüs funktionieren? Da müsste ja noch zusätzlicher Code übertragen werden und Koordinaten etc.. Bei diesen Dingen müsste die Zielmaschine ja eh noch in die Bitmap eingreifen/schreiben.
Es würde vermutlich genauso funktionieren als hätte der C64 die Darstellung selber gerendert/geprintet. Auch da bräuchte er ja entsprechende Datenstrukturen welche die Position von "anklickbaren Elementen" beinhalten und müsste ggf. ebenfalls in die Darstellung eingreifen. Ob der c64 diese Daten selber bestimmt oder geliefert bekommt ist dabei glaube ich eher zweitrangig.
Die Übertragung von fertigen Bitmaps war aber auch nur ein Gedanke, einer von vielen. Jedoch, wenn ich das hinzufügen darf: Wir wären wohl produktiver wenn wir uns weniger Gedanken über die Probleme einzelner Ansätze und mehr Gedanken über die Lösungsmöglichkeiten derselben machten. (soll keine Kritik an dir sein; ist halt nur etwas das man allgemein in Forenthreads immer mal wieder in Erinnerung rufen darf... )
Alles anzeigenAlso um grundsätzlich mit PHP den Quelltext um TAGS und Script/Style Teile zu reduzieren dürften ja nur wenige Zeilen erforderlich sein.
Ob das am Ende MD oder reduziertes HTML wird, ist auch relativ wurscht.
Was muss dann aber noch gemacht werden?
Splitten großer Seiten in mehrere abrufbare Elemente (vermutlich mit Sessions)
Formulardaten empfangen und übermitteln (da hab ich mal gerade keinen Plan)
Bilder umwandeln (hab ich gar keine Ahnung und halte es für sehr aufwendig)
Links weiterleiten (vielleicht eher direkt vom Endgerät aufgerufen)
Wenn du in PHP fit bist dann versuch dich doch mal daran. Ich glaube Retrofan würde sich über einen Prototypen schon freuen, und er könnte uns glaube ich helfen klarer zu sehen wie's weitergehen soll.
* Da meine Kenntnisse in Perl/CGI/Web-Programmierung schon arg eingerostet sind kann das wohl ein paar Wochen dauern...
Und nicht vergessen: SW-Entwickler hassen es wie die Pest wenn der Kunde im Nachhinein mit Änderungswünschen aller Art ankommt.
Vielleicht werden sie bei MD nicht End-Tags genannt, aber wenn ich das richtig erkannt habe verwendet z.B. deine Erweiterung für Formulare dieses Konzept.
Nicht wirklich. Und wenn doch, dann nur, weil ich selbst mit der der End-Tag-armen Darstellung von MD noch nicht richtig warm geworden bin. Ohne jetzt einen MD-Interpreter auseinander genommen zu haben, würde ich sagen, das ganz oft ein Zeilenumbruch das Ende eines "Tags" bedeuten. Ein Return innerhalb einer Aufzählung bedeutet halt, dass ein Aufzählungspunkt beendet ist. Kommt kein weiterer (bzw. zwei Returns in Folge), ist die ganz Aufzählung (und damit gegebenenfalls das Menü) zuende.
Für Menus werden wir das wohl ebenfalls benötigen.
Ich glaube, ich würde Menüs weiterhin (also wie bei HTML) als Aufzählungen behandeln und nur mit einem kleinen Kürzel (und sei es @@menu) kennzeichnen, dass es ein Menü werden soll (quasi ein Hinweis für den Browser). Man kann es natürlich auch, wie bei MD sonst üblich, optisch (z.B. mit Pipe-Zeichen statt Sternchen) schon ein wenig an einer Menüdarstellung orientieren.
Bei den Steuerzeichen für Hervorhebung ("*" bzw. "_") ist's sogar noch schlimmer, dort kann man nur aufgrund des Kontextes zwischen Start und Ende unterscheiden.
Ja, entweder einfach an der Reihenfolge (es muss mit einer "Einleitung" beginnen und jedes 2. Auftreten ist eine Beendigung) oder an führenden bzw. nachfolgenden Leerzeichen. Aber eigentlich muss uns das erstmal überhaupt nicht beschäftigen! Denn niemand will hier (in dieser Phase) einen MD-Interpreter schreiben. Bei allem, was auf dem Server läuft, sollten wir im ersten Schritt mit vorgefertigten Tools arbeiten. Es gibt eine Hand voll HTML-2-MD-Konverter und wie die letztendlich arbeiten, kann uns egal sein. Wir wissen, das sie funktionieren und lassen sie ihre Arbeit tun.
Außerdem: Vergesst doch erstmal Markdown – das ist nur ein letzter (optionaler) Optimierungsschritt, um den Code kompakter zu bekommen. Geht doch erstmal von HTML aus. Wenn das HTML am Ende schön simpel und kompakt ist, dann kann man es immer noch durch einen existierenden MD-Konverter jagen.
Weswegen ich mich überhaupt im Vorfeld darum gekümmert hatte, war die Erkenntnis, dass einige MD-Konverter anscheinend den Job von Lynx gleich mit erledigen und unbekanntes HTML rauswerfen. Aber diese Fähigkeit ist sicherlich nicht Standard und man kann das natürlich auch vorab tun. Also: Vergesst MD – das kommt ganz zum Schluss, wenn überhaupt.
Einen grafischen Browser auf dem C64 sehe ich hingegen als noch offenes und relativ interessantes "Forschungsprojekt" an.
Ich kann dich da verstehen. Deswegen will ich das auch gar nicht bremsen. Mach, was dich interessiert und ich versuche so gut es geht, mitzuhelfen. Nur bin ich eben der Falsche, wenn es darum geht, Infos bzgl. DOM oder so zu geben. Ich weiß, dass es das gibt und dass man darüber jedes Objekt innerhalb einer HTML-Struktur ansprechen kann – aber das ist eben nur gefährliches Halbwissen.
Deswegen würde ich sagen: Wenn du Farben, Schriftgrößen, Bildgrößen, Seitenaufteilungen etc. behalten willst, dann überlass die Arbeit einer fertigen Renderengine. Wenn wir jetzt anfangen, HTML und CSS wirklich selbst zu zerpflücken, kommen wir in Teufelsküche und haben Ende (in 10 Jahren) doch nur eine (wahrscheinlich schlechte aber eigenen) Renderengine.
Ich glaube keiner hier hat versucht seinen täglichen Surfbedarf auf diese Weise zu decken um Vor- und Nachteile der einzelnen Engines zu erkennen, um Unzulänglichkeiten und Verbesserungsmöglichkeiten benennen oder gar eine Empfehlung für eine bestimmte Engine abgeben zu können.
Nein, damit wird hier niemand dienen können. Letztendich muss man die Tools halt hintereinanderschalten und mit einem Test-Set von Webseiten beschießen und gucken, was hinten herauskommt. Wenn wir alles selbst machen wollen, werden wir, befürchte ich, nicht fertig. Meines Erachtens kann unser Proxy nur gelingen, wenn wir eine Kombination von fertigen Tools gut miteinander kombinieren und immer gucken, was hinten herauskommt. Das beste Ergebnis nehmen wir dann und optimieren es mit ein paar selbst geschriebenen Filtern weiter.
Es dürfte ja irgendwo begründet sein, das man seinerzeit bei PDAs, J2ME-Phones etc. nicht einfach auf ein html2markdown- oder html2wap-Skript gesetzt sondern erheblich größeren Aufwand betrieben hat.
Zum einen liegt es daran, dass MD relativ neu ist (2004 von John Gruber erfunden) und zu Hoch-Zeiten von j2ME-Phones noch nicht existierte. Dann liegt es daran, dass in den frühen 2000er Jahren HTML noch sehr komplex war (die Table-Strukturen brachten selbst beste Browser ins Straucheln).
Und es gab "einfache" HTML-2-WAP Proxys: Sie wurden jahrelang von Google betrieben – bis sich halt niemand mehr für WAP interessierte. Aber leider gibt Google ja für alles, was wirklich interessant (und Kerngeschäft) ist, die Quelltexte nicht heraus – immer nur für Nebenschauplatz-Tools oder wenn es nicht anders geht (Android).
Es würde vermutlich genauso funktionieren als hätte der C64 die Darstellung selber gerendert/geprintet. Auch da bräuchte er ja entsprechende Datenstrukturen welche die Position von "anklickbaren Elementen" beinhalten und müsste ggf. ebenfalls in die Darstellung eingreifen.
Man muss halt zusätzlich die Bild-Koordinaten für jeden Link angeben, während bei einer Textdarstellung der Link direkt am Objekt steht. Den zusätzlichen Speicherverbrauch man aber wahrscheinlich ignorieren, wenn man speicherintensive Bilder statt schlankem Text überträgt.
Wenn du in PHP fit bist dann versuch dich doch mal daran. Ich glaube Retrofan würde sich über einen Prototypen schon freuen, und er könnte uns glaube ich helfen klarer zu sehen wie's weitergehen soll.
Ich wäre wirklich sehr dafür, anhand von konktreten Outputs zu diskutieren, als die Sachen weiterhin komplett theoretisch zu betrachten. Man kann das Für und Wider bzgl. HTML vs. MD, Grafik vs. UTF8-Text usw. noch Monate lang besprechen, ohne zu abschließenden Ergebnissen zu kommen.
Und nicht vergessen: SW-Entwickler hassen es wie die Pest wenn der Kunde im Nachhinein mit Änderungswünschen aller Art ankommt.
Das lässt sich hier leider nicht umgehen. Außer es setzt sich jetzt jemand hin und schreibt 3 Monate an einem Pflichtenheft in der Hoffnung, dass das wer liest und nach Vorschrift umsetzt/programmiert (was auch kein Spaß ist). Hier ist aber Learnig-by-doing angesagt und es WIRD (permanente) Änderungen geben.
Also habe mal ein bißchen rumprobiert.
Das Forum64 hat so dermaßen viele Links, dass das schwierig sinnvoll zu reduzieren ist. Allein bei jedem Beitrag steht sind da schon zahlreiche Links. Die sind dann schon recht störend.
Das automatisiert zu reduzieren halte ich für schwierig.
Kann man das Forum64 irgendwie direkt in der mobilen Darstellung aufrufen?
Abgesehen davon hackt er z.B. Seite 12 dieses Threads nach Beitrag 222 (2. Beitrag bei mir) ab und gibt vor der Seitennummerierung den Hinweis
In Ihrem Webbrowser ist JavaScript deaktiviert. Um alle Funktionen dieser Website nutzen zu können, muss JavaScript aktiviert sein.
aus.
Vermute der Browser lädt irgendwas selbständig nach. Hab' ich mir jetzt aber nicht so genau angesehen.
Das Forum64 hat so dermaßen viele Links, dass das schwierig sinnvoll zu reduzieren ist.
Was soll an Links schwierig sein? Ist halt nur viel (unsichtbarer) Text. Ich hatte ja schon vorgeschlagen, dass der Proxy gleichzeitig als Link-Verkürzer auftritt. Er nummeriert einfach alle Links einer Seite durch und löst die echten Links beim Anklicken auf.
(Du könntest mal schreiben, womit du "herumprobiert" hast.)
Kann man das Forum64 irgendwie direkt in der mobilen Darstellung aufrufen?
Ja, indem man das Browserfenster kleiner als 800 px zieht.
"In Ihrem Webbrowser ist JavaScript deaktiviert. Um alle Funktionen dieser Website nutzen zu können, muss JavaScript aktiviert sein."
Ja, das erscheint hier öfters. Muss man ignorieren bzw. entfernen. Es macht ja keinen Sinn, jemandem die Warnung zu zeigen, der kein JS aktivieren kann. Ich konnte bei Lynx-Verwendung trotz der Warnungen alle (wichtigen) Features nutzen.
Ich würde allerdings für allererste Test nicht unbedingt dieses Forum wählen. Technisch ist das zwar ganz OK – aber es sind unglaublich lange Seiten mit extrem vielen Links. Kann man eher so als Stress-Test verwenden. Ich würde mit einem kleinen Nachrichten-Portal o.ä. anfangen.
Was soll an Links schwierig sein? Ist halt nur viel (unsichtbarer) Text. Ich hatte ja schon vorgeschlagen, dass der Proxy gleichzeitig als Link-Verkürzer auftritt. Er nummeriert einfach alle Links einer Seite durch und löst die echten Links beim Anklicken auf.
So sieht grob reduzierter Quelltext Deines letzten Beitrages aus (händisch korrigiert, siehe unten):
Was ich meine sind z.B. Zitieren, Inhalt melden, Antworten... unter jedem Beitrag oder auch z.B. Retrofan, Beiträge und Karteneintrag am Anfang. Das wären z.T. links, die ich in einer stark vereinfachten Darstellung gerne nicht (alle) sehen würde.
(Du könntest mal schreiben, womit du "herumprobiert" hast.)
Nicht öffentlich erreichbarer PHP-Server. Da erstmal nur Reduzierung und Anzeige einer per POST übermittelten Adresse.
Ja, indem man das Browserfenster kleiner als 800 px zieht.
Das deutet z.B. auf die Dynamik der Seite hin, die schwer runterzurechnen ist. Es ist eben eine stark browserintepretierte Darstellung.
Ja, das erscheint hier öfters. Muss man ignorieren bzw. entfernen. Es macht ja keinen Sinn, jemandem die Warnung zu zeigen, der kein JS aktivieren kann. Ich konnte bei Lynx-Verwendung trotz der Warnungen alle (wichtigen) Features nutzen.
Das Problem hatte eine andere Ursache: DICH 
Nein ehrlich! Wenn Du Dir den Quelltext dieser Seite ansiehst, wirst bei Beiträgen von Dir auf folgendes Stoßen:
IMG wird nicht mit > geschlossen. Das führt dann zu Problemen.
Ich würde allerdings für allererste Test nicht unbedingt dieses Forum wählen. Technisch ist das zwar ganz OK – aber es sind unglaublich lange Seiten mit extrem vielen Links. Kann man eher so als Stress-Test verwenden. Ich würde mit einem kleinen Nachrichten-Portal o.ä. anfangen.
Sehe ich anders. Ich brauche nicht die optimale Darstellung dieses Forums, aber hier treten eben sehr viele Probleme auf, die ich gleich zu Beginn feststellen will.
Was ich meine sind z.B. Zitieren, Inhalt melden, Antworten... unter jedem Beitrag oder auch z.B. Retrofan, Beiträge und Karteneintrag am Anfang. Das wären z.T. links, die ich in einer stark vereinfachten Darstellung gerne nicht (alle) sehen würde.
Wenn ich das richtig sehe, handelt es sich bei "Zitieren, Inhalt melden, Antworten..." um eine "unordered list", wie andere Menüs auch. Wenn du dir die mobile Ansicht anguckst, siehst du, dass das Forums-CSS diesen Teil auch als Hamburger-Menü aufbaut und nicht mehr als horizontale Icon-Reihe. Ich würde also versuchen, hier möglichst ähnlich zu verfahren.
Ich schrieb ja mal, dass man versuchen sollte, Menüs zu erkennen (ULs mit LIs, die mit "<a" anfangen) – und sie dann auch als solche darstellen sollte. Unser Browser würde dann nicht, wie Lynx, haufenweise einzelne Links untereinander schreiben, sondern eine Art Popup-Menü mit den Menüpunkten anzeigen, welches natürlich eingeklappt bliebe, bis man es anklickt.
aus:
könnte also werden:
Und das (oder noch etwas kürzerer MD-Code) würde dann von unserem Browser als Klappmenü angezeigt werden – und kaum Platz beim Scrollen auf der langen Seite verbrauchen.
Nicht öffentlich erreichbarer PHP-Server.
Gefällt mir. Mit sowas kann man die Ideen gut austesten.
Das deutet z.B. auf die Dynamik der Seite hin, die schwer runterzurechnen ist.
Naja, meistens bleibt beim "Responsive Design" ja der HTML-Code identisch. Es wird halt entweder ein alternatives CSS geladen oder aber das CSS ist selbst schon so flexibel angelegt, dass es die Darstellung auf die Fensterbreite anpasst. Der Proxy sollte aber sicherheitshalber dem Server einen kleinen Screen melden, weil in seltenen Fällen der Webserver auf eine komplett getrennte mobile Site verzweigen.
IMG wird nicht mit > geschlossen. Das führt dann zu Problemen.
Ok, das ist ein Problem, mit dem sich Webbrowser auch herumschlagen müssen: Fehlerhafter HTML-Code. Da ich nicht weiß, wie Renderengines solchen Fehlern begegnen (sie sollen ja möglichst fehlertolerant sein, weswegen sie nicht ideal zum Austesten von Webseiten sind), kann ich da leider kein Patentrezept liefern. Wahrscheinlich schließen Browser fälschlicherweise offen gehaltene Tags "in Gedanken", sobald ein weiterer Tag folgt (Tag-in-Tag geht ja nicht)
Sehe ich anders. Ich brauche nicht die optimale Darstellung dieses Forums, aber hier treten eben sehr viele Probleme auf, die ich gleich zu Beginn feststellen will.
Das stimmt natürlich – wenn man im Hinterkopf behält, dass es sich um eine Seite handelt, die von der Komplexität eher am oberen Rand anzusiedeln ist. Heise.de ist im Vergleich fast Kindergarten. Warum man das im Hinterkopf behalten sollte: Um nicht zu resignieren, wenn man sich als Piloten-Frischling (damit meine ich dein Script und nicht dich) als erstes in einen A380 setzt und den nicht sofort vom Boden bekommt.
Wenn ich das richtig sehe, handelt es sich bei "Zitieren, Inhalt melden, Antworten..." um eine "unordered list", wie andere Menüs auch. Wenn du dir die mobile Ansicht anguckst, siehst du, dass das Forums-CSS diesen Teil auch als Hamburger-Menü aufbaut und nicht mehr als horizontale Icon-Reihe. Ich würde also versuchen, hier möglichst ähnlich zu verfahren.
Ja, stimmt, dann rutscht das Menü auch nach oben.
Ich schrieb ja mal, dass man versuchen sollte, Menüs zu erkennen (ULs mit LIs, die mit "<a" anfangen) – und sie dann auch als solche darstellen sollte. Unser Browser würde dann nicht, wie Lynx, haufenweise einzelne Links untereinander schreiben, sondern eine Art Popup-Menü mit den Menüpunkten anzeigen, welches natürlich eingeklappt bliebe, bis man es anklickt.
Ja stimmt, LI -> A könnte man als Kriterium nehmen.
Ja, dass das Formatierungsgedöns (insbesonder CLASS) aus den Links noch rausgefiltert werden muss ist soweit schon klar. Da in meiner Version kein CSS geladen wird, interessieren sie mich aber erstmal nicht, da die Anzeige identisch bleibt.
Gefällt mir. Mit sowas kann man die Ideen gut austesten.
Jo, nur wenn es soweit testbar ist, sollte es auch für andere erreichbar sein.
Naja, meistens bleibt beim "Responsive Design" ja der HTML-Code identisch. Es wird halt entweder ein alternatives CSS geladen oder aber das CSS ist selbst schon so flexibel angelegt, dass es die Darstellung auf die Fensterbreite anpasst. Der Proxy sollte aber sicherheitshalber dem Server einen kleinen Screen melden, weil in seltenen Fällen der Webserver auf eine komplett getrennte mobile Site verzweigen.
Ja eben, das ist ja das Problem, dass ich dann mit dem Code arbeiten muss, der mir aufgeliefert wird anstatt auf eine Mobile Version zugreifen zu können. Aber sollte schon gehen.
Ok, das ist ein Problem, mit dem sich Webbrowser auch herumschlagen müssen: Fehlerhafter HTML-Code. Da ich nicht weiß, wie Renderengines solchen Fehlern begegnen (sie sollen ja möglichst fehlertolerant sein, weswegen sie nicht ideal zum Austesten von Webseiten sind), kann ich da leider kein Patentrezept liefern. Wahrscheinlich schließen Browser fälschlicherweise offen gehaltene Tags "in Gedanken", sobald ein weiterer Tag folgt (Tag-in-Tag geht ja nicht)
Ja, sieht dann wohl so aus, als würde man doch besser sequentiell den Quelltext durchgehen und ggf. schließende TAGS vor öffnende TAGS setzen. Dabei kann dann auch gleich der ganze ungewünschte Formatierungskram herausgelöscht werden.
Das stimmt natürlich – wenn man im Hinterkopf behält, dass es sich um eine Seite handelt, die von der Komplexität eher am oberen Rand anzusiedeln ist. Heise.de ist im Vergleich fast Kindergarten. Warum man das im Hinterkopf behalten sollte: Um nicht zu resignieren, wenn man sich als Piloten-Frischling (damit meine ich dein Script und nicht dich) als erstes in einen A380 setzt und den nicht sofort vom Boden bekommt.
Na für besondere Formate kann man ja ggf. auch eine etwas verschobene Darstellung akzeptieren (erstmal).
Hast Du eine Idee, woher der Fehler bei Deinem Bild kommt? Hast Du da was rumgewerkelt oder ist das vom Forum her?
