Codecandies

Ich verlasse mich ja lieber auf ColorZilla, wenn’s um Webfarben und deren Hexadezimalcodes geht, aber die Idee sich Webfarben anhand von Sprüchen zu merken ist auch nicht schlecht. Müsste man mal in deutsch umsetzen… ;)

… ist down. Ein unfreundlicher Provider hat offenbar nach eine DDOS-Attacke gegen die Site den Hahn zugedreht und die Verträge gekündigt. Mehr dazu bei Learning jQuery. Ich habe gestern die jQuery-Doku zunächst schmerzlich vermisst, aber zum Glück gibt’s ja noch Visual jQuery als Alternative.

Update: jQuery.com ist inzwischen wieder erreichbar, aber bspw. die Doku funktioniert noch nicht wieder…

Update Update: Alles wieder up.

Andy Budd ist Managing Director der »Clear: Left«-Agentur in Brighton und setzt sich in seinem aktuellen Blogposting: CSS2.2 ausführlich mit den Prozessen und Abläufen beim W3C auseinander, die dazu geführt haben, dass CSS heute dort steht, wo es noch vor 1999 gestanden hat. Im Juni dieses Jahres wurden die ersten CSS3-Module als drafts veröffentlicht. Seitdem ist leider nicht mehr viel passiert: CSS3 ist von der flächendeckenden Implementierung soweit entfernt, wie vor 10 Jahren und es scheint auch keine Aussicht auf eine schnelle Lösung zu geben.

Wie Andy treffend feststellt, wird an keinem Standard so deutlich, wie schwerfällig, ja teilweise bewegungsunfähig das W3C und seine Working Groups sind. Die verschiedenen Interessengruppen, die in der CSS Working Group vertreten sind, neutralisieren sich offenbar aufs heftigste. Dabei gerät die Entwicklung und Weiterentwicklung von CSS immer mehr ins Hintertreffen. Es ist sogar so, das Teile des vorgeschlagenen Standards anstatt in der Entwicklung durch die verschiedenen, komplexen Vorschlagsphasen des W3C eher zurückschreiten: das »Selectors Module« beispielsweise stand 2001 im Status Candidate Release und wurde 2005 auf den Status »Last Call« zurückgestuft, wo es bis heute (wieder zwei Jahre später) verweilt. Kurzum: das ganze nimmt groteske Formen an.

Man sollte sich darüber eigentlich nicht weiter aufregen, denn ganz ehrlich gesagt, wen interessiert heute noch die Arbeit des W3C, dort hat man inzwischen oft genug bewiesen, dass eine Working Group dem Namen selten entspricht und eher einem Kaffeekränzchen der sprichwörtlichen drei Affen gleicht: nichts sehen, nichts hören, nichts sagen! Aber gerade im Bereich CSS würde die Entwicklung so dringend gebraucht. In keinem anderen Bereich ist die Implementierung in die verschiedenen Browser so schlecht und dabei Cross-Browser-Kompabilität so wichtig, und vor allem: in keinem anderen Bereich ist der Konkurrenzdruck so hoch!

Besagter Konkurrenzdruck kommt von den Techniken, die ähnliche Werkzeuge wie CSS zur Verfügung stellen, aber von unabhängigen Firmen erdacht und entwickelt werden. Adobe beispielsweise. Oder seit neuestem Microsoft. Sie stellen mit Flash, Flex, Apollo und Silverlight Tools zur Verfügung, die heute das Webdesign ermöglichen, wie es eigentlich CSS ermöglichen sollte. Dort unterliegt man nicht ewigen Gruppensitzungen und Diskussion, man erdenkt, entwickelt und veröffentlicht. Kann man eigentlich nicht mal böse drüber sein.

Aber es bringt die HTML/CSS-Gilde ins Hintertreffen, denn während die Anforderungen immer weiter steigen, sind die Möglichkeiten die man mit CSS hat im Grunde gleich geblieben in den letzten 10 Jahren, mal abgesehen davon, dass eine Menge Hilfstechniken erdacht wurden, um die Probleme von CSS zu umgehen und das IE7 erschienen ist. Wer heute den typischen Anforderungen der Kunden gerecht werden will, kann sich kaum noch auf reine HTML-CSS-Konstrukte verlassen, sondern muss mindestens auf Javascript zurückgreifen – einige stellen beispielsweise schon heute die CSS3-Selektor cross-browser zur Verfügung, die es noch gar nicht gibt. Webdesign und Webentwicklung geht – wenn es so weitergeht – deswegen zwei drei tragische Wege:

• Immer mehr Design wird in den Bereich Flash etc. verlagert, also weg von offenen Standards, hin zu von Firmen und Konzernen gelieferten Techniken,
• bei der Erstellung von Webseiten wird zur Relalisierung designerischer Elemente eine zusätzlich Programmiersprache benötigt (Javascript),
• zumindest durch ersteren Trend gerät mit CSS auch HTML immer weiter ins Hintertreffen.

Die Konsequenzen sind sowohl im politischen Bereich zu finden, als auch in den Bereichen Zugänglichkeit und Bedienbarkeit des Webs.

Zurück zu Andy Budd: er sieht ein Problem, das die CSS3 Working Group quält darin, dass man sich einfach viel zu viel vorgenommen hat und schlägt deswegen vor, eine Version 2.2 einzuschieben, die zumindest das festschreibt und zementiert, was heute schon in viele Browser an CSS3-Funktionalitäten eingebaut ist. So könnten zumindest diese Teile des Standards auf einen in Zukunft flächendeckenden Einsatz hoffen. Die Frage die bleibt: wie lange wird man brauchen um sich zu einem solchen Schritt zu entschliessen, und wie lange dauert es dann, bis ein entsprechender Standard beschlossen und veröffentlicht ist? Und wann ist das dann alles im gerade meistbenutzten Browser eingebaut und verfügbar? Wir warten!

Welt-Relaunch-Chef Peter Schink im Interview mit den Webkrauts zum Thema Newssite-Relaunch:

Es ging wahnsinnig schnell – erste Designs gab es Anfang Juli, ab Oktober wurde programmiert – und siehe da, Mitte Februar sind wir auch schon online gegangen – rasend schnell für ein Projekt dieser Größenordnung, wenn man auch noch die Aboverwaltung und ähnliches migrieren muss.

www.webkrauts.de

Über die Technik weiss Herr Schink nicht viel zu sagen, aber er verrät eine Menge übe die Arbeitsweise der technischen Abteilung der Welt-Onliner.

Formulare sind auch so ein Gebiet, wo der Auftraggeber gewöhnlicherweise am wenigsten Vorstellungen hat, wie sie auszusehen haben, jedoch genau weiss, wie sie nicht aussehen sollen. Auf Zugänglichkeit und Nützlichkeit wird dabei in der Regel wenig Wert gelegt, und auch wenig daran gedacht, dass Formulare im Netz nicht so funktionieren, wie bspw. die Eingabefelder in einer Excel-Tabelle. Ich habe dahingehend eigentlich alles Ansätze durchgespielt: auf die Wünsche des Kunden komplett eingehen, und alles was möglich ist mittels Javscript und Ajax herausholen oder auch zu versuchen, Accessibility und Usability zu diktieren: funktioniert leider beides nicht so richtig (hinsichtlich User- und Kundenzufriedenheit).

Ausserdem habe ich festgestellt, dass verschiedene Entwickler sehr unterschiedliche Ansätze bei der Umsetzung von Formularen haben, was vor allem bei großen Websites oft dazu führt, dass Formulare keineswegs einheitlich gleich funktionieren. Oft werden Formulare auch schon von Anwendungen schlecht vorgegeben und sínd schwierig anzupassen: bspw. in Drupal.

Vielleicht hilft allen dabei Uni-Form:

Uni-Form is an attempt to standardize form markup (xhtml) and css, “modularize” it, so even people with only basic knowledge of these technologies can get nice looking, well structured, highly customizable, semantic, accessible and usable forms.

dnevnikeklektika.com

Die Formulare von Uni-Form sehen nicht nur gut aus (das auch), sondern verfolgen sehr geschickt einen standardisierten Ansatz der Bedienbarkeit. Das scheint mir alles sehr gelungen und durchaus ein zwei Überlegungen Wert, ein solches oder auch genau dieses Modell in die Site zu übernehmen.

In einem früheren Projekt haben ich schon ein paar schlechte Erfahrungen mit asynchronen File-Uploads sammeln dürfen, es hat einige Zeit gedauert, das cross-browser-kompatibel zum Laufen zu bringen. Bei El Micox gibt’s nun eine ziemlich sauber ausformulierte Version eines asynchronen Uploads via iFrame, dass sich sicherlich auch gut in jQuery o.ä. Libraries umsetzen lässt. Empfehlenswert.

Better Explained ist ja irgendwie auch ein sehr vielversprechender Name für eine Website. Dort finden wir aktuell: How To Debug Web Applications With Firefox, eine saubere Auflistung der drei essentiellen Debugging-Hilfen für Webanwendungen: die Web Developer Toolbar, Firebug und Live HTTP Headers, sowie jeweils eine kurze Anleitung, wie man die genannten Extensions benutzen kann. Level: Starter. [via roScripts: Top developer tools of the month.]

Firebug gehört wirklich, wirklich zu den nützlichen Tools, die man beim Entwickeln verwenden kann. Ein kleines Beispiel, mal so aus dem praktischen Geschäft heraus…

Beim Schreiben angepasster Stylesheets für den IE benutze ich ausgiebig Firebug. Und zwar lade ich mir im Firefox die Seite und identifiziere parallel die Anzeigefehler im IE. Mit dem Firebug lasse ich mir dann die Styles des in Frage kommenden Elements anzeigen (siehe oben).

Irgendwann bin ich dann dazu übergangen, den ganze Styleblock aus der Firebug-Ansicht heraus zu kopieren und in das IE-spezifische Stylesheet zu pasten. Dort editiert man den Block wie gewünscht. Und um die mitkopierte Datei- und Zeilenangabe kommen flugs Kommentarzeichen drumrum. Fertig: eine sauber referenziertes Stylesheet für den Deppenbrowser…

So. Feierabend für diese Woche. Zu Hause wartet schon unser Balkon.

Das Project Honeypot macht auf sich aufmerksam, indem es eine Woche lang Projekte vorstellt, die es initiiert. Das Projekt von gestern »http:BL« hört sich ziemlich interessant an: eine Spammer-Blacklist, die mithilfe eines Apache-Moduls abgefragt werden kann und dann Verdächtigen bspw. gleich den Zutritt zur Webpräsenz verwehrt (oder Emailadressen aus dem HTML ausfiltert o.ä.). So könnte man sowohl Kommentarspammer aussperren und Emailharvester ins Leere laufen lassen (sic!). Und dabei jede Menge Bandbreite sparen… Alles noch Beta, aber wie gesagt, klingt wirklich gut.

Douglas Crockford gibt im Yahoo! Interace Blog eine kleine Lehrstunde in Sachen switch-Statement. switch, geerbt aus einer langen Ahnenreihe von Programmiersprachen (Java, C++, C), kann ein mächtiges Instrument sein. Aber – mächtige Instrumente habe das oft an sich – es ist auch gefährlich: man kann es viel zu sehr zu einem goto umwandeln, was man nicht will. Auch wenn die Erinnerung an alte Brotkastentage lebt:

10	print "Dummes Zeug"
20	goto 10

LOL. Nein, nein, das wollen wir nicht.

Und switch hat noch ein anderes Problem: die sogenannten Fallthroughs. Allzuoft (das sieht man auch gerne mal in PHP-Programmen) wird es benutzt, um für eine Bedingung mehrere Tasks auszuführen, ganz einfach indem man das break am Ende eines case-Blocks weglässt. Denn dann wir bekanntermaßen fröhlich weitergeswitched. Was als prima Trick daherkommt, ist gar nicht so schlau, weil das Vergessen eines breaks eben auch ein unfreiwilliger Bug sein kann. Und wer geht nun hin und findet in ein paar tausend Zeilen Code die Blöcke, die absichtlich kein break haben und welche nicht? Eben.