Ich durfte die letzten zwei Tage auf dem Chrome Dev Summit verbringen (Danke Paul Kinlan für die Einladung!) Ich habe mir ein paar Dinge notiert, die mir aufgefallen sind.
Es gab eine kurze Erwähnung der manifest.json-Datei, von der ich noch nie gehört hatte. Anscheinend ist das eine Chrome-Sache, die wichtig für Erweiterungen und Ähnliches ist, aber auf das Web übertragen werden kann (oder werden könnte?).
Die Idee ist, dass man vieles, was in den <head> kommt, dort unterbringen könnte. Nicht lebenswichtige Dinge wie den Titel, Meta-Tags und Ähnliches. Ich nehme an, das bereinigt das Dokument ein wenig (auf Kosten einer Anfrage), aber wichtiger ist, dass man so mehr in diese "ersten 14 KB" packen kann – was für das Laden des kritischen Pfades wichtig ist.
Apropos Meta-Tags, hier ist ein neues
<meta name="theme-color" content="#db5945">Nur eine einfache Möglichkeit, das Aussehen Ihrer Website in die Browser-Oberfläche einfließen zu lassen (zumindest unter Chrome für Android). Das passt zu aktuellen Designtrends (z. B. all die Transparenz / Farbverläufe, die in Yosemite zu sehen sind).
Wahrscheinlich war das aufregendste für mich die Rede über das Übertragen von Elementen über Seitenaufrufe hinweg.
1. Teilen Sie der aktuellen Seite mit, was Sie übertragen möchten
<meta name="transition-elements" content="#move-me, .move-all-these">2. Verknüpfen Sie eine spezielle CSS-Datei nur für diese Übergänge
Um den Übergang vor dem Ausblenden durchzuführen
<!-- I imagine you'd defer loading of this one -->
<link rel="transition-exiting-stylesheet" href="page-transitions.css">Oder um ein Element zum neuen Ort auf der eingehenden Seite zu übertragen
<!-- But this one you'd want to link up right at the top -->
<link rel="transition-entering-stylesheet" href="page-transitions.css">3. Verwenden Sie @keyframes, um die Elemente zu verschieben
@keyframes moveToNewPosition {
from { /* where ever it was before */ }
to { top: 0; }
}
#move-me {
animation: moveToNewPosition 0.5s;
}Sicherlich wurden größere, weitaus wichtigere Dinge besprochen, die die Zukunft des Webs beeinflussen. Aber hey, ich mag Tricks. Anscheinend wurde dies hinter einem Flag in Chrome 38 veröffentlicht, aber ich hatte noch keine Zeit, es zum Laufen zu bringen.
Ein vorherrschendes Thema, das heutzutage in der gesamten Branche präsent ist, ist, dass wir, wenn wir wollen, dass das Web "gewinnt" (das tun wir, es ist gut für die Welt), sicherstellen müssen, dass es im Wettbewerb mit nativen Apps steht. Das bedeutet Dinge wie "installierbare" Websites (Präsenz auf Startbildschirmen), Offline-Funktionen und echte (Push-)Benachrichtigungen.
Von den beiden letzteren ist Service Workers die Lösung. Es ist größtenteils über meinen Kopf hinaus, aber so wie ich es verstehe, ist es ein Zugang zu einigen Low-Level-Web-Sachen, die wir noch nie zuvor hatten. Wie weitaus bessere Kontrolle über Offline/Cache, als wir sie zuvor hatten (es ist nicht nur "eine Liste von Dateien, die lokal gespeichert werden sollen", wie frühere Versuche waren).
Service Workers sind der Ort, an dem Sie Benachrichtigungen registrieren (d. h. navigator.push.register()). Selbst wenn eine Website geschlossen ist, können Sie (irgendwie) Benachrichtigungen erhalten. Desktop Safari hat sie, aber ich denke, das ist proprietär. Da es mehrere Wege geben wird, werden Zwischenhändler wie Roost sicher zu einer Möglichkeit, sie mit weniger Komplexität zu nutzen.
Die Idee ist, die Grenze zwischen nativen Apps und Websites besser zu verwischen, und dann wird der Rest dessen, was das Web großartig macht (plattformübergreifend, URLs, Allgegenwart...), es zum Sieg führen.
Es war cool, Paul Lewis über die Gestaltung einer echten Website (der Chrome Dev Summit-Website selbst) sprechen zu hören. Ich denke, wir alle haben mittlerweile einige "Material Design"-Sachen gesehen, wie expandierende Bereiche. Aber das ist meistens in mobilen Apps. Es ist nett zu sehen, wie es hier in responsiven Design funktioniert.
Das Ziel überall für ein ruckelfreies Gefühl ist "60fps". Sechzig Bilder pro Sekunde. Paul sprach viel darüber, wie man das auf dieser Website erreicht, einschließlich kleiner interessanter Details wie der Tatsache, dass man nicht immer 60fps braucht, sondern nur, wenn sich etwas bewegt. Wenn Sie also teure Operationen verschieben können, tun Sie das, wenn sich nichts bewegt.
Paul animierte die (veraltete) clip-Eigenschaft in CSS, um vieles davon zu tun. Ich sprach mit ihm darüber und er sagte, er hätte eine bessere Leistung daraus erzielt als mit dem neueren clip-path.
Es ist jedoch keine reine CSS-Angelegenheit. Jede Animation wird im Grunde wie folgt behandelt:
- Sammeln Sie viele Informationen über das aktuelle Element über
getBoundingClientRect(); - Animieren Sie diese Positionen zu neuen Positionen
Clever, da man nichts fest in CSS einstellen muss (oder im Voraus wissen muss), um diese Animationen durchzuführen. Der Seitenfluss kann völlig normal bleiben. Ich vermute, wir werden in Zukunft viel von dieser Art von Dingen sehen. Finden Sie heraus, was in JS passiert, animieren Sie mit CSS.
Hier ist sein Vortrag (und von dort aus können Sie zu allen anderen gelangen)
Verpassen Sie nicht den Teil über die Verwendung von DevTools zur Inspektion und Steuerung von Animationen. Wie das Verlangsamen, das Anzeigen, welche Elemente betroffen sind, und das Durchsuchen der gesamten Animation mit einem Schieberegler.
Ich könnte mich irren, dass Animationen größtenteils in CSS bleiben, da die Web Animations API kommt.
Eine für Autoren sichtbare Funktion ist .animate() – die so ziemlich wie jQuery (oder Velocity) .animate() ist, bei der Sie ihr einige CSS-Eigenschaften und Werte übergeben und sie dorthin animiert. Es ist jetzt einfach nativ, anstatt eine Bibliothek zu benötigen. Ich stelle mir vor, dass Dinge wie GSAP beginnen werden, native Unterstützung zu erkennen und diese zu nutzen oder auf rAF oder weiter zurückzufallen.
Ich habe mit Alex Danilo darüber gesprochen und ein besseres Verständnis gewonnen. Ich schätze, das Wichtige ist, dass dies nicht nur eine neue API für uns Autoren ist, sondern eine ganze Animations-Engine im Hintergrund. Anstatt also drei verschiedene Animations-Engines (CSS-Übergänge, die etwas anderes waren als CSS-Animationen, die etwas anderes waren als SMIL), ist es nur eine Engine, die alles verwendet.
Ich habe Gerüchte gehört, dass die SMIL-Unterstützung aus Blinks SVG-Unterstützung entfernt wird, und wollte das eigentlich hören. Anscheinend liegt der Ursprung darin, dass es einfach schlecht ist, dass es seine eigene Animations-Engine ist und die Quelle für ziemlich viele Sicherheitsprobleme darstellt. Jetzt gibt es anscheinend einen Mann, der eingestellt wurde, um zu sehen, ob er SMIL unter der Haube die Web Animations API nutzen lassen kann. Wenn ja, großartig, wenn nicht, wird SMIL so selten verwendet (und für eher unwichtige Dinge wie Spinner), dass es entfernt werden könnte.
Meine Sorge ist, dass SMIL einige ziemlich coole Dinge kann, von denen ich nicht zu 100% sicher bin, dass die Web Animations API sie kann, wie Shape Morphing und das Auslösen von Animationen durch Ereignisse (oder andere Animationen).
Es gab viel Polymer-Gerede. Sie sind mit Polymer an einem interessanten Punkt, was das Verständnis der Entwickler angeht. Ich glaube, viele Leute denken dabei an "ein Web-Komponenten-Polyfill", aber
- Web Components ist eigentlich nur ein Überbegriff für vier verschiedene Technologien: Templates, Custom Elements, Shadow DOM und HTML Imports. (gute Anleitung von Googles Rob Dodson).
- Jede dieser Technologien hat einen anderen Polyfill
- Keiner dieser Polyfills ist Polymer
Polymer ist
- Eine Bibliothek, die die Arbeit mit Web Components einfacher und leistungsfähiger macht
- Eigentlich sehr klein: 6 KB komprimiert.
Ein benutzerdefiniertes Element mit einem benutzerdefinierten Shadow DOM hat eine Grenze. Ähnlich wie ein iframe, bei dem die Styles der Elterngruppe nicht durchdringen und die Styles darin nicht austreten. Das ist *wirklich* cool, aber vielleicht nicht immer ideal, denn wenn Sie eine ganze Website um diese Komponenten herum aufbauen, möchten Sie vielleicht, dass Ihre Styles diese Grenzen durchdringen und Dinge stylen, wie wir es von CSS gewohnt sind.
Es gab mehrere Versuche mit Shadow DOM durchdringenden CSS-Selektoren, wie .outside ^^ .inside, eine Pseudo-Klasse, die ich vergessen habe, wie .outside:shadow(.inside). Es gibt eine, die jetzt in Chrome funktioniert, wie .outside /deep/ .inside, aber anscheinend wird das auch nicht die Lösung sein (schwer schnell zu machen, war ein Grund, den ich hörte).
Ich bin gespannt auf eine Lösung hier, denn sie wird das Styling von SVG <use> durch die Shadow DOM-Grenze beeinflussen, was ziemlich interessant sein sollte.
Es gab auch viel "Material Design"-Gerede. Ich fühle mich aus irgendeinem Grund immer, als müsste ich es in Anführungszeichen setzen. Ich mag es sehr, aber ich habe das Gefühl, es ist nur der Name einer Sache, keine echte Sache. Es ist eine Musterbibliothek. Es ist eine Reihe von Richtlinien. Es ist einfach schlichtes, geschmackvolles Design. Ich stimme Khoi Vinh hier zu
Ich bin mir nicht sicher, ob Material Design viel Beachtung finden würde, abgesehen von der Google-Verbindung. Zur Protokollierung: Ich finde Material Design als schöne Arbeit und es ist sicherlich attraktiv, aber die Rhetorik darum erscheint mir viel heiße Luft.
Ein riesiges Unternehmen wie Google mit zig Eigenschaften braucht ein kohärentes System, um alles zusammenzuhalten, und jetzt haben sie es, und das ist großartig. Du und ich können davon lernen, aber wir müssen es nicht direkt verwenden oder es seltsam in lockere Gespräche einfügen. Fühlen Sie sich frei, das bei Ihrer nächsten Cocktailparty nicht zu verwenden
„Wie, ich habe das Gefühl, dass diese Material Design-Bewegung das Arts and Crafts-Bewegung des späten 19. Jahrhunderts parallelisiert, da es darum geht, einfache Formen zu schaffen. Es geht darum, sparsam und sorgfältig mit dem umzugehen, was wir haben. Es geht darum, zu dem zurückzukehren, was einfach und wichtig ist, Mann.“
Chris Palmer sprach viel über Transport Layer Security (TLS). Ich nannte es immer SSL, aber anscheinend ist das die alte Version. Im Grunde URL-Adressen, die mit https:// beginnen.
Es gibt einen großen Vorstoß, das gesamte Internet so zu gestalten, und Chris hat es nachdrücklich unterstützt. Ohne es kann jeder, der sich dazwischen befindet (viele Leute), die übermittelten Daten manipulieren. Es ist für einige ISPs zur Standardpraxis geworden, ihre eigene Google AdSense-ID in den HTML-Code von Websites einzufügen, anstelle der ID des Website-Eigentümers. Das ist Wahnsinn. Kann nicht mit HTTPS gemacht werden, da das, was über die Leitung geht, verschlüsseltes Kauderwelsch ist.
Ein Gegenargument hierzu ist, dass HTTPS "langsam" ist, und wie alle guten Mythen steckt auch hier etwas Wahres drin. Es gibt einige Teile, die Millisekunden dauern können. Aber vieles davon kann durch allgemein kluges Handeln (wie das Zusammenfassen von Anfragen) gemildert werden. Plus, viel moderner Kram, wie das sehr fantastische Zeug in HTTP2 und Service Workers, erfordert HTTPS, also ist es wirklich Zeit, es zu tun.
Ich denke, das ist auf CSS-Tricks einfach genug, aber auf CodePen kann jeder leicht auf unsichere Ressourcen verlinken, daher müssen wir bewerten, wie die UX für eine reine HTTPS-Einrichtung aussieht.
PUH! Das ist viel zu lernen. Es gab dort viel mehr als die wenigen Dinge, die ich abgedeckt habe. Und ich komme gerade von zwei Tagen auf der An Event Apart, also ist mein Gehirn ziemlich voll.
Die Theme-Color-Sache wurde auch in Firefox OS 2.1 übernommen.
Besser ein voller Kopf als ein voller Dickdarm.
— Clinton Gallagher @virtualCableTV @METROmilwaukee
Ich bin Feuer und Flamme und unterstütze die Entfernung von SMIL aus Blink und allem anderen so schnell wie möglich. SMIL wurde mit guten Absichten entwickelt, war aber schon immer schlecht dokumentiert, es gibt keine Entwicklungs- und Testwerkzeuge, und schließlich haben die Browserkriege die SMIL-Goldgans schon vor langer Zeit getötet.
Für mich wird der beste Teil der Abschaffung von SMIL die Umwälzung des Digital Signage-Marktes sein, dessen Softwareanbieter SMIL für die programmatische Steuerung von auf dem Bildschirm angezeigten Assets verwendet haben. Das gibt uns "normalen" Client-seitigen Entwicklern ein offenes Fenster, um unsere eigenen Produkte und Dienstleistungen zu starten und uns einen Vorsprung zu verschaffen, während die alten Anbieter von Signage-Lösungen ihre Apps neu schreiben.
… Hast du dich gerade selbst zitiert?
Hey Chris!
Es war toll, dich bei CDS zu sehen. Danke, dass du dir die Zeit genommen hast, dorthin zu kommen.
Das Web Manifest-Format ist JSON, aber es ist völlig anders als das Chrome Extensions-Format. Sie können sich hier darüber informieren: https://w3c.github.io/manifest/
Die meisten Metadaten, die es unterstützt, sind die Art von Dingen, die Sie heute wiederholen, um Verknüpfungen zu erstellen, wenn Sie etwas als Lesezeichen speichern.
Vielen Dank für das Verfassen von Navigation Transitions! Ich bin SO gespannt, was Ihre Leser damit machen werden.
Grüße
Ich warte immer noch auf ein <foot> (Inhalt unter <body>), um all diese zusätzlichen Meta-Tags zu speichern, sowie all die Skripte, die erst ausgeführt werden, wenn die Seite geladen ist. Aber das Auslagern der Meta-Tags in eine separate Datei könnte auch funktionieren.
Ich habe Tricks verwendet, um den "DOM zu stopfen", aber die Verwendung von data-Attributen ist jetzt der De-facto-Standardtrick, der vom W3C anerkannt wird, mit der folgenden nützlichen Erkenntnis:
http://caniuse.com/#feat=dataset
// Anwendungsfall
‘‘
Versuchen wir noch einmal, diesen Anwendungsfall auszudrücken
<i data-[name]=”[value]”
data-[name]=”[value]”
data-[name]=”[value]”
…
>
Ich bin nicht zu 100% auf dem neuesten Stand der Web-Animationen, aber die Idee ist, eine Kern-API zu haben, die CSS-, SVG/SMIL- und reine JavaScript-Animationen integriert. Sie ist kein Ersatz für die SVG-Animations-Markup, sondern nur eine Schnittstelle zur Steuerung davon.
Insbesondere sagt der neueste Editor's Draft
Mit anderen Worten, SMIL-Unterstützung könnte entfernt werden, aber Sie hätten immer noch <animate>-Elemente (und ihre Geschwister) in SVG. Die SMIL-Spezifikationen sind tatsächlich viel komplexer als das, was in Browsern für SVG implementiert ist. Es ist vielleicht eher eine Anerkennung dafür, dass bestehende SVG-Animationen ein separater Fork von SMIL sind, und sie erlaubt, sich unabhängig zu entwickeln (und mit CSS und JavaScript in einer großen glücklichen Familie namens Web Animations zusammenzuleben).
Wie gesagt, ich habe die Diskussion nicht zu genau verfolgt, also bitte korrigieren Sie mich, wenn jemand kann!
Exzellent zu lesen… sehr informativ….
Diese neuen Meta-Tags in Bezug auf Seitenübergänge klingen einfach erstaunlich… Ich kann es kaum erwarten, sie auszuprobieren…
Ändert die Theme-Color die Farbe der Browser-Oberfläche?
Auf jeden Fall… Danke fürs Teilen, was Sie gelernt haben…
Michael!
Großartiger Beitrag +1 von mir
schöne Informationen, es hilft, mehr Material-Design-Übergänge für Web-Apps zu erstellen. Hier sind einige Webfonts, die sich auf Google Material Design beziehen. http://mirchu.net/material-design-icons/
Hey Google! Sie haben meine Idee "kopiert" :P lmao
Oder vielleicht habe ich Ihre kopiert, aber ich habe es vor Ihnen benutzt… ähm..
http://www.mywebexpression.com (klicken Sie auf einen der Schwänze unten auf der Seite)
Autsch. Und das von den Leuten, die uns sagen, wie wichtig es ist, die Anzahl der HTTP-Anfragen für externe Ressourcen zu minimieren – hätten sie keinen besseren Weg gefunden, dies zu tun, wie z. B. die Erweiterung der Media-Query-Syntax für diesen Zweck (oder im Grunde alles andere, was es uns erlauben würde, dies zusammen mit dem Rest der Seitenformatierung in einer einzigen CSS-Ressource zu behalten)?