Codecandies

Das Weblog von Nico Brünjes.

Wenn Mr. Zeldman zum Event lädt, dann können einem schon bei der Gästeliste die Tränen in die Augen treten:

Learn from Tim Bray, father of XML; Google’s Jeff Veen; designer Andy Budd of Clearleft; Khoi Vinh, design director at NYTimes.com; Mint creator Shaun Inman; Newsvine CEO/ESPN redesigner Mike Davidson; and messieurs Jason Santa Maria, Eric Meyer, and me [Anm.: Jeffrey Zeldman].

www.zeldman.com

Wow! (© by M$), das nenne ich eine fette Gästeliste – eine $795-Gästeliste sozusagen. Der 5$-Shake unter den Veranstaltungen nachgerade (© by _ben). Da will man doch hin. 😉

Ich überlege gerade, wie ein gleichwertiger Event in Deutschland aussehen würde…

Ich wollte mir ja immer ein Sammlung alter Macs zulegen. Wie das Leben so spielt – sammeln ist ein teures und mithin aufreibendes Hobby, da muss man entweder irgendwann privat Abstriche machen (also auf den Platz für das Sofa zugunsten eines weiteren Rechners eben verzichten), oder man beendet eben seine Sammlungsbemühungen. Meine Freundin versichert mir sowieso ebenfalls oft und gerne, dass sammeln an sich und sowieso total krank und mit schlechtem Chi (Tschie?) behaftet sei, ein weiterer Minuspunkt für das Projekt »jetzt stelln wir uns die Wohnung mit alten Rechnern zu«. Tja, man muss eben auch abgeben können. Und wenn’s denn solche Freude bereitet, dann macht man das doch gern.

Freunde, Bekannte, Kollegen rufen mich gerne mal zu sich an den Arbeitsplatz, präsentieren einen Schnipsel aus einem CSS und schauen mich dann mit einem großen Fragezeichen im Gesicht an und die Frage lautet: »Warum wird das nicht so dargestellt, wie ich das will?« Mal davon ausgegangen, das HTML– und CSS-Code formal richtig sind, kann es ja schon einmal passieren, dass die eine CSS-Regel die andere überschreibt. Nach welchem Muster dies geschieht, das ist leider Gottes für so manchen der an CSS herumschraubt ein böhmisches Dorf, obwohl ich mir fast sicher bin, dass selbst in »CSS für Dummies« etwas darüber gesagt wurde.

OK, wir wollen ja nicht dumm sterben, deswegen hier nochmal die goldenen Regeln der Spezifität von CSS-Selektoren. Und das geht so: je nach ihrer Spezialität sind CSS-Selektoren von unterschiedlichem Wert oder Gewicht. Ein Beispiel:

[syntax,specificity1.html,html]

Ein passendes CSS dazu könnte so aussehen:

[syntax,specificity1.css,css]

Preisfrage: ist »Hier steht Text« nun grün oder rot? Antwort: rot. Denn #number1 .red p wiegt schwerer als #number1 p. Anders sieht es aus, würde folgendes CSS benutzt:

[syntax,specificity2.css,css]

Nun wird der Text grün gerendert. Das ist kein Hexenwerk, sondern beruht auf einer einigermassen einfachen Berechnung. Je nachdem wie oft ein CSS-Selektor mit IDs, mit Klassen oder mit HTML-Tags ausgezeichnet ist, werden ihm unterschiedliche Werte zugeschrieben. IDs zählen dabei 100, Klassen 10 und HTML-Tags 1, jeweils multipliziert mit der Anzahl des Auftretens. Die obigen Beispiele mal ausgerechnet:

Beispiel1: #number1 p = 1 x 100 + 1 x 1 = 101
#number1 .red p = 1 x 100 + 1 x 10 + 1 x 1 = 111

Beispiel2: #number1 p = 1 x 100 + 1 x 1 = 101
.red p = 1 x 10 + 1 x 1 = 11

Unnötig komplizierter Code wie body #id #subid p span.card hat dann schon ein Gewicht von: 1 + 100 + 100 + 1 + 1+ 10 = 213.

Wer das nicht im Kopf ausrechnen kann oder will, es gibt dann noch eine nette Eselsbrücke. Man zähle zuerst die IDs, dann die Klassen und dann die Tags und schreibe die jeweiligen Werte einfach in dieser Reihenfolge nebeneinander:
body #id #subid p span.card {color: red} /* IDs=2 Klassen=1 Tags=3 = 213 */
[Gefunden in der guten alten WDG HTML Help.]

Damit kann man dann schon ein wenig Spass haben und mit ein wenig Hirnschmalz sein CSS doch einigermassen planen und auch ein Stückweit sprechend gestalten. In meinen aktuelle CSS heisst ein sehr hohes Gewicht immer: diese Regel ist wichtig, sie steht fest, wahrscheinlich im Styleguide, bitte nicht überschreiben. Was für Kollegen die später mit dem Code hantieren schonmal ein Hinweis ist… da könnten sie nun natürlich immer noch mit einem beherzten !important drüber bügeln, aber das müssen sie sich auch erstmal trauen. 😉

Mit Yahoo Pipes: Mashups für den Rest von uns gibt’s bei Frank Westphal (Extreme Programmer. Ruby on Rails Freelancer. Web 2.0 Technologist.) alles nachzulesen, was man als Unbedarfter über Yahoo! Pipes wissen muss und sollte. Sollte man vielleicht ausdrucken.

Dass auf Netlabeln in der Hauptsache langatmige und unstrukturierte Reason-Tracks veröffentlicht werden ist ein Gerücht, dass sich mal eben gerade wieder selbst wiederlegt. Mit dem japanischen Netzlabel »BumpFoot« nämlich und vor allem mit dessen aktuellen Release von DJ Toshio: The Turntablelist. Housezucker aus dem Land mit dem roten Gummiball im Wappen.

Funky-House, wo bekommt man das noch geboten, ausser in der Werbepause oder in den Klaulisten aktueller Chart-Hits? Eben. Und dazu noch einigermassen tricky getrackt, ich liebe sowas: das hätte ich vor Jahren auf jedenfall mit in die Lounge geschleppt. Und dann hätte ich den sich dort regelmäßig am Donnerstag versammelten drei Gästen Everything is gonna be alright vorgespielt, in meiner unverwechselbaren deepen optimistischen Art. 😉

So kann eine Newspaperwebsite aussehen. Tja.

Klassenfahrt

…ach nee, nochmal Schulung. 😀

2 Kommentare

Wohl sehr demnächst erscheint eine neue Version meines Lieblings-Eclipse-Plugins Aptana, eine Preview-Version ist jedenfalls schon erschienen. Der Knüller: Aptana bringt fortan eine integrierte Version eines meiner Lieblings-Firefox-Plugins mit: Firebug.

Und dann wird’s wohl auch ein Buch über Aptana geben, man sucht allerdings noch nach deutschsprachigen Autoren:

We’re interested in partnering with a German author to write a book about the Aptana IDE. If you’re interested, please contact Ingo at ingo (at) aptana.com.

www.aptana.com

Apropos Bücher: Auch über TextMate, den allerallerallerbesten Editoren für den Mac, wird gibt es ein Buch geben. Das vermeldet das immer lesenswerte TextMate Blog.

Im dojo.foo ist aktuell der neueste Release Candidate für Dojo 0.4.2 angekündigt. Viel wichtiger dort ist aber der Ausblick auf die kommenden Releases, inklusive Dojo 1.0, das noch dieses Jahr erscheinen soll.

Die 0.4.2-Version von Dojo soll vor allem Fehler der 0.4.1 beheben und enthält in diesem Sinne keine neuen Features, sie wird in zwei Wochen verfügbar sein. Allerdings wurde kräftig am Dojo Build System geschraubt – ein Feature, das leider viel zu wenig genutzt wird und nun vielleicht zu seiner verdienten Ehre kommt:

While 0.4.2 doesn’t include new features, the build system has changed significantly thanks to the hard work of James Burke from AOL. It now supports cross-domain builds even better and a new sub-domain, build.dojotoolkit.org, has been setup to support a brand-new web-based build tool.

Viel neues wird es dann aber bis zur Version 1.0 geben, die für den Spätsommer/Herbst 2007 angekündigt ist und der wohl nur noch ein 0.9-Ast vorhergehen wird.

we will be splitting the project up into 3 separate but coordinated efforts: dojo core, dijit, and dojox. Lastly, it was decided that a major backwards incompatible jump will be made for the next major release of Dojo. To date, we have always attempted to provide at least one full point revision’s warning regarding APIs that were changing or being removed. This policy has allowed attentive users to easily stay abreast of porting their applications between Dojo versions but it has also contributed significant cruft to the core of the toolkit. This cruft will be removed wholesale in the next major revision, Dojo 0.9. No in-code deprecation warnings will be provided. Instead, a full and complete porting guide for 0.4.x users will be created. The extent of the planned changes make back-compat shims unrealistic.

Kenner der Dojo-Dokumentationsbemühungen (sic!) werden spätestens an dieser Stelle die Augen verdrehen: es soll komplette verschriftlichte Richtlinien für das Portieren von Dojo 0.4.x nach 0.9 geben… na hoffentlich. Die (nicht nur hier immer wieder aufgebrachte) ewige Kritik an der Dojo-Dokumentation scheint bei den Dojos zumindest angekommen sein. Denn die oben erwähnte Aufteilung in drei Projekte – dojo.core, dijit (die Widget-Engine) und dojox – zielt u.a. deutlich daruaf ab, bereits gut dokumentierte und gleichzeitig stabile Bereiche von den Spielwiesen der Dojo-Contributoren zu trennen:

All code in the core (and its widget-focused sister project, dijit) will be required to meet stringent quality, testing, and documentation standards. Most of the code currently in Dojo’s utility namespaces is being pored over and most will be either discarded outright or moved to dojox.[…]

dojox will carry on Dojo’s strong tradition of invention. Many of the most important Dojo modules push the edges of what’s possible and have helped to bring the theoretical into the plausible over the last 2 years they will be allowed to thrive in dojox without the restrictions placed on core and Dijit code.

blog.dojotoolkit.org

Das scheint mir der wirkliche Fortschritt zu sein, denn die Probleme, die man als Dojo-Benutzer haben kann rühren eben vor allem aus den genannte Punkten: mangelhafte Dokumentation und starkes Qualitätsgefälle zwischen einzelnen Komponenten von Dojo. Viele Dinge in Dojo funktionieren tatsächlich hervorragend, viele aber eben auch nicht. Man muss bis dato immer überprüfen, ob die Komponente, die man einsetzen will, dem Qualitätsversprechen des gesamten Dojo überhaupt entspricht. Dazu ist viel Testen von Einzelkomponenten von Nöten (oder so gute Javascriptkenntnisse, dass man Denkfehler anderer Programmierer schon beim schnellen Codelesen entdeckt – öhm… dann könnte man aber sicherlich auch selbst eine eigene Engine schreiben), was den Entwicklungsprozess stark verlangsamt. Der neue Ansatz scheint dem entgegen zu kommen, also besteht für Dojo wenigstens Hoffnung.

BuddyWave, der auf IE7 basierende Webbrowser nur für MySpace. Kopfschüttel.

Via: TechCrunch, wo man noch mehr über die schwachmatischen Features von BuddyWave nachlesen sollte.