Man kann es mit Ubuntu als Betriebssystem vergleichsweise gut aushalten, weil es gut funktioniert. kann man so ziemlich alles machen, und alle Dinge tun was sie sollen. Allein, die Art und Weise wie sie tun, das ist teilweise ganz schön diskutabel und so manche Design-Entscheindung verleitet geradezu zum Fazialpalmieren. Meine Wenigkeit erschlägt das Ganze immer mit ein paar zusätzlichen Stücken Software, die ich im Folgenden einfach mal aufliste – jedenfalls die Software, die ich im Moment bei Raring Ringtail 13.04 im Einsatz habe. Falls ihr noch mehr in dieser Richtung vorschlagen wollt: Ab damit in die Kommentare!
Neuen Nautilus loswerden: in Ubuntu 13.04 wird aus unerfindlichen Gründen Nautilus 3.6 verwendet, eine schlecht integrierte, fehlgeleitete Karikatur des vorherigen Dateimanagers mit der Versionsnummer 3.4 – hässliches Aussehen, Funktionen fehlen, Hotkeys tun es nicht mehr usw. Einen gepatchten, zu Ubuntu 13.04 kompatiblen Nautilus 3.4 gibt es bei Webupd8. Installieren und alle Probleme verschwinden.
Unity konfigurieren:Unsettings ist ein GUI zur Konfiguration von Unity. Neuerdings gibt es mit dem Unity Tweak Tool auch eine offizielle Lösung, aber warum die nicht standardmäßig installiert ist, ist mir schleierhaft. Aber beide Tools funktionieren ganz gut. Das Wichtigste ist die Auswahl der passenden Hintergrundfarbe für das Dash.
Gepatchtes Notify-OSD: Die Ubuntu-Notifications sind in ihrem Auslieferungszustand nicht konfigurierbar, also müssen eine gepatchte Version und ein damit kompatibler Konfigurator) her. Auch hier: Hintergrundfarbe das wichtigste, Kontrolle über Positionierung und Timeout nice to have.
Compiz konfigurieren: Falls man auf die (aus Canonical-Sicht wohl völlig abwegige) Idee kommen sollte, seinen Window Manager konfigurieren zu wollen: sudo apt-get install compizconfig-settings-manager && ccsm
Das ist ungefähr der Werkzeugkasten, mit dem ich mir alle halbe Jahr, nach jedem Release, den Desktop wieder in genehme Form bringe. Ich verstehe nicht, warum man die Konfiguratoren nicht zum Standard macht bzw. eigene bereitstellt. Bei rechtlichen Fragen (Codecs usw.) habe ich vollstes Verständnis, aber hier muss man einfach Böswilligkeit und/oder Arroganz unterstellen. Canonical hält mich anscheinend für blöder als ich bin und ihre Designer für besser als sie sind. Grr … aber hey, immerhin kann man die Sachen patchen und alles andere fluppt ja ganz gut. Und alles zu patchen hat mich gestern abend auch nur 30 Minuten gekostet.
Die letzten Jahre habe ich ständig Seminare und Vorträgen zu HTML5, CSS3, JavaScript und verwandten Themen gegeben. Bei diesen Themen ist es natürlich naheliegend, HTML/JS-Demos und -Codeschnipsel direkt in die Präsentation einzubetten. Auf HTML fußende Präsentationstools, mit denen das theoretisch denkbar wäre, gibt es wie Sand am Meer. Allerdings haben all diese meine dringendsten Präsentationsprobleme nicht gelöst, weswegen ich (nach mehreren Anläufen) mein eigenes Tool geschrieben habe. Die Hörsuppe hat mich vor ein paar Tagen dazu veranlasst, dem Ganzen mal ein ordentliches Release zu gönnen: Pik7 v. 1.0.0 ist da!
Ich bin nicht restlos davon überzeugt, dass irgendwer außer mir Pik7 einsetzen sollte, weil ich doch sehr spezielle Primärziele damit hatte:
Performance. Dinge wie mein Canvas-Intensivkurs haben deutlich mehr als 100 Slides, auf denen zu allem Überfluss auch noch allerhand Animationen usw. ablaufen. Das brauche ich in flüssig.
Presenter View. Ein aus „richtigen“ Präsentationstools wie Power Point bekanntes Feature, das auf einem Zweitbildschirm nicht für das Publikum gedachte Infos anzeigt – so kann der Vortragende zum Beispiel sehen, welche Slide als nächste dran ist und wie viel Zeit er noch hat. Bei der Masse meiner ganzen Folien darf dieses Feature nicht fehlen.
Druckbarkeit. Ich brauche PDF-Fassungen all meiner Slides. Druckbare Präsentationen + Chromes „print to PDF“ = Problem erledigt. Mit ein bisschen JavaScript und CSS kann man außerdem mehrere verschiedene PDFs erzeugen, z.B. einen Cheat Sheet für den Workshop und eine Komplettfassung für das spätere Nacharbeiten.
Einfache Programmier- und Stylebarkeit. Versteht sich von selbst: simple Themes, JavaScript-Events beim Folienwechsel usw.
Nobrainer-Funktionen für Nerds. Eingebautes Syntax-Highlighting. Eingebautes prefix-free. Auto-Synchronisation von mehreren offenen Präsentationen und Presenter Views. Ich muss kompliziertes Zeugs erzählen, ich habe keine Zeit komplizierte Tools zu bedienen.
Kein Firlefanz. Ich brauche weder fancy 3D-Animationen noch verschachtelte Slides noch eine Funktion, die mich Bullet Points nach und nach einblenden lässt. Die könnte man sicher alles einbauen, aber ich habe daran erst mal keinen Bedarf.
Da es, zumindest als ich anfing meine eigenen Tools zu basteln, diese Features in dieser Kombination nirgendwo zu finden gab, musste ich eben selbst ran. Pik7 ist selbstverständlich Open Source (MIT), liegt auf Github rum oder kann von pik.peterkroener.de heruntergeladen werden. Eine Präsentation zu erstellen ist recht einfach …
… aber wie schon gesagt: ich bin nicht sicher, ob ich Pik7 wirklich empfehlen sollte. Zu den Nachteilen gehört unter anderem der etwas bei HTML-Slides übliche, mühsame Folienbau (Snippets für ST2 liegen aber bei) und dass zwingend ein Websever benötigt wird. Ein kleiner Node.js-Server wird zwar mitgeliefert, ist aber sehr spartanisch gehalten. Außerdem fehlen, wie erwähnt, Animationen und Co. Aber falls ihr euer Glück mit Pik7 versuchen wollt, werde ich euch nicht aufhalten.
Ich bin zwar kein Doktor und draußen ist auch gerade alles andere als Sommer, aber Fragen beantworte ich trotzdem gern. Bevorzugt solche zu HTML5, CSS3, JavaScript und anderen Themen rund um Webentwicklung. Die folgenden vier Fragen sind alle in den letzten Wochen via Twitter und E-Mail an mich herangetragen worden, was genau die beiden Kanäle sind, über die ich auch euch gerne die Fragen beantworte, die euch unter den Nägeln brennen. Einfach anschreiben!
Leerzeichen bei mobiler Datenverbindung verschwunden?
In mobilen Browsern (Verbindung über EDGE/3G/LTE) werden manchmal Leerzeichen aus meiner Webseite entfernt. Weißt du etwas darüber? Ist das vielleicht eine Art von Kompression?
Ohne es konkret testen zu können ist eine Antwort schwer, aber es kann durchaus sein, dass Mobilfunkanbieter das HTML einer Seite komprimieren, um hier und da ein paar Bytes zu sparen. Es ist jedenfalls nicht unüblich, dass die Provider in auszulieferndes Markup eingreifen. Besonders problematisch wird das Ganze, wenn, wie im verlinkten Artikel beschrieben, der Inhalt verändert wird, aber auch wenn „nur“ komprimiert (d.h. Whitespace zwischen Tags entfernt) wird, kann es durchaus zu sichtbaren Veränderungen in der Seite kommen, denn egal ist solcher Whitespace bei HTML nicht. Vergleichen wir doch mal:
Der Unterschied zwischen den beiden Absätzen ist an im gerenderten Endergebnis sichtbar und kommt daher, dass die Leerzeichen und Zeilenumbrüche zu zusätzlichen Textknoten zwischen den Elementen führen. Man beachte die childNodes-Eigenschaft im DOM:
Streicht ein übereifrig optimierender Mobildatendienstleister diese Leerzeichen weg, hat man natürlich plötzlich ein ganz anderes DOM und das kann ein handfestes Problem werden. Schnelle Abhilfe schafft möglicherweise die Codierung von Leerzeichen als Entity ( ) an kritischen Stellen.
Bilder und Videos per Canvas verkleinern
Vielen Dank für das Tutorial! Eine Frage hätte ich allerdings: was müsste ich machen, um das Video oder das Bild in eine kleine Canvas zu skalieren, also z.B. statt 400×300 in ein 40×30, wenn die Originaldatei aber 400×300 hat?
Das ist zum Glück ganz einfach. Die drawImage-Methode kann man nicht nur mit zwei Parametern (Bild, X-Koordinate, Y-Koordinate) aufrufen, sondern auch mit vier oder acht. Die beiden zusätzlichen Parametern bestimmen dann die Höhe und Breite des gemalten Bildes und wenn die Quelle andere Maße hat, wird sie automatisch gestreckt oder verkleinert. Außerdem kann man auch nur einen Ausschnitt aus der Quelle verwenden. Ein Bild sagt mehr als tausend Worte; der Aufruf context.drawImage(image, sx, sy, sw, sh, dx, dy, dw, dh) bedeutet:
Leider wird diese Technik noch viel zu selten genutzt. Warum zum Beispiel sollte man bei Bilduploads eine viel zu große Datei hochladen, nur um sie dann auf dem Server von einem PHP-Script kleinrechnen zu lassen? Das kann man dank HTML5 viel besser auf dem Client erledigen.
End-Slashes für Leer-Elemente
Hallo, ich beobachte, dass häufig ein End-Slash im IMG-Tag gesetzt wird (<img />). Bisher funktionieren auch die alten Tags ohne „/“. Kann es sein, dass der End-Slash zukünftig zwingend geschrieben werden muss? Und wenn ja, ab wann?
Nein, dieser schließende Slash wird voraussichtlich nie auf breiter Front Pflicht werden. Der Slash rührt daher, dass das W3C zwischenzeitlich mal plante, HTML auf XML-Basis neu aufzustellen – XHTML sollte der neue Standard werden. Dort wäre dann schließende Slash für Elemente wie <img> Pflicht geworden. Diese XML-Umstellung hat aber aus einer ganzen Reihe von Gründen nicht so recht funktioniert und heute (d.h. in HTML5) ist der Slash damit wieder optional. Die HTML5-Parser in modernen Browsern werden durch ihn nicht gestört, benötigen ihn aber auch nicht. Es ist buchstäblich völlig egal ob man ihn verwendet oder nicht.
Es existiert zwar auch XHTML5, wo der Slash Pflicht wäre, aber wegen vieler vieler Problem damit (u.A. funktioniert es nicht im Internet Explorer 6, 7 und 8) ist die Verwendung von XHTML5 nicht zu empfehlen. Man nur Nachteile, keine Vorteile.
Inline-Video mit HTML5 auf dem iPhone
Gibt es irgendwie die Möglichkeit, mit HTML5 eingebundene Videos auf dem iPhone inline d.h. ohne automatischen Fullscreen darzustellen?
Zunächst sollten wir festhalten, dass sich das iPhone nicht direkt unkorrekt verhält, wenn es Videos ausschließlich im Vollbild abspielt. Die in den Spezifikationen festgeschriebenen Regeln lassen sich mit geringem Aufwand so weit dehnen, dass dieses Verhalten standardkonform erscheint. Zitat:
User agents may allow users to view the video content in manners more suitable to the user (e.g. full-screen or in an independent resizable window). As for the other user interface features, controls to enable this should not interfere with the page's normal rendering unless the user agent is exposing a user interface. In such an independent context, however, user agents may make full user interfaces visible, with, e.g., play, pause, seeking, and volume controls, even if the controls attribute is absent.
Wenn der Browser ein Interface mit Steuerungselementen für das Video anzeigt, darf er das im Fullscreen-Modus machen. Und wenn der Browser im Fullscreen-Modus ein Video anzeigt, soll er dort auch ein Interface mit Steuerungselemente anzeigen, selbst wenn das dafür normalerweise nötige controls-Attribut auf dem Video-Element gar nicht gesetzt ist. Und so startet iOS auf iPhone und iPod Touch jedes Video im Vollbild, da es schließlich ein Steuerungsinterface zeigt, das es auch in Abwesenheit des controls-Attributs anzeigen darf, da das im Vollbild passiert. Richtig falsch ist das also nicht.
Kann man denn etwas dagegen tun? Leider nicht. Es gibt zwar das proprietäre HTML-Attribut webkit-playsinline, aber das scheint nur für native Apps mit UIWebViews gedacht zu sein und funktioniert nicht auf iPhones und dem iPod Touch.
Wie den wenigsten Webdesignern und -entwicklern entgangen sein dürfte, hat Opera angekündigt, in all ihren Produkten die hauseigene Presto-Engine gegen Webkit auszutauschen. So richtig habe ich die Gründe aus den entsprechendenBlogposts nicht herauslesen können, aber die wohl (für Nicht-Opera-Mitarbeiter) auch nicht so wichtig ist, wie die web-weiten Folgen dieses Schritts. An Prognosen hierüber herrscht kein Mangel – von goldener Zukunft bis hin zum Untergang der Webstandards lässt sich so ziemlich jede Aussage im Web finden. Eine besonders schöne Fundgrube stellt Hacker News dar. Ich habe zur Zeit noch keine fertige Meinung zu dieser Angelegenheit und möchte mich an dieser Stelle darauf beschränken, ein paar meiner Meinung nach leicht abenteuerliche Vorstellungen über die Folgen der Webkit-Entscheidung zu besprechen.
Alles wird besser! Auf dem Holzweg sind meines Erachtens vor allem jene, die glauben, dass es Entwicklern mit einer Engine weniger einfacher fallen wird, Web-Frontends zu bauen. Zum einen haben viele nicht ganz so professionelle Entwickler Opera ob seines eher geringen Marktanteils ohnehin völlig ignoriert. Alle, die ihre Werke auch in Opera getestet haben, werden gemerkt haben, dass dieser Browser sich seit jeher sehr standardkonform verhielt und selten die ganz großen Probleme machte (und wenn, dann hat selbst ein mittelschwerer Darstellungsfehler aufgrund des geringen Marktanteils wohl kaum fatale Auswirkungen auf das Gesamtprojekt gehabt). Und vor allem: um zu behaupten, dass es zwischen Browsern, die eine gemeinsame Engine haben, keine großen Unterschiede gibt, muss man die diversen Mobile-Browser ignorieren. Die verwenden zwar fast alle Webkit als Engine, aber in so unterschiedlichen Versionen und Zusammensetzungen mit anderen Komponenten, dass man davon als Webentwickler nicht wirklich viel merkt.
Das Ende ist nah! Die Apokalyptiker-Fraktion sieht hingegen eine neue Browsermonokultur unmittelbar vor der Tür stehen. Das ist, Stand heute (mit neben Webkit noch Gecko und Trident als relevanten Browserengines), natürlich noch längst nicht der Fall. Allerdings kann man das Ende von Presto schon als Wegfall eines Glieds aus der Monokultur-Abwehrkette interpretieren. Immerhin reicht es jetzt, wenn entweder Mozilla oder Microsoft aus dem Browsermarkt ausscheiden oder selbst zu Webkit wechselt, denn das dann bestehende Engine-Duopol könnte sich aufgrund des Übergewichts der Webkit-Browser als instabil erweisen. Aber selbst dann ist nicht gesagt, dass das Web im Innovationsstillstand versackt – die Konkurrenz durch die nativen Plattformen könnte das verhindern. Die Frage ist natürlich, wie der weitere Fortschritt dann aussehen könnte, was uns direkt zu Prognose Nummer drei bringt …
Gut für Webstandards! Manche sagen auch, weniger Engines seien besser für die Entwicklung und Durchsetzung von Standards. Ich weiß nicht so recht. Wenn man der Presto-Engine etwas nicht vorwerfen kann, dann sind das gewohnheitsmäßige Standards-Abweichungen. An dieser Front war Opera sicher nie das größte Problem. Andersherum könnte durchaus ein Schuh draus werden, denn Webstandards richten sich oft nach den Implementierungen – was in allen Browsern vorhanden ist, und sei es noch so größer Käse, wird früher oder später Standard. So war es zum Beispiel mit <center> oder der grausligen Drag & Drop-API. Mit nun einer Engine weniger fällt es vielleicht etwas leichter, Fakten zu schaffen, die dann in einem Standard münden. Das kann man durchaus gut finden weil es schneller gemeinsame APIs produziert, andererseits ist ein hohes Tempo ein Risiko für die Qualität dieser gemeinsamen Features. Allerdings hat Opera nun auch nicht all seine Entwickler entlassen, sondern lässt diese jetzt an Webkit mitbasteln, d.h. die Stimmen der Vernünftigen, die einst für Presto sprachen und programmierten, sind weiterhin zu hören. Ob das reicht wird man sehen.
Ich selbst habe, wie eingangs erwähnt, noch keine fertige Meinung zu diesem Schritt von Opera. Zu bejubeln finde ich nichts, aber die auch den unmittelbaren Weltuntergang vermag ich nicht festzustellen. Klar, im Prinzip sind das WWW der Webkit-Hegemonie einen Schritt näher gekommen, aber dass demnächst wirklich Mozilla und/oder Microsoft zumachen, fällt mir schwer zu glauben. Und beide haben einen ganz gesunden Marktanteil und können mit jeder Version steten Fortschritt vermelden. Selbst was die Entwicklung von Standards angeht, muss sich erst mal zeigen ob sich überhaupt etwas ändert. Das halte ich zwar noch am wahrscheinlichsten (jedenfalls wahrscheinlicher als eine Browser-Einheitsfront) aber wie genau sich das auswirkt, ist reine Spekulation.
Mein Fazit: Interessante Entwicklung, aber (noch) kein Grund die Gelassenheit zu verlieren.
