[Berlin-wireless] Barrierefreihes Web-Frontend fuer dieFreifunk-Firmware?

[Sven-Ola Tuecke]

Alita,

wenn ich das richtig sehe, gibts keinen echten technischen Grund fuer dieses 
"Mime-Type-Tohuwabohu". Ob das W3C sich bei den Browserherstellern durchsetzt 
ist mir herzlich egal. Von daher arbeite ich gerne mit Quirks-CSS, dann muss 
ich nicht soviel an der Kompatibilitaet basteln. Ich meinten im Uebrigen die 
XML-Deklaration <?xml... ?>, daran kann ein geuebter Browser XML-Daten schon 
erkennen ;)

Ich wuerde ungern auf die Moeglichkeit statischer Webseiten verzichten und 
eine Aenderung der Busybox macht den Webadmin auf Dauer inkompatibel zu 
anderen Busybox-System wie OpenWRT. Wie schon geschrieben: Dann lieber kein 
XHTML.

XXE ist als Editor prima. Solange ein Tag in der DTD steht kann der alles 
(Schemas kann er halt nicht). Du meist sicher die beliebten Office-Pakete mit 
"XML kanns auch". Das ist richtig, da wird XML-Roundtripping zur Qual.

Ein paar kleine Extradateien werden nicht stoeren, im CRAMFS werden die gut 
wegkomprimiert, nur leider macht jede Datei einem Symlink im JFFS2 mit 64 
(oder waren es 32/128?) Bytes Inode. Ich spare da halt grundsaetzlich - sonst 
sind die 2Mb-Geraete nicht zu unterstuetzen. Zusaetlicher Platz dort fuer den 
Webadmin max. 20kb (Compressed) bei Verzicht auf die EIngangsgrafik. Ich 
werfe evt. fuer FFF 1.1 die Befehle "route" und "ifconfig" noch raus, die 
kann man mit "iproute2-ip" ersetzen.

Ach ja: Ich habe auch was gegen UTF-8. Nimm doch bitte iso-8859-1 Bis die 
erste chinesische Uebersetzung auftaucht, ist das Busybox-AWK hoffentlich 
Binary-Clean. Die vielen Nullbytes fuer die Umlautkodierungen machen sonst 
Fehler. Sorry - in spaetestens 3 Jahren gibts die billigen Kisten sicher als 
LAMP mit 2 Gb Platz, JRE und allem drum und dran. Bis dahin...

Grusz, Sven-Ola

Am Sonntag, 25. September 2005 12:45 schrieb Alita Friedrichsen:
> Hallo Sven-Ola!
>
> > herzlichen Dank fuer deinen Erst-Entwurf. Bin beeindruckt - weil es
> > funktioniert. Mein XHTML-Editor hat das auch korrekt validiert und ich
> > denke, dasz solche Seiten auch mit meinem Werkzeugsatz noch bearbeitbar
> > waeren (verwende XXE).
>
> Hmm, (...google...) der XML-Editor von XMLmind? Ich kenn die Software
> nicht, aber einige WYSIWYG-Editoren haben die angwohnheit ziemlich
> schlaechten Code zu erzeugen. Ich verwende deshalb immer einen ganz
> normalen Text-Editor, wie z.B. gedit oder kate. Laest er den Sourcecode
> so wie er ist? Kann man auch Sprachwechsel und Abkuertzungen auszeichnen,
> was fuer die Barrierefeiheit wichtig ist.
>
> > Wenn du damit weitermachen willst, dann sollten wir zunaechst ein paar
> > Kleinigkeiten abstimmen.
>
> Ok.
>
> > Ich habe dir auf
> > http://styx.commando.de/sven-ola/work.zip die meine aktuelle
> > Arbeitsversion hinterlegt. Darin enthalten sind die wichtigsten Varianten
> > der UI (ich hab noch zwei, aber das kann spaeter und die PSF-Varianten
> > ist eh noch todo). Um aus der Work-Version die Dateien zu machen, die auf
> > den Routern installiert werden, folgendes aufrufen:
> >
> > Linux: "sh _build.sh -s", Windows: "_build.bat -s"
> >
> > (Die *.txt-Dateien sind Extrakte aus den Title-Tags, dienen zum
> > Spellcheck der Hilfetexte in den einzelnen Sprachen. In den
> > out-xxx-Verzeichnisse werden die jeweiligen Varianten der UI abgelegt)
>
> Danke.
>
> > Ein paar Fragen habe ich natuerlich. Der Busybox-httpd kennt nur eine
> > geringe Auswahl an Mimetypes. Du schreibst "Kein application/xhtml+xml
> > ist unschoen". Die Ausfuehrungen unter
> > http://www.w3.org/TR/xhtml-media-types/ interpretiere ich aber so, dasz
> > niemand das technisch wirklich braucht solange bei XHTML/HTML Compatible
> > ein "MAY" dransteht.
>
> Das ist richtig. Aus Sicht der Standardkonformitaet ist es ok XHTML 1.0
> uebergansweise als text/html auszuliefern. Es ist aber nicht der
> empfohlende MIME-Type.
>
> > Schlieszlich kann
> > jeder Browser in der ersten Zeile die XML-Deklaration auswerten - und
> > einige Browser (MSIE) ignorieren die oft fehlkonfigurierten
> > Mimetype-Angaben sowieso. Was spricht aus technischer Sicht fuer den
> > Aufstand, [...]
>
> Das Problem ist das das den standardkonformen Browser, wie Firefox, Opera,
> oder Konqueror zu haarig ist, da man z.B. in XML 1.0 den XML-Header auch
> weglassen kann und es auch oft getahn wird, da dieser den IE in der
> Quirks-Mode treibt. Und so lesen sie jede XHTML-Datei, die als text/html
> ausgeliefert wird ueber ihren HTML-Parser ein. Das Problem dabei ist nun,
> dass man nun keinen Browser mehr hat, der es wirklich als XML einliest.
> Das fuert wiederum dazu, dass viele nun XHTML-Code schreiben, der unter
> normalen Bedingungen niemals funktionieren wuede. Somit werden die
> Bemuehungen nach Standardkonformitaet ins komplette Gegenteil verkaert.
> U.a. deswegen ist einglich stark davon abzuraten XHTML nur als text/html
> auszliefern.
>
> http://schneegans.de/web/xhtml/
>
> > alles in
> > cgi-bins einzupacken oder den busybox-httpd aufzuruesten? Ich wuerde eher
> > auf XHTML pfeifen, wenn das nicht anders geht...
>
> Hmm, schade. Ich haette daran gedacht ihn so umzuprogrammieren, dass man in
> der Configurations-Datei einstellen kann, was als CGI ausgefuert wird.
> So koennte das Webfrontend auch so gannante "Cool URIs" haben. So wuerden
> die URIs bzw. URLs menschlich lesbarer bzw. schreibarer werden. So koennte
> z.B. der Admin bereich sein eigenes Verzeichnis (z.B. http://[...]/admin/)
> haben oder die Status-Seite fuer die Routen koennte man z.B. statt
> http://[...]/cgi-bin-status.html?post_route=1 unter
> http://[...]/status/routes ereichen. Ich musste diese Seite naemlich einige
> male werent einer Debian-Installation mit wget abrufen, was mich ziemlich
> generft hat, da die BusyBox keine wirkliche History hat.
>
> http://www.w3.org/Provider/Style/URI
>
> > Ich nehme an, der CSS-Doppelverweis (HTML -> screen.css ->
> > screen_styles.css) ist eine Art Browser-Compat-Check. Mozilla und MSIE
> > haben AFAIK unterschiedliche Vortellungen, welches Verzeichnis genommen
> > wird, wenn der urspruegliche CSS-Verweis mit "../styles" begaenne. Wegen
> > Platzspar waere ich aber dagegen, mehrere "./styles" aufzumachen. Kann
> > man den Doppelverweis loswerden?
>
> Ich wuerde es nicht empfehlen, da dieser dazu da ist den Stylesheet u.a.
> vom Netscape 4 zu verstecken. Man koennte die @import-Anweisung hoestens in
> der XHTML-Datei direkt einen Style-Block schreiben, was zwar an anderer
> Stelle wieder zu Problemen fueren wuerde, weswegen ich es normaler Weise
> lassen, aber not wuerde es auch so gehen.
>
> > Ich finde es ausserdem schoener, die Printstyles
> > nicht soweit von der Screen-Anzeige zu entfernen und es wuerde 2 (kleine)
> > Dateien sparen.
>
> Das ist nicht moeglich, da bei allen gaengigen Browsern
> Hintergrund-Grafiken nicht mit augedruckt werden. Das wuerde dann u.a.
> deswegen ziemlich zerschossen ausehen. Ausdem waere das, finde ich, auch
> nicht wueschentswert. Wenn man ein CSS-Layout hat, wiese sollte man es
> nicht nutzen um fuer jedes Ausgabemedium eine angepasste Darstellung
> liefern zu koennen? Zur not koennte man aber den Print-Stylesheet ganz weg
> lassen, was dazu fueren wuerde, dass der Browser die Seite in seinem
> Default-Syle ausdrucken wuerde. Aber ein normaler Print-Style ist wirklich
> nicht gross. Mein laetzer war grade mal 423 Byte, aber ich krieg ihn zur
> not auch noch wesentlich kleiner. Und eine Datei wuerde beim Print-Style
> auch reichen. Der
> Screen-Style ist auch noch nicht optimiert. Den koennte ich auch noch
> kleiner kriegen.
>
> > Bytes sparen ist wirklich wichtig, ich brauche noch 64k fuer
> > 2-Megabyte-Flash-Geraete...
>
> Wie viel Speicher waere denn fuer das Webfrontend noch frei? Und wie viel
> Speicher brauch denn eine z.B. 1 Byte grosse Datei auf der Firmware
> wirklich?
>
> Liebe Gruesse
> Alita


_______________________________________________
Berlin mailing list
Berlin at olsrexperiment.de
http://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin