With all the heck about Apple blocking and removing applications from the App Store there clearly are some things they don’t have a problem with:
In all the clauses of the App Store there has to be one banning mass-application-submission, doesn’t it?
Oh by the way: those “SpeedDate” apps at the moment fill about the first three pages if you sort by date so there are about 60 of them…
Yesterday there appeared a screenshot containig a nice localization problem in fscklog:
Christian in iTunes 9 - fscklog.com
So what’s the problem: the user who submitted this screenshot is named “Christian” – you’ll see the consequences.
Another cool thing that happened to me:
iTunes 9 Deutschrock-Mix
“Franz Ferdinand” in my “Deutsch-Rock-Mix”? Well, as well as two Rogers don’t make a right – two German names don’t make it German music.
By the way: Genius mixes is really awesome!
After following today’s WWDC 2009 Keynote held by Phil Schiller and more Apple of course had to switch the new versions of their site online. See some screenshots appearing on my side, (both Firefox and Safari involved ;-) ). Of course they’re all property of Apple Inc. (unfortunately, in this quality)… in my company we would say “there was a trainee on the website!”
You get the idea that it’s none of Apple’s business switching sites online every day (in contrast to my company ;-) )
Ich war erfreut zu lesen, dass Firefox 3.1 mit Gecko 1.9.1 nun ebenfalls das Selectors API unterstützen wird.
Gleichzeitig ist mir ein Artikel von John Resig vom 10. Juli aufgefallen, der sich ebenfalls mit einer Test Suite für das Selectors API beschäftigt. Im Gegensatz zu den Performance-Tests werden in dieser Test Suite die einzelnen Implementierungen auf ihre Vollständigkeit der Selektoren hin überprüft. Mir waren bei Webkit/Safari schon Fehler bei etwas “exotischeren” Selektoren aufgefallen, was sich hiermit bestätigt hat. Die Implementierung Firefox 3.1 hingegen deckt laut Artikel schon weite Teile (ca. 70%) der Selektoren ab.
Ich werde mir in den nächsten Tagen eine Alpha-Version von Firefox 3.1 besorgen und hier ebenfalls die Performance testen.
Seit einiger Zeit (2007 und davor) gibt es die Selectors API als Working Draft des W3C – wem sie noch nicht bekannt ist, hier wird sie nun kurz vorgestellt.
Die großen Neuerungen durch dieses API heißen querySelector() und querySelectorAll(). Mit ihnen kann man sich anstatt den DOM-Tree manuell zu durchlaufen sehr schnell (da im Browser zu implementieren) entweder eines oder alle DOM-Elemente zu einem CSS Selektor zurückliefern lassen. Doch wie sieht es mit der Unterstützung aus?
Da hierdurch in unterstützenden Browsern ein enormer Performance-Gewinn bei derartigen Operationen zu erwarten ist, halte ich dies für eine erfreuliche Entwicklung. Auf Surfin Safari gibt es dabei noch einige Beispiele, was sich damit sehr gut ausnutzen/umsetzen lässt.
Für alle Browser, die die Selectors API noch nicht implementieren (und das sind nach diesem Stand ja noch ein paar) gibt es aber auch einen netten Workaround: base2.DOM von Dean Edwards ist eine offene JavaScript Implementierung der Selectors API, ist somit Cross-Browser tauglich und bietet noch ein paar Fixes für fehlerhafte Selektor-Handhabung durch den Internet Explorer.
Verwundert hat mich nur, dass dieses API (wie schon so Einiges) sehr lange beim W3C liegt und erst jetzt so langsam davon Gebrauch gemacht wird. Bei mir in der Firma war dies ein völliges Novum. Ist es anderen schon länger bekannt?
Gestoßen bin ich auf dieses API während der letzten Frontend-Optimierungsmaßnahmen bei denen sich mir die Frage stellte ob es nicht möglich ist, ungenutztes CSS automatisiert zu erkennen und zu entsorgen. Nun damit geht das allem Anschein nach sehr gut. Ein willkommenes Thema für meine zweite Projektarbeit.