Liebe Verleger [Update]

Also liebe Verleger,

wisst Ihr eigentlich, was Euer Problem ist? Ihr selber. Ihr schiebt das Argument Pressefreiheit vor, aber eigentlich wollt Ihr nur Geld.

Ihr müsst doch gar keine App für Apple, das iPad und den AppStore machen. Es geht doch schließlich nur um (s.og. Link) „Pressefreiheit“ und so – warum macht ihr nicht einfach eine (mobil optimierte) Variante Eurer Internetplattformen? Für Eure Informationsarten eine quasi un-ein-ge-schränkte Möglichkeit der Informationsverbreitung. Da können die Schmuddelbildchen rein. Da kann Satire rein. Da kann man sogar ’ne ganze Artikelserie einbringen, wie viel besser Android als das iPhone OS sei. Alles kein Problem. Geht seit Jahren. Wisst Ihr was? Das kann sogar aussehen wie eine „echte“ App. Ja echt, Dinge gibt’s…

Ach, das wollt Ihr aber gar nicht? Wie kann das denn sein? Mal überlegen…

Der Vorteil einer Native App gegenüber einer Web App ist… richtig, man kann den Inhalt bezahlbar machen. Oder, man könnte es auch anders formulieren: Ihr wollt Inhalte, die derzeit meistens im Netz kostenlos vor „Qualitätsjournalismus“ nur so strotzen eben nur noch gegen Geld anbieten (oder die noch gar nicht online vorliegen => Print). Aber natürlich exklusiv, also dafür keinen „Zoll“ bezahlen. Zugegeben, man könnte das auch über die eigene Webseite machen, aber da müsste der Leser ja sich noch einen Account zum Bezahlen bei ClickAndBuy/PayPal/Konsorten machen und anmelden. Und diese tatsächlich existierende Hürde (sic!) wirkt abschreckend. Ach ne, da ist diese AppStore/iTunes-Plattform/Infrastruktur zu verlockend, gerade zu paradiesisch — nur ohne diese Gebühr. Euer Content, Eure Preise, Euer Geld, richtig? Im Internet ist schließlich alles frei. Naja, also fast.

Und erweitern wir doch mal unseren Horizont: Wo sind denn die zahlreichen Apps Eurer Zeitungen und Magazine für andere Systeme wie Android, WebOS? Sind die etwa nicht attraktiv genug, weil noch zu wenig zahlungswillige Kundschaft? Oder fehlt die Infrastruktur?

Gut, den Absatz über Alternativen zum iPad kann ich mir natürlich jetzt mangels möglicher Alternativen schenken — aber irgendwie befürchte ich, dass es noch eine ganze Zeit dauernd wird, bis die „Masse“ an Apps für die Konkurrenz-Tablets kommen wird. Und ob die Benutzer dann auch noch wirklich bereit sind, viel Geld zu zahlen.

Man kann das ganze doch in zwei Punkten zusammenfassen:

  1. Ihr versteht (stellvertetend) Android nicht als mögliche Alternative, als „Wahlfreiheit“ für den Anwender, sondern als eine (nahezu) kostenlose Möglichkeit, Euren Content an den Mann zu bringen. Wie ein billiger Selbstbedienungsladen — nur eben für Euch. Es geht nicht um die Freiheit der Benutzer, sondern um Euer Geld.
  2. Sollte das Modell „AppStore“ für Euch nicht funktionieren, dann ist laut Euch nur Apple daran Schuld. Dass Euer Konzept selbst daran — mal wieder — Schuld sein könnte, das schließt man jetzt schon bereits aus. Clever!

Ein kleiner Tipp: Nach der Sache mit Google solltet Ihr doch gelernt haben, dass die Zeiten heute etwas anders ticken. Sonst kommt Ihr noch auf so abgefahrene Ideen, wie diese hier. Dann Gute Nacht.

Update: Ich habe hier, da und dort gelesen, dass es doch eine Gebühr und Umsatzbeteiligung an Google bzw. den jeweiligen Netzbetreibern (also im Endeffekt kommt ja das gleiche heraus) gibt. Ist das wirklich so? Dann führen die Verlage und Verleger gerade also nur einen Stellvertreterkrieg gegen Apple, weil das iPad gerade so „in“ ist?

Ich habe gerade mal de.androlib.com benutzt: „FAZ“: 0 Punkte, „Spiegel“: 0 Punkte (2 RSS), Focus (Online): 0 Punkte. Sollte da doch eine bei sei – wie habt Ihr die dann gefunden? (AndroLib war jetzt die erste Anlaufstelle für mich, bin ja kein Android-User.)

Muss mich auch in einem Punkt korrigieren: Manche Apps sind zwar wirklich nur beschnittene(!) Content-Lieferanten der eigentlichen Webseite (wie armselig ist das eigentlich, sowas noch als „App“ zu verkaufen?). Der Spiegel scheint tatsächlich die Printausgabe als App auszuliefern. Derartiger Mehrwert darf natürlich bezahlbar sein — auch wenn die Präsentation des Wired Magazines noch ein Deut besser aussieht. Und hier greift auch die Kritik.

HTML5 Youtube Videos in Vollbild / Fullscreen [Update2]

Der HTML5-YT-Player unterstützt leider keinen Fullscreensupport — und deshalb glauben tatsächlich einige Leute, HTML5 könnte kein Fullscreen. Youtube ist der Nabel der Welt…

Eigentlich hat Youtube nur „vergessen“, das entsprechende Control-Element in die Leiste einzufügen.

Für ein kleinen „Geht doch!“-Beweis: Diesen Linkcode im Fenster von Youtube ausführen.

  1. Möglichkeit 1: Den Link einfach in die Linkleiste des Browsers „ziehen“. Beim Betrachten eines HTML5-Videos einfach drauf klicken.
  2. Möglichkeit 2: Den Linkcode in die Zwischenablage kopieren. Beim Betrachten eines HTML5-Videos den Code in die Addresszeile einfügen und ausführen.

Es gäbe noch die Möglichkeit, daraus ein Greasemonkey-Script zu bauen. Wer es unbedingt braucht’s, darf es gerne selber bauen.

Code im Safari4 entwickelt, aber sollte überall funktionieren. Nichts weltbewegendes…

Update: Natürlich geht es dabei nur um ein Vollbild im Browser selbst. Denn selbst dieses Feature unterstützt der HTML5-YT-Player nicht. Ein kompletter, systemweiter Vollbildmodus *muss* über den Browser gemacht werden. Firefox 3.6 hat einen entsprechenden Menüpunkt im Kontextmenü, der aktuelle WebKit als API.

Update2: Tatsache ist, in der WebKit-Nightly hat Youtube auch einen Fullscreen-Button…

Android Upgrades

Die Upgradeparty wird in wenigen Wochen starten können (oder Monate, je nachdem, wie schnell die OEM-Hersteller sind). Aber schon jetzt zeichnet sich ab, das eine ganze Reihe von Gästen schon vorab abgesagt wird.

Android 2.2 wird es für für das G1 nicht geben

Vielmehr sagt HTC, das erstmal (=überhaupt?) nur Geräte aus dem Jahre 2010 in den Genuss von 2.2 kommen werden.

Gab es da nicht letztens einen — wenn auch kurzen — Aufschrei in der Community, als bekannt wurde, dass das drei(!) Jahre alte, erste iPhone nicht mehr mehr in den Genuss eines Upgrades kommen wird.

Lachhaft.

Selbstverständlich ist das kein Problem von Android oder Google, sondern die schlichte Arroganz der Hersteller. Jedes Jahr ein neues „Android“ kaufen kann doch jetzt auch nicht die Lösung sein?!

Fwd: Wo bleiben die ARM-Netbooks?

Der letzte Absatz der Heise-Artikels bringt es auf den Punkt.

Anscheinend gibt es aber auch noch technische Probleme. Dem britischen ZDNet erklärte ARM-Vertriebschef Ian Drew, dass Verzögerungen bei der Implementierung von Adobe Flash (vermutlich meint er Flash 10.1, welches unter anderem Hardware-Beschleuniger zur Videowiedergabe einbinden können soll) dazu beigetragen hätten, dass es noch keine ARM-Netbooks und auch nur wenige Tablets zu kaufen gibt. Da mutet es geradezu ironisch an, dass der Browser des bisher erfolgreichsten ARM-Tablets, des Apple iPad, Adobe Flash nicht unterstützt.

Der Nutzen des HTML5-Hypes

Ich erwähnte bereits gestern, dass der aktuelle HTML5-Hype kaum zu bremsen ist. Man begegnet ihm in Form von Video, aber auch in „HTML5-Tutorials“ oder CSS3-Survival-Kits. Okay, gerade letztes habe ich ja indirekt auch angesprochen. Womit wir wieder am Anfang dieses Absatzes wäre (Achtung: Rekursionswitz).

Oft wird in Diskussionen oder Artikel über den Themenpool „Apple, Adobe, Flash, HTML5, Video“ gesagt, dass HTML5 das Adobe Flash Format oder den Player abschafft. Dann sagen Kritiker wieder: Nein, Flash ist viel besser. Einfacher. Performanter. Verbreiteter. Bekannter. Leistungsfähiger.

In meinen Augen wird sich die Entwicklung ähnlich wie bereits in der Vergangenheit fortführen: das sukzessive Replacement von alten in neue, bewährte Techniken.

Wenn nicht jetzt…

Früher gab es eine Zeit, in der konnte man Rolloverbuttons entweder gar nicht oder nur über Umwege in allen Browsern lösen — die Techniken waren damals Javascript. Heute in der Regel ausschließlich CSS (seitdem der IE das auch kann). Daher lösten einige gewitzte Designer das Problem mit Mini-Flashbuttons. Heute jedoch sind solche Buttons sowie komplette Navigationsmenüs technisch gesehen „out“; und wer so etwas immer noch abliefert, muss sich die Frage gefallen lassen: „Warum…?“.

Auch dynamische Aktivitäten ließen sich eine Zeit lang einfacher in Flash lösen (gepaart mit entsprechenden Effekten) — bis ein paar Menschen herausfanden, dass man nur ein Modewort braucht, um alternative Techniken sich zu nutze machen zu können. Heute gibt es kaum eine Seite, die kein Ajax in irgendeiner Form braucht.

Kennt noch jemand die „coolen“ Flash-Chat-Apps? Sie waren damals schon ein Graus und stammten aus einer Zeit, als Ajax bei Google nur Suchergebnisse für einen Fußballverein oder einen Haushaltsreiniger ergaben. Heute wird sowas in Ajax (und offenen Verbindungen serverseitig) gelöst. Man stelle sich das mal vor: Goggle Mail oder Facebook mit einem Flash, welches sich jedes mal neu lädt. (Okay, schlimmer wäre nur noch eine komplette Fullpage-Anwendung.)

Ebenfalls nahezu erfolgreich wurden die Fotoalben verdrängt, die lange Zeit auf Flash basierten. Während Flickr hierbei ein schlechtes Beispiel wäre, zeigen etwa Googles Picasa Webalben schon seit Jahren, was möglich ist. Oder Apples .mac, jetzt MobileMe. Und auch jeder zweite Internetseite nutzt irgendeine Form von Javascript-Plugin, welche eine Art „Lightbox“ (manchmal mit automatischer Skalierung, FadeIn, FadeOut) zaubert.

Es gab schon immer die Early Adopters — und eben diejenigen, die entweder auf Nummer sicher gehen wollen. Naja, oder die einfach zu faul umstellen sind. Letzteres ist bei HTML5 o.ä. weniger der Fall, da es tatsächlich noch kein (bindender) Standard ist. Es schadet jedoch nicht, die bereits vorhandenen Möglichkeiten anzuschauen und ggf. zu nutzen.

Seitdem Webseitenbetreiber gemerkt haben, dass man auch mittels Ajax auch Werbung in eine Klickserie einbinden kann — *seufz* — wird es meiner Meinung auch verstärkt genutzt. Irgendwo muss ja auch der bekannte Wermutstropfen bei der Sache bleiben.

…wann dann?

In den letzten Wochen, und sicherlich auch noch in den nächsten Monaten, erleben wir das gleiche eben mit neuen technischen Komponenten von Webseiten. Wichtig für eine Akzeptanz ist, dass es während der Umstellung nicht zu inversiv ist. Gleichzeitig kann die Umstellung aber nur richtig funktionieren, wenn alle an einem Strang ziehen. Ein bisschen wie das Henne-Ei-Problem, jedoch machen derzeit ohne Ausnahme alle Browserengine-Hersteller gute Fortschritte.

Folgende Komponenten haben gute Chancen, in den nächsten Monaten und Jahren für moderne Browser von der Bildfläche zu verschwinden.

  • Musikplayer sind bisher als Flash gelöst, weil nicht jeder Browser einen MP3-Link im Browser abspielt — viele bieten dann einen Download an. Beides ist jedoch nicht „embeddable“.. Sicherlich, wir werden bei dem Audio-Tag mit einer HTML5-OGG/MP3/Flash-Weichenkonstellation ein paar Jahre leben müssen. But who cares?
  • Videoplayer sind ebenfalls als Flash gelöst; aus den gleichen Gründen wie Musik. Der Flashcontainer wurde aus der Not gewählt, mangels Alternative. Tatsächlich sind aber Werbeeinblendungen und Editorfunktionalitäten noch in keinem HTML5-Player implementiert (wenn doch, bitte ich um eine Anmerkung). Aber für die einfachen „only play a video“-Fälle reicht das Videotag aus. Genau wie bei Audio wird es auch hier auf eine Weiche hinauslaufen. But who cares? Flash wird auch stets auf zwei Arten eingebunden, dafür gibt es Frameworks.
  • Schriften sind eins der Themen, wieso man bisher immer Grafiken oder sogar Flashs verwendet hat. Grafiken sind statisch und müssen beim Design angelegt werden, Flash ist dynamisch (etwa wichtig für die I18n). Es lassen sich mit CSS3 gute Fallbacks mit Text+Hintergrundgrafik erzeugen. Im Endeffekt haben schriftlastige Seiten und alte Clients dann mehr Traffic als neuere Clients, aber das macht die Natur der Technik ja auch so gut.

Weniger schnell werden sich jedoch andere gute HTML5-Features verbreiten:

  • Offline-Features für Offline-Sitzungen (inkl. einer Datenbank) sind bisher eine technische Barriere gewesen, weshalb man ein Internetbrowserplugin brauchte. Allerdings kann man hier nicht mit Weichen arbeiten sondern muss tatsächlich zwei parallele Versionen (HTML5, Flash) anbieten. Auch wenn dies „nur“ Aufwand für die GUI ist, so ist das Mehraufwand, der abschrecken kann. Da ist es egal, wenn HTML5 auch simple Datenbankstrukturen aufweisen kann — man muss ja eine Alternativlösung für ältere Browser haben.
  • Animationen und Transformationen stecken auch im Moment noch in der Entwicklung — tatsächlich kann man sie auch hauptsächlich im WebKit und in Apples MobileSafari (nicht 100% synchron mit WebKit oder gar Safari4) erleben. Hier ist eine Fallbacklösung ebenfalls schwierig und bedarf tiefer Einschnitte ins HTML-Markup als das sich da jemand darauf — vorerst — einlassen wird. Zu mindestens für einfache Dinge wie „sliden“ kann man jedoch eine JS-Api nutzen, und damit quasi von hinten herum das Feld der unsupported Browser aufräumen. Das wird sich aber zeigen.

Interessant wird es beim Thema Werbung. Prinzipiell scheint mir die Branche aufgeschlossen zu sein, auch neue Techniken (Stichwort: Damals & das „DHTML“) zu nutzen. Ich würde sogar soweit gehen, dass sie es besser steuern könnten, in dem der Adserver einfach nach dem Useragent das passende Codefragment ausgibt. Zur Zeit könnte etwa die etwas ungelöste Frage, wie man HTML5-Werbung vernünftig blockt, für die Branche interessant sein. Vielleicht analysieren die Adblocker von Morgen die Koordinaten und Größenangaben von HTML-Elementen, um Blöcke von Standard-Werbeformaten zu erkennen?

CSS3 erleben – als Entwickler

HTML5 entpuppt sich langsam als ein würdiger Nachfolger des Ajax-Hypes. Das mag zwar von Produkten wie dem iPhone und iPad beeinflusst worden sein, hauptsächlich aber natürlich die fortschreitende Entwicklungen der Browserengines Gecko und WebKit. In gewisser Weise natürlich auch Opera, und — das wird die Zukunft zeigen — wohl auch Trident von Microsoft.

Obwohl CSS technisch gesehen nichts mit HTML zu tun hat, erfahren die CSS3-Features derzeit in der HTML5-Welle eine außergewöhnliche Bedeutung.

Da CSS3 noch nicht endgültig verabschiedet wurde (wenngleich es da auch wahrscheinlich keine größeren Überraschungen geben wird), gibt es leider nicht für alle CSS3-Eigenschaften eine breite Basis — sprich: Gleichheit. So konnte man lange Zeit in Mozilla Browsern nur mit der Eigenschaft -moz-opacity: 0.9 einen Alphawert von 90 für ein Element definieren. Und WebKit hatte natürlich -webkit-opacity: 0.9. Und Opera mit -o-opacity: 0.9. Mittlerweile ist das glücklicherweise einfacher: Die CSS2-Eigenschaft opacity: 0.9 wird von beiden unterstützt, wie auch allen anderen Browsern mit CSS2-Unterstützung.

siehe http://girliemac.com/blog/2009/04/30/css3-gradients-no-image-aqua-button/

Das gleiche Spielchen können wir jetzt auch beobachten, allerdings mit Eigenschaften, welche um einiges komplexer und umfangreicher als die Alphawert-Steuerung sind.

Auf CSS3 Please! kann man beispielsweise auf einem Blick ein paar ausgewählte CSS3-Eigenschaften in Action sehen — inkl. deren vorläufigen Browserengine-Implementierungen. Dabei sind die Auswahlen nicht zufällig (und deshalb auch dieser Artikel). Sie sind allesamt sehr nützlich für Webdesigner, weil sie bisher notwendige Grafikbearbeitungen unnötig machen:

  • Farbverläufe
  • runde Ecken (sic!)
  • Rotationen
  • Schatten

Der Teufel steck im Detail, denn es sind einige Dinge zu beachten, um bereits jetzt Photoshop in die Tonne zu hauen.

Unterschiedliche Namen der vorläufigen Eigenschaften…

Wie bereits erwähnt war das Spiel bei opacity relativ einfach: jeweils den Prefix des Supports (moz, o, webkit) anfügen und gut war.

.alpha { /* Regel mit Unterstützung für Browser ohne endgültigen/vollständigen CSS2-Support */
-moz-opacity: 0.9;
-o-opacity: 0.9;
-webkit-opacity: 0.9;
opacity: 0.9;
}

Man könnte also denken, das die Umstellungen relativ einfach sind — und daher schnell den Rückschluss ziehen, dass der Hersteller doch direkt „opacity“ hätte nehmen können. Klar, heute sind wir schlauer.

Sehen wir uns mal an, wie die Namen der Regeln für border-radius aussehen; diese Eigenschaft steuert den Radius der Ecken („runde Ecken“).

.roundedBox {
-moz-border-radius: 10px; /* jeder Firefox */
-webkit-border-radius: 10px; /* alle aktuelle WebKit basierte Browser */
border-radius 10px; /* CSS3 */
}

Sauber. Allerdings gibt es neben der CSS3-Eigenschaft border-radius auch die detaillierten Eigenschaften border-top-left-radius, border-top-right-radius, border-bottom-left-radius und border-bottom-right-radius. Während WebKit das gleiche Namensschema hat (immer mit dem Präfix -webkit), hat Mozilla ein eigenes: -moz-border-radius-topright, -moz-border-radius-topleft u.ä. Umpf.

Anmerkung: Die Spezifikation der Regel als solches sagt nichts darüber hinaus, wie sie auch in der Browserengine implementiert wurde. Da gibt es einen lesenswerten Beitrag über border-radius vom IE9-Team (!!).

… unterschiedliche Konfigurationsmöglichkeiten…

Anderes Beispiel, gleiche Problematik: Gradienten oder Farbverläufe. Während Mozilla dies über die CSS-Background-Eigenschaft -moz-linear-gradient ab Geck 1.9.2 (=Firefox 3.6) vorläufig implementiert hat, heißt es bei WebKit/Safari -webkit-gradient.

Übrigens: Es ist auch nicht verwunderlich, dass hier Apple genannt wird. Einige Module der CSS3-Spezifikation (etwa Animationen und Transformationen!) werden von Apple-Entwicklern beim W3C angeführt — und werden bereits erfolgreich in den bereits genannten Produkten produktiv genutzt.

So sind folgende zwei Zeilen an für sich im jeweiligen Browser gleich bedeutend:

background-image: -moz-linear-gradient(top, #444444, #999999); /* FF3.6 */
background-image: -webkit-gradient(linear,left top,left bottom,color-stop(0, #444444),color-stop(1, #999999)); /* Saf4+, Chrome */

oder, alternatives Konfigurationsmuster:

background: -moz-linear-gradient(0 0, #000, #fff);
background: -webkit-gradient(linear, 0 0, 0 100%, from(#000), to(#fff));

Hinweis: Während Mozilla eine zweite Eigenschaft -moz-radial-gradient für radiale Gradienten — Kreise 😉 — eingeführt hat, wird dies bei WebKit über den ersten Parameter gesteuert.

Hat noch jemand Einwände, dass die Browserengines vorläufige Implementierungen auch als solche explizit einführen? Nicht wirklich, oder?

… und der Internet Explorer?

Traditionell braucht der Internet Explorer natürlich eine Extrawurst. Das wiegt jedoch nur unschwer als die Lösungen der anderen. Naja, fast. Alle Lösungen sind aus technischer Sicht des CSS-Standards auch nur proprietäre Lösungen.

Microsoft hat seit Jahren ihre eigenen Lösungen unter dem Sammelcontainer filter abgelegt. So heißt das Pendant zu dem oberen Verlauf:

filter:  progid:DXImageTransform.Microsoft.gradient(startColorStr='#444444', EndColorStr='#999999');

Nun ja, dies galt zu mindestens für Internet Explorer 6 und 7. Bei 8 hat sich Microsoft dem Schema der anderen Entwickler genähert, und die proprietäre Eigenschaft filter als solche gekennzeichnet: -ms-filter und Eigenschaften in Anführungszeichen. Ignoriert man bei einer Überprüfung der CSS-Eigenschaften die proprietären Eigenschaften (die mit einem Strich beginnend), so kann man jetzt in der Theorie ein valides CSS erhalten. So weit in der Theorie.

-ms-filter: "progid:DXImageTransform.Microsoft.gradient(startColorStr='#444444', EndColorStr='#999999')";

Leider hat Microsoft zeitgleich für manche Eigenschaften die Variante über filter deaktiviert. Daher gilt: Ab sofort muss man beide Anweisungen im Doppelpack mitangeben um IE6, 7 und 8 ansprechen zu können. Oder wahlweise die Anweisungen in die entsprechenden Conditional Comments packen. Ich wünsche viel Spass beim Chaos.

Schatten

Die Anwendung der Schatten ist ähnlich einfach wie bei den Gradienten, abgesehen von folgenden Problematiken im Internet Explorer:

  • Die Konfiguration eines Schattens kann zu einer wahren Try-and-Error-Orgie führen, weil man selten die Box mit allen 8 Richtungen im Kopf hat (bzw. daran denkt).
  • Der Internet Explorer hat das typische hasLayout-Problem (Lösung: zoom: 1).
  • Sobald ein Element nicht static ist (etwa relative) wird der Schatten unbrauchbar.

Beispiel für umfangreiche vollständigen Schatten in allen Browsern.

Werkzeuge

Als „Nachschlage-Werk“ kann man sicherlich die simple Seite CSS3 Please! nutzen. Ein spezieller CSS Gradient-Generator ist vorhanden, aber ohne IE-Support.

Prinzipiell unschlagbar ist das Script ie-css3.htc — es liest die CSS3-Eigenschaften border-radius, box-shadow und text-shadow und erstellt dynamisch die proprietären Microsoft-filter-Eigenschaften. Die HTML Components sind im Grunde kleine Javascripts zur Erweiterung des Internet Explorers.

Eine Erweiterung für Gradienten wäre wünschenswert, falls jemand sich spontan dazu veranlasst sieht.. bitte 🙂 Der Autor hat sich leider bisher auf meine Mail nicht gemeldet.

Ein kleiner Schönheitsfehler, der scheinbar mit HTCs selber zu tun hat: Die Angabe im CSS muss mit absoluten Pfad gesehen. Das ist unschön und für Webanwendungen mit dynamischen Kontexten schlicht unbrauchbar.

Die Vergessenen

Bei aller Liebe zu den technischen Neuerungen, man sollte nur eines nicht vergessen: Viele Nutzer haben aus verschiedenen Gründen noch einen Firefox 3.5 oder gar 3.0 am Laufen. Und auch Opera-Nutzer sind erst in den neueren Versionen in den Genuß von einigen, aber nicht allen, Eigenschaften gekommen. Bei den WebKit-Benutzern hat wohl die Mehrzahl eine aktuelle Version, sei es durch den automatischen Google-Chrome-Updater oder die starke Verbreitung der 4er-Version von Safari. (Notorische Update-Verweigerer sind selbst für ihr Dilemma verantwortlich.)

  • Gradient: Eine Fallback-Lösung kann man unter Umständen über die Eigenschaft background-image erstellen.
  • Border-Radius: Nicht ohne HTML-Markup-Änderungen.
  • Shadow: Schwer bis unmöglich.

Mit anderen Worten heißt das: Sofern border-radius und box-shadow nur nice-to-have Features sind oder es vernachlässig ist, wenn ältere Browser die Seite unvollständig anzeigen, stehen dem Einsatz keine Grenzen mehr!

Nützliches

Mein Lieblingsthema: Android

Ich kann es nicht lassen, aber über Android hatte ich mich ja schon mal ausgelassen 🙂

Data collected during two weeks ending on May 3, 2010 (borrowed from http://developer.android.com/resources/dashboard/platform-versions.html)Google hat jetzt veröffentlicht, wie die Verteilung von Softwareversionen grad so ist… und… Überraschung: Android 1.5 führt. Und dann 2.1, aber dicht gefolgt von 1.6. W-O-W. Die Geräte- und Mobilfunkhersteller lernen auch im dritten Erfolgsjahr von Apple einfach nicht dazu. Es wird die 66% der Benutzer sicher freuen, dass sie wahrscheinlich bspw. nie die offizielle Twitterapp nutzen können. Selbstverständlich nur ein Stellvertreter für alle neuen Apps – man muss ja kein Twitter nutzen.

Notiz am Rand: Während Golem.de korrekterweise von „Zwei Drittel aller Android-Smartphones sind veraltet“ spricht, beschönigt Heise das mit „Android 2.1 holt auf“. Stimmt zwar, liest sich aber anders.

Griechenland…

Der Artikel bei der tagesschau ist echt nicht zu übertreffen. Un-mög-lich! Beispiele gefällig?

Staatsbedienstete können durch diverse Boni bis zu 1300 Euro pro Monat hinzuverdienen. Extrageld gibt es beispielsweise für die Nutzung eines Computers, das Beherrschen einer Fremdsprache oder das pünktliche Erscheinen am Arbeitsplatz.

Bei uns selbstverständlich.. ??!

Eine griechische Eigenheit ist die Existenz von Hunderten staatlich berufener Gremien – wobei oft unklar ist, warum sie bestehen. So gibt es eine Kommission, die den See Kopais verwalten soll. Der ist allerdings schon in den 30er-Jahren des vorigen Jahrhunderts ausgetrocknet.

Wahnsinn.

Wegen der Schuldenkrise ist für 2010 ein [Verteidigungs-]Etat von nur noch 6,7 Milliarden Euro vorgesehen. Die Regierung hat zugesichert, in diesem Jahr maximal 1,8 Milliarden Euro oder 0,7 Prozent des Bruttoinlandsproduktes für Waffenkäufe auszugeben.

Ja super. Man hat ja sonst nichts zu bezahlen.

In diesem Zusammenhang auch zu erwähnen: The New York Times: Europe’s Web Of Debt. Vor allem, die schulden sich das ja gegenseitig. Irre.