It’s #FrontendFriday – Animationen mit Webkit

It’s Friday that means #FrontendFriday :)

Der ein oder andere findet Animationen auf einer Homepage passend zum Kontent interessant.

Was sind CSS Webkit-Animationen?

Eine Animation lässt die CSS-Eigenschaften ändern so wie ihr es haben wollt und auch so oft ihr es wollt.

Um die CSS Webkit-Animationen zu verwenden, muss man zunächst einige Keyframes für die Animationen festlegen.

Die @keyframes Regeln

Bei den Keyframes geht es darum, zu entscheiden, wann und wie sich das Element zu verhalten hat.

Unterstützung von Browsern:

Fill-Modus für eine Animation

CSS-Animationen haben keinen Einfluss auf ein Element, welches vor dem ersten Keyframe gespielt oder nach dem letzten Keyframe gespielt wird. Die Animation-fill-mode Eigenschaft kann dieses Verhalten außer Kraft setzen.

Die animation-fill-mode Eigenschaft gibt einen Stil für das Zielelement vor, wenn die Animation nicht abgespielt wird (bevor es beginnt, nachdem er endet, oder beides). Die Animation-fill-mode-Eigenschaft kann die folgenden Werte haben:

  • none – Standardwert. Für die Animation gelten keine Stile auf das Element vor oder nach dem es ausgeführt wird
  • forwards – Das Element wird die Stil-Werte beibehalten, die vom letzten Keyframe (abhängig von der Animation-Richtung und Animation-Iteration-count) gesetzt sind.
  • backwards – Das Element wird die Stil-Werte erhalten, die durch den ersten Keyframe (abhängig von der Animation-Richtung) gesetzt sind und bewahren diese während der Animation-Verzögerungszeit.
  • both – Die Animation folgt den Regeln für Vorwärts- und Rückwärtsbewegungen und erweitert die Animationseigenschaften in beide Richtungen

 

Animationen werden öfters im Zusammenhang mit JavaScript verwendet, um z.B. beim Klick auf einem Bild dieses zu animieren.

Auf GitHub gibt es zahlreich viele kleine oder auch große Bibliotheken, welche einem das Animieren einfacher machen, z.B.: https://daneden.github.io/animate.css/

Habt ihr schon mal Animationen auf einer Seite gesehen, wo ihr „Die Animation konntet ihr euch sparen können“ dachtet?

It’s #FrontendFriday – Warum heute noch iFrames zum Standard gehören?

Es ist mal wieder Freitag und das heißt It’s #FrontendFriday. In diesem Blogpost geht es um iFrames – manche haben bestimmt sowohl gute als auch schlechte Erfahrung hiermit gemacht.

Was ist ein iFrame und was ist der Sinn und Zweck hierzu?

Ein iFrame ist das Einbetten einer HTML-Seite innerhalb einer HTML-Seite. Beispiel: Auf einer Webseite gibt es eine Menüleiste, je nach Auswahl wird in einem festgelegtem Bereich der Inhalt einer anderen HTML-Seite angezeigt (HTML-Seite innerhalb einer HTML-Seite) – Oldschool, derzeit nicht mehr state of the art.

Wo werden heute noch iFrames eingesetzt?

Im Allgemeinen werden iFrames dort eingesetzt, wo die Seite bzw. der Entwickler keine Chance hat, den Code (inhaltlich) zu verändern.

Um die eigene Webseite zu tracken, um herauszufinden, wie viele Anwender z.B. die Seite aufgerufen haben oder Interaktionen durchgeführt haben, werden auch Code-Snippets wie z.B. Piwik oder Google Analytics eingesetzt (Cross-Domain Tracking).

iFrames umgehen die Cross-Domain-Ursprungs-Richtlinien (Bilder, Skripte und Stile nicht). Dies kann nützlich sein, um Webseiten/Inhalte relativ sicher aus anderen Domänennamen anzugeigen bzw. zu ziehen. Im Grunde genommen ermöglichen iFrames den Vorteil, Daten von anderen Domains visuell darzustellen zu können.

Zum Beispiel, falls man eine PDF anzeigen möchte, kann man einen iFrame „öffnen“ und den Inhalt durch das Adobe Reader Plug-in anzeigen lassen, dies wird auch heutzutage so gemacht.

Auch heute noch, werden iFrames oft eingesetzt.

Der sichtbare Teil ist nur schlaue Positionierung. Darüber hinaus verwenden viele OAuth-Implementierungen (Twitter, Facebook, Google, Yahoo!) normalerweise iFrames, um einen Benutzer in seiner Domäne mit einer erfolgreichen Authentifizierungs-URL zu verknüpfen (nachdem der Benutzer sich angemeldet hat). Folgende Seiten

  • Gmail
  • Facebook

Wie bekommt man heraus, wie viele iFrames eine Webseite einsetzt?

  1. DevTools öffnen – F12 innerhalb der Webseite
  2. In der Konsole folgendes eingeben:
    1. document.getElementsByTagName(‚iframe‘).length
  3. Falls iFrames eingesetzt werden, wird die Anzahl der iFrames angezeigt, z.B. bei Gmail kam der Wert 13 zurück.

Wie werden iFrames eingesetzt?

Diese werden wie im folgendem Beispiel-Code eingesetzt:

1
2
3
<iframe src="URL" width="200px" height="200px">
    Alternativen Text, falls der iFrame nicht gerendert werden kann.
</iframe>

In diesem Beispiel, wird der iFrame immer angezeigt. Dies kann man ganz einfach per JavaScript ein-/ausblenden lassen.

Welche Browser unterstützen iFrames?

Welche Alternativen gibt es zu iFrames?

Die meisten Frameworks bieten alternativen zu iFrames. jQuery war hierzu einer der Ersten.

Beispiel jQuery:

1
2
3
$( document ).ready(function() {
    $( "#AnzeigeInDieserBox" ).load("www.eine-webseite.de");
});

It’s #FrontendFriday – Was sind die Standards für ein Webfrontend-Projekt?

Es ist wieder Freitag und kurz vor dem Wochenende – It’s #FrontendFriday :)

EditorConfig

EditorConfig hilft den Entwicklern konsistenze Codierungsstile zwischen verschiedenen Editoren und IDEs zu definieren und zu pflegen.

Das EditorConfig-Projekt besteht aus einem Dateiformat zum Definieren von Codierungsstilen und einer Sammlung von Text-Editor-Plugins, die es Editoren ermöglichen, das Dateiformat zu lesen und definierte Stile einzuhalten. EditorConfig-Dateien sind leicht lesbar und funktionieren gut mit Versionskontrollsystemen.

Für die Installation der EditorConfig, muss überprüft werden, ob die eingesetzte Entwicklungsumgebung (IDE) bereits ein EditorConfig Plugin installiert hat oder ob dies manuell durchzuführen ist. In Visual Studio Code muss dies manuell durchgeführt werden.

Naming Conventions für HTML, CSS und JavaScript

Naming Conventions sind sehr wichtig für die Lesbarkeit des Codes und der Spruch „Wenn es schwer war zum schreiben, soll es auch schwer sein zum Lesen“ soll hiermit nicht mehr geltend sein.

Damit auch der Code von jedermann gelesen und auch verstanden werden kann müssen alle Namen also für Klassen, Interfaces und auch Variablen in der Sprach Englisch sein. Bei komplexen und nicht so einfach zu verstehenden Methoden sollten diese mit Kommentare versehen werden. Diese sind wichtig, damit die Person, welche den Code noch nie gesehen haben, schnell verstehen, wofür diese Methode ist und was sie macht.

Codeanalyse mit SonarQube

Die Codeanalyse durch SonarQube ist für jedes Projekt, wo natürlich auch Code besteht, wichtig. Hierbei sind Regeln definiert, sei es Regeln, welche vom Kunden festgelegt sind oder auch eigene Regeln. Wichtigste Regel hierzu ist, dass die Naming Conventions eingehalten wurden.

It’s #FrontendFriday – Was sind Testpfade und welche gibt es?

Es war eine sehr warme Woche, aber dies haben wir auch überstanden und was fällt euch zu Freitag ein – Ganz genau It’s #FrontendFriday ;)

Im heutigem Post geht es um die Testpfade, welches sowohl im Frontend, Java Projekten, etc. eingesetzt bzw. getestet wird.

Was sind Testpfade?

Im Umfeld eines Projektes werden auch unter anderem andere Services angebunden, da von diesen bestimmte Informationen erhalten werden soll. Ihr möchtet über z.B. einem JUnit-Test testen, ob auch deine Implementierung das tut, was es auch machen sollte. Dies gibt es auch im Frontend.

Hierbei testet man ein Codeausführungsszenario, von dem ein bestimmtes Verhalten erwartet und geprüft wird.

 

 

Welche Testpfade gibt es?

Happy Path

Natürlich möchte man als erstes immer den Erfolgsfall bzw. Good-Case-Fall testen – Happy Path. Dies ist das einfachste Szenario, ohne dass Ausnahmen oder Fehlerzustände eintreten. Dieser Test stellt die Basisfunktionalität des Codeabschnitts dar – Happy Path ist das Mindeste, welches getestet werden sollte.

Natürlich möchte man sehr gerne vom Good-Case ausgehen, aber dieser reicht allerdings nicht aus, um die Funktionalität des Codes mit Verzweigung zu testen.

Scary Path

So schlimm sich dies auch anhört, sollten auch die Szenarien getestet werden, welches den Code zu einem Fehlverhalten oder ein einem Fehlzustand bringt. Der Scary Path ist vor allem dann zu testen, wenn durch das Fehlverhalten bzw. den Fehlerzustand ein hohes Risiko für die Stakeholder besteht.

Angry Path

Was ist wenn der angebundene Service einen Fehler zurückgibt? Ist dann euer Code noch stabil? Oder werden nur noch Fehler geworfen?

Es ist ärgerlich, wenn der angebundene Service einen Fehler zurückgibt, aber dafür hast du dir schon Gedanken gemacht und es auch deinem Code beigebracht, was es wie machen soll, wenn ein Fehler erhalten wird. Angry Path testet den Code, welches es zu einem Ausnahmeverhalten führt, jedoch in einem gültigen und funktionierenden Zustand verbleibt.

Delinquent Path

Du stellst bspw. für dein Projekt auch eine Oberfläche bereit. Du möchtest nicht, dass jede Person, welches die URL hat, darauf kommt – also berechtigst du nur bestimmte Personen mit bestimmten Zugangsdaten. Mit dem Delinquent Path wird die Autorisierung, Authentifizierung, Berechtigung oder andere Sicherheitsmaßnahmen getestet.

Desolate Path

Diesen Test macht im Prinzip jeder Standardmäßig – Was ist wenn null, 0, 1, -1 oder auch NaN zurückgegeben wird? Was soll dann passieren? Hierzu ist der Desolate Path zuständig, welches diesen Fall testet.

Forgetful Path

Um Daten nicht zu verlieren oder auch um diese Weiterzuleiten, werden diese oft in einer Datenbank gespeichert – Aber was ist, wenn die Datenbank nicht vorhanden oder verfügbar ist? Dies soll der Forgetful Path testen.

Ihr habt Kundendaten, welches durch bestimmte Prozesse durchlaufen soll. Ihr speichert initial die Daten die ihr erhalten habt in der Datenbank. Zu diesem Zeitpunkt ist die Datenbank nicht verfügbar – Was soll geschehen? Soll eine Fehlermeldung geworfen werden? Genau hierzu ist der Forgetful Path-Test gut

Greedy Path

Auf der Oberfläche, hat der Anwender die Möglichkeit eine große Anzahl an Optionen zu wählen oder eine Vielzahl von Aktionen ausführen zu lassen – Greedy Path testet, dass die Aktionen innerhalb von kürzester Zeit ausgeführt werden.

Stressful Path

Was ist wenn der HTTP-Request zu lange dauert? Bricht es ab, oder wartet es solange, bis eine Antwort erhalten wird? Wie soll es sich verhalten, wenn es zu lange dauert? Wurde denn schon Gedanken über eine Timeout gemacht? Ja? Nein? Genau dies soll der Stressful Path-Test testen.

It’s #FrontendFriday – Bootstrap wechselt von jQuery to Hugo.js

Es ist wieder Freitag und das heißt: #FrontendFriday! :)

Heute geht es um das Framework Bootstrap, welches der ein oder andere kennt, angewendet oder auch nur mal gehört hat.

Was ist Bootstrap?

Jeder möchte sich sein Leben einfach machen, deshalb gibt es auch Boostrap, welches ein Frontend-Framework ist. Es werden viele HTML- und CSS-Vorlagen bereitgestellt, um verschiedene Webseite-Elemente unterschiedlich darzustellen.

Hierzu gehören Formulare, Buttons, Tabellen, Navigationsleisten sowie ein Grid-System für Layouts. Über HTML- und CSS-Vorlagen hinaus ist es durch JavaScript-Module möglich, Interaktionen, wie z.B. Bilder-Slideshow, Tabs und Dialogboxen auf der Webseite einzubinden.

Bootstrap bietet alle Voraussetzungen, um responsive Design optimal zu gestalten, sei es für Desktop, Smartphone oder Tablet.

Ihr wollt wissen was Bootstrap an Layout und viele andere Features mit sich bringt, dann könnt ihr euch gerne die Dokumentation anschauen: https://getbootstrap.com/docs/4.3/getting-started/introduction/

Was ist jQuery?

Boostrap erleichtert die Arbeit eines Entwicklers in Sachen HTML und CSS. jQuery hingegen die JavaScript-Arbeit – es ist eine JavaScript-Bibliothek.

Es überbrückt technische Unterschiede verschiedene Browsern – ermöglicht komfortablen und kompakten Code, der im Vergleich zu reinem JavaScript häufig sehr viel kürzer ist.

Mehr zu jQuery: https://jquery.com/

Bootstrap verwendete für die JavaScript Modulen jQuery, jedoch nur bis Version 4.3

Warum verwendet Bootstrap 4.3 kein jQuery mehr?

Etwas was die Community wohl bereits länger diskutiert hat, war der Abschied von jQuery für die DOM-Manipulation (Document Object Model) bzw. -Navigation.

Bootstrap wird ohne jQuery auskommen und dies wird derzeit entfernt. Bootstrap ist nicht das erste Tool, das diesen Schritt geht, auch Ember und GitHub arbeiten bereits nicht mehr standardmäßig mit jQuery.

Der wichtigste Punkt hierbei ist: Schonen von Ressourcen auf dem Server!

Bye Bye jQuery – Hello Hugo.js

Bei Hugo handelt es sich um einen Static Site Generator, der in Go geschrieben ist. Hugo beschreibt sich selbst: world’s fastest static website engine.

Hugo zählt zu den Statischen Webseiten-Generatoren und kann ganz ohne weitere Hilfsmittel genutzt werden.

Aber warum nun Hugo.js?

Es handelt sich hierbei um einen statischem Webseitengenerator – Dies bedeutet, dass der Inhalt nicht jedes Mal neu generiert wird, sondern nur, wenn sich der Inhalt der jeweiligen Seite ändert.

Insbesondere ermöglicht es Hugo, dass nur diejenigen HTML-Dokumente der jeweiligen Webseite neu gebaut werden müssen, in denen Änderungen auftraten.

Hierdurch sollen die Ressourcen des Servers geschont und eine hohe Effizienz von diesem erreicht werden.

Mehr zu Hugo: https://gohugo.io/getting-started/

Fazit

jQuery hat viel Arbeit für den Frontend-Entwickler entnommen, vor allem, wenn man Einsteiger ist. Im Gegensatz zum reinem JavaScript war auch der Code häufig viel kürzer und lesbarer.

Um Ressourcen sowohl auf dem Server, als auch lokal beim Entwickeln zu sparen, sodass die Inhalte nicht immer wieder neu erstellt werden müssen, ist Hugo hierbei sehr Ressourcen- und Zeit-Sparender.

It’s #FrontendFriday – Browserengines

It’s Friday that means #FrontendFriday! :)

Heute geht es um das Thema „Browserengines“.

Was ist eigentlich eine Browserengine?

Eine Browser-Engine ist eine zentrale Softwarekomponente eines Webbrowsers.

Die Hauptaufgabe einer Browserengine besteht darin, HTML-Dokumente und andere Ressourcen einer Webseite in eine interaktive visuelle Darstellung auf dem Gerät eines Benutzers zu transformieren.

Eine Browser-Engine ist kein eigenständiges Computerprogramm, sondern ein Bestandteil eines Webbrowsers, aus dem der Begriff abgeleitet ist.

Neben der Browserengine werden in Bezug auf verwandte Konzepte zwei weitere Begriffe verwendet: „Layout-Engine“ und „Rendering-Engine“. Theoretisch könnten Layout und Rendering von separaten Engines übernommen werden. In der Praxis sind sie jedoch eng gekoppelt und werden selten getrennt betrachtet.

Zusätzlich zum Layout und Rendering erzwingt eine Browser-Engine die Sicherheitsrichtlinien zwischen Dokumenten und implementiert die Datenstruktur des Document Object Model (DOM), die Seitenskripten ausgesetzt ist. Es werden auch Hyperlinks und Webformulare behandelt.

Das Ausführen von JavaScript (JS)-Code ist jedoch eine separate Angelegenheit, da jeder gängige Webbrowser dafür eine eigene Engine verwendet. Die JS-Sprache wurde ursprünglich für die Verwendung in Browsern entwickelt, wird aber nun auch an anderer Stelle verwendet, so dass die Implementierung von JS-Engines von Browser-Engines entkoppelt ist. In einem Webbrowser arbeiten die beiden Engines über die gemeinsame DOM-Datenstruktur zusammen.

Vergleich von Browserengines

Engine
Status
Verwalter
Lizenz
Eingebunden in
WebKit Aktiv Apple GNU LGPLBSD-style Safari sowie alle Browser, die im iOS App Store zufinden sind
Blink Aktiv Google GNU LGPLBSD-style Google Chrome und alle anderen Chromium-basierten Browser wie Microsoft EdgeBrave und Opera
Gecko Aktiv Mozilla Mozilla Public Firefox und Thunderbird email client, sowie forksSeaMonkey und Waterfox
Servo Aktiv Mozilla Mozilla Public Versuchsbrowser (Kann unvollständig oder fehlerhaft sein)
Goanna Aktiv M. C. Straver Mozilla Public Pale Moon und Basilisk browser
NetSurf Aktiv Hobbyisten GNU GPLv2 NetSurf
KHTML Nicht fortführend KDE GNU LGPL Konqueror
Trident Nicht fortführend Microsoft Proprietary Internet Explorer und Microsoft Outlook
EdgeHTML Nicht fortführend Microsoft Proprietary formerly in the Microsoft Edge browser

Unterstüzung von HTML, CSS, Grafiken und Typographie

Engine
Status
WebKit Aktiv
Blink Aktiv
Gecko Aktiv
KHTML Nicht fortführend
Presto Nicht fortführend
EdgeHTML Nicht fortführend
Trident Nicht fortführend

Bevor ich mich mit Browserengines beschäftigt hatte:

 

 

 

 

 

 

 

Und jetzt: