Posted: Mai 29th, 2014 | Filed under: Java | Tags: css, Java, JavaFX, JavaFX8, progress-bar, styling, Tutorial | 3 Comments »
In my opinion the JavaFX CSS Reference Guide is not well elaborated. With the help of screenshots and concrete examples it would be much easier to understand the explanations. Therefore I started https://github.com/frankred/JavaFX-Tutorials to give you some examples for specific components.
In the following post the progress-bar component is introduced.
.progress-bar {
-fx-background-color: yellow;
-fx-background-radius: 10, 10, 10, 10;
}
.progress-bar .track{
-fx-background-color: green;
-fx-background-insets: 20;
-fx-background-radius: 6, 6, 6, 6;
}
.progress-bar .bar {
-fx-background-color: grey;
-fx-background-insets: 30, 30, 30, 30;
-fx-background-radius: 4, 4, 4, 4;
}
Feel free to copy and paste everything!
Posted: Oktober 12th, 2011 | Filed under: Internet, Programmieren, Tutorials | Tags: css, GZIP, JavaScript, komprimieren, Ladezeit, Minify, optimieren, pingdom, Sprites, Wordpress Plugins, YSLOW | 4 Comments »
In folgendem Artikel möchte ich euch einen Anreiz geben wie ihr bei eurem Blog oder bei eurer Webseite schnellere Ladezeiten erreicht. Angeregt dazu hat mich der Artikel “Speed me up!” aus der c’t 2011 / Heft 20.
Analyse
Zu allererst misst ihr am Besten eure die Ladezeit eure Webseite. Damit ihr einen Vergleichswert nach dem Optimieren habt. Dafür eignet sich das Tool pingdom hervorragend, damit könnt ihr sehen welche Komponenten wie lange laden. Als weiteres Tool kenne ich YSLOW aus dem Hause Yahoo, welches mich jedoch nicht so sehr überzeugt hat. YSLOW bietet einige Zusatzfeatures wie die Bewertung bestimmter Parameter mit Schulnoten von A (sehr gut) bis F(sehr schlecht).
CSS-Datei vor JavaScript laden
Da JavaScript Code auf die Informationen von CSS angewiesen ist wird JavaScript erst ausgeführt wenn alle CSS-Dateien geladen sind.
Nur eine CSS-Datei und eine JavaScript-Datei
Jedes laden einer Datei bedeutet für den Browser eine neue Anfrage an den Server. Bis diese Anfrage gestellt ist und mit einer Datei beantwortet wird vergeht relativ viel Zeit im vergleich zum Herunterladen der Datei. Packt man also drei CSS-Dateien mit je 10KB zusammen zu einer 30KB Datei ist das im Vergleich viel schneller wie das dreimalige herunterladen von 10KB. Das gleiche gilt natürlich auch für JavaScript-Dateien.
Komprimieren von CSS-Dateien
Um CSS-Dateien zu komprimieren gibt es mehrere Dienste zur Auswahl. Ich verwende jedoch immer CSS-Compressor von minifycss.com. Die CSS-Datei meines Blog-Theme konnte immerhin von 9.126KB auf 6.834KB komprimiert werden. Das entspricht einer Komprimierungsrate von 25.1%. Bei der Komprimierung werden zum Beispiel Farbinformationen, unnötige Backslashes oder Sonstige Attribute gekürzt.
Komprimieren von JavaScript-Dateien
Um JS-Dateien zu komprimieren verwende ich jscompress. Komprimiert man zum Beispiel die JS-Datei des Plugins Lightbox, kommt man von 23.83KB auf stolze 10.590KB und einer Komprimierungsrate von stolzen 56%. Setzt man JavaScript-Frameworks wie jQuery oder ähnliches ein kann man das Framework als bereits komprimierte JS-Datei herunterladen.
Bilder zusammenfassen
CSS-Sprites werden benutzt um die Anzahl der HTTP-Anfragen an einen Server zu reduzieren um somit schnellere Seitenladezeiten zu erreichen. Hierbei werden alle Bilder zu einem einzigen Bild gepackt, und über CSS Positionsinformationen je nach anzuzeigendem Bild ausgerichtet. Auch hier gibt es eine Menge Anbieter. Da ich CSS-Sprites für meinen Blog nicht verwende kann ich leider keinen mir bekannten Dienst nennen, aber einfach mal nach css sprites generator googlen.
Sonstiges
Hier noch eine andere Methoden die ich kenne mich jedoch noch nicht wirklich damit beschäftigt habe:
WordPress-Plugins
- WP Super Cache: Cached Bloginhalte, somit werden Datenbankzugriffe und Ausführung von PHP-Code reduziert.
- WP Minify: Reduziert die Anzahl von CSS- und JS-Dateien
- Use Google-Libaries: Ladet alle bekannten Bibliotheken wie zum Beispiel jQuery oder Prototype von Google-Servern, dies reduziert die eigene Serverlast.
Falls ihr noch mehr Informationen habt zu dem Thema, könnt ihr diese gerne hier posten. Ich hoffe ich konnte dem ein oder anderen weiterhelfen.
Posted: Oktober 14th, 2008 | Filed under: Internet, Programmieren | Tags: barrierearm, barrierefrei, css, html, Internet | No Comments »
Hier mal eine von mir erstellte Dokumentation über barrierefreies beziehungsweise barrierearmes Internet.
Barrierefreies Internet
1.1 Gliederung
- Einleitung
- Probleme bei der Informationsverarbeitung
- Webstandards
- Techniken
- Schlusswort
- Quellen
1.2 Einleitung
Barrierefreies Internet bietet die Möglichkeit allen Menschen unabhängig von technischen und körperlichen Voraussetzungen die verschiedensten Internetinhalte zugänglich zu machen. Die Kunst dabei ist es Webseiten so zu gestalten dass jeder die Informationen nutzen, lesen und verarbeiten kann.
1.3 Probleme der Informationsverarbeitung
1.3.1 Körperlich eingeschränkte Menschen
- Blinde Menschen benutzen so genannte Screenreader (Bildschirmleseprogramme). Dabei werden Texte und Bedienelemente, mittels akustischer Sprachausgabe, vorgelesen. Befinden sich nun Bilder auf der Internetseite hat der blinde keine Möglichkeit irgendeine Information daraus zu gewinnen. Deshalb sollte zu jedem Bild, zu jeder Animation oder zu jedem Video ein Alternativtext verwendet werden.
- Durch die Verwendung von Java oder Flash Applikation, vor allem in der Navigation oder auf anderen wichtigen Seitenelementen, werden sehbehinderte automatisch ausgesperrt.
- Sehschwache oder ältere Menschen benötigen skalierbare Schrift um den Seiteninhalt ihrer Bedürfnisse entsprechend anzupassen.
- Personen die keine Maus bedienen können weil sie Spastiken oder andere Bewegungseinschränkungen haben navigieren sich meistens mit der „Tab“ Taste und springen so von Link zu Link. Deshalb sollte die Webseite gut mit der Tastatur bedienbar sein und es ist wichtig dass die einzelnen Elemente in einer sinnvollen Reihenfolge sind. Durch Einsatz von z.B. JavaScript Links (onclick Aktionen) können diese Menschen keine Interaktionen durchführen.
- Gehörlose Menschen können akustische Inhalte nicht wahrnehmen. Deshalb sollte darauf verzichtet werden oder ein Alternativer Text der den Inhalt der Audiosequenz widerspiegelt zur Verfügung gestellt werden.
- Da manche Menschen Probleme mit langen und umständlichen Texten haben sollte der Inhalt und die Navigation leicht verständlich formuliert werden.
1.3.2 Technisch eingeschränkte Benutzer
- Durch Verwendung von Flash, Java, Qicktime, RealPlayer, Shockwave oder Windows Media Player Elementen werden Benutzer denen diese Plugins nicht zur Verfügung stehen automatisch benachteiligt.
- Aus Sicherheitsgründen deaktivieren einige Benutzer JavaScript oder sie besitzen kein JavaScript, weil ihr Browser zu alt ist. Deswegen sollte kein JavaScript verwendet werden. Diese Vorstellung scheint jedoch sehr unrealistisch in Anbetracht der momentanen Web 2.0 Entwicklung. Je höher die Vielfalt die durch JavaScript entsteht, zum Beispiel „Asynchrone http Requests“, desto höher ist das Risiko der ausgrenzenden Mechanismen.
1.4 Webstandards
1.4.1 Auswirkungen auf das Frontend
Auszug aus http://www.lingo4u.de/article/checklist#level-01-01 . Diese Checkliste ist lediglich ein kleiner Leitfaden an dem sich orientiert werden kann. Für ausführlichere Informationen bitte das von „Web Accessibility Initiative“ (Initiative von W3C) erstelle Handbuch (http://www.w3.org/TR/WCAG10/) und die Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz (BITV) (http://www.einfach-fuer-alle.de/artikel/bitv/ ) verwenden.
• Qualität des Codes
• Hat die Seite einen korrekten Doctype?
• Hat die Seite eine Zeichensatzcodierung?
• Verwendet die Seite gültiges (X)HTML?
• Verwendet die Seite gültiges CSS?
• Nutzt die Seite CSS-Hacks?
• Hat die Seite unnötige Klassen oder IDs?
• Ist der Code gut strukturiert?
• Gibt es tote Links auf der Seite?
• Wie sieht es mit der Größe/Geschwindigkeit der Seite aus?
• Treten JavaScript-Fehler auf?
• Grad der Trennung von Inhalt und Layout
• Verwendet die Seite für die Gestaltung überall CSS (Schriftart, Farbe, Abstände, Ränder etc.)?
• Sind alle dekorativen Bilder mit CSS realisiert oder erscheinen sie im (X)HTML?
• Zugänglichkeit für Nutzer
• Ist das Alt-Attribut für alle beschreibenden Bilder sinnvoll gesetzt?
• Verwendet die Seite relative Einheiten für die Schriftgröße (statt absoluter Einheiten)?
• Wird das Layout beim Vergrößern der Schrift gestört?
• Verwendet die Seite »visible skip menus«?
• Nutzt die Seite zugängliche Formulare?
• Nutzt die Seite zugängliche Tabellen?
• Haben die Farben ausreichend Helligkeit/Kontrast?
• Werden wichtige Informationen nur mit Farben gekennzeichnet?
• Gibt es verzögerte DropDown-Menüs (für Nutzer, mit eingeschränkten motorischen Fähigkeiten)?
• Sind alle Linktexte beschreibend (für blinde Nutzer)?
• Zugänglichkeit für Geräte/Maschinen
• Funktioniert die Seite in neuen und alten Browsern vernünftig?
• Ist der Inhalt der Seite auch ohne CSS zugänglich?
• Ist der Inhalt der Seite auch ohne Bilder zugänglich?
• Funktioniert die Seite auch in Textbrowsern wie Lynx?
• Lässt sich die Seite vernünftig ausdrucken?
• Funktioniert die Seite auf Handhelds?
• Besitzt die Seite ausführliche Meta-Informationen?
• Funktioniert die Seite in verschiedenen Fenstergrößen des Browsers?
• Grundlegende Benutzbarkeit
• Gibt es eine klare visuelle Gliederung?
• Sind die Überschriften unterschiedlicher Ordnung leicht unterscheidbar?
• Besitzt die Seite eine leicht verständliche Navigation?
• Ist die Navigation auf allen Seiten durchgängig?
• Wird eine konsistente und passende Sprache/Formulierung verwendet?
• Gibt es eine Sitemap und ist diese leicht zu finden?
• Ist bei größeren Seiten eine Suchfunktion vorhanden?
• Gibt es auf jeder Seite einen Link zur Startseite?
• Sind alle Links unterstrichen?
• Sind schon besuchte Links entsprechend farblich gekennzeichnet?
• Seitenverwaltung
• Hat die Seite eine aussagefähige und hilfreiche 404-Fehlerseite, die überall funktioniert?
• Hat die Seite lesbare URLs?
• Ist die Seite auch ohne »www« erreichbar?
• Hat die Seite ein Favicon?
1.5 Techniken
- Gültiges HTML/XHTML nach W3C Standart.
- Durch CSS strikte Trennung von Layout und Inhalt.
- Skalierbarkeit von Schriften, Abständen und Größen. Alle Abstände sollten relativ sein, d.h. alle Angaben in „em“ oder „%“.
- HTML/XHTML Elemente entsprechend ihrer Bedeutung nutzen. Mehr dazu unter http://de.selfhtml.org/html/text/logisch.htm . Hier einige Beispiele: (Überschrift), (stark betont), (wichtiger Text), (Numerische Liste).
- Quelltext nicht unnötig aufblähen durch anwenden von Div Layouts anstatt Tabellen Layouts.
- Bilder mit Alternativtext ausstatten.
- Schaltflächeneffekte über CSS anstatt JavaScript.
Um zu prüfen ob eine Internet Seite in gültigem HTML oder XHTML geschrieben ist gibt es Prüfungsdienste. Zum Beispiel: http://validator.w3.org
1.6 Schlusswort
Durch die rasante Verbreitung von Ajax, visuellen Effekten und benutzerfreundlichen Interaktionen bietet uns das Internet immer mehr neue Chancen und Möglichkeiten um den „normalen“ Internetbenutzer das Surfen angenehmer, unterhaltsame, spektakulärer und interaktiver zu gestalten. Webapplikationen wie http://www.pixlr.com/app oder http://280slides.com Editor lassen uns erahnen was in Zukunft möglich sein wird. Hoch komplexe Software wird auf den Browser projiziert und uns von überall zugänglich gemacht. Dabei wird vor allem auf die Techniken JavaScript und Flash gesetzt.
Der neue Browser „Chrome“ (http://www.google.com/chrom) aus dem Hause Google setzt durch seine neuartige JavaScript Engine neue Maßstäbe im Bereich Geschwindigkeit, Stabilität und Sicherheit.
Diese Entwicklung wird das „Web 2.0“ weiterhin vorantreiben und es wird zu einem verstärkten Einsatz, aller Barrierefreiheit zum Trotz, zu komplexen JavaScript Applikationen kommen.
Jedoch besteht darin die Gefahr, dass die Barrierefreiheit noch schneller und mehr ins Hintertreffen gerät. Durch diese rasante Entwicklung (Neues Web Konzept: http://adaptivepath.com/aurora) werden immer mehr Menschen ausgegrenzt und ihnen der Zugang zu Webinhalten unzugänglich gemacht.
1.7 Quellen
Ein Karlsruher Bloggt!
