Man könnte nach Größe und Namen der in den Frames aufgerufenen Seiten gehen.
Gute Idee, zusätzlich die Größe heranzuziehen, um herauszufinden, welches der Content-Frame ist.
1. Das Frame mit dem Menu heißt: Menu, das Frame mit dem Hauptinhalt heißt: Content
2. Die Links in "dem einzigen, großen Bild" sind alle mit ALT-Texten versehen, die zur Erstellung des Hamburger Menüs reichen.
Die Frame-Namen hatte ich mir schon rausgesucht und die Alt-Texte hatte ich auch gesehen. Ja, damit haben sie natürlich nicht alles MAXIMAL falsch gemacht – aber dennoch ist es ein übles HTML-Gegurke, wie es eigentlich schon zur Jahrtausendwende verschwunden ist. Nichts desto trotz sind wir uns einig, dass man es trotz aller Widrigkeiten doch noch ganz gut parsen kann.
es wird nicht die einzige Seite sein, die ein BILD oder mehrere Bilder für das Menü benutzt.
Nicht die Einzige – aber es wird doch selten – und immer seltener – vorkommen.
area... href... alt könnte man ebenso automatisiert als Linkliste suchen, wie die <li><a href... Geschichten.
Richtig.
aber gerade unser Hobby ist weniger "modern" und ich denke, die eine oder andere Seite diesbezüglich arbeitet vermutlich mit sehr "einfachem" HTML bzw. wurden seit Jahren nicht modernisiert.
Gegen "einfaches" HTML ist nur wenig einzuwenden. Es gibt Webseiten, die ganz simples, Frühzeit-HTML verwenden, um auch den Zugriff mit ganz frühen Browsern, wie Mosaic zu ermöglichen. Üblicherweise verzichten solche Seiten aber auch auf Frames. Aber wir haben ja jetzt gemeinsam eine schöne Lösung erdacht, wie man wahrscheinlich auch über 90% der Frame-Sites "flach-rechnen" könnte.
Wenn man jedoch eine spezielle "App" schreiben wuerde, um auf dem C64 Software zu finden und herunterzuladen, dann waere diese Software 1:1 drauf zugeschnitten, dass man genau diesen Use Case auf dem C64 durchfuehren kann, und zwar so bequem wie moeglich. Das ist schon ein riesiger Unterschied in meinen Augen.
Ein riesiger Unterschied. Deswegen bezeichne ich es als Projekt, dass komplett unabhängig vom WWW-Projekt laufen könnte. Ich würde mich freuen, wenn es solche Apps mit Online-Anbindung geben würde (nur eben nicht auf Kosten von einem echten Browser).
Es schadet ja nicht, verschiedene Konzepte zu erlaeutern bzw. eroertern.
Auf gar keinen Fall. Einige Sachen haben sich jetzt schon in meinem Kopf deutlich verändert oder auch stärker etabliert.
Was davon umgesetzt wird, liegt letztendlich an den Programmierern.
So ist es.
Es gibt einfach viel zu viele Seiten, die nicht gescheit funktionieren werden. Und genau das waere z.B. fuer mich ein Grund, solch ein Vorhaben gar nicht erst umzusetzen.
Nein, es sind eine Minderheit an Seiten, die nicht funktionieren würden. Und man kann die Anzahl immer weiter minimieren.
Für den/die Programmierer dieses Proxy ist es wohl ein wachsendes / endloses Projekt mit wenig Nutzung.
Jedes Internet-Projekt ist quasi endlos. Das heißt nicht, dass ein Programmiere auf ewig daran gebunden wäre. Ich gehe davon aus, dass so ein Projekt komplett auf OpenSource basieren würde – und so kann jederzeit jemand am Projekt weiter arbeiten, wenn jemand anderes (absichtlich oder unabsichtlich) ausfällt.
Grundsätzlich ließe sich ja auch die Abfrage einer Seite über diesen Proxy erkennen und dann ggf. eine bereits reduzierte Seite (ähnlich der mobilen Seiten) liefern.
Das ist natürlich auch eine Idee. Die "C64-Optimierungen", die ZeHa gerne auf der Seite des Servers (C64-Web im Web) oder auf Seite des Clients (spezielle C64-App je Website) hätte, könnte man genauso gut zentral auf dem Proxy erledigen. Bei Zugriff auf sehr spezielle C64-Seiten könnte der Proxy, wenn er dafür vorbereitet ist, auch diese Optimierungen vornehmen und z.B. Download-Listen von der CSDB anbieten. Es gäbe dann eben Ausnahme-Bearbeitungen. Vorteil: Man hätte immer noch das ganze Internet zu Verfügung und trotzdem optimierte Seiten für Spezialwünsche. Und das ganze ohne Sonder-Apps auf dem C64 und alles zentral gepflegt (und nicht im HTML-Code der jeweiligen Ausgangsseite versteckt, wo sich nach 5 Jahren keiner mehr dran erinnert).