Bei unserer Tonqualität ist es wie beim Google Linkjuice: Zählt man alle Beteiligten zusammen, kommt immer die Zahl 1 heraus. Während Markus nun also THX-Ultra-zertifiziert ist, zerbröselten unserem Gast Nico Brünjes, Frontendentwickler bei ZEIT ONLINE, reihenweise die Headsets unter den Fingern weg :(
Schaunotizen
- W3C HTML5 Logo!
- Das ansonsten eher langweilige W3C überrascht mit einer Art Promotion-Aktion: Auf einer sehr schicken, modernen Seite präsentiert es ein Logo, das vielleicht von Superhelden, vielleicht von einem 3D-Würfel inspiriert ist. Dazu gibt es einen HTML5-Gummipunkt-Generator und ein T-Shirt. Wir finden’s gut und Nico hat sich direkt das T-Shirt bestellt.
- HTML is the new HTML5
- Die WHATWG denkt die korrekte Namensgebung der HTML-Version-nach-HTML-4.01, formerly known as HTML 5, formerly known as HTML5, konsequent zu Ende und stellt fest: Die HTML-Spezifikation ist permanent im Fluss und macht keinen Halt bei Versionnummern, also weg mit der 5! Ab jetzt heisst die Spezifikation selbst nur noch HTML. Und HTML5 möge neuerdings ein Schlagwort für diejenige Generation Webanwendungen sein, die allem Web-Zwo-Nulligen nachfolgt. JavaScript und CSS als Techniken inklusive.
- Using CSS Selectors as Fragment Identifiers
- Der altehrwürdige Eric Meyer und Simon St.Laurent von O’Reilly Media haben einen inoffiziellen Draft online gestellt, in dem sie eine neue Sprungmarker (Fragment) Syntax im CSS-Selektor-Stil vorschlagen. So soll man beispielsweise mit folgender URL direkt zu dem zweiten Absatz einer Seite springen können:
http://example.com/lorem.html#css(p:nth-child(2)). - Learning from Twitter
- Dass man selbst mit jQuery noch großen Bockmist bauen kann, haben letzte Woche die Twitter-Programmierer bewiesen. Dumm war, dass sie behauptet hatten, es läge an der neuen jQuery-Version dass Twitter neuerdings so langsam geworden war. Das hat John Resig dazu animiert, sich deren Code genauer anzuschauen, und er hat dabei Grauenhaftes zu Tage gefördert.
- Hinter dem mobilen Proxy
- Unser Gast Nico Brünjes schrieb letzte Woche über eine sehr unangenehme Entdeckung, die er und sein Team von ZEIT ONLINE machten: Die mobilen Zugangsprovider manipulieren das HTML, JavaScript und CSS nach gutdünken um, und vor allem stillschweigend. Das geht dummerweise ganz und gar nicht zerstörungsfrei vonstatten.
- Mozilla plant Do-not-track-HTTP-Header
- Mozilla und Microsoft planen, den Browser mit einer zusätzlichen Header auszustatten, dem
X-Tracking-Choice: do-not-track. Dieser soll immer dann gesendet werden, wenn der Benutzer von Inhalteanbietern nicht getrackt werden will. Das Ganze setzt allerdings voraus, dass die Gegenseite diesen Header auswertet und respektiert. Beim Diskutieren darüber kommt uns die Robinson Liste in den Sinn. Google will es in Chrome hingegen via Browsererweiterung lösen. - ARPAgeddon (IPv4 Countdown)
- Unser Vorrat an IPv4-Adressen geht nun wirklich zur Neige. Knapp über 30 Millionen Adressen sind noch frei, 4,3 Milliarden sind in Gebrauch. Laut ARPAgeddon hält der verbliebene Vorrat noch für etwa eine Woche. Es wird also höchste Zeit, breitflächig auf IPv6 mit seinen 665 Billiarden möglichen IP-Adressen umzusteigen – auch wenn es vielleicht weh tun wird.
KEINE Schaunotizen
- UglifyJS
- Neuer JavaScript-Minifizierer und -Beautifier (Gegenteil von ersterem), der auf node.js läuft und dadurch doppelt bis fünf mal so schnell arbeitet wie der YUI Compressor oder Googles Closure. Kommt im Gegensatz zu letzterem auch mit
eval()und (dem bösen)with{}klar, und verfügt über eine Google Closure kompatible HTTP-API. Steckt auch im kommenden WebKit Webinspector
Kommentare
Peter #
Geschrieben am 25.01.2011 um 20:53
Also zu UglifyJS… wenn das Programm wirklich auf
with {}klarkommt, ist das ein Bug und kein Feature. Das ist nicht umsonst in ES5 Strict rausgeflogen. Übles Ding.Jens #
Geschrieben am 26.01.2011 um 15:12
Ich höre nun seit Jahren Podcasts und möchte euch ans Herz legen auf Gäste zu verzichten die nicht ansatzweise zu verstehen sind.
Schepp #
Geschrieben am 26.01.2011 um 17:17
Da rennst Du offene Türen ein. War auch unser Fazit.
Frank #
Geschrieben am 31.01.2011 um 20:30
Was schade ist, da auch Nico als Person zu kurz kommt.
PAT #
Geschrieben am 29.01.2011 um 18:40
Das Mikro ist schrecklich, man versteht kaum was!
Peter #
Geschrieben am 29.01.2011 um 18:57
Kommt nicht wieder vor. Versprochen.
Nico #
Geschrieben am 11.03.2011 um 13:14
Ich finde den Vorschlag CSS-Selektoren zur Adressierung zu nutzen nicht sonderlich sinnvoll. Eine Dokumentstruktur kann sich über die Jahre ändern (im einfachsten Fall durch ein Redesign, im schlimmsten Fall durch hinzufügen neuer Absätze, Werbung, etc.), eine URL sollte aber möglichst eindeutig sein. Der Effekt, dass man bereits nach wenigen Monaten an eine völlig andere Stelle verlinkt ist dabei ja quasi vorprogrammiert. Meiner Meinung nach kann das nicht sinnvoll funktionieren.
Schepp #
Geschrieben am 11.03.2011 um 13:36
Die Frage ist: Ist der herkömmliche Weg, also über IDs oder benannte Anker zu gehen diesbezüglich robuster? Nicht unbedingt. Desweiteren erlaubt das Selektoren-System, zusätzliche Fallbacks anzugeben, was auch nicht zu verachten ist. Deshalb würde ich insgesamt sagen: Auch wenn es nicht bulletproof ist, besser als das jetzige System ist es allemal. Also her damit!
Nico #
Geschrieben am 11.03.2011 um 14:30
Robuster ist es allemal, denn IDs sind eindeutig. Angenommen ich arbeite in einem CMS und ändere das Layout, dann sind die IDs, die ich in meinem Content vergeben habe auch nach einem Redesign die gleichen, die CSS-Selektoren führen aber unter Umständen ins Nirvana (inkl. der Fallbacks). Das System mag kurzfristig funktionieren, aber da es keine Haltbarkeitsdaten für Links gibt wird es dazu führen, dass wir nach etlichen Jahren unzählige Links haben, die ins Nirgendwo zeigen, auf einen bestimmten Punkt Bezug nehmen, aber nicht erklären auf welchen, weil der Link zur Erstellung ja genau darauf hingewiesen hat.
Das Beispiel mit den Kommentaren, dass ihr im Cast hattet, ist sehr gut in dieser Hinsicht. Angenommen ich kommentiere Kommentar #3 in einem Blog und darauf wird mit einem CSS-Link verwiesen. Nun wird Kommentar #2 allerdings aus irgendeinem Grund (rechtlich, Spam, vollkommen egal) entfernt. Nun verweist mein Link auf den ursprünglichen Kommentar #4, weil dieser nun aufgerückt ist zu Kommentar #3. Eine Lösung hierfür wäre gelöschte Kommentare als leere Elemente zu hinterlassen, aber ich denke wir wissen beide, dass in der Praxis diese Lösung eher selten eingesetzt werden wird.
Schepp #
Geschrieben am 11.03.2011 um 14:44
Das kann passieren, ja. Aber wenn Du IDs beim nächsten Redesign weglässt oder anders vergibst, ist das Problem genauso da. Letztendlich muss man gut nachdenken, bevor man sich für ein System entscheidet. Welchen Vorteil Du bei den CSS-Selektor-Hashs auch übersiehst ist der, dass ich Leute viel besser zu Passagen einer fremden Seite lenken kann, auf deren Code ich keinen Einfluss habe (sprich: die nicht an allen Stellen IDs vorsieht).
Nico #
Geschrieben am 11.03.2011 um 15:07
Aber genau das ist ja das Problem. In meinen Augen kein Vorteil, sondern ein gravierender Nachteil: Ich kann meine Leser nur so lange dorthin lenken, bis sich die Seite ändert und genau darauf habe ich keinen Einfluss. Da wäre ein System sinnvoller, dass automatisch jedem HTML-Element eine festkodierte Link-ID vergibt, die aber immer eindeutig auf genau dieses Element verweist.
RSS-Feed zu diesem Beitrag
Kommentare sind für diesen Beitrag geschlossen.