Any -webkit- feature that doesn’t exist in a specification (not even an Editor’s draft) is not CSS3. Yes, they are commonly evangelized as such, but they are not part of CSS at all.

→

Zunächst einmal die Fakten. Scheinbar ist es so, dass Webentwickler weltweit zu dämlich oder zu faul sind, die für neue und experimentelle Funktionen vorgesehenen Browserprefixe richtig einzusetzen. Offenbar ist bei vielen mit dem Einsatz von -webkit Schluss, dass es auch noch -o, -moz, -khtml und -ms gibt, wissen sie nicht, oder es interessiert sie nicht. Zunächst mal: das müssen ja ein paar schöne Deppen sein, die sowas tun. Nur für einen Browser zu entwickeln, das wäre ja ziemlicher Schwachsinn.

Tatsächlich ist es so, dass viele denken, dass Webkit-Browser die einigen Browser sind, für die man im mobilen Web entwickeln muss. das ist natürlich falsch. Und Webkit ist ja nicht mal ein Browser. Oder ein Browserhersteller (schließlich heissen die Kürzel vendor-prefixex). Eigentlich gibt es gar nicht den einen Webkit:

There are, to my latest count, Safari desktop, Safari iOS, Chrome desktop, Chrome Android, Android WebKit (in various flavours), BlackBerry WebKit, Nokia WebKit (in various flavours), Samsung Dolfin, LG WebKit, Palm Webkit, NetFront WebKit, Obigo WebKit, and UC WebKit. Thirteen browsers, eleven vendors — or fourteen, if you count the Android vendors separately. PPK

Womit Glazman nun droht ist, dass die anderen Browserhersteller anfangen werden, auch -webkit als Präfix zu benutzen (so sie die entsprechende Funktionalität denn anbieten können). Das wäre nun das Ende des Webstandards CSS. Ist es das? Wirklich? Oder ist es vielmehr das Ende der Idee Hersteller-Präfix, die sich in der Praxis offenbar nicht bewährt hat. Der Himmel wird uns wohl nicht auf den Kopf fallen. Und Webkit wird auch nicht die Weltherrschaft an sich reissen.

Vielleicht ist es einfach Zeit, die vendor-prefixes zumTeufel zu jagen und ein beta-Präfix einzufühen, wie PPK es vorschlägt?

Nebenbei bemerkt: das im Laufe der Debatte Lea Verou fälschlicherweise beschuldigt wurde der Präfixfaulheit Vorschub zu leisten… das ist ja fast schon lächerlich.

Aber auch sonst hat sich SVG nicht sonderlich im Netz verbreitet: obwohl man beispielsweise in Adobe Illustrator schon lange nach SVG speichern kann, findet man ausser in der Wikipedia im Web nur seltentst SVG-Grafiken, dafür aber viele viele in Flash umgesetzte Vektorbilder. Im Gegenzug ist die Unterstützung des SVG-Standards in Webbrowsern auch nicht gerade vollständig: neueste Opera-Versionen bringen es auf eine Unterstützung von rund 95% des Standards, die Webkit(s) immerhin noch auf rund 83%. Die 3.7er Previewversion von Firefox bringt dagegen nur etwa 72% SVG-Umsetzung mit. Am weitesten hinten liegt natürlich die PLatform Preview von IE9 mit derzeit 29% (Quelle: Wikipedia). Aber da mag ja noch etwas kommen.

Soll man nun Microsoft danken, und sich darauf freuen, dass man in einigen Jahren endlich Vektorgrafiken auf seinen Seiten nutzen kann ohne den User ein Plugin installieren zu lassen? Mich dünkt, M$ setzt nun Jahre zu spät auf den alten SVG-Zopf, einzig um HTML5-Canvas auszulassen und damit einem ähnlichen Schicksal auszuliefern wie es SVG vor Jahren hatte. Denn zur Umsetzung von Canvas schweigt man bei Microsoft ausgerechnet. Noch ist es nicht raus, aber ich sehe das kommen (denkt an meine Worte).

SVG kann dabei zum Glück nicht mehr unter die Räder kommen, es ist längst platt gewalzt und begraben.

→

Als Absturzursache No. 1 für Safari war und ist Flash sicherlich ein Dorn in Steve Jobs Auge. Adobe gerät dadurch aber extrem unter Druck und wird schon abgeschrieben. Denn der einzige Grund, warum Flash noch hier herumhängt, ist ja Video. Und diese Vorherrschaft wird ja nicht nur von Apple angegriffen.

Schlagen sich die Companies, geht’s anderenorts voran. In Riesenschritten schreitet HTML5 <video></video> auf die Bühne, mit kräftigem Rückenwind von Google, die auf YouTube schon testen. Das funktioniert noch nicht ohne Flash als Fallback und über den Videocodec ist man sich auch nicht einig, wohl aber darüber, dass man Flash für das Abspielen von Videos loswerden möchte.

Und so wie die Berater, die dieser Tage den Sitebtreibern mit CSS media queries aufgeppte Standard-HTML-Seiten, als iPad kompatible Seiten zu verticken suchen, werden diese sicherlich die Abschaffung von Flash Video propagieren. Mindestens in Raten.

Und Flash? Könnte man in Zukunft ja wieder für das Nutzen, wozu es eigentlich gut ist. Nur, was war das nochmal?

Seit Ian Hickson im Interview einen Zeitplan für HTML5 aufmachte, der bis 2022 reicht, wird es nicht mehr ruhig in Standardspiesserhausen. Nicht nur Unbedarfte und Ahnungslose, auch hochdekorierte und anerkannte Szenegrößen liefen zum Sturm, gegen ein Mißverständnis. Man hat fast ein wenig den Eindruck, als ginge es allein um Animositäten und verletzten Stolz. Wie peinlich ist das denn wieder?

Nochmal zum Mitschreiben, Ende 2009 wird die Entwicklungsphase von HTML5 als Standard weitegehend abgeschlossen sein, bereits jetzt werden HTML5-Elemente in Browser eingebaut, man rechnet damit, dass sich HTML5 im Jahre 2022 flächendeckend urchgesetzt hat. Oder wie Anne van Kersteren es schreibt:

What used to be known as W3C Recommendation (in the HTML 4 era) is something we now know as Last Call Working Draft or maybe Candidate Recommendation. Using the new terminology, Ian expects HTML5 to become a Last Call Working Draft in 2009 and W3C Recommendation in 2022. So it’s actually quite close given that the latter date is not that meaningful. On top of that, HTML5 features are already shipping in various browsers today.

annevankesteren.nl

→

• 96% of top blogs are not standard-conform,
• 8% of top blogs have over 500 errors
  (Ben Smith’s Blog, Neatorama, Search Engine Land),
• 28% have 200 – 499 errors,
  (BoingBoing, ProBlogger, Google Blog, Engadget),
• 24% have 100 – 199 errors,
  (TreeHugger, Mashable, ReadWriteWeb, Gigazine, TUAW),
• 22% have 50 – 99 errors,
  (TechCrunch, CopyBlogger, Dooce, Ars Technica, Lifehacker),
• 10% have 1 – 49 errors,
  (Kottke, GigaOM, AutoBlog, Google Blogoscoped),
• 4% have 0 errors
  (e.g. A List Apart).

Zum Glück soll es ausdrücklich keine Anleitung zum erfolgreichen Bloggen sein. Puh, Glück gehabt.

]]> http://codecandies.de/2008/08/01/keine-standards-bei-den-erfolgreichen-us-blogs/feed/ 0 http://codecandies.de/2008/06/24/semantisches-bei-der-bbc/ http://codecandies.de/2008/06/24/semantisches-bei-der-bbc/#comments Tue, 24 Jun 2008 09:06:44 +0000 Nico Brünjes http://codecandies.de/?p=648 Die BBC hat das Microformat hCalendar aus seinen semantic markup standards entfernt, weil es <abbr /> mißbraucht, was widerum die Zugänglichkeit der Dokumente für bestimmte Nutzergruppen erschwert.

Durchaus diskutabel, wie ich leider finden muss. Die <abbr /> und deren title-Attribut werden zur Auszeichnung der Datumsangaben genutzt. Das ist zunächst mal eh’ semantisch nicht korrekt und führt wohl auch zu einem doppelten Vorlesen und damit zu allgemeiner Verwirrung. Hier müsste man das abbr-Design-Pattern wohl anzweifeln.

Cool sind nebenbei bemerkt allerdings die semantic markup standards der BBC. Die werde ich jetzt mal direkt kopieren, übersetzen und ein Logo draufknallen… ;) wirklich phat!

]]> http://codecandies.de/2008/06/24/semantisches-bei-der-bbc/feed/ 0 http://codecandies.de/2008/06/19/html5-working-draft-2/#comments Thu, 19 Jun 2008 07:14:04 +0000 Nico Brünjes http://codecandies.de/?p=636 →

]]> Aktuelle Version des W3C HTML5 WD vom 10.Juni 2008.

→

]]> http://codecandies.de/2008/06/19/html5-working-draft-2/feed/ 0 http://codecandies.de/2008/05/09/first-letter-und-first-line/#comments Fri, 09 May 2008 13:10:58 +0000 Nico Brünjes http://codecandies.de/?p=485 →

]]> Ob CSS Selektoren eine vergessene Spezies sind… wohl eher nicht. Dafür beschreibt man bei webstandards aber alles, was man über die Pseudo-Elemente :first-letter und :first-line wissen muss.

→

]]> http://codecandies.de/2008/05/09/first-letter-und-first-line/feed/ 0 http://codecandies.de/2008/05/06/image-replacement-considered-ok/ http://codecandies.de/2008/05/06/image-replacement-considered-ok/#comments Tue, 06 May 2008 08:22:55 +0000 Nico Brünjes http://codecandies.de/2008/05/06/image-replacement-considered-ok/

So it appears that, short of a set of stone tablets carried down from the hills of Mountain View, we do have a fairly clear answer. Using CSS image replacement in a responsible way, where the image truthfully represents the content it’s replacing, is safe to use. The simple act of hiding text from users is not enough to get your site banned from Google’s index.

mezzoblue.com

Schreibt Dave Shea, ist also wahr.

Since the release of CSS Level 2 Recommendation ten years ago in may 1998, the Web authors’ community has been requesting a way of defining variables in CSS. Variables allow to define stylesheet-wide values identified by a token and usable in all CSS declarations. If a value is often used in a stylesheet – a common example is the value of the color or background-color properties – it’s then easy to update the whole stylesheet statically or dynamically modifying just one variable instead of modifying all style rules applying the property/value pair. We expect CSS Variables to receive a very positive feedback from both the Web authors’ community and browser vendors.

disruptive-innovations.com

Ok, ein wenig dauert’s ja vielleicht noch,… aber man darf hoffen.

1. Es handelt sich um eine erste Betaversion, das merkt man an allen Ecken: Dinge die funktionieren sollten (lt. Ankündigung) oder schon funktionierten (bspw. in IE7), funktionieren nicht, oder falsch. Aufführen muss man diese Fehler natürlich trotzdem, denn man weiss ja, wie schnell man bei M$ Fehler zu Features erklärt und der IE6 war ja der vielleicht längste Betatest aller Zeiten, also… die Angst ist vorhanden, berechtigt und nicht klein.
2. Es deutet sich schon jetzt an, das M$ an einigen Stellen die falschen Entscheidungen getroffen hat. Das implementieren einer ganz eigenen Methode für domainübergreifende XHR wird ebenso harsch kritisiert, wie die Entscheidung das W3C-Event-Modell nicht zu unterstützen.

Meanwhile in the jungle: das IE Blog versucht immer noch die Default Layout Modi des IE8 zu erklären. In den Kommentaren sieht man, dass dies gar so leicht zu sein scheint. Wie soll das erst bei IE9 und IE10 werden? ;) Derweil bloggt das JScript-Team (also das möchte man auch nicht auf der Visitenkarte stehen haben, oder?) über JScript improvements. Und irgendwo las ich vorhin, dass man mit IE8 das Windows Update nicht mehr besuchen kann, um an Updates zu kommen muss man zunächst in den IE7-Modes schalten. LOL.

Wie dem auch sei, bei der eigentlich aktuelleren Challenge des Acid 3 erzielt IE gute Ergebnisse… im Vergleich zu seinem Vorgänger IE7. Der hatte noch mit 11% eine Schulnote 6 kassiert, IE8 steigert das Ergebnis auf 17%, das mag dann schon eine 5 sein. Zum Vergleich sei gesagt, dass auch die anderen Browser Acid 3 noch nicht im Griff haben: Safari 3.0.4 erreicht 39%, Opera 9.26 46%, Firefox 2.0.12 hat 50%, Firefox 3.0b3 immerhin schon 61% und die Spitze halten die WebKit Nightlies mit derzeit 87%.

Ich habe gestern abend noch einen Kurztest durchgeführt und muss zunächst mal feststellen, dass es die typische Betaprobleme gibt. IE8 ist zumindest in dieser Version wieder langsamer als IE7 und die Geschwindigkeit des Renderings war so mit das einzig Positive, was ich am Vorgänger finden konnte. Ziemlich annoying fand’ ich auch den nach jedem Reload erneuerten Hinweis, dass nicht alle Addons geladen werden könnten. Einen leicht zugänglichen Button/Haken: “Diese Warnung nicht wieder anzeigen”, konnte ich allerdings nicht entdecken. Eines der deaktivierten Addons war die “IE Developer Toolbar”, diese wird jedoch durch die eingbauten “Developer Tools” ersetzt, die gerne Firebug wären, es aber natürlich nicht sind. Zu guter Letzt: mein Blog geht im IE8 durchaus durch, alle anderen Seiten die ich besucht habe jedoch zeigen – wenn auch meist nur leichte – Anzeigefehler, häufig dort, wo Ads eingeblendet werden. Da werd’ ich mich mal am Wochenende mit beschäftigen…

CSS Tabellen gibt es schon lange, IE war der einzige Browser, der das nicht unterstützt hat, deswegen sind sie so selten anzutreffen. Tatsächlich jedoch sind sie natürlich ein hervorragendes Werkzeug um spaltige Layouts zu realisieren, denn so kompliziert der HTML-Code für Tabelle immer war (und der fällt ja weg), so einfach zu begreifen ist die visuelle Idee hinter einer Tabelle. Es bestehen gute Chancen, dass in ein bis fünf Jahren – je nachdem wie lange es braucht, bis sich IE8 ausreichend durchgesetzt hat – CSS Tabellen die komplizierten position- und/oder float-Konstruktionen der heutigen Zeit ersetzt haben werden.

Nachdenklich macht mich das ganze nun aus zwei drei Gründen:

• Die Reihenfolge des Contents in Code und Präsentation ist gleich. Es besteht keine Möglichkeit, den wichtigen Content zuerst zu liefern, Navigation etc. nach hinten zu stellen, diese Reiehenfolge in der Präsentation jedoch umzudrehen. SEO-Leute stehen da aber total drauf und bei Nutzern von Screenreadern ist das wohl auch sehr gewünscht.
• So einfach dieses Konstrukt für simple Layouts auch ist, aus den Zeiten des Tabellenlayouts weiss man, wie kompllziert das ganzen wird, wenn man beginnt Tabellen zu verschachteln. Dies wird aber nötig sein, um das umzusetzen, was sich Screendesigner ausdenken, wenn sie wieder beginnen in Tabellen zu denken.
• Ich halte Tabellen für ein böses Relikt aus schlimmen Tagen. Böse. Böse böse böse.
• Ich glaube Tabellenlayouts, ob nun in HTML oder CSS realisiert, sind total 90er. Ebenso kopieren die Gridlayouts, die man heute allenortens trifft, Paradigmen aus der Zeitungswelt, sind also ebenfalls total 90er (allerdings 1890er). Will sagen: ich bin mir nicht sicher, ob es nicht Layouts gibt, die besser ins Netz passen, und für die vielleicht keine Tabellen gebraucht werden. Aber das… ist nur so ein Gefühl. ;)

We’ve decided that IE8 will, by default, interpret web content in the most standards compliant way it can. This decision is a change from what we’ve posted previously.

Hervorragend, da regt man sich auf, spinnt Verschwörungstheorien und schreibt sogar eine grimmige Mail an ALA und dann soetwas: Microsoft rudert zurück. Damit wird, entgegen voriger Ankündigungen, IE8 sich erstmal verhalten wie IE8 und nicht wie IE7. Mit dem inzwischen viel diskutieren <meta>-Tag-Switch kann man IE8 nun in den IE7 Mode schalten. Ein kleiner aber feiner Unterschied.

Now, IE8 will show pages requesting “Standards” mode in IE8’s Standards mode. Developers who want their pages shown using IE8’s “IE7 Standards mode” will need to request that explicitly (using the http header/meta tag approach described here).

Damit wendet Microsoft seinen Hals nach den Webentwicklern, die Webstandards unterstützen. Ebenso ist es eine geschäftliche Entscheidung, wie Quicksmode feststellt:

Microsoft has decided to put the interests of web standards above the interests of the Intranets of its corporate clients.

I advise you to read the previous paragraph again. Even two years ago I had never expected to be able to write such a statement.

blogs.msdn.com

Yes.