Über die berühmten CSS Media Queries haben wir ja schon viel gehört und gelesen. Mitunter werden sie unnütz für das mobile Web angesehen und ohne eine nennenswerte Zusammenarbeit mit Javascript wird man wohl auch nicht auskommen. Damit wissen wir ja schon einiges. Hier im Blog sind sie seit den letzten kosmetischen Korrekturen im Einsatz (einfach mal die Fenstergröße anpassen oder Codecandies auf dem Kindle 3 aufrufen), sehr schön kann man das auch bei den iAs anschauen.
Was Jason Grigsby vor allem kritisiert ist, dass man um eine Anpassung bspw. für mobile Clients zu erreichen, mehr anstatt weniger Code hinzufügt:
The idea of adding more code—adding more to download—in order to optimize for mobile should be the first clue that this isn’t a good solution.
Das wäre natürlich kontraproduktiv und ist für große Websites, die sowieso schon immer mit ihrem Gewicht zu kämpfen haben auch tatsächlich keine Alternative. Zudem hat man ja auch keine Unterscheidung für die ausgelieferten Medien, bspw. Bilder. Große hochaufgelöste Bilder braucht man bspw. für das iPad, aber nicht für das kleine Display eines Mobiltelefons. Smartphones wie das iPhone4 fallen aus dieser Kritik aber eher heraus, lechzt es doch nach noch höher aufgelösten Bildern als der Desktopwebbrowser. Hier müsste dann je nach Nutzungssituation unterschieden werden.
Allen Lösungen gemein ist im Moment, dass die mit media queries spezialisierten Seiten, nur wenige kleine Effekte anbieten, bspw. schmalere Spalten, verkleinerte Bilder etc. Was aber, wenn die Seiten für das iPad und später auch das iPhone wirklich komplett anders aussehen sollen? Versucht man sämtlichen CSS-Code zu überschreiben, landet man schnell in der Codinghölle und das Gewicht der Seite explodiert. Ich habe mich nun gefragt, mal in Bezug auf das iPad (und andere Tablets) gesehen, deren Nutzung ich weniger als mobile Nutzung betrachte, wie man mit den media queries nun zwar genug, aber eben möglichst wenig CSS-Daten an die Browser schicken kann. Mein derzeitiger Lösungsansatz sieht so aussiehe Update am Ende des Artikels:
Zur Erklärung: Zunächst mal werden die IEs bedient, die derzeitig nicht in der Lage sind media queries auszuwerten. Der bekommt ganz normal sein CSS geliefert. Die restlichen Stylesheets ignoriert ein IE dann geflissentlich. Alle anderen Browser widerum ignorieren die conditional comments und falls sie eine min-device-width größer 769px haben, laden und zeigen sie das normale base.css. Hernach folgt dann das CSS für das iPad, mit einem Query auf seine Werte abgestimmt.
Soweit zur Theorie. In der Praxis scheint das so zu funktionieren. Lädt man viele verschiedene CSSse, kann das allerdings schnell unübersichtlich werden, da alle nichtmobilen CSSse doppelt aufgeführt werden müssen.
Anregungen und andere Ideen sind mehr als willkommen.
Update: Zwei Tatsachen haben inzwischen dazu geführt, dass ich selbst nicht mehr so überzeugt von dieser Lösung bin: 1. werden ob mit media queries oder ohne immer alle Dateien vom Browser gezogen. Man spart aber ggf. durch weniger CSS-Überschreiben, je nach Art und Größe der Styles; 2. wichtige Info: schon Firefox 3.0 kann keine CSS media queries.
Soeben habe ich Kathrin Passig bei Buzz entfollowed, wegen zwei fürchterlichen Tiraden über das Sharen und Resharen in Google Reader und Buzz (Teil 1, Teil 2), auf die ich durch diesen Artikel aufmerksam geworden bin. Frau Patzig ereifert sich darüber, dass ihre bei Google Reader geshareten Items oft ohne Quellenangabe weitergeshared werden, somit also ihr, die sie die entsprechenen Quellen ausgegraben hat kein Tribut gezollt wird. Sie bezeichnet zudem diesen völlig normalen Vorgang als Schwarzfahren in der Aufmerksamkeitsökonomie, was mich wirklich ein wenig ärgert. Hört sich für mich eher an, wie Auffallen um jeden Preis.
Was Leute wie Frau Passig einfach nicht geregelt kriegen ist, dass es eine Abstufung im Wirtschaftsmodell der Webaufmerksamkeit gibt. Natürlich glauben diverse Menschen, dass sie auch noch an einem ihrer Darmwinde ein @xyz dranpappen können, der allgemeinen Schaffenshöhe wegen, begreifen aber nicht, dass man genau umgekehrt eben nicht überall den Stempel: »ich hab’s gefunden« drankleben muss, ums mit den Schweizern zu sagen. Ich sehe im sharen eines Blogartikels in Google Reader, mglw. auch noch ohne weiteren Kommentar, selbst einfach nur durch das Anklicken eines Icons, keinerlei Schaffenshöhe. Punktum. Deswegen mag auch jeder von Euch Artikel, die ich im Google Reader resp. Buzz share, unter seinem Namen weitersharen soviel er oder sie mag. Das schert mich wenig und ficht mich auch nicht an. Ich habe dazu nämlich weiter nichts getan, als den Artikel selber gelesen und für gut befunden, nicht aber gut genug, ihn in meinem Blog zu featuren. Dort sammle ich nämlich die wirklich wichtigen Links.
Wenn die Autorin oder der Autor aber selbst etwas dazugetan hat, bspw. in seinem eigenen Blog die Originalquelle in Beziehung zu anderen Quellen gesetzt hat, oder den eigenen Senf dazu getan hat, dann bin ich sofort bereit und willens eine Quelle anzugeben. Lustigerweise gibt es sie dann nämlich auch, die Quelle, mit Link und allem. In Zeiten der weiterverlinkten Links, die verlinkt werden, ist es IMHO müßig, wenn da eine Art Urverlinkungsrecht eingefordert wird. Nervt mich sogar geradezu, wenn beispielsweise auf Twitter hundertfach geretweetet wird. Es ist so langweilig, wenn jemand auf Twitter nichts weiter tut, als auf “Retweet” zu klicken. Nicht dass ich das nicht in Ausnahmefällen auch schon gemacht hätte, aber ich halte Twitter eher für eine Plattform der selbstgetätigten Äußerung, als der Weitergabe von Links. Dafür nutze ich Google Reader. Damit verbinde ich—und jetzt beginne ich mich zu wiederholen—aber noch keine besondere Schaffenshöhe, jedenfalls nicht, wenn ich Links weitershare oder Links von mir weitergeshared werden. Wenn ich jedoch einen Link aus Google Reader in meinem Blog verarbeite, also zu Schaffung eigenen Contents nutze, dann verschweige ich die Zwischenquelle auf keinen Fall. Ist das zu kompliziert? Oder unlogisch?
Leute die das anders sehen, soll es geben, ich muss ihnen aber ja nicht followen. Plonk!
P.S. Nachdem Herr Lobo noch vor kurzem Fileshare als Diebe bezeichnete und nun Frau Passig Linksharer sozusagen der Beförderungserschleichung bezichtigt, würde ich am liebsten aus Sicherheitsgründen alles was ich in deren gemeinsamen Buch »Dinge geregelt kriegen – etc. etc.« gelesen habe, wieder vergessen, es sozusagen entlesen, aber das funktioniert mit diesem altmodischen Kram natürlich wieder nicht…
Ich betreibe ja nun schon seit einiger Zeit dieses sogenannte art directed blogging und es ist mir eins der liebsten Steckenpferde geworden. Im Grunde würde ich ja nur noch gestaltete Einträge posten, aber ich habe ja kaum Zeit normale Einträge zu schreiben, geschweigen denn alle zu gestalten. Und das wäre natürlich auch oft Quatsch, denn es lassen sich lange nicht alle Themen gestalterisch begleiten.
Ich wiederhole mich wahrscheinlich, wenn ich sage, dass Filme und Musik die dankbarsten Themen sind, die zur art direction förmlich auffordern. Fast 20 Uniques habe ich inzwischen abgeliefert, mehr als die Hälfte der Artikel handelten von Film, Fernsehen und Musik. Was ja weder etwas dramatisches, noch verwundertswert wäre: ich liebe das Kino (wenn ich’s zu Hause nutzen kann) und jede Form von Musik. Das passt also.
Inzwischen bringe ich es auch schon auf eine ziemlich respektable Produktionsgeschwindigkeit, es ist eine gewissen Übung eingetreten. Zudem habe ich mir meine Blogumgebung inzwischen soweit gestaltet, dass die Produktion auch leichter fällt. Die gewonnene Zeit investiere ich aber sofort wieder (ich geb’s zu, es gab Ausnahmen). Zur Miniserie über Animes in Deutschland habe ich beispielsweise richtig ein wenig recherchieren müssen, also über das Maß hinaus, was ich sonst in einen Artikel investiere. Oft herrscht jedoch eine Mischung aus Zeitmangel und Ungeduld, was zu einen dazu führt, dass Entwürfe lange herum liegen oder im Schnellverfahren durchgeboxt werden. Soviel zur Arbeitsweise.
Ich werde dieses Hobby auf jeden Fall weiterführen, soviel ist schon einmal klar. Hinderlich bleibt die fehlende Zeit, man hat ja immer so verdammt viel vor. Dabei habe ich noch einen ganzen Batzen Ideen im Simplenote stecken, man muss sie nur mal eben heraus holen. Mal sehen, wann das klappt.
PPK weist uns völlig treffend darauf hin, dass media queries allein noch nicht der Weisheit letzter Schlus sind und das man mit Javascript kombinieren müssen wird.
in den Browser eingebauten Players abzuspielen. Dieser Fakt ist ja nun inzwischen hinreichend bekannt. Auch schon gehört hat man davon, dass man diesen Videoplayer selbst gestalten kann, also eigene Buttons, Seekbar und Controls hinzufügen kann. Aber wie genau macht man das?
Unter dem klanghaften Motto »Sprite up the web« finden wir das Spritely jQuery Plugin, das angetreten ist, die Webseitenwelt mit Spriteanimation ein wenig hübscher zu machen. Und wirklich, dass was wir auf der Seite sehen, und auch einige der Beispiele aus der Early Adopter Gallery, machen wirklich Spass.
Das Plugin stellt zwei Methoden zur Verügung, und zwar sprite(), mit der Elemente aus Einzelbildern animiert werden könne, und pan(), mit der (mehrere) Endloshintergrundbilder animiert verschoben werden können. Das alles soll in den Browsern IE6+, Firefox, Safari, Chrome und Opera funktionieren und außerdem einen angepassten Modus für iPhone, Android und iPad haben. Bitte schön: alles natürlich ohne Flash, Silverlight oder sonstigen Rotz.
EDerzeit liegt Spritely in Version 0.2 vor, es ist also noch Entwicklungsluft nach oben, aber das sieht alles schon ganz brauchbar aus. Bitte testen.
Es hat sich längst rumgesprochen, unter dem Buzzword HTML5 hat die Entwicklung kleiner Applikationen im Web mit standardkonformen HTML, CSS3 und Javascript Einzug in die Welt der Webseiten gehalten. Eines Tages wird man wahrscheinlich doch noch davon sprechen können, HTML5-Seiten programmiert zu haben (oh-oh!).
Dabei sind die Apps die man jetzt schon kennt oft schwergewichtige Ungetüme aus HTML und vor allem Javascript. Das muss natürlich nicht so sein. Um all dem Rechnung zu tragen (und ein wenig Werbung zu betreiben) haben MIX (≅ Microsoft) und An Event Apart einen Wettbewerb ausgerufen: gesucht werden kleine HTML5-Apps, kleiner als 10K, wobei die Verwendung von jQuery, Prototype und Typekit als Webservices ausgenommen sind. Laufen sollen die Apps in der IE9 Preview, Firefox und einem Webkit Browser. Na, dann mal los…
