Archiv der Kategorie: Webdesign

Und ich dachte lange, ich wäre in HTML/CSS halbwegs auf einem brauchbaren Stand. Technisch, weniger als Designer. Nunja, seit flex wurde es ja auch nicht mehr wirklich komplizierter einfacher 😅

Jetzt bin ich bei einem debugging-Einsatz in einem ERP-Portal über die Einheit q gestolpert. Die Existenz von q und dessen Bedeutung waren mir bisher nicht bewusst.

Also habe ich natürlich angefangen zu lesen.

Was für ein 🐰🕳️

Es gibt 42 verschiedene Einheiten in CSS

Kein Scherz: Mittlerweile gibt es mit 42 (43, wenn man die Umrechnungsfaktoren mitzählt) ganz schön viele Größeneinheiten.

px, %, em, ex, cm, mm, in, pt, pc, vh, vw, rem, vmin, vmax, lvh, lvw, swh, svw, svb, svi, dvh, dvw, dvb, dvi, dvmin, dvmax, Q, cqw, cqh, cqi, cqb, cqmin, cqmax, ch, rch, lh, rlh, cap, rcap, ic, ric, rex

Einige davon klingen einleuchtend und sind recht nützlich, andere klinge für mich eher esoterisch … wie beispielweise das q 😉

px – Pixel, absolute Längeneinheit. Ein Pixel bei 96 dpi (Dots Per Inch) ist ~0,264mm groß, weil 96 Pixel in einen Zoll (25,4mm) passen

% – Prozentsatz, relative Einheit. Relativ zum umgebenden Element

em – Schriftgröße des lokalen Elements. Wenn man eine Schriftgröße von 12px verwendet, dann entspricht 1em = 12px

rem – Prinzipiell identisch zu em, aber von der Schriftgröße des Stammelements ausgehend

ex – Eine Länge, die relativ zur Höhe des kleinen Buchstaben „x“ in der aktuellen Schriftart des aktuellen Elements. Zum Beispiel: „font-size: 2ex;“. Hier würde ich gerne einen Anwendungsfall sehen …

cm – Absolut, Länge in Zentimetern

mm – Absolut, Länge in Millimetern

in – Absout, Länge in Zoll (1 Zoll = 2,54 cm)

pt – Absolut, Länge in Punkt (1pt = 1/72 Zoll)

pc – Absolut, Länge in Pica (1pc = 12pt)

vh – Relative Höhe als Prozentsatz der Ansichtsfensterhöhe, wobei 1vh genau 1% der Ansichtsfensterhöhe entspricht.

vw – Relative Länge als Prozentsatz der Ansichtsfensterbreite, wobei 1vw genau 1% der Ansichtsfensterbreite entspricht.

vmin – Relative Viewport-Einheit, die den Wert 1% der kleineren Dimension des Viewports darstellt. vmin wählt also zwischen der Viewport-Breite (vw) und der Viewport-Höhe (vh) den jeweils kleineren Wert – und bezieht sich darauf als Prozentangabe.

vmax – Relative Viewport-Einheit, die den Wert 1% der größeren Dimension des Viewports darstellt, wie vmin.

lvh – Die größtmögliche Viewport-höhe, während des Seitenladens. Steht für „Large Viewport Height“ und meint die maximale Höhe des Viewports, die ein Element einnehmen kann, wenn alle dynamischen Benutzeroberflächenelemente (Tastatur, Adressleiste, …) ausgeblendet sind. Sozusagen der „Innenraum“

lvw – Siehe lvh, nur in der Breite.

swh – Die kleinstmögliche Viewport-höhe, während des Seitenladens. Komplementör zu lvh

svw – Siehe swh, nur in der Breite.

svb – Die kleinste Viewportblockgröße, basierend auf der kleinsten Blockabmessung. Also die kleinste mögliche Größe des Viewports in Blockrichtung (in der Regel vertikal für die Höhe).

svi – Wie svb, nur für die inline-Größe.

dvh – Die dynamische Ansichtsfensterhöhe. Passt sich immer an, wenn die Höhe des Ansichtsfensters geändert wird (z.B. Resize oder einblenden der Tastatur).

dvw – Die dynamische Ansichtsfensterbreite. Passt sich immer an, wenn die Breite des Ansichtsfensters geändert wird (z.B. Resize oder einblenden der Tastatur).

dvb – Die dynamische Viewportblockgröße, also immer die (Innen-) Dimension des Viewport in Blockrichtung.

dvi – Wie dvb, nur für die inline-Größe.

dvmin – Dynamisch, der jeweils kleinere Wert von dvh oder dvw.

dvmax – Dynamsich, der jeweils größere Wert von dvh oder dvw.

Q – Absolut: steht genau für einen Viertelmillimeter (1q = 1/4mm = 0,25mm). Wenn jemand herausfindet, wofür das jemals (sinnvoll) genutzt wurde, freuen wir uns über einen Hinweis.

cqw – Die dynamische Container-Abfragebreite, jeweils relativ zur Breite des Abfragecontainers. Genauer: die Länge, die einem Prozent der Breite des nächstgelegenen Elements mit einem definierten Containerelement-Kontext entspricht. also ganz ähnlich wie die Viewport-Einheiten, aber auf den Container bezogen

cqh – Siehe cqw, nur relativ zur Höhe.

cqi – Siehe cqw, nur relativ zum inline-Element.

cqb – Siehe cqw, nur relativ zur Blockgröße.

cqmin – Die kleinste Viewportblockgröße aus cqi oder cqb, basierend auf dem umgebenden Container.

cqmax – Siehe cqmin, nur die größere.

ch – Relative Größe zur Höhe des Zeichens „0“ in der aktuellen Schriftart. Also wie ex, aber mit der Null als Basis

rch – Relative Größe (in ch) zum Stammelement

lh – Relative Größe zur Zeilenhöhe (Line-Height) des aktuellen Elements

rlh – Wie lh, nur relativ zum Wurzelelement

cap – Relativ zur Höhe der Großbuchstaben der aktuellen Schriftart

rcap – Wie cap, nur zum Wurzelelement

ic – Steht für das „Ideographische Zeichen 水“ und enthält (pseudo-dynamisch) als Basis die Breite des Schriftzeichens, das durch das CJK-Wasser-Ideogramm (U+6C34) im jeweiligen Element dargestellt wird

ric – Relativ zu 水 (wie ic), aber zum Wurzelelement

rex – Relativ zur ex-Einheit des Root-Elements. Beispiel: height: 2rex;

Wem das auch viel vorkommt: Willkommen im Club. Ganz besonders sei man in CSS (auch relativ und absolut gemischt) rechnen kann, erscheinen die zahlreichen Einheiten etwas überdimensioniert

Sinnloses Beispiel mit verschachtelten calc() Anweisungen:

calc((100% / 7ex) - (4q * 30ric)

1996 fing CSS (CSS Level1) mit 6 Einheiten an und wuchs nach und nach auf diese Monströsen 42. In einem ganz bestimmten Bereich ergeben die meisten auch Sinn. Die Meisten. Nicht alle.

WordPress erlaubt in der Standardkonfiguration leider bis heute noch keine Verwendung von SVG-Bildern in der Mediathek. Versucht man eine SVG-Datei hochzuladen erscheint der Fehler „<Name>konnte nicht hochgeladen werden. Du bist leider nicht berechtigt, diesen Dateityp hochzuladen.“

Das hat natürlich auch einen Grund: SVGs sind ja XML-Dateien mit potenziell ausführbarem JS-Inhalt. Die „falsche“ SVG Datei könnte, genau wie eine „falsche“ JS oder HTM* Datei möglicherweise Schaden anrichten.

Unverständlicherweise gibt es bis heute aber noch keine „offizielle“ Möglichkeit, SVGs in seinem eigenen privaten Blog zu erlauben.

Lösung

In der functions.php des aktuell verwendeten Themes kann man den Filter einfach umgehen.

<?php
/* SVG erlauben - the old way */
function kb_svg ( $svg_mime ){
	$svg_mime['svg'] = 'image/svg+xml';
	return $svg_mime;
}
add_filter( 'upload_mimes', 'kb_svg' );

/* SVG erlauben - the new way (WP 4.7+) */
function kb_ignore_upload_ext($checked, $file, $filename, $mimes){
if(!$checked['type']){
	$wp_filetype = wp_check_filetype( $filename, $mimes );
	$ext = $wp_filetype['ext'];
	$type = $wp_filetype['type'];
	$proper_filename = $filename;

	if($type && 0 === strpos($type, 'image/') && $ext !== 'svg'){
		$ext = $type = false;
	}

	$checked = compact('ext','type','proper_filename');
}

return $checked;
}
add_filter('wp_check_filetype_and_ext', 'kb_ignore_upload_ext', 10, 4);
?>

Natürlich sollte das nicht so sein, ein Theme sollte nicht die Sicherheitsfunktion des WordPress-Systems verbiegen müssen. Leider ist das bisher der schnellste Weg für Admins um SVG-Grafiken zu erlauben.