Kategorie: Webentwicklung

Kategorien
Webentwicklung

display: table-row – Nicht alles was glänzt ist Gold!

CC0 by gozha.net / via unsplash.com

Neulich schrieb ich ja schon über den sehr interessanten Styling-Ansatz von Google Chrome in Verbindung mit display: table-row. Das entdeckte ich im Zuge des Produktkonfigurator-Projekts. Nun hat es sich ergeben, dass ich im Zuge einer Optimierung eines Webshops für einen Kunden umsetzen sollte, dass alle Footer-Widgets (genauer: 4 Listen mit Navigationspunkten, aufgeteilt auf 4 Spalten) als jeweils eine Box mit gleicher Höhe wie die anderen 3 dargestellt werden sollte.

Das ganze soll natürlich möglichst dynamisch sein, damit unterschiedliche Schriftrenderings auf unterschiedlichen OS- und Browserkombinationen problemlos läuft. Vorgabe des Kunden: Alte Browser (IE<10) dürfen schlechter aussehen, aktueller Firefox ist die Referenz. (‘Und alle so yeah!‘).

Vorher schon habe ich im Zuge der Kästenanpassung für die Breitenoptimierung der Kästen auf box-sizing: border-box; umgestellt, so dass ich außer den Margins hier eigentlich keine größeren Probleme erwartete: Einfach die Kästenelemente auf Tabellen-Zellen-Style umstellen, fertig – wenn eine Zelle höher wird, werden die anderen automatisch auch höher. Jung und naiv.

Nach einer Experimentierphase mit zwei Wrap-Elementen, die display: table und display: table-row stand fest: Es gibt keine Möglichkeit bei display: table und Co., das Spacing der “Tabellenzellen” zu beeinflussen, so dass eine breiter Kasten statt 4 angezeigt wurde. Margins: Ein Ding der Unmöglichkeit. Und weiter mit Wrappern innerhalb der Kästen um das alte Design wieder herzustellen fand ich nicht zielführend.

Ich hatte dann doch kurz überlegt, ob ich nicht das Javacript von OXID anschauen und wieder aktivieren sollte, welches eine Equalheight-Funktion hat, die aber scheinbar mit border-box nicht klarkommt. Da der Kunde (für einen Webshop) sehr progressiv auf Browserebene arbeitet, hab ich dann überlegt, welche Möglichkeiten CSS only dann noch in Frage kommen, ohne am DOM viel zu verändern und dachte mal kurz an das Flexbox-Modul. Und hey: Es funktioniert ab IE10 und in allen modernen Browsern.

Dazu kam folgende Anforderung, die die Entscheidung leichter machte: der letzte Kasten, der bisher nur eine Zeile enthielt wurde mit mehr Inhalt (dynamisch) gefüllt, war nun aber 1 Zeile länger als die anderen Kästen.

Wrapper um die Kästen mit display:flex-box und die Kästen auf flex:1 gesetzt, fasst in allen aktuellen Browsern. IE 8 und 9 kennen Flexbox nicht und machen einen Fallback auf die bereits vorhandene float-Lösung (wodurch der 4. Kasten geringfügig größer ist als die anderen).

  • Schlagwörter
Kategorien
Code Webentwicklung

Performance steigern für WordPress Child-Themes: Alternative zu @import

Oft findet man beim Thema WordPress Child Themes den Hinweis, dass man die Parent-Theme-CSS-Datei im Childtheme dann mittels @import übernehmen soll, wie z.b. so:

/* Use @import, to borrow the style sheet from the Waipoua parent theme */
@import url('../waipoua/style.css');

Das ist zwar richtig und funktioniert, kann aber durchaus nachteilige Effekte auf das CSS-Rendering und Ladeperformance haben. Schließlich wird erst die Child-Theme-Datei geladen, die stößt den Parent-Download und dann muss das ganze lustig berechnet werden.

Einfacher ist es, wenn man die Parent-Style-Datei entweder komplett kopiert oder direkt im HTML einbindet.

Methode 1: Kopieren des Parent-Styles

Vorteil: Nur eine Style-Datei, nur ein Request, kein Style-Merging: Optimale Performance

Nachteil: Beim Theme-Update müssen Differenzen ggf. mühsam  per Hand übertragen werden.

Methode 2: Einbinden ins HTML statt per @import

Vorteil: Update-Kompatibel, nur geänderte Styles müssen in die Datei, Performance besser als bei @import

Nachteil: Perfomance ist schlechter als eine Kopie des Parents

Mein Senf: Methode 2 gewinnt

Aus meiner Sicht ist die Methode 2 besser geeignet, da hier der Wartungsaufwand bei Theme-Updates gegen 0 tendiert, genau wie bei @import. Aber wie funktioniert das?

Zuerst löscht man die @import-Zeile aus der style.css. Dann fügt man in die functions.php folgendes ein:

add_action('wp_enqueue_scripts', 'add_parent_css');
function add_parent_css() {
	wp_enqueue_style('waipoua_main', get_template_directory_uri() . '/style.css', false, '');
	wp_enqueue_style('waipoua_child', get_stylesheet_uri(), 'waipoua_main' );
}

Hier passiert folgendes: Mit get_template_directory_uri() bekommt man das Verzeichnis des Parent-Themes, während man mit get_stylesheet_uri() die Stylesheet-URL des aktiven (in diesem Fall des Child-) Themes bekommt.

Die Namen für die Stylesheets (“waipoua_main” und “waipoua_child”) sind in diesem Fall der Umgebung bei Develovers.de geschuldet, die könnt ihr nennen wie ihr wollt.

Schon meckern Perfomance-Tools evtl. nur noch die Einbindung mehrerer Stylesheets an, aber nicht mehr die Verwendung von @import.

Kategorien
Code Webentwicklung

Do-It-Yourself oder intelligente Verzahnung – Wieviel Eigenleistung steckt in einem Software-Projekt?

Mauer - Stein auf Stein
Stein auf Stein – So ähnlich baut ein modernes Web-Projekt auf bestehenden Bibliotheken auf – oder?

Hintergrundinformation: Ich arbeite aktuell in der Firma an einem größeren Projekt, welches unter anderem die Entwicklung einer komplett JS-basierten Oberfläche zur Konfiguration und Abfrage von Maschinen und der Erstellung eines Angebots für Kunden enthält. Das Projekt läuft seit 8 (“initial commit”: 22. Juli)  Monaten und es arbeiten 2, stellenweise 3 Entwickler daran.

Ich habe mir mal den Spaß gemacht, nachzuschauen, wie viel Code da von unserer Firma drinsteckt:

Die Gesamtsumme aller “per Hand” bearbeiteten Daten beträgt knapp 600KB. Der Rest des Projekts setzt sich zusammen aus den benutzten Bibliotheken: cookie.js, Ember.js, Font Awesome, Handlebars, Holder.js, html5shiv, jQuery, jQuery Tools, jQuery UI, Normalize.css, spin.js, Underscore.js, Grunt

Insgesamt werden beim ersten Laden des Projekts im Browser 580 KB abgerufen, dazu kommen noch ca. 62,7 KB aus (bisher unkomprimierten) Dateien, die erst später Nachgeladen werden (können). Das schließt allerdings keine Abfrage von Daten, sondern nur den Payload des Projekts ein. HTML, JS, CSS/LESS, Bilder.

Ich schwanke meinungstechnisch noch zwischen: “Cool wie effizient” und “oh, das ist aber wenig” (Das Quantität keine Qualitätsaussage ist, ist mir dabei durchaus bewusst). Zum Glück werden wir nicht nach KB bezahlt. (Ausnahmen bestätigen die Regel aber meistens ist das dann eher eine Bezahlung pro gespartem KB)

Wie ist das bei euch? Wie viele Libraries haben eure großen Projekte? Ist das Verhältnis von eigenem vs. fremdem Code bei euch auch so ähnlich oder entwickelt ihr alles “from Scratch”? Sieht das bei “Backend”-Projekten ähnlich aus?

Bild: CC0 von Martin Wessely via Unsplash.com

Kategorien
Webentwicklung

Chrome übernimmt schlechte Table-Row-Stylings vom Internet Explorer

Der Google Chrome nimmt das Attribut “display: table-row” übrigens extrem ernst und liefert eine 1A verbuggte Interpretation (erste Box): Der Hintergrund des umgebenden DIV mit der Klasse “row1” wird in jedem untergeordneten DIV von neuem wiederholt. Das gilt nicht nur für den hier demonstrierten Background-Gradient, sondern auch für Hintergrundbilder. Im Firefox lässt sich das Phänomen nicht beobachten.

Die Lösung ist “einfach” und traditionell bewährt: Anstatt display: table-row; und display: table-cell; nimmt man das halbwegs ausgereifte display: inline-block; für die inneren Elemente und arbeitet wieder mal mit festen Breiten.

Schade.

HTML:

<div class=row1> 
  <div class=cell>1</div>
  <div class=cell>2</div>
  <div class=cell>3</div>
  <div class=cell>4</div>
</div>
<hr>
<div class=row2> 
  <div class=cell>1</div>
  <div class=cell>2</div>
  <div class=cell>3</div>
  <div class=cell>4</div>
</div>

CSS:

.row1 {
  display: table-row;
  background-color: rgb(241,218,54); /* Old browsers */
  background-image: -webkit-gradient(radial, center center, 0, center center, 100%, color-stop(0,rgba(254,252,234,1)), color-stop(100%,rgba(241,218,54,1))); /* Chrome,Safari4+ */
  background-image: -webkit-radial-gradient(center, ellipse cover, rgba(254,252,234,1) 0,rgba(241,218,54,1) 100%); /* Chrome10+,Safari5.1+ */
  background-image: -o-radial-gradient(center, ellipse cover, rgba(254,252,234,1) 0,rgba(241,218,54,1) 100%); /* Opera 12+ */
  background-image: -ms-radial-gradient(center, ellipse cover, rgba(254,252,234,1) 0,rgba(241,218,54,1) 100%); /* IE10+ */
  background-image: -moz-radial-gradient(center, ellipse cover, rgba(254,252,234,1) 0, rgba(241,218,54,1) 100%); /* FF3.6+ */
  background-image: radial-gradient(ellipse at center, rgba(254,252,234,1) 0,rgba(241,218,54,1) 100%); /* W3C */
  filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#fefcea', endColorstr='#f1da36',GradientType=1 ); /* IE6-9 fallback on horizontal gradient */
}
.row1 .cell {
  display: table-cell;
  padding: 150px;
}

.row2 {
  display: block;
  background-color: rgb(241,218,54); /* Old browsers */
  background-image: -webkit-gradient(radial, center center, 0, center center, 100%, color-stop(0,rgba(254,252,234,1)), color-stop(100%,rgba(241,218,54,1))); /* Chrome,Safari4+ */
  background-image: -webkit-radial-gradient(center, ellipse cover, rgba(254,252,234,1) 0,rgba(241,218,54,1) 100%); /* Chrome10+,Safari5.1+ */
  background-image: -o-radial-gradient(center, ellipse cover, rgba(254,252,234,1) 0,rgba(241,218,54,1) 100%); /* Opera 12+ */
  background-image: -ms-radial-gradient(center, ellipse cover, rgba(254,252,234,1) 0,rgba(241,218,54,1) 100%); /* IE10+ */
  background-image: -moz-radial-gradient(center, ellipse cover, rgba(254,252,234,1) 0, rgba(241,218,54,1) 100%); /* FF3.6+ */
  background-image: radial-gradient(ellipse at center, rgba(254,252,234,1) 0,rgba(241,218,54,1) 100%); /* W3C */
  filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#fefcea', endColorstr='#f1da36',GradientType=1 ); /* IE6-9 fallback on horizontal gradient */
}
.row2 .cell {
  display: inline-block;
  padding: 150px;
}

Wer sich das ganze nicht zusammenkopieren will, kann auch einfach bei jsFiddle schauen, da hab ich das mal vorbereitet.

Kategorien
Allgemein Webentwicklung Werkzeuge

Finger abhacken!

screenshot.28-12-2013 22.17.46

Entwickler die scheissteure Module für Shopsysteme vertreiben und dann das Zeuch mit ZendGuard “schützen”, sollte man IE6-Fixing für asm.js aufnötigen. Mittlerweile weiß ich auch, welches Modul das ist. Hat der Kunde halt Pech (im Sinne des Aufwands) gehabt. Ich darf mir nämlich jetzt eine neue Entwicklungsumgebung aufbauen.

Wer PHP Code schreibt und verkauft sollte das als Open Source tun oder die Lizenz entsprechend gestalten, dass eine Änderung am Code einen Verlust der Gewährleistung zur Folge hat, aber nicht so eine Zusatzkacke einbauen, die es anderen erschwert, damit zu arbeiten. Und als Plattformanbieter für Module würde ich genau solche Code Obfuscations ausschließen.

Und für Zend: Warum muss ich einen Account erstellen, wenn andere ihre Software mit eurem Scheiss verschlüsseln und ich nur die verdammte Runtime brauche?