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

[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
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: Digital signature
URL         : http://lists.olsrexperiment.de/cgi-bin/mailman/private/berlin/attachments/20050925/ab2975d9/attachment.pgp 
-------------- nächster Teil --------------
_______________________________________________
Berlin mailing list
Berlin at olsrexperiment.de
http://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin