nicht angemeldet
Matthias Scharwies
Robert B.
Matthias Scharwies
Rolf B
Matthias Scharwies
Matthias Scharwies
Rolf B
Rolf B
Sind das die Orte (also all die Stellen, welche SVGs mit Dimensionen versehen sollen, nicht nur width), welche den Wahn vom pixelgenauen Layout für alle Ewigkeit festschreiben sollen? Oder welchen Grund sollte es sonst geben, so ein „frei skalierbares“ Format daran zu hindern, sich z. B. an Größen von Schriften (pt, ex, em, lh usw.), Grid- und Flex-Items (fr und vielleicht sogar cq…), ja wenigstens am Viewport (vw, vh, vb, vi) — oder auch nur schnöden Maßen, welche wenigstens versuchen, eine konkrete Größe zu bestimmen, zu verweigern? — Weil das Umrechnen von solchen Angaben in ungefähr geschätzte Größen „ungenau“ sein soll?
Könnte da nicht jemand Hirn …? Nein? Na, dann muß SVG hier draußen im Regen stehen bleiben. Sogar dann, wenn es damit vielleicht sogar einfach möglich wäre, meinen 90°-Text zu realisieren. Aber wenn der schon nicht mal die Schriftgröße halten kann …
Wobei — umrechnen? Na, daß z. B. „1px + 50%“ zu einem geschätzt-genauen Maß wird, also in Pixeln gezählt werden kann, bedeutet ja in keiner Weise, daß „1px / 1px“ irgend etwas mit Relation, womöglich gar Prozenten drin, wäre. Fängt das Schätzen also schon an, bevor es in Pixeln seine Masern zeigt?
Oh, da war noch was: Maße, die nur für ein Print-Layout gut sein sollen — sind doch völlig nutzlos! Niemand weiß, aus welchem Abstand die Betrachter auf das Papier schielen. Ja womöglich benutzen die dabei dann auch noch Lupen, gar Mikroskope? Oder der Drucker hat auf ein Blatt gleich 8 A4-Seiten gedruckt – das kann doch zumindest jeder Laserdrucker für den Heimgebrauch, oder? …
Aloha,
Bitte lies ein paar Tutorials!
Bei SVG/Attribut/width geht es um dimensionslose Einheiten im SVG-Koordinatensystem!
Bei CSS kannst du Pixel und cm verwenden, wenn es um den Druck geht, sonst eben em oder Schlüsselwörter wie min-Content.
Tust du nur so unwissend? Es klingt oft wie Getrolle!
Sind das die Orte (also all die Stellen, welche SVGs mit Dimensionen versehen sollen, nicht nur
width), welche den Wahn vom pixelgenauen Layout für alle Ewigkeit festschreiben sollen? Oder welchen Grund sollte es sonst geben, so ein „frei skalierbares“ Format daran zu hindern, sich z. B. an Größen von Schriften (pt, ex, em, lh usw.), Grid- und Flex-Items (fr und vielleicht sogar cq…), ja wenigstens am Viewport (vw, vh, vb, vi) — oder auch nur schnöden Maßen, welche wenigstens versuchen, eine konkrete Größe zu bestimmen, zu verweigern? — Weil das Umrechnen von solchen Angaben in ungefähr geschätzte Größen „ungenau“ sein soll?Könnte da nicht jemand Hirn …? Nein? Na, dann muß SVG hier draußen im Regen stehen bleiben. Sogar dann, wenn es damit vielleicht sogar einfach möglich wäre, meinen 90°-Text zu realisieren. Aber wenn der schon nicht mal die Schriftgröße halten kann …
Wobei — umrechnen? Na, daß z. B. „1px + 50%“ zu einem geschätzt-genauen Maß wird, also in Pixeln gezählt werden kann, bedeutet ja in keiner Weise, daß „1px / 1px“ irgend etwas mit Relation, womöglich gar Prozenten drin, wäre. Fängt das Schätzen also schon an, bevor es in Pixeln seine Masern zeigt?
Oh, da war noch was: Maße, die nur für ein Print-Layout gut sein sollen — sind doch völlig nutzlos! Niemand weiß, aus welchem Abstand die Betrachter auf das Papier schielen. Ja womöglich benutzen die dabei dann auch noch Lupen, gar Mikroskope? Oder der Drucker hat auf ein Blatt gleich 8 A4-Seiten gedruckt – das kann doch zumindest jeder Laserdrucker für den Heimgebrauch, oder? …
Herzliche Grüße
Matthias Scharwies
Moin Matthias,
Tust du nur so unwissend? Es klingt oft wie Getrolle!
Ich finde meine Antwort an „nix“ gerade nicht mehr, aber ich halte sie/ihn für einen Troll und beschäftige mich daher nicht mehr mit den Posts. Es ist ein Wiki, da kann, darf und soll jede*r beitragen, die/der etwas konstruktiv beizutragen hat.
Viele Grüße
Robert
Hallo Matthias,
Bei SVG/Attribut/width geht es um dimensionslose Einheiten im SVG-Koordinatensystem!
Nur als Ergänzung: Auch das Attribut width kann Werte mit Einheiten wie cm, mm, pt, pc, in haben, eben um Druckausgaben zu realisieren.
Grüße,
Thomas
Hallo ThomasM,
ja, aber die Viewbox kennt nur einheitenlose Werte. Und alle Angaben innerhalb des SVG werden in Bezug auf die Viewbox dargestellt. Damit wird das ganze ad absurdum geführt.
Rolf
Hallo Rolf,
ja, aber die Viewbox kennt nur einheitenlose Werte. Und alle Angaben innerhalb des SVG werden in Bezug auf die Viewbox dargestellt. Damit wird das ganze ad absurdum geführt.
Nein, für ein A4-Druckformat lässt sich formulieren:
<svg width="21cm" height="29.7cm" viewBox="0 0 21 29.7">…</svg>
Einfach auch mal daran denken, dass man SVG auch in PDF hinein rendern kann – etwa via DocBook – und dann sind Druckeinheiten durchaus sinnvoll.
Grüße,
Thomas
Hallo ThomasM,
das ist das HTML Attribut width, wenn auch auf dem SVG Element.
Der Artikel, auf den sich nix bezieht, ist das SVG Attribut width, welches innerhalb eines SVG ist. Darauf hatte ich mich bezogen, und dort ist eine Angabe in em oder cm wenig sinnvoll, weil die Viewbox immer einheitenlos ist (d.h. für die Umrechnung von em oder cm wie px aufgefasst wird).
Rolf
Hallo Rolf,
das ist das HTML Attribut width, wenn auch auf dem SVG Element.
Der Artikel, auf den sich nix bezieht, ist das SVG Attribut width, welches innerhalb eines SVG ist. Darauf hatte ich mich bezogen, und dort ist eine Angabe in em oder cm wenig sinnvoll, weil die Viewbox immer einheitenlos ist (d.h. für die Umrechnung von em oder cm wie px aufgefasst wird).
Ich bezog mich auf das width-Attribut innerhalb von SVG unabhängig von HTML, also etwa auch für ein rect-Element, wenn dieses Rechteck in einem Druckprozess zum Einsatz kommt. SVG suggerierte auch der Wikilink.
Wollte ja nur sagen, dass width eben durchaus Einheiten haben kann.
Grüße,
Thomas
Hallo Thomas,
ja, das verstehe ich schon. Mir geht es aber um den Nutzen und die Komplexität im Gebrauch.
Was bringt mir width mit einer cm Angabe innerhalb von SVG, wenn ich in Folge außer der SVG-Größe noch drei magische Zahlen brauche, damit das Ergebnis passt? Von denen eine nicht mal sichtbar ist, nämlich der Umrechnungsfaktor
$$\displaystyle \frac{96 \frac{px}{in}}{2{,}54 \frac{cm}{in}} \approx 37{,}7952 \frac{px}{cm}$$.
Damit kann ich die SVG Größe in px umrechnen und in der Viewbox angeben. Dann stehen da zwei Zahlen, die einer Dokumentation bedürfen, damit ich später noch weiß, dass sie aus der width/height des SVG umgerechnet wurden. Aber das muss ich tun, um im SVG "5cm" hinschreiben zu können und nachher auch 5cm zu erhalten.
<svg viewBox="0 0 680.31596 377.95276" width="18cm" height="10cm">
<rect x="8cm" y="2cm" width="5cm" height="4cm" fill="pink" />
</svg>
Ja klar, die Viewbox könnte ich auch mit Script ausrechnen. Aber warum die Mühe machen? Da lasse ich doch lieber die Einheiten und Umrechnungen ganz weg. Dann ist die Magie komplett verschwunden und ich muss mein kleines Gehirn nicht mehr anstrengen.
<svg viewBox="0 0 18 10" width="18cm" height="10cm">
<rect x="8" y="2" width="5" height="4" fill="pink" />
</svg>
Dadurch, dass ich die Viewbox auf den gleichen Zahlenwert wie die SVG Abmessungen gesetzt habe, kann ich innerhalb des SVG einfach mit Zahlen arbeiten, die automatisch wie cm verwendet werden. Und schon muss ich fast gar nicht mehr nachdenken.
Dadurch, dass ich in der viewBox nur Zahlen angeben kann, führen innerhalb des SVG alle Maßeinheiten außer px zu unnötiger Umrechnerei. WENN die viewBox ebenfalls Maßeinheiten zuließe, wäre das etwas ganz anderes. Dann wäre ich sofort dabei.
Wie gesagt: das ist nur im SVG. Bei CSS Boxen außerhalb von SVG sieht das anders aus.
Rolf
Hallo Rolf,
Was bringt mir width mit einer cm Angabe innerhalb von SVG, wenn ich in Folge außer der SVG-Größe noch drei magische Zahlen brauche, damit das Ergebnis passt? Von denen eine nicht mal sichtbar ist, nämlich der Umrechnungsfaktor
Ich habe doch deutlich einen möglichen Print-Anwendungsfall für Zentimeterangaben genannt, wobei eben die Ausmaße des Mediums bekannt sind.
Wenn ich diese beiden Rechtecke via DocBook in ein PDF wandle, dann sind Breiten und Höhen auch identisch (x="3cm" / y="8cm" beim zweiten Rechteck):
<rect x="3cm" y="2cm" width="10cm" height="5cm" fill="red"/>
<rect x="113.39px" y="302.36px" width="377.95px" height="189.98px" fill="blue"/>
Zentimeter in Webinhalte zu bringen, war gar nicht mein Ansinnen.
Grüße,
Thomas
Hallo ThomasM,
Ich habe doch deutlich einen möglichen Print-Anwendungsfall für Zentimeterangaben genannt,
Hast Du. Und ich meine vorgerechnet zu haben, welche Bocksprünge nötig sind, damit das klappt.
Du hast dagegen eine andere Viewbox genannt:
<svg width="21cm" height="29.7cm" viewBox="0 0 21 29.7">…</svg>
Das kann aus meiner Sicht nicht mit den cm Angaben funktionieren, die Du im SVG vorschlägst. Weil viewBox-Koordinaten einheitenlos sind und im Vergleich zu cm wie px gerechnet werden.
Ich kenne DocBook allerdings nicht. Meinst Du docbook.org? Ist das ein Tool? Die Webseite hat mich nicht eingeladen, auch nur irgendwas zu verstehen.
Zentimeter in Webinhalte zu bringen, war gar nicht mein Ansinnen.
Das wollte ich auch nicht unterstellen.
Rolf
Hallo Rolf,
Du hast dagegen eine andere Viewbox genannt:
<svg width="21cm" height="29.7cm" viewBox="0 0 21 29.7">…</svg>Das kann aus meiner Sicht nicht mit den cm Angaben funktionieren, die Du im SVG vorschlägst. Weil viewBox-Koordinaten einheitenlos sind und im Vergleich zu cm wie px gerechnet werden.
Den Vergleich von cm vs. px habe ich ohne viewBox gemacht und es funktioniert formal im PDF. DocBook ist hier nicht entscheidend, sondern das daraus generierte XSL-FO (SVG in fo:external-graphic).
Ansonsten klinke ich mich hier aus. Bezüglich SVG im Druck einfach mal Inkscape benutzen und die Dokumenteigenschaften wie oben genannt auf A4 setzen, cm oder mm einstellen inkl. viewBox, dann etwas in diesen Einheiten zeichnen und mal testweise ein PDF ausgeben. Passt.
Grüße,
Thomas
Mal von „hier“ abgesehen (da war irgendwo ein Wurm drin, der an den U-Bahn fressenden aus “Men in Black” erinnert): das grundsätzliche Festhalten an „Bildschirm ≠ Print“ halte ich für einen Fehler. Nicht nur, aber auch, weil der Weg, den die Darstellung dabei (wenigstens) unter (älteren?) Versionen von OS X den umgehend ad absurdum führt: eine „ordentliche“ (ältere?) Bildschirm-Darstellung unterscheidet sich da nur von einer Print-Darstellung, wenn das bei der Entwicklung unbedingt gewollt ist! Sicher, das kann, nein, ist, sicher oft gut begründet oder begründbar. Aber muß dann eben geradezu erzwungen werden. Warum? Weil (wenigstens „früher™ eimal“) jede grafische Ausgabe (egal, ob Bilder oder Schrift) auf einem virtuellen Canvas gerendert wird, welcher dann ans jeweilige Device gemapt wird. Und das paßt dann „nur“ das jeweilige Koordinatensystem dazu an. Wenn da also z. B. eine Linie mit 10 Zentimetern Länge drin steckt, dann ist es nur dieser Anpassungsschritt, der daraus – und „HTML sei dank“ – etwas wird, das so eine „magische Zahl“ (irgendwas mit 96dpi und tatsächlicher Bildschirmauflösung) in sich trägt. Eben IMHO völlig ohne tatsächlichen Grund! Höchstens mit einem, der an das Trotzverhalten von kleinen Kindern erinnert.
Und die oben verwendete Vergangenheitsformen entspringen dem (durchaus nicht unbegründeten) Verdacht, daß man in Cupertino Display-PDF mittlerweile durch ein Display-HTML ersetzt hat. Wobei ich da dann durchaus auch die Möglichkeit sehe, schon den Desktop ggf. mittels irgendwelcher Probleme anzugreifen, die „bisher™“ nur Web-Browser betroffen hätten.
Oh weh! Wenn ich jetzt nur wüßte, wie ich „da hin“ kam, ja gar, wie ich es vorzeigen könnte. Jedenfalls habe ich „alles (un-)mögliche“ unternommen, um ein SVG passend in ein ::before hineinzuzaubern. Und bin damit gescheitert: das SVG wollte einfach nie die passende Größe annehmen. Nicht mal annähernd. Dabei hätte es sich an etwas wie 1em oriientieren müssen.
Zum Ende war ich dann mit dem Versuch (große Hoffnungen hatte ich in den ja sowieso nicht gesetzt), etwas wie width: calc((1em+0px) / (1em) dazu zu verwenden, da was dimensionsloses draus zu machen. Dann war das Faß voll und ich habe, wieder einmal, gemeckert.
Und danach? Wirklich gleich danach? Genau diese eine Stelle auf 1em gesetzt — und plötzlich war das Ding tatsächlich genau so groß im Browser zu sehen. Wenn mir das jemand erklären könnte! (Und natürlich hätte ich da am liebsten gleich diesen „Beitrag“ wieder gelöscht …)
Ach ja: im ::before paßt es immer noch nicht. Aber … da mag ich jetzt auch nicht weiter drüber nachdenken.
Servus!
Lies ein Tutorial!
Oh weh! Wenn ich jetzt nur wüßte, wie ich „da hin“ kam, ja gar, wie ich es vorzeigen könnte. Jedenfalls habe ich „alles (un-)mögliche“ unternommen, um ein SVG passend in ein ::before hineinzuzaubern. Und bin damit gescheitert: das SVG wollte einfach nie die passende Größe annehmen. Nicht mal annähernd. Dabei hätte es sich an etwas wie 1em oriientieren müssen. Zum Ende war ich dann mit dem Versuch (große Hoffnungen hatte ich in den ja sowieso nicht gesetzt), etwas wie
width: calc((1em+0px) / (1em)dazu zu verwenden, da was dimensionsloses draus zu machen. Dann war das Faß voll und ich habe, wieder einmal, gemeckert. Und danach? Wirklich gleich danach? Genau diese eine Stelle auf 1em gesetzt — und plötzlich war das Ding tatsächlich genau so groß im Browser zu sehen. Wenn mir das jemand erklären könnte! (Und natürlich hätte ich da am liebsten gleich diesen „Beitrag“ wieder gelöscht …)
Deshalb evtl. mal ein Live-Beispiel entwickeln, dass nur das aktuelle Problem arstellt. Dann sieht man manchmal schon selbst, wo es hakt.
Lies ein Tutorial!
In SVG/Tutorials/Einstieg/SVG_in_responsiven_Webseiten wird erklärt, wie SVG_als_Leinwand mit einheitenlosem Koordinatensystem funktioniert und mit der viewBox nochmal fokussiert werden kann.
Wichtigstes Hilfsmittel für mich sind diese Zeilen:
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 750 250">
<title></title>
<rect width="100%" height="100%" style="fill:none;stroke:hotpink; stroke-width:1" />
So habe ich ein Rechteck, dass mir zeigt, wo meine viewBox „zu Ende“ ist. Wenn ich über den Rand zeichnen muss, verändere ich die viewBow oder verschiebe die bereits vorhandenen Grafikobjekte. (Die Icons der Cards im Wiki haben z. B überwiegend viewBox="0 0 200 200")
Dieses SVG kannst du beliebig skalieren - es ist responsiv.
@Rolf B Hier (https://css-tricks.com/interactive-data-visualization-animating-viewbox/) zeigt css-tricks, wie man mit media queries auf kleinen Viewports einzelne Objekte der Grafik zoomt, bzw andere ausblendet. Da bräuchte ich mal ein gutes Anwendungsbeispiel.
Das SVG passt man dann in ein Pseudoelement ein.
Ach ja: im
::beforepaßt es immer noch nicht. Aber … da mag ich jetzt auch nicht weiter drüber nachdenken.
Herzliche Grüße
Matthias Scharwies
Hallo Matthias Scharwies,
wie man mit media queries auf kleinen Viewports einzelne Objekte der Grafik zoomt
Soweit ich das erkenne: Nö. Er berechnet die bounding box und schiebt die in das viewBox Attribut.
Von Media Queries träumt er - das setzt nämlich voraus, dass viewBox zum presentation attribute würde. Und das ist es nicht.
Insofern versteh ich jetzt nicht ganz, was Du möchtest.
Rolf
Servus!
Hallo Matthias Scharwies,
wie man mit media queries auf kleinen Viewports einzelne Objekte der Grafik zoomt
Soweit ich das erkenne: Nö. Er berechnet die bounding box und schiebt die in das viewBox Attribut.
Du hast ein HTML-Dokument mit Inline-SVG. Das ist schön breit, weil Desktop (gedacht: viewBox="0 0 640 480").
Von Media Queries träumt er - das setzt nämlich voraus, dass viewBox zum presentation attribute würde. Und das ist es nicht.
Nein, ich würde jetzt den Browser den Viewport ermitteln lassen. Wenn unter 30em Breite nicht alles ins Winzige skalieren, sondern jetzt die Inhalte neu anordnen:
SVG nur noch gedacht: viewBox="0 0 480 640" - da es ja kein Präsentationsattribut ist. Man kann aber width und height, bzw. aspect-ration des SVG neu setzen.
Aber die Geometrie-Attribute der einzelnen Objekte kann man mit CSS in die Media Queries schreiben:
.legend {
x: 600;
Y: 100;
}
@media (width < 30em) {
.legend {
x: 100;
Y: 400;
}
}
Jetzt wäre das rect .legend nicht mehr rechts oben, sondern unten platziert und man würde das auf Handy-Bildschirmen besser sehen.
Insofern versteh ich jetzt nicht ganz, was Du möchtest.
Die Idee habe ich, siehe oben verlinktes css-tricks-Tutorial, mir fehlt nur ein gutes Anwendungsbeispiel, vorzugsweise eine Infografik.
Herzliche Grüße
Matthias Scharwies
Na, viel Spaß:
<svg version="1.1" xmlns="http://www.w3.org/2000/svg">
<title>Whatsapp</title>
<desc>WA-Logo</desc>
<g viewBox="0 0 48 48" fill="#67C15E">
<path d="
M 23.99 0
C 10.76 0 0 10.76 0 23.99 C 0 29.24 1.69 34.11 4.57 38.06
L 1.57 46.98
L 10.80 44.03
C 14.59 46.54 19.12 48 24.00 48 C 37.23 48 48 37.23 48 24.00
C 48 10.76 37.23 0.00 24.00 0.00
L 23.99 0.00
L 23.99 0
Z" />
<path fill="white" d="
M 17.29 12.19
C 16.82 11.07 16.47 11.03 15.76 11.00 C 15.52 10.99 15.26 10.97 14.96 10.97
C 14.04 10.97 13.08 11.24 12.51 11.83 C 11.80 12.55 10.05 14.23 10.05 17.67
C 10.05 21.12 12.56 24.45 12.90 24.91 C 13.25 25.38 17.80 32.55 24.85 35.47
C 30.36 37.75 32.00 37.54 33.26 37.27 C 35.09 36.88 37.39 35.52 37.97 33.89
C 38.54 32.25 38.54 30.85 38.38 30.56 C 38.21 30.26 37.74 30.09 37.04 29.74
C 36.33 29.38 32.90 27.69 32.25 27.47 C 31.62 27.23 31.01 27.31 30.53 27.99
C 29.86 28.93 29.19 29.89 28.66 30.47 C 28.23 30.92 27.54 30.98 26.96 30.74
C 26.19 30.42 24.02 29.65 21.34 27.27 C 19.26 25.42 17.85 23.12 17.44 22.43
C 17.03 21.72 17.40 21.31 17.72 20.93 C 18.08 20.50 18.42 20.19 18.77 19.78
C 19.12 19.37 19.32 19.16 19.54 18.68 C 19.78 18.21 19.62 17.73 19.45 17.38
C 19.28 17.03 17.87 13.58 17.29 12.19
Z" />
</g>
</svg>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<style>
li { list-style-type: none; }
li::before, p::before {
display: inline-block;
content: url("…s.o.…");
min-width: 1ex; width: 10px;
min-height: 1em; height: 10px;
border: 1px solid red;
text-indent: 5em;
}
p::before {
width: 5em;
height: 5em;
}
</style>
</head>
<body>
<figure role="group"><img src=""…s.o.…" alt="WA-Logo"><figcaption>
Das SVG-WA-Logo
</figcaption>
<!-- Das SVG läßt sich also zeichnen! -->
</figure>
<p>Test. Test. Test.</p>
<ul><li> L-Test. L-Test. L-Test.</li><ul>
</html>
(Ach ja: das Logo wurde aus Platzgründen für hier etwas verstümmelt.)
Ich sehe da (es kommt mir hier aufs ::before an!) immer nur gleich große Abbildungen. Die immer hübsch außerhalb ihrer Box stehen. Und: wie groß genau, dazu haben Firefox und Safari unterschiedliche Meinungen.
Servus!
Na, viel Spaß:
Nein, niemand (hoffentlich jedenfalls) wird Dein Beispiel kopieren, abspeichern und dann für dich suchen.
Warum online-Beispiele besser als das Posten von Code sind!
Das SVG passt man dann in ein Pseudoelement ein.
Ach ja: im
::beforepaßt es immer noch nicht. Aber … da mag ich jetzt auch nicht weiter drüber nachdenken.
(Ach ja: das Logo wurde aus Platzgründen für hier etwas verstümmelt.)
Ich sehe da (es kommt mir hier aufs
::beforean!) immer nur gleich große Abbildungen. Die immer hübsch außerhalb ihrer Box stehen. Und: wie groß genau, dazu haben Firefox und Safari unterschiedliche Meinungen.
Vergleich mal die Beispiele der Tutorials mit Deinem Versuch!
Herzliche Grüße
Matthias Scharwies
Ja wenn es denn ein Beispiel mit SVG im ::before oder wenigstens ::after zu finden gäbe …
Servus!
Ja wenn es denn ein Beispiel mit SVG im ::before oder wenigstens ::after zu finden gäbe …
hier:
oder hier:
Herzliche Grüße
Matthias Scharwies
Schön, dieses Code-Dingens. Mail-Adresse abgeben darf man und soll dann „“ eingeben. Ein reCaptcha wäre der Inhalt, steht wohl sinngemäß da. Und da das, was da einzugeben wäre, eben so viel Inhalt hat … wird wieder eine Mail-Adresse gelöscht. Daß Google meinen Kreditkarten keine Telefonnummer zuordnen kann hat vmtl. den gleichen Grund. Egal: ich habe nicht vom Inhalt eines Grid geschrieben. Sondern davon, daß welche (und/oder auch Flex) mehr oder weniger nebeneinander, nein, im Quelltext nacheinander auftauchen. Und die isolieren sich wie beschrieben gegeneinander.
Hallo nix,
Schön, dieses Code-Dingens. Mail-Adresse abgeben darf man und soll dann „“ eingeben.
Wovon redest Du? Frickl fragt keine Mailadressen ab. Oder hast Du auf den jemand@example.com Link geklickt? Dann startet das Programm, das auf deinem Computer für mailTo-Links hinterlegt ist. Sollte es jedenfalls…
Rolf
CodePen (da vorgeschlagen) will das aber schon. So richtig mit (nicht-)anmelden.
Hallo nix,
der entscheidende Punkt ist: man kann SVG zwar mit Hilfe von JavaScript responsiv machen (viewBox anpassen), aber eigentlich fehlen in SVG alle Werkzeuge für ein responsives Layout. Insofern ist die Verwendung von relativen Einheiten innerhalb von SVG nicht wirklich hilfreich. Meine ich.
Ich kann zwar per CSS sagen, dass ich einen Kreis mit Radius 5em haben will, oder ein Text-Element mit einer font-size von 2em erzeugen, aber das nützt mir nicht wirklich was, weil sich das SVG beliebig skalieren lässt und die viewBox keine relativen Maße kennt. SVG ist nicht HTML, auch wenn ein paar Hartgesottene der Meinung waren, ganze Webseiten als SVG-Dokumente implementieren zu müssen.
Mich interessieren an dem Artikel aber etwas anderes:
Maße, die nur für ein Print-Layout gut sein sollen — sind doch völlig nutzlos!
Nö. Screen- und Print-Layout sind Usecases mit sehr verschiedenen Zielsetzungen. Wenn ich ein Layout gestalte, womit ich ein DIN A4 Formular bedrucken will (mit 2cm Rand links und 1cm Rand rechts), dann muss ich im Stande sein, etwas zu drucken, das exakt 18cm breit ist. Das hast Du auf dem Bildschirm so nicht. Bildschirm-Viewports sind flexibel und im Zweifelsfall kann ich scrollen. Auf Papier ist das schwieriger. Ein responsives Bildschirmlayout sollte dann aber auch im Stande sein, sich beim Druck auf ein Papier anzupassen. In diesem Fall erwarte ich aber auch keine pixelgenaue Übertragung vom Bildschirm auf's Papier - es sei denn, ich bin ein Betonbürokrat, der Webdesign nicht verstanden hat. Ich erwarte nur, eine lesbare Ausgabe zu erhalten, bei der nicht die Hälfte über den Rand hinaus gedruckt wird (was leider bei schlecht gemachten Webseiten der Fall ist).
Rolf
Nö. Screen- und Print-Layout sind Usecases mit sehr verschiedenen Zielsetzungen.
Das sah man aber schon unter NeXTstep (und wo wurde doch gleich „das Web erfunden“) aber grundsätzlich anders!