06 Nov 2006

Technikwürze 45 (S01/E45) Interview Teil 2 mit Sierk

Heute hört ihr den zweiten Teil des Interviews mit Sierk Bornemann. Wir unterhalten uns über Tidy, Internet Expolorer 7, Web 2.0 und dem neuen Mimetype von JavaScript.

Höre Technikwürze auf SoundCloud: Diese Folge | Alle Folgen

Unser Hörer Matthias möchte wissen, wie man barrierefreie Captchas erstellen. Habt ihr Tipps und Lösungen? Schickt uns eure Meinung. Oliver Nadig hat das Thema bei Einfach für Alle aufgegriffen.

Nocheinmal für euch die Links zum Interview mit Sierk Bornemann.

Links

Kuchen von Microsoft an das Mozilla-Team

!http://static.flickr.com/118/278562314_14716c0232.jpg?v=0 (Kuchen von Miscrofot)!

In From Redmond with love zeigen die Mozilla-Entwickler den Kuchen, den sie von Microsoft-Entwicklern zum Launch des Firefox 2 bekommen haben.

Tags: , , , , , , , ,

Dieser Beitrag wurde am Montag, 6. November 2006 um 00:00 Uhr in der Kategorie Podcast veröffentlicht.
Kommentare sind im Moment nicht erlaubt, du kannst aber einen Trackback von deiner Seite aus senden.

Kommentare

  • 1.
    Herr Voß
    am 8. November 2006, 10:54 Uhr

    Warum sind eigentlich Nerds immer so konservativ, wenn es um neue Begriffe geht? Ich selbst bastel Internetseiten seit 1995 und ich bin schon der Meinung, dass es in den letzten 2 Jahren eine Veränderung im Netz gegeben hat, die durchaus als 2. Generation der Webanwendungen bezeichnet werden kann.

    Das hat zum einen damit zu tun, dass technisch eine Menge mehr geht als früher und zum anderen gibt es jetzt einfach das Massenpublikum, das sich überhaupt dafür interessiert. Nun kommt ihr bestimmt wieder und sagt: “HTML, JavaScript, XML - is alles uralt und Menschen sind noch älter. Alter Wein in neuen Schläuchen.”

    Am schlechtesten fand ich noch die Besen/Staubstauger-Metapher. Immerhin ist der Staubsauger tatsächlich eine Weiterentwicklung des Besens und trotzdem heisst er Staubstauber und nicht Besen. Nur um euch zu ärgern, nenn ich meinen Staubsauger ab sofort: Besen 2.0

    Das gleiche gilt für die Ajax-Geschichte. Warum ist es so schlimm, wenn ein Phänomen einen Namen bekommt. Sicher kann man die gleichen Effekte auch anders erreichen als mit asynchronem JavaScript und XML. So aber hat James Garrett es in seinem Artikel damals beschrieben und die Pioniere dieser Technologie benutzen das ja auch so. Es kann doch aber das Wort nichts dafür, wenn es auch in anderem Zusammenhang benutzt wird.

    Aber sonst möchte ich Euch auch loben: in den 45 Folgen habt ihr Euch stetig weiterentwickelt und man merkt den qualitativen Unterschied zu anderen Podcasts nicht nur in den Inhalten, sondern auch in der Präsentation. Nichts ist nerviger, als ein Sprecher, der nicht sprechen kann. Da kann der auch 1000x interessante Sachen erzählen. ;-)

    Keep up the good work.

  • 2.
    macx
    am 8. November 2006, 11:21 Uhr

    Vielen lieben Dank für deinen Kommentar und die Anmerkungen. Mich persönlich stört nicht, wenn man neue Methoden, und mehr ist ja tatsächlich nicht, einen neuen Namen gibt. Allerdings stört mich die Terminologie. Warum möchte man unbedarften klar machen, dass wir zwei verschiedenen Internets haben? Da kommen sofort Fragen auf, wann dann das erste Internet abgeschaltet ist, und ob man nun seinen DSL-Vertrag kündigen muss, um Internet 2.0 nutzen zu können (bei einem anderen Anbieter). Es ist tatsächlich nur der Name. Niemand käme auf die Idee, das Auto “Auto Zwei Punkt Null” zu nennen, oder “Geschirrspüler Zwei Punkt Null”. Sicher, beides hat sich in den letzten Jahren eklatant weiterentwickelt, und es gab immer Nachfolger der Nachfolger. Aber im Ursprung ist es immer noch das gleiche.

  • 3.
    Herr Voß
    am 8. November 2006, 15:19 Uhr

    Bei “Web 2.0” handelt es sich aber um einen Begriff, der eigentlich nur im “internen” Gebrauch – also im Fachjargon benutzt wird. Es gibt ja keinen Internetprovider, der wirbt “jetzt auch mit Web 2.0”. Es geht darum ein Phänomen zu beschreiben – das ist nur relevant für die, die sich mit dem Phänomen befassen müssen. Wer jetzt eine Seite in Netz stellt, die auf all die Dinge verzichtet, die im Zusammenhang mit Web 2.0 genannt werden, hat sicherlich immer noch eine Internetseite. Aber er sollte sich zumindest im klaren sein, dass es zur Zeit einen Trend gibt, der anders läuft. Ob man diesem Trend folgt oder nicht, kann man dann ja noch entscheiden.

    Deswegen werden große, schnelle Geländewagen auch “SUV” genannt und trotzdem als “große, schnelle Geländewagen” verkauft.

  • 4.
    Steffen Voß
    am 9. November 2006, 11:14 Uhr

    Na gut. Dann habe ich mal eine Web-Standards Frage:

    Ein übliches Vorgehen auf Webseiten ist das Anzeigen einer Bildbeschreibung unter einem Bild. Dazu gibt es natürlich verschiedene Lösungen: Früher hat man das immer in einer Tabelle mit einer Spalte und zwei Zeilen gemacht. Da es einen Zusammenhang zwischen Bild und Text gibt, könnte man das immer noch rechtfertigen, wenn man die Zeilen entsprechend beschriftet.

    Schlauer scheint aber die Lösung mit einer Definition Liste zu sein. Da wird das Bild durch die Beschriftung definiert. Es gab auch einmal einen Artikel bei A List Apart dazu – den finde ich aber gerade nicht wieder.

    Nachdem ich mich, wie zur Zeit wohl viele andere, mal tiefergehend mit HTML/CSS als Prinzip auseinandergesetzt habe, frage ich mich, ob es nicht eigentlich die Aufgabe von CSS wäre, das ALT-Attribut entsprechend anzeigbar zu machen. AFAIK geht das zur Zeit nicht. Aber wäre das nicht eigentlich die Lösung, die am sinnvollsten wäre? Gibt es dazu Pläne in CSS 3?

  • 5.
    macx
    am 9. November 2006, 12:04 Uhr

    Eine Tabelle lehne ich auch aus semantischen Gründen dafür ab. Für Bildunterschriften würde ich derzeit auch Definitionslisten nutzen, kommt das der Anwendung am nahesten.
    Deine Frage nach dem CSS3 und ALT habe ich leider nicht verstanden. Der ALT-Text eines Bildes sollte eh nur angezeigt werden, wenn die Anzeige des Bildes nicht möglich ist. Was genau hast du also vor?

  • 6.
    Herr Voß
    am 9. November 2006, 14:45 Uhr

    @Table: Naja, wenn man die erste Zeile als “Bild” beschriftet und die zweite als “Beschreibung” wäre die Tabellen-Lösung IMHO sogar semantisch zu vertreten. Wenn auch nicht die beste Lösung.

    Der Inhalt des ALT-Attributs beschreibt kurz, was auf dem Bild zu sehen ist. Das ist IMHO ziemlich das Gleiche, was auch unter dem Bild stehen sollte, wenn eine Definitions-Liste rechtzufertigen sein soll. Denn sonst definiert die Bildunterschrift nicht das Bild. Zum Beispiel: Ein Foto auf dem David Maciejewski zu sehen ist. Im Alt-Attribut steht “David Maciejewski”. Wenn jetzt unter dem Bild steht “Webstandards sind toll”, wäre das keine Definition des Bildes. Also wäre eine Definitionsliste nicht semantisch korrekt. Obwohl es vielleicht als Zitat von Dir eine tolle Bildunterschrift ist. DA wäre eine Tabelle treffender.

    Ich habe mich auf ein paar Seiten umgeguckt und festgestellt, dass im Alt-Attribut of das steht, was auch unter dem Bild steht. Es sei denn, das Alt-Attribut wird für Copyright-Hinweise misbraucht. Aber wenn da ohnehin das gleiche steht, wäre es auch nicht sinnvoll das HTML aufzublähen und per Definitionsliste noch einmal zu definieren, was schon im Alt-Attribut steht. Dann kann man nämlich auch gleich das Alt-Attribut ausgeben lassen. Und das sollte per CSS gehen – immerhin ist das ja nur eine Frage der Formatierung. Und es geht auch schon (aber natürlich nicht im IE):
    img[alt]:after {
    content:”A (“attr(alt)”)”;
    }

    Siehe: http://aktuell.de.selfhtml.org/artikel/css/drucklayout/#bildbeschreibung

    Damit habe ich mittlerweile meine Frage größtenteils beantwortet: Ja, es soll zumindest gehen.
    Unklar bleibt, ob Du das schlau findest. Oder ob da etwas gegen spricht (Außer dass der IE es nicht kann)

  • 7.
    macx
    am 9. November 2006, 14:58 Uhr

    Die :after-Methode ist, wie ich finde sehr smart, danke für den Hinweis.
    Der Tabelle sage ich weiterhin ab, und zwar wegen der BITV: “Tabellen sind mittels der vorgesehenen Elemente der verwendeten Markup–Sprache zu beschreiben und in der Regel nur zur Darstellung tabellarischer Daten zu verwenden.”. Bild plus Bildunterzeile sind keine tabellarischen Daten.

  • 8.
    Herr Voß
    am 9. November 2006, 17:06 Uhr

    Und wenn ich jetzt 20 Bilder mit 20 Bildunterschriften hätte? Zum Beispiel 20 Fotos, die von einer Person im Abstand von einem Jahr gemacht wurden. Und in der Zeile unter den Bildern steht dann immer “David Maciejewski 1 Jahr”, “David Maciejewski 2 Jahre” usw. Dann wären das doch tabellarische Daten. Oder dürfen Daten in einer Tabelle nur alphanumerisch sein? Wenn die Darstellung von 20 Bildern in einer Tabelle okay wäre – wo ist dann der Unterschied zur Darstellung eines Bildes – immer vorrausgesetzt, dass die Zeilen der Tabelle entsprechend beschriftet sind.

  • 9.
    macx
    am 9. November 2006, 18:15 Uhr

    Bilder sind definitiv keine Tabellarischen Daten, sondern es sind “Bilder”.

  • 10.
    Clemens
    am 10. November 2006, 15:15 Uhr

    Wie wäre es mit einer Frage anstelle eines Zahlencode-Bildes? (Bezüglich der Frage am Anfang von Technikwürze…)

    Die muss nur ganz einfach sein… z.B. “Welche Farbe hat der wolkenlose Himmel am Tag?”
    Antwort: “Blau”

    Und wenn ein Spam-Script alle deine Fragen erfasst hat, machst du einfach neue…

  • 11.
    Steffen Voß
    am 10. November 2006, 16:12 Uhr

    Diese Spamskripte sind meistens dazu gedacht, möglichst viele Seiten vollzuspammen. Die haben zum Beispiel eine generelle Funktion, um per OCR Buchstaben und Zahlen in so einem Captcha-Bildchen zu entziffern. (Soetwas könnte man ja einfach in Screenreader einbauen ;-) )
    Die Steigerung der normalen Text-Captchas sind ja die mit einer kleinen Rechnung im Bild “3+4=” und dann muss man das Ergebnis eingeben. Auch da könnte man sich noch vorstellen, dass es für Spammer möglich ist, die Zeichen zu erkennen, eine Rechnung festzustellen, das Ergebnis auszurechnen und es dann auszugeben.
    Bei logischen Fragen sehe ich aber nur ein Problem, wenn Du ein bekanntes CMS/Gästebuch/Forum benutzt in dem einige Fragen vorgegeben sind. Da lohnt es sich für Spammer die Fragen und Antworten (per Google Codesearch) aktuell zu halten. Wenn Du Dir aber völlig eigene Fragen und Antworten nimmst, halte ich die Sache für ziemlich sicher. Die sind dann sprachabhängig und individuell. Da stelle ich es mir ziemlich schwer vor, einen Bot drauf anzusetzen.

  • 12.
    Dörte
    am 10. November 2006, 23:53 Uhr

    Im Vergleich mit einer als Bild generierten Zeichenfolge ist eine Frage, die beantwortet werden muss, sicher die bessere Lösung, wenn man auf Zugänglichkeit der Website Wert legt. Hat jemand einen Link auf eine Seite, die solche Fragen schon integriert hat? Wenn die Antworten als Auswahlliste angezeigt werden, wird ein Spam-Robot dann nicht einfach alle Antworten durchgehen? – Wie man auch vorgeht, ob mit Wort-Filter, Captcha, IP-Filter etc., man wird immer gezwungen sein, zu aktualisieren und den Spammern hinterherzuarbeiten.

  • 13.
    macx
    am 11. November 2006, 09:50 Uhr

    Hier ist eine Lösung mit php.

  • 14.
    molily
    am 15. November 2006, 15:07 Uhr

    Es ist überhaupt keine einfache Aufgabe, application/xhtml+xml zu unterstützen, siehe IE Blog:
    http://blogs.msdn.com/ie/archive/2005/09/15/467901.aspx

    Was den neue JavaScript-MIME-Typ angeht, so halte ich die Diskussion um eine schnelle Nutzung für ziemlich weltfremd und akademisch. Der neue MIME-Typ ist vielleicht in ein vielen Jahren interessant, wenn genug Browser ihn unterstützen und alle alten Browser ausgestorben sind. Bis dahin reicht die Kombination aus application/x-javascript (HTTP) und text/javascript (HTML) aus. Die Empfehlung der Weiche jedenfalls halte ich für absolut praxisfern, da soll man sich lieber um reale Probleme kümmern. Denn Vorteile bringt der neue MIME-Typ nicht außer Standardkonformität zum Selbstzweck, die nur Arbeit macht.

    Die Vorhersage, dass die drakonische Fehlerbehandlung von XHTML sich letztlich durchsetzt, blendet die gegenwärtigen Entwicklungen aus. Alle großen Spieler suchen momentan eine Lösung jenseits der fehlgeschlagenen XML-Strategie, siehe: http://aktuell.de.selfhtml.org/weblog/bewegung-im-w3c

  • 15.
    Sierk Bornemann
    am 20. November 2006, 10:29 Uhr

    @Mathias Schäfer (aka molily):
    “Es ist überhaupt keine einfache Aufgabe, application/xhtml+xml zu unterstützen, siehe IE Blog:
    blogs.msdn.com/ie/archive/2005…”

    Wieso schaffen das dann andere Browser-Hersteller besser? Die Begründung, die das IE Blog liefert, ist mir bekannt. Nicht nur ich empfinde sie als nur vorgeschoben, entsprechende kritische Kommentare finden sich ja auch in den Kommentaren desselben Blogeintrags. Und nicht nur da. Es würde Einiges erleichtern, würde der IE/IE7 den MIME-Typ application/xhtml+xml wenigstens erkennen und nicht einfach einen Download-Dialog anbieten. Warum sollen beim Erkennen des MIME-Typs plötzlich strengere Regeln gelten, die man bei anderen Dingen in der jetzigen Umsetzung des IE7 ebenfalls nicht schafft, einzuhalten? Es wäre so einfach gewesen—wahrscheinlich nur ein oder zwei Codezeilen—dem IE7 die Existenz dieses MIME-Typs beizubringen. Wie soll sich die Akzeptanz von XHTML denn überhaupt durchsetzen können, wenn der am weitesten verbreitete Web-Browser dieses noch nichtmal erkennen kann, obwohl er höchstwahrscheinlich schon seit längerem in der Lage wäre, XHTML korrekt darzustellen? Der IE trägt schon seit seiner Version 5.5 mit MXML einen recht passablen XML-Parser mit sich herum, um XML-Dateien darzustellen. Warum diesen nicht auch für XHTML einsetzen, wenn XHTML mit entsprechendem MIME-Typ ausgeliefert wird? Wo soll hier das große Umsetzungsproblem sein?

    Was das Ausblenden der drakonischen Fehlerbehandlung bei XHML im XML-Modus angeht: Wieso wiederspricht sich Microsoft hier selber und wirbt damit, dass der IE7 nun Newsfeeds darstellen kann, diese aber valides und wohlgeformts XML sein müsseen, ansonsten zeigt er den betreffenden Feed nicht an? Warum klappt hier, was bei XHTML plötzlich so schwierig sein soll umzusetzen? Der Mechanismus und das Prinzip, ausgelöst durch den browsereigenen XML-Parser, ist derselbe.

    Zum Thema Scripting Media Types, also den neuen, empfohlenen MIME-Typen für JavaScript/ECMAScript: hier gilt Ähnliches wie bzgl. XHTML MIME-Typ. Wo ist das große Problem, diesen MIME-Typ in jene Erkennungstabelle aufzunehmen, die auch für andere MIME-Typen in jedem Browser existiert? Hier ist das Problem vielleicht nicht so dringend wie bei XHTML, doch es sollte doch schon drauf hingewiesen werden, dass der jahrelang eingesetzte MIME-Typ bei JavaScript eben nicht der nirgends spezifizierte und nirgends abgesegnete Typ text/javascript sein soll, sondern application/javascript. Die Begründung, warum dieser neue Typ bevorzugt werden sollte, steht klar in RFC4329 drin, welcher zum ersten Mal überhaupt den MIME-Typ von JavaScript definiert und spezifiziert.
    Auch, wenn es Dir zu akademisch erscheinen sollte: es gibt Dinge, die sollte man schon einigermaßen beherzigen oder im Hinterkopf behalten, sonst dauert es ewig mit deren Verbreitung. Nichtwissen ist dabei ein großer, unnötiger Hemmschuh. Deshalb habe ich darüber gesprochen.

    Was die Browser-Implementierung von application/javascript angeht:

    “Bis dahin reicht die Kombination aus application/x-javascript (HTTP) und text/javascript (HTML) aus.”

    Der IE kennt “application/x-javascript” nicht. Wäre nur was für die übrigen Browser, zumal die Variante mit x-Prefix laut RFC-Bestimmungen immer nur übergangsweise verwendet werden sollte, solange kein offizieller andere MIME-Typ spezifiziert ist. Und die übrigen Browser kennen mittlerweile auch den vom RFC empfohlenen MIME-Typ “application/javascript”. Die Tage von application/x-javascript sind somit gezählt, zu gegebener Zeit wird die Unterstützung für diese Hilfskrücke in den verschiedenen Browsern sicher entfernt.

    Firefox kennt den neuen MIME-Typ für JavaScript seit mehreren Monaten (kurz, nachdem absehbar war, dass RFC4329 die Standardisierungs-Gremien erfolgreich passieren wird, hatte Firefox schon einen entspr. Fix). Opera hat irgendwann im Laufe des Jahres nachgezogen. Die aktuelle Konqueror-Version erkennt diesen neuen MIME-Typ nun auch, dafür habe ich im Oktober dieses Jahres gesorgt, Safari wird aufgrund seines Code-Sharings mit Konqueror diesbzgl. deswegen wohl bald ebenfalls in der Lage sein, application/javascript zu erkennen. Bleibt als wichtiger Browser nur noch der IE. Hier ist ungewiss, wann hier die IE-Entwickler den Finger rühren.
    Auch für den Apache-Webserver existiert bereis ein Patch, der jedoch leider noch nicht in die aktuelle Codebasis eingepflegt ist. Etwas Voting-Druck beim betreffenden Bug könnte da sicherlich helfen.

    In einem gebe ich Dir recht: das ganze Thema brennt noch nicht. Aber man sollte meiner Meinung nach davon wissen, dass es nun einen definierten MIME-Typ für JavaScript gibt und für ECMAScript, welches ja die Grundlage von JavaScript wie von JScript (Microsofts Variante von JavaScript) bildet, ebenso. Vor allem diejenigen sollten davon wissen, die mit JavaScript/ECMAScript/JScript umgehen.

    Es geht nicht darum, ob es von Vorteil ist, am Bestehenden festzuhalten. Das Argument ist für Faule und Ignoranten. Es geht darum, langfristig etwas besser zu machen, was man vorher nicht besser wusste, weil es bislang auch nirgends festgeschrieben war. Mit der nicht spezifizierten Verwendung von text/javascript hat man sich bislang immer im Niemannsland bewegt. Dazu gibt es jetzt keinen Grund mehr.

    Gruß,
    Sierk Bornemann

Dein eigener Kommentar

Die Kommentarfunktion für diesen Beitrag wurde deaktiviert.