Nach gefühlten Ewigkeiten waren mal wieder alle festen Hosts beieinander. Und noch jemand war da, nämlich Haymo Meran, CTO und Mitbegründer des Wiener Unternehmens Gentics und vor allem geistiger Vater des HTML5 Aloha Richtext Editors.
Schaunotizen
- [00:02:14] jQuery 1.7 released
- Eine neue jQuery-Version wurde auf die Welt losgelassen, die die neue Methoden
on
undoff
für das Eventmanagment einführt, delegierte/gebubbelte Events schneller macht und nicht zuletzt ein HTML5 innerShiv Polyfill von Haus aus integriert. - [00:14:33] Sisyphus.js – Gmail-like client-side drafts and bit more
- Ein sehr praktisches jQuery-Plugin, das Formulareingaben vor dem expliziten Absenden vor Verlust schützt. Peter findet es in dem Zusammenhang jedoch schade, dass so viele Tools auf jQuery bauen, obwohl es eigentlich gar nicht nötig wäre.
- [00:26:13] CSS Media Queries
- Einige kleinere Geschichten, nämlich einsetzende Ernüchterung einerseits und ein schöner Trick andererseits, welche diese Woche zu CSS Media Queries über den Äther gingen, sind für uns der Anlass, über Responsive Web Design im Allgemeinen zu reden.
- [00:42:13] Sencha Offline Web Apps Workshop Position Paper
- James Pearce von Sencha nutzte die diesjährige W3C Technical Plenary / Advisory Committee Meetings Week, kurz TPAC, um den W3C Theoretikern mal klar zu machen, was für ein Stück dampfender Bockmist der HTML5 App Cache aktuell ist.
- [00:55:33] Aloha Editor – HTML5 WYSIWYG Editor
- Haymo erzählt uns ein wenig was zum Aloha Editor, einem WYSIWYG/Richtext Editor der ein anderes Implementierungskonzept verfolgt als etwa TinyMCE oder der CKEditor. Dieses fußt nämlich auf HTML5 und so könnte man Aloha eigentlich auch als
contenteditable
-Polyfill einstufen.
[01:19:52] Keine Schaunotizen
- Node v0.6.0
- Node.js ist in der Version 0.6 erschienen und zum ersten Mal nativ für Windows erhältlich. Hurray!
- h5ai – a beautified Apache index
- Mit h5ai kann man das Browsen durch Apache Verzeichnis Indizes optisch um einige Lichtjahre in die Zukunft katapultieren. Schaut selbst.
Kommentare
Anselm H. #
Geschrieben am 9.11.2011 um 09:44
Christian meintest du die Übersicht? http://www.cloudfour.com/responsive-imgs-part-3-future-of-the-img-tag/
Wie ich drüber denke, weißt du ja: Bildformat wäre supertoll, aber zum Übergang brauchen wir jetzt(!) was.
Anselm H. #
Geschrieben am 9.11.2011 um 11:56
Achso: https://github.com/simsalabim/sisyphus/issues/7#issuecomment-2679927
f #
Geschrieben am 11.11.2011 um 16:02
Also ich stimme euch in dem Punkt nicht zu, dass es schaden Würde, dass der FF fragt, wenn ein App Cache angelegt werden soll. Angenommen jede Webseite würde den App Cache nutzen, dann würden mich auch 5MB extrem stören. Was weiß ich, wiev iele Seiten von denen überhaub jemals wieder ansurfen werde. Der App Cache macht also auch nur bei wichtigen Seiten Sinn, denen ich damit beinahe einen gesonderten Status einräume.
Tim Kraut #
Geschrieben am 12.11.2011 um 00:35
Ich hätte noch einen Alternativvorschlag für die Bilderproblematik (ließe sich dann wohl auch recht unproblematisch auf Videos und andere Inhalte ausweiten):
Man nimmt ganz normal wie gehabt sein img-Tag, definiert aber per CSS alternative Auflösungen in Verbindung mit Media Queries. Das könnte dann z.B. so aussehen:
#bild_xyz {
src: url(...);
}
Das hätte in der Form ein paar Vor- und ein paar Nachteile:
Vorteile:
– Es wäre rückwärtskompatibel – jeder Browser, der das img-Tag hinkriegt (das dürften so ziemlich alle sein, wenn man von den zig Milliarden Lynx-Installationen absieht), schafft es auch, das Bild anzuzeigen.
– Man würde an genau der Stelle, wo derzeit die Unterscheidung der verschiedenen Auflösungen (Media Queries) stattfindet, also im CSS, ALLE Unterscheidungen treffen. Ist sicherlich nicht verkehrt, wenn man das an einer zentralen Stelle machen kann.
Nachteile:
– Man müsste die Bilder irgendwie ansprechen. Sprich, man vergibt entweder eine ID, macht etwas über nth-child oder ähnliches. Das wäre unnötiger Code. Für so einen Fall wäre die bessere Lösung sicherlich, über CSS irgendwie auf Medien direkt zuzugreifen. So à la:
@bild_in_html.png {
src: url(...);
}
Bei Änderungen des Bildnamens wäre das aber auch reichlich unpraktisch. Aber es würde einer möglichen ID-Flut entgegen wirken. Das jeweils passende Bild könnte man über eine ähnliche Funktionalität wie bei PHP-Includes (such im aktuellen Verzeichnis, ansonsten such ein Verzeichnis weiter oben, wenn nichts anderes angegeben ist) finden.
– Man brauch logischerweise alle Medien in verschiedenen Auflösungen. Das dürfte sich aber nur durch ein neues Bildformat (dauert Jahre, bis das entwickelt und verbreitet ist – hilft also im Moment eher wenig) oder irgendwelche serverseitigen Lösungen beheben lassen. Problematisch könnte es werden, wenn man es schafft, durch das Rotieren des Tablets die Auflösung in einen neuen Bereich zu bekommen, sodass dann das Gerät letztendlich 2 Bilder laden muss. Insbesondere Smartphones sind doch deutlich höher als länger für gewöhnlich. Da könnte das eventuell kritisch werden.
Was haltet ihr davon? Fallen euch weitere Vor-/Nachteile ein?
Das Ganze könnte man sogar noch weiter treiben und sagen: Medien haben in HTML generell nichts zu suchen und man zeigt standardmäßig den Alternativtext an. Medien = Präsentation = CSS. Das wäre sicherlich aus Sicht der Barrierefreiheit eine Superlösung, aber irgendwie habe ich doch starke Zweifel, dass DAS jemals passieren wird. Aber wäre mit so etwas doch recht einfach realisierbar.
Schepp #
Geschrieben am 12.11.2011 um 02:38
Hallo Tim, Deine Idee ist zunächst mal naheliegend und über sowas ähnliches hatte auch schon Anselm Hannemann (siehe weiter oben) gebrütet. Was ich an Media Queries in Bezug auf Medien aber total doof finde, ist dieses von Vorneherein festzulegende Raster, plus eine Explosion an gedanklicher Komplexität und involvierten Dateien. Daher favorisiere ich mehr oder weniger ausschließlich eine Lösung, dessen Magie im Dateiformat selbst steckt, denn:
– Woher weiß ich heute, was morgen noch eine gute Auswahl an Media Query Zwischenschritten ist? Ich will eine Lösung, die stufenlos skaliert, je nach Bedarf, also auch nachträglich. Zumindest von der maximalen Auflösung der Datei stufenlos runter auf Null (hoch geht ja schwerlich)
– Warum soll ich aus meiner Bildverarbeitung heraus x-beliebige Auflösungen rausspeichern? Der Arbeitsaufwand ist ja verrückt. Und was ist, wenn ich später einen zusätzlichen
Auflösungsschritt brauche? Dann muss ich streng genommen alle unkomprimierten Quelldateien wiederfinden und diese Auflösung daraus nachträglich ausspielen. Ein progressives Bildformat würde das Problem direkt am ersten Tag lösen.
– Warum soll es nicht der Browser selbst regeln, wieviel Details er von einem solchen „progressiv“ nachladbaren Bild lädt, wo er doch am ehesten weiß, was gerade Sinn macht. Man denke zum Beispiel daran, dass Bilder auf dem iPhone zunächst nicht hoch aufgelöst sein müssen, nach dem Doppeltap, also nach dem Heranzoomen dann aber schon. Da könnte der Browser einfach Details nachladen oder weglassen, je nach Zoomstufen. Auch könnte er sein Nachladeverhalten an die verfügbare Bandbreite koppeln und so auf einem Desktop, der über GPRS ins Netz geht die Bilder geringer aufgelöst einladen, als wenn der Rechner an einer DSL-Leitung hängt. Da wird es schon langsam eng mit Media-Query-artigen Konstrukten.
Alles andere ist wohl nur Flickschusterei, mit der wir uns nicht wirklich einen Gefallen tun (HTML Verhunzung), und mit dem wir, wenn wir Pech haben, nur genau so viel Druck aus der Problematik herausnehmen, dass die Entwicklung eines neuen Bildformats vor sich hergeschoben wird. Ich finde, WebP sollte diesen Entwicklungsschritt machen, da es aktuell am wenigsten Rücksicht auf Altlasten nehmen muss und mir Google am Wendigsten erscheint.
Tim Kraut #
Geschrieben am 12.11.2011 um 12:21
Wenn man per Knopfdruck alle alten Browser durch moderne ersetzen könnte, wäre ein neues Bildformat sicherlich spitze. Solange man die Aufgabe aber nicht an Facebook delegiert (die würden es sicherlich schaffen, das Update dem User irgendwie heimlich unterzumogeln ;-)), dürfte das nicht realsierbar sein.
Man hätte also das massive Problem der nicht vorhandenen Abwärtskompatibilität. Wenn man so eine Art no_new_image_format-Element einführt, wäre das für die Zukunft nicht verkehrt, aber die allseits geliebten IE-Opis könnten damit ähnlich wenig anfangen und die neuen Browser würden wiederum wohl ohnehin das neue Bildformat unterstützen. Also der nächste Polyfill. Oder irgendeine JavaScript-Lösung, die ein anzeigbares Bild runterlädt. In jedem Fall wäre man auf irgendeine Trickserei angewiesen, die dafür sorgen würde, das moderne Browser unnötigen Code laden müssen.
Das Problem mit den sinnvollen Auflösungsschritten ist natürlich so eine Sache. Klar, das wird man niemals genau wissen. Müsste man dementsprechend ständig anpassen. Dass das der Otto-Normal-Metzgerei-Betreiber nicht hinkriegt, dürfte klar sein (wobei der wohl auch keine mobile Webseite braucht – egal). Der Trend dürfte zu höheren Pixeldichten gehen, zur Not kriegt das Smartphone dann halt die Tablet-Version. Wäre auch kein Weltuntergang. Bei dem nächsten Update wird das dann eben wieder korrigiert.
Die verschiedenen Auflösungen sollte das CMS von sich aus anlegen. Alles andere wäre definitiv ein gigantischer Mehraufwand.
Das mit den Media Queries stelle ich mir so vor, dass man das Bild in einer bestimmten Auflösung speichert (sagen wir mal 200px) und der Browser das Bild mit 200px dann für 0 bis 240px (120% – da müsste man mal genau gucken, wie weit Vergrößerungen sinnvolle Lösungen ergeben) nimmt. Alles was darüber geht, kriegt die 600px-Auflösung (für 240px bis 720px) und so weiter. Wenn es dumm läuft, lädt man dann zwar zu große Bilder (deswegen müsste man die Auflösungen ständig an die Marktgegebenheiten anpassen), aber man hätte eine stufenlose „Bilderfahrung“. Und vergrößern wäre in diesem „dummen“ Fall auch kein Problem – das hochaufgelöste Bild ist ja geladen.
Wie wäre es denn mit einer Kombination aus beiden Vorschlägen?
Man nimmt die von mir beschriebene src-Eigenschaft in irgendeiner Form und arbeitet gleichzeitig an einem Bildformat, was so etwas von Haus aus unterstützt (meinetwegen WebP). Dann könnte man in Zukunft einfach WebP in die src-Eigenschaft schreiben und für den Übergang mehrere Auflösungen benutzen.
Natürlich ist das nicht die optimale Lösung. Es bläht die CSS-Dateien zwar unnötig auf, es wird sicherlich nicht einfacher dadurch, aber es wäre immerhin eine praktikable Lösung.
Noch ein anderer Vorschlag, der die Idee von mir in etwa „nachbaut“ (keine Ahnung, ob das funktioniert) – nur eben ohne irgendeine Änderung der Spezifikation:
Wie wäre es denn mit einem Return der 1px-Transparent-GIFs? Die lädt man für jedes Bild (das alt-Tag würde also schon mal funktionieren) und die Bilder, die man wirklich sehen will, lädt man über die background-Eigenschaft von CSS.
Anselm H. #
Geschrieben am 12.11.2011 um 14:26
Wäre doch klasse, wenn ihr einfach hier weiter drüber diskutiert: https://groups.google.com/forum/#!topic/jquery-standards/rl8886ZRs8o
Da kommts nämlich auch wirklich bis oben durch… :)
Daniel Kreiseder #
Geschrieben am 21.01.2012 um 21:50
Ich bin ziemlich beeindruckt von sysiphus und dachte mir, dass es eigentlich schade ist, dass es sowas nicht auf jeder Webseite mit Formular gibt.
Tollerweise gibt es ja Greasemonkey bzw. Tampermonkey mit denen man mit einem Userscript ja sowas nachrüsten könnte.
Naja, dann hab ich mir gedacht, ich mach mal so ein Userscript: http://userscripts.org/scripts/show/123674 :)
Schepp #
Geschrieben am 23.01.2012 um 10:16
Sehr cheffig!
Type-Style #
Geschrieben am 28.02.2012 um 11:06
Hallo Hallo,
Zunächst mal danke für eine weitere tolle Sendung.
Bei 28:53 erwähnt der Schepp glaube ich, das man mit MediaQueries abfragen kann ob ein Gerät touch-enabled ist.
Das ist mir neu. Geht das wirklich, oder hab ich den Zusammenhang falsch verstanden und es handelt sich um eine Javascript Möglichkeit?
Zum Aloha Editor.
Also wirklich toll das sich jemand über sowas Gedanken macht.
Allerdings bin ich nach 2min des Testens schon entäuscht.
Gerade wenn auf Copy & Paste fokus gelegt wurde, frage ich mich warum es nicht mal in dieser Beispielbox auf der Startseite korrekt funktioniert.
Zum Abschluss sei nochmal energisch darauf hingewiesen, dass Lichtjahre die Entfernung und nicht die Zeit messen.
Das sollte man als Otto-Normal-Nerd doch wissen.
Mich wundert nur das bisher keiner darüber in den „Keine Schaunotizen“ gestolpert ist.
Also ein grinsendes Kopfschütteln!
Danke schön.
Anselm H. #
Geschrieben am 28.02.2012 um 11:12
zu Media-Queries: Naja, es gibt in Mozilla das proprietäre Feature „-moz-touch-enabled“, was dann 0 oder 1 zurückgibt. Siehe auch hier: https://developer.mozilla.org/en/CSS/Media_queries#-moz-touch-enabled
ich würde es aber dringend abraten, da bisher nur Mozilla. WebKit hat da auch was in Bau, aber mit anderer Syntax und einen WorkingDraft dazu gibt es aktuell nicht.
Löse das besser mit Modernizr und der darin enthaltenen Testfunktion http://www.modernizr.com/docs/#touch
Schepp #
Geschrieben am 28.02.2012 um 11:58
Neben der von Anselm erwähnten Media Query gibt es dann noch die kaum dokumentierten:
@media -o-touchscreen
(Opera & Samsung WebKit)und
@media touchscreen
(iOS)RSS-Feed zu diesem Beitrag
Kommentare sind für diesen Beitrag geschlossen.