Eine Sache, die mich schon lange überrascht (und betrübt) hat, ist, dass die clip-path Eigenschaft, so toll sie auch ist, nur wenige Werte akzeptiert. Die Funktionen circle() und ellipse() sind nett, aber das Ausblenden von Überläufen und das Runden mit border-radius helfen da im Allgemeinen schon. Vielleicht ist der nützlichste Wert polygon(), weil er es uns ermöglicht, eine Form aus geraden Linien an beliebigen Punkten zu zeichnen.
Update: Alle drei Browser-Engines unterstützen clip-path: path() jetzt. Hurra!
Hier ist eine Demo für jeden Wert
Der traurige Teil kommt, wenn man feststellt, dass clip-path path() nicht akzeptiert. Kommt schon, es hat *path* im Namen! Die Pfadsyntax, die von SVG stammt, ist die ultimative Syntax. Sie erlaubt es uns, buchstäblich jede Form zu zeichnen.
Noch verwirrender ist, dass es bereits eine Funktion path() gibt, die Eigenschaften wie offset-path verwenden.
Ich war einmal so fassungslos über all das, dass ich einen ganzen Konferenzvortrag daraus gemacht habe.
Der Vortrag geht auf die Eigenschaft shape-outside ein und wie sie path() nicht verwenden kann. Er geht auch darauf ein, dass wir die Eigenschaft d eines tatsächlichen <path> ändern *können*.
Ich mache aber niemandem wirklich Vorwürfe. Das sind seltsame Dinge und sie werden von verschiedenen Teams implementiert, was unweigerlich zu unterschiedlichen Ergebnissen führt. Schon die Tatsache, dass SVG einheitenlose Werte in der Syntax <path d=""> verwendet, ist ein wenig seltsam und eine Anomalie in der CSS-Welt. Wie das funktioniert, wie Werte mit Einheiten funktionieren, welche Kommasyntax erlaubt und verboten ist und was das DOM zurückgibt, wenn man danach fragt, ist genug, um einen Kopf zum Drehen zu bringen.
Aber egal! Da kommt Firefox mit einer Implementierung!
Weiß jemand, ob clip-path: path() in Chrome hinter einem Flag liegt oder so. Ich kann es nicht finden, aber sie unterstützen offset-path: path(), also dachte ich, sie würden beides unterstützen.
Danke @CSS und @ChromiumDev Freunde.https://#/YTmwcnilRB funktioniert hinter einem Flag in FF. Chrome?
— Estelle Weyl (@estellevw) 13. September 2018
Unterstützung
Hier ist das Flag in Firefox (layout.css.clip-path-path.enabled)
Update!
Auch in Firefox 71 heute veröffentlicht – Unterstützung für die Verwendung der SVG path()-Syntax mit Clip Path in CSS.
Ja – das ist jetzt eine Sache
clip-path: path(‘M0.5,1 C0.5,1,0,0.7,0,0.3 A0.25,0.25,1,1,1,0.5,0.3 A0.25,0.25,1,1,1,1,0.3 C1,0.7,0.5,1,0.5,1 Z’);
— Jen Simmons (@jensimmons) 3. Dezember 2019
Und hier ist eine Demo...
In nicht unterstützten Browsern sehen Sie ein Quadrat und in denjenigen, die clip-path: path(); unterstützen – was zum Zeitpunkt des Schreibens nur Firefox Nightly mit aktiviertem Flag ist – ein Herz.
Jetzt brauchen wir nur noch
clip-pathin der Lage sein, auf die URL eines<path>in SVG zu verweisen, wie z. B.url("#clip-path");shape-outsidein der Lage sein,path()zu verwendenshape-outsidein der Lage sein, auf einen<path>zu verweisenoffset-path, um all die anderen Formfunktionen zu verwenden- Wahrscheinlich eine Reihe von Spezifikationen, um sicherzustellen, dass dies alles sauber gehandhabt wird (Viel Glück, Team!)
- Browser, die all das implementieren
😉
(Ich habe das als Twitter-Kommentar begonnen, aber es wurde ein Thread, also dachte ich, es passt besser hierher! Und nachdem ich es hier geschrieben hatte, erkannte ich, dass ich es auch im Issue Tracker der Arbeitsgruppe veröffentlichen sollte, um Feedback zu sammeln. Also ist es dorthin kopiert, bitte fügen Sie Ihre Stimmen hinzu: https://github.com/w3c/csswg-drafts/issues/3468 )
## Re: „Haufen von Spezifikationen – Viel Glück, Team!“
Der knifflige Teil ist fill-rule. Die Funktion
polygon()enthält fill-rule-Schlüsselwörter als optionalen ersten ParameterAber ein
<path>-Element verwendet die Schlüsselwörter, die von den Eigenschaftenfill-ruleODERclip-rulegesetzt werden, abhängig vom Kontext der Form. Ein Schlüsselwort in der Eigenschaftdwürde also einen Konflikt erzeugen.Die Funktion
path(), wie sie derzeit füroffset-pathspezifiziert ist, enthält keinen Schlüsselwortparameter, da die Bewegung nur die Umrisslinie verwendet, nicht die Füllung.Wir haben uns darauf geeinigt, diese Syntax für
d(<path>-Form) als Eigenschaft zu verwenden.Aber für
clip-path(und zukünftige Dinge wieshape-insidezur Definition des Textumflussbereichs als Form) müssen wir wissen, welche Füllregel verwendet werden soll.Eine Idee, die ich mir überlegte (aber nie aufgeschrieben habe), ist, zwei verschiedene CSS-Datentypen zu definieren, von denen einer eine Oberklasse des anderen ist
<outline-shape>hat keine fill-rule-Schlüsselwörter<filled-shape>=<outline-shape>(mit Standard-fill-rule) |polygon()undpath()mit SchlüsselwörternSomit würde die Eigenschaft
deine<outline-shape>-Funktion akzeptieren, keine Schlüsselwörter erlauben und immer noch die Eigenschaftenfill-rule/clip-ruleohne Konflikt verwenden.Eine andere Option ist die Definition eines
auto-Wertes für das Schlüsselwort innerhalb der Funktionen, und diesen als Standard zu machen. Inclip-pathwürde einauto-Wert sich genauso verhalten wie der aktuelle Standard (nonzero). Aber indwürde er sich so verhalten, dass die Eigenschaftfill-ruleoderclip-ruleje nach Kontext geprüft und verwendet wird. Wenn Sie ein anderes Schlüsselwort in einer Funktion innerhalb vondangeben würden, würde dies die anderen Eigenschaften überschreiben.Ein Nebeneffekt, meiner Meinung nach, ist, dass wir langfristig die Verwendung der Eigenschaften
fill-rule/clip-ruleeinstellen könnten, die bereits auf nervige Weise vom Kontext abhängen. Wenn Sie kontextspezifische Schlüsselwortwerte in der CSS-Funktionsnotation wünschen, könnten Sie geerbte CSS-Variablenwerte verwenden.Aber der wichtigste Vorteil *eines* dieser Ansätze ist, dass sie es uns ermöglichen würden, alle Formfunktionen (möglicherweise abzüglich fill-rule-Schlüsselwörter) in allen formbezogenen Eigenschaften zu verwenden!!!
Wenn Sie Meinungen zu all dem haben, lassen Sie es uns (CSS/SVG-Editoren) und den Browser-Teams wissen! An diesem Punkt würde ich gerne eine Option wählen, damit wir die vollständige Suite von Formfunktionen in allen zugehörigen Eigenschaften erhalten.
https://github.com/w3c/csswg-drafts/issues/3468#issuecomment-449760438
Es gibt immer noch ein paar andere speicherbezogene Dinge, die aufgeräumt werden müssen, wie Animationsregeln und wie stark die Syntax von Pfadzeichenketten normalisiert wird, wenn Sie
getComputedStyle()aufrufen oder anderweitig vom DOM serialisieren. Aber es gibt dort nicht viel Uneinigkeit, es ist nur eine Frage des Ausarbeitens der Details.(Nun, und dann gibt es noch alle möglichen zukünftigen Erweiterungen, die ich gerne sehen würde, wie zum Beispiel das Verketten mehrerer Pfadzeichenketten, die in Variablen gespeichert sind, oder die Verwendung von Einheiten in Pfaden. Aber das ist für später...)
Nebenbei bemerkt, bin ich fasziniert von der Idee, ein SVG
<clipPath>-Element inshape-outsideverwenden zu können.In SVG 2 (Abschnitte, die derzeit auf SVG irgendwann verschoben werden) war der Plan, dass
shape-outsideundshape-insidedirekt auf ein einzelnes SVG-Formelement (wie ein<path>) verweisen könnten. Aber vielleicht macht das Verweisen auf ein<clipPath>mehr Sinn, denn ein ClipPath definiert bereits Regeln für die Skalierung, um es an ein referenzierendes Element anzupassen?Wenn Sie weitere Ideen zu diesem speziellen Vorschlag haben, Chris, würde ich mich freuen, sie im offiziellen Issue Tracker zu sehen.