2d context für Style Elemente
j4nk3y
- html
- javascript
- sonstiges
Guten morgen und Frohe Ostern zusammen,
Ich hab ein interessantes Pen gefunden und hab dazu zwei Fragen. Zum einen interessieren mich die "komplexen" style Elemente in der Linken Navigation die mit canvas.getContext('2D')
gezeichnet werden (also nicht die Linien sondern die Flächen an der rechten Seite).
Nun sagt die W3C: "This specification is no longer in active maintenance and the HTML Working Group does not intend to maintain it further." Hm blöd, würde ich nämlich gerne so oder ähnlich umsetzen, da solche Elemente in plain HTML/CSS eine Div-Suppe mit etlichen Pseudoelementen erzeugen würde. Gibt es also etwas anderes was besser geeignet wäre?
Dies führt gleich zur nächsten Frage.
<ul class="marks"><li></li>...</ul>
ist ja auch nicht gerade die feine Art, oder?
Geht es anders besser? (Nur weil es mich interessiert, nicht das ich vor hätte so etwas zu kreieren).
Gruß
Jo
@@j4nk3y
Ich hab ein interessantes Pen gefunden und hab dazu zwei Fragen. Zum einen interessieren mich die "komplexen" style Elemente in der Linken Navigation die mit
canvas.getContext('2D')
gezeichnet werden (also nicht die Linien sondern die Flächen an der rechten Seite).
Ich finde dort mit der Tab-Taste keine Navigation.
Den Pen würde ich nicht als „interessant“ bezeichnen, sondern als schlechtes Beispiel.
Dies führt gleich zur nächsten Frage.
<ul class="marks"><li></li>...</ul>
ist ja auch nicht gerade die feine Art, oder?
<nav><ul><li><a href="…">…</a></li>…</ul></nav>
ist die feine Art.
Geht es anders besser?
Es mag anders gehen, aber nicht besser.
LLAP 🖖
@@j4nk3y
Ich hab ein interessantes Pen gefunden und hab dazu zwei Fragen. Zum einen interessieren mich die "komplexen" style Elemente in der Linken Navigation die mit
canvas.getContext('2D')
gezeichnet werden (also nicht die Linien sondern die Flächen an der rechten Seite).Ich finde dort mit der Tab-Taste keine Navigation.
Das stimmt, die Tatsache habe ich bewusst außer Acht gelassen, da ich nicht auf die offensichtlichen Fehler eingehen möchte. Genauso wie die Div-Suppe die dort fabriziert wurde.
Den Pen würde ich nicht als „interessant“ bezeichnen, sondern als schlechtes Beispiel.
Interessant für mich da ich da ein beispiel sehe, wie ich etwas umsetzen oder realisieren kann. und die Frage ist ob dieses Beispiel für diese eine Sache gut ist und nicht ob der Pen ansich schlecht ist.
Dies führt gleich zur nächsten Frage.
<ul class="marks"><li></li>...</ul>
ist ja auch nicht gerade die feine Art, oder?
<nav><ul><li><a href="…">…</a></li>…</ul></nav>
ist die feine Art.Geht es anders besser?
Es mag anders gehen, aber nicht besser.
Das Element ist keine Navigation sondern nur ein Element was gut aussehen soll. Man muss auch nicht aus allem eine <nav>
machen nur weil meist ein <ul>
da rein gehört. Und es ging mir darum ob das:
<ul class="marks">
<li></li><li></li><li></li><li></li><li></li><li></li>
<li></li><li></li><li></li><li></li><li></li><li></li>
<li></li><li></li><li></li><li></li><li></li><li></li>
<li></li><li></li><li></li><li></li><li></li><li></li>
<li></li><li></li><li></li><li></li><li></li><li></li>
<li></li><li></li><li></li><li></li><li></li><li></li>
<li></li><li></li><li></li><li></li><li></li><li></li>
<li></li><li></li><li></li><li></li><li></li><li></li>
<li></li><li></li><li></li><li></li><li></li><li></li>
<li></li><li></li><li></li><li></li><li></li><li></li>
</ul>
besser geht? Das ist übrigens der äußere Ring um den "Arc", falls das nicht auf den ersten Blick ersichtlich wird.
Gruß
Jo
@@j4nk3y
Und es ging mir darum ob das:
<ul class="marks"> <li></li><li></li><li></li><li></li><li></li><li></li> <li></li><li></li><li></li><li></li><li></li><li></li> <li></li><li></li><li></li><li></li><li></li><li></li> <li></li><li></li><li></li><li></li><li></li><li></li> <li></li><li></li><li></li><li></li><li></li><li></li> <li></li><li></li><li></li><li></li><li></li><li></li> <li></li><li></li><li></li><li></li><li></li><li></li> <li></li><li></li><li></li><li></li><li></li><li></li> <li></li><li></li><li></li><li></li><li></li><li></li> <li></li><li></li><li></li><li></li><li></li><li></li> </ul>
besser geht? Das ist übrigens der äußere Ring um den "Arc", falls das nicht auf den ersten Blick ersichtlich wird.
Ah, da in die Untiefen hatte ich mich nicht begeben.
Das ist natürlich völliger Unsinn. Die Ringe sind mit wenigen Zeilen SVG gemacht und mit wenigen Zeilen CSS animiert.
JavaScript und canvas sind hier völlig fehl am Platz.
Sieht nach JavaScript-Kiddie aus, dem die Grundlagen der Webentwicklung fehlen.
LLAP 🖖
Hey,
Das ist natürlich völliger Unsinn. Die Ringe sind mit wenigen Zeilen SVG gemacht und mit wenigen Zeilen CSS animiert.
JavaScript und canvas sind hier völlig fehl am Platz.
Da ist auch kein Javascript involviert. Egal lenken wir das Thema auf die eigentliche für mich wichtige Frage.
<canvas id="particle1_2" width="40" height="510"></canvas>
<script>
var canvas = document.getElementById('particle1_2');
var context = canvas.getContext('2d');
context.beginPath();
context.lineTo(10, 80);
context.lineTo(0, 65);
context.lineTo(0, 15);
context.lineTo(10, 0);
context.lineTo(10, 80);
context.closePath();
context.lineWidth = 1;
context.fillStyle = 'rgba(2,254,255,0.3)';
context.fill();
context.strokeStyle = 'transparent';
context.stroke();
</script>
Dies finde ich sehr interessant, vorallem weil ich keine Ahnung habe wie ich .svg's schreibe und mich besser hiermit auskenne. Aber die W3C eben sagt: "This specification is no longer in active maintenance and the HTML Working Group does not intend to maintain it further".
Gruß
Jo
@@j4nk3y
JavaScript und canvas sind hier völlig fehl am Platz.
Da ist auch kein Javascript involviert. Egal lenken wir das Thema auf die eigentliche für mich wichtige Frage.
<canvas id="particle1_2" width="40" height="510"></canvas> <script> var canvas = document.getElementById('particle1_2');
Also zu JavaScript‽
LLAP 🖖
Hey,
JavaScript und canvas sind hier völlig fehl am Platz.
Da ist auch kein Javascript involviert. Egal lenken wir das Thema auf die eigentliche für mich wichtige Frage.
<canvas id="particle1_2" width="40" height="510"></canvas> <script> var canvas = document.getElementById('particle1_2');
Also zu JavaScript‽
Jep.
Gruß
Jo
Servus!
Ich hab auch mit canvas angefangen und bin erst später auf SVG umgestiegen.
Glaub mir es ist genial.
Nutz die Feiertage und lies dich in SVG ein:
zum Orientieren die Blog-Serie: SVG - ein Format für alle Fälle
praktischer Einstieg: SVG/Anwendung_und_Praxis/Flaggen_mit_SVG_zeichnen
Wie Gunnar schon sagt, benötigst Du für die linke Uhr nur 2 Kreise und 2 Text-Elemente:
<circle cx="100" rx="100" r="70" />
<circle cx="100" rx="100" r="50" />
<text x="100" y="50" font-size="24">04</text>
<text x="100" y="70" font-size="16" >January</text>
(Warum hat das Bsp keine Live-Uhr?)
Die Randlinien kannst du mit stroke-dasharray als durchgezogene (Standard) oder gestrichelte Linie festlegen. Das kannst du dann mit CSS-Animation oder JavaScript animieren.
hier ein Beispiel für Text.
SVG kann wie HTML ids und Klassen haben, mit denen Du CSS und JS anhängen kannst. Das ist keine große Umstellung.
Herzliche Grüße
Matthias Scharwies
Hey,
Ich hab auch mit canvas angefangen und bin erst später auf SVG umgestiegen.
Glaub mir es ist genial.
So nach kurzem experimentieren hab ich eine Frage. Welche Einheit hat das Koordinatensystem? Und die gleiche frage stellt sich eigentlich auch bei der Canvas Methode.
Genauer moveTo(x,y)
oder lineTo(x,y)
? Pixel ist es nicht und Prozent auch nicht. Bin etwas ratlos.
Frohe Ostern Jo
P.s: Neue Problematische Seite
Servus!
So nach kurzem experimentieren hab ich eine Frage. Welche Einheit hat das Koordinatensystem?
Das hatten wir vor ein paar Wochen schon im Forum. Ich hab's für mich so verstanden, dass es Pixel sind die dann entsprechend skaliert werden. @Gunnar Bittersmann hat gemeint, dass es einheitenlose Längeneinheiten des Koordinatensystems sind.
Da man z.B für stroke-with als Attribut keine Einheit setzt, als CSS aber dann doch eine Einheit zum Wert hinzufügen muss (meist dann doch px) bleib ich bei Pixel für mich.
Und die gleiche frage stellt sich eigentlich auch bei der Canvas Methode.
Genauer
moveTo(x,y)
oderlineTo(x,y)
? Pixel ist es nicht und Prozent auch nicht. Bin etwas ratlos.
Dito.
Herzliche Grüße
Matthias Scharwies
Hey,
Das hatten wir vor ein paar Wochen schon im Forum. Ich hab's für mich so verstanden, dass es Pixel sind die dann entsprechend skaliert werden. @Gunnar Bittersmann hat gemeint, dass es einheitenlose Längeneinheiten des Koordinatensystems sind.
Hm.
Da man z.B für stroke-with als Attribut keine Einheit setzt, als CSS aber dann doch eine Einheit zum Wert hinzufügen muss (meist dann doch px) bleib ich bei Pixel für mich.
Und die gleiche frage stellt sich eigentlich auch bei der Canvas Methode.
Genauer
moveTo(x,y)
oderlineTo(x,y)
? Pixel ist es nicht und Prozent auch nicht. Bin etwas ratlos.
Naja, wenn man sich die Beispiele anschaut mit z.B. <path d="M50,50 H100" stroke="#5a9900" />
und der Container bei mir nur etwa 40 Px breit ist, ist es eben schon komisch. Klar es ist eine Vektorgrafik und durch width
und height
wird das ganze skaliert aber ein Ansatz punkt wäre gut, da ich es grad nicht schaffe ... Hm da fällt mir...
Stunden später…
Also, ich bin mittlerweile soweit, dass ich herausgefunden habe, dass,:
var canvas = document.getElementById('style_element_right');
var context = canvas.getContext('2d');
context.beginPath();
context.moveTo(0, 0); // obere linke Ecke
context.lineTo(0, 150); // untere linke Ecke
context.lineTo(300, 150); // untere rechte Ecke
context.lineTo(300, 0); // obere rechte Ecke
context.closePath();
context.lineWidth = 1;
context.fillStyle = color;
context.fill();
context.strokeStyle = 'transparent';
context.stroke();
diese Koordinaten immer (jedenfalls bei mir nach einigen Versuchen), egal wie width
und height
definiert sind, die Eckpunkte eines Containers sind.
Gruß
Jo
@@Matthias Scharwies
So nach kurzem experimentieren hab ich eine Frage. Welche Einheit hat das Koordinatensystem?
Keine.
Das hatten wir vor ein paar Wochen schon im Forum. Ich hab's für mich so verstanden, dass es Pixel sind die dann entsprechend skaliert werden.
„Pixel“ und „skalierbare Vektorgrafik“ sind zwei völlig verschiedene Welten.
@Gunnar Bittersmann hat gemeint, dass es einheitenlose Längeneinheiten des Koordinatensystems sind.
Dem ist so.
Da man z.B für stroke-with als Attribut keine Einheit setzt, als CSS aber dann doch eine Einheit zum Wert hinzufügen muss
Dem ist nicht so.
<svg xmlns="http://www.w3.org/2000/svg" viewBox="-1.1 -1.1 2.2 2.2">
<style>circle { stroke: rebeccapurple; stroke-width: 0.1; fill: transparent }</style>
<circle r="1"/>
</svg>
liefert exakt dasselbe Ergebnis wie
<svg xmlns="http://www.w3.org/2000/svg" viewBox="-1100 -1100 2200 2200">
<style>circle { stroke: rebeccapurple; stroke-width: 100; fill: transparent }</style>
<circle r="1000"/>
</svg>
Es gibt ein inneres Koordinatensystem, auf das sich alle einheitslosen Angaben (hier r
, stroke-width
und viewBox
) beziehen.
viewBox
legt fest, welcher Ausschnitt der xy-Ebene zu sehen ist.
Wenn man also alles wie bspw. oben mit 1000 multipliziert, ergibt sich dasselbe Bild.
Das gilt prinzipiell immer – von Browserbugs abgesehen.
LLAP 🖖
Nachtrag: Pixel kommen dann ins Spiel, wenn überhaupt keine Angabe gemacht wurde, wie groß der Browser ein SVG darstellen soll. Dann interpretiert er die viewBox-Ausmaße als Pixel.
Servus Matthias,
Ich hab auch mit canvas angefangen und bin erst später auf SVG umgestiegen.
Glaub mir es ist genial.
Nach einigem Experimentieren: Das stimmt. Vorallem, was ich nicht ganz nachvollziehen kann, sind schräge Linen wesentlich schärfer, woran auch immer das liegen mag.
Aber eine Frage habe ich. Habe heute morgen dann auch herausgefunden, dass das Koordinatensytem die Einheit Pixel hat, was das zeichnen von Linien und Flächen extrem vereinfacht wenn x und y die selbe Einheit haben.
Nun habe ich gerade einen kleinen test gestartet, etwa so.
<svg id="style_top" width="100%" height="6em" viewBox="0 0 1218 77">
<title>Test</title>
<polyline points="250,0 250,20 968,20 968,0 250,0" stroke-width="1" stroke="rgba(250,180,150,0.75)" fill="rgba(250,180,150,0.45)" />
</svg>
#style_top
{
position: absolute;
height: 6em;
width: 100%;
margin: 0em;
padding: 0em;
z-index: 5;
}
Wenn die Grafik nur als Dekoration dient und das <title>
-Element von einem Screenreader gelesen werden kann, kann man das dann auch weglassen? Ich meine es muss ja nicht sein, dass einige male gesagt wird Style-Element, Style-Element,... oder was auch immer ich da einsetzen möchte.
Bis zu einer gewissen Breite wird das Quadrat (wird später umfangreicher daher kein rect
) am oberen Rand dargestellt. Logisch wegen den x Koordinaten 250,0 und 968,0. Aber wenn das Fenster verkleinert wird rutscht die Null Koordinate nach unten obwohl der Container seine Größe nicht ändert.
Kann man das beheben?
Gruß
Jo
@@j4nk3y
Vorallem, was ich nicht ganz nachvollziehen kann, sind schräge Linen [bei SVG] wesentlich schärfer, woran auch immer das liegen mag.
Vermutlich daran, dass beim Rendern von SVG Anti-Aliasing gemacht wird. Wenn du Pixel auf den Canvas malst, müsstest du Anti-Aliasing selbst berechnen.
Habe heute morgen dann auch herausgefunden, dass das Koordinatensytem die Einheit Pixel hat
Nein, das hat es nicht. Es gibt in SVG keine Pixel.
- Wenn die Grafik nur als Dekoration dient und das
<title>
-Element von einem Screenreader gelesen werden kann, kann man das dann auch weglassen?
Ja, weglassen. Und role="none presentation"
fürs svg
-Element setzen.
LLAP 🖖
@@Gunnar
Vorallem, was ich nicht ganz nachvollziehen kann, sind schräge Linen [bei SVG] wesentlich schärfer, woran auch immer das liegen mag.
Vermutlich daran, dass beim Rendern von SVG Anti-Aliasing gemacht wird. Wenn du Pixel auf den Canvas malst, müsstest du Anti-Aliasing selbst berechnen.
Das klingt logisch.
Habe heute morgen dann auch herausgefunden, dass das Koordinatensytem die Einheit Pixel hat
Nein, das hat es nicht. Es gibt in SVG keine Pixel.
Ok Falsch formuliert:
"Sie haben nun zwei Koordinatensysteme in der SVG-Grafik: das "eigentliche" Koordinatensystem des svg-Elements mit den Attributen width und height das "neue" Koordinatensystem, bestimmt durch das mit dem viewBox-Attribut definierte Rechteck."
Aus dem Wiki.
Das 'neue' Koordinatensystem hat in Bezug zur Viewbox für den Abstand x zu x + 1 die Länge von einem Pixel, sobald die Größe des <svg>
-Elementes nicht der definierten Viewbox Größe enstpricht, ist der Abstand x zu x + 1 kleiner oder größer im Verhältnis <svg>
-Größe / definierte Viewbox.
- Wenn die Grafik nur als Dekoration dient und das
<title>
-Element von einem Screenreader gelesen werden kann, kann man das dann auch weglassen?Ja, weglassen. Und
role="none presentation"
fürssvg
-Element setzen.
Danke.
Gruß
Jo
Hallo,
Vorallem, was ich nicht ganz nachvollziehen kann, sind schräge Linen [bei SVG] wesentlich schärfer, woran auch immer das liegen mag.
Vermutlich daran, dass beim Rendern von SVG Anti-Aliasing gemacht wird. Wenn du Pixel auf den Canvas malst, müsstest du Anti-Aliasing selbst berechnen.
kann man hier noch mal vergleichen:
Gruß
Jürgen
Hallo Jürgen,
Vorallem, was ich nicht ganz nachvollziehen kann, sind schräge Linen [bei SVG] wesentlich schärfer, woran auch immer das liegen mag.
Vermutlich daran, dass beim Rendern von SVG Anti-Aliasing gemacht wird. Wenn du Pixel auf den Canvas malst, müsstest du Anti-Aliasing selbst berechnen.
kann man hier noch mal vergleichen:
Schönes Beispiel, Danke.
Gruß
Jo
Hallo,
es gibt zu beiden Beispielen auch einen Wiki-Artikel:
SVG/Anwendung und Praxis/Funktionsplotter
JavaScript/Anwendung und Praxis/Funktionsplotter
Gruß
Jürgen
So.
<svg id="style_top" width="100%" height="6em" viewBox="0 0 1218 77"> <title>Test</title> <polyline points="250,0 250,20 968,20 968,0 250,0" stroke-width="1" stroke="rgba(250,180,150,0.75)" fill="rgba(250,180,150,0.45)" /> </svg>
#style_top { position: absolute; height: 6em; width: 100%; margin: 0em; padding: 0em; z-index: 5; }
- Bis zu einer gewissen Breite wird das Quadrat (wird später umfangreicher daher kein
rect
) am oberen Rand dargestellt. Logisch wegen den x Koordinaten 250,0 und 968,0. Aber wenn das Fenster verkleinert wird rutscht die Null Koordinate nach unten obwohl der Container seine Größe nicht ändert. Kann man das beheben?
Erst dachte ich das ich vielleicht mit #style_top > polyline {position: absolute; top: 0em;}
etwas erreichen könnte, dem war leider nicht so, nach kurzer recherche dann: preserveAspectRatio="xMinYMin"
gefunden. In dem Wiki steht dann noch etwas von "meetOrSlice", was bedeutet das?
Gruß
Jo
@@j4nk3y
nach kurzer recherche dann:
preserveAspectRatio="xMinYMin"
gefunden. In dem Wiki steht dann noch etwas von "meetOrSlice", was bedeutet das?
Schlag nach bei Sara Soueidan: Understanding SVG Coordinate Systems and Transformations (Part 1) — The viewport
, viewBox
, and preserveAspectRatio
“The last argument, meetOrSlice
is also optional, and it defaults to meet
. This argument specifies whether or not the entire viewBox
should be visible inside the viewport. If provided, it is separated from the align
parameter by one or more spaces. For example: preserveAspectRatio = "xMinYMin slice"
“These values may seem foreign at first. To make understanding them easier and make them more familiar, you can think of the meetOrSlice
value as being similar to the background-size
values contain
and cover
; they work pretty much the same. meet
is similar to contain
, and slice
is similar to cover
.”
LLAP 🖖
PS: Ja ich weiß, die Rahmen um Inline-Code sind furchtbar und sollten ASAP weg.
🖖 Gunnar Bittersmann,
Ja ich weiß, die Rahmen um Inline-Code sind furchtbar und sollten ASAP weg.
Magst du mal einen oder mehrere Vorschläge bei github unterbringen?
Bis demnächst
Matthias
Servus!
So, kleiner ich-fall-vom-hocker-Moment. Bin gerade nachhause gekommen und hab den Rechner gewechselt, Somit eine Neue Auflösung. Folgendes Beispiel:
<svg id="style_top" role="none presentation" viewBox="0 0 1218 77" preserveAspectRatio="xMinYMin">
<polyline points="250,0 250,15 265,30 459,30 484,55 559,55 574,70 644,70 659,55 734,55 759,30 953,30 968,15 968,0 734,0 704,30 514,30 484,0 250,0" stroke-width="1" stroke-linecap="round" stroke="rgba(250,180,0,0.75)" fill="rgba(250,180,0,0.45)" />
<polyline points="489,60 554,60 569,75 489,60" stroke-width="1" stroke-linecap="round" stroke="rgba(250,180,0,0.75)" fill="rgba(250,180,0,0.45)" />
<polyline points="649,75 664,60 729,60 649,75" stroke-width="1" stroke-linecap="round" stroke="rgba(250,180,0,0.75)" fill="rgba(250,180,0,0.45)" />
</svg>
Nun dachte ich, dass durch die Angegebene viewBox
also dem Koordinatensystem für die Grafik, sich die Grafik automatisch einer sich ändernden Größe des <svg>
anpasst. So sollte es doch sein?
Nun bei mir ist nichts mehr da wo es geplant ist, alles kleiner, nicht mehr mittig, nichtmal das die Grafik und damit anscheinend auch das Koordinatensystem über die gesamte breite von width: 100%;
geht. Irgendwie sehe ich gerade nicht was ich Falsch gemacht bzw verstanden hab.
Edit: Aha. Klasse, wenn man dann auch height: auto;
bzw width: auto;
verwendet würde es passen.
Gruß
Jo
@@Gunnar Bittersmann
Die Ringe sind mit wenigen Zeilen SVG gemacht und mit wenigen Zeilen CSS animiert.
Das könnte in etwa so aussehen.
LLAP 🖖
Hallo j4nk3y,
<ul class="marks"><li></li>...</ul>
ist ja auch nicht gerade die feine Art, oder? Geht es anders besser? (Nur weil es mich interessiert, nicht das ich vor hätte so etwas zu kreieren).
Unzählige HTML-Elemente zur Darstellung zu missbrauchen, ist in Zeiten von SVG nicht notwendig. Aber wems Spaß macht: https://pattle.github.io/simpsons-in-css/
Bis demnächst
Matthias
Nun sagt die W3C: "This specification is no longer in active maintenance and the HTML Working Group does not intend to maintain it further."
Da hast du eine veraltete Spezifikation gefunden. Das war das geplante "Level 2" des Canvas 2D-Context. Eine Weiterentwicklung, die lediglich auf Seiten des W3C eingestellt wurde.
Die ursprüngliche Spezifikation existiert immer noch und ist eine W3C Recommendation, damit ein Webstandard. Und bei der WHATWG wird der 2D-Context auch weiter entwickelt.
Canvas und der 2D-Context sind weiterhin aktuell, sind breit unterstützt und werden bleiben.
Siggi