CSS Code für einen Codeblock kopieren

[ebody]

Hallo,

Ist es möglich mit den Chrome Dev Tools oder anderen Tools den kompletten CSS Code von einem Codeblock zu kopieren? So dass ich den vollständigen CSS Code von dem im Bild markiertem Layout kopieren kann?

Man kann zwar ein Element selektieren und erhält für dieses Element die CSS Regeln, aber nicht für die Kindelemente.

Gruß ebody

[C&P]

Hallo,

Ist es möglich mit den Chrome Dev Tools oder anderen Tools den kompletten CSS Code von einem Codeblock zu kopieren? So dass ich den vollständigen CSS Code von dem im Bild markiertem Layout kopieren kann?

https://dev.to/dailydevtips1/chrome-copy-all-css-for-an-element-2p19

Man kann zwar ein Element selektieren und erhält für dieses Element die CSS Regeln, aber nicht für die Kindelemente.

Dann musst du das eben ein paar mal wiederholen. Oder die entsprechende Seite speichern und die code-Blöcke im Editor bearbeiten.

Bei so einer Vorgehensweise steigt aber auch die Gefahr, dass du irgendwas mitkopierst, was du gar nicht haben willst /was später stört.

LG C&P

[Rolf B]

Hallo C&P,

Bei so einer Vorgehensweise steigt aber auch die Gefahr, dass du irgendwas mitkopierst, was du gar nicht haben willst /was später stört.

Vor allem ist zu beachten, dass CSS einen schweren Defekt hat: Es ist nicht isolierbar. Man kann nach heutigem Stand kein CSS für Komponenten bauen. Es sei denn, man erstellt ein custom element mit Shadow DOM, da kann man einiges einkapseln. Oder man verwendet Namenskonventionen wie BEM - aber auch die müssen immer mit Einsatz von Hirn an die jeweilige Situation adaptiert werden.

Komponenten-CSS außerhalb eines Shadow DOM fängt mit der @container Regel langsam erst an, und ist noch lange nicht fertig. Es fehlt ein Scope-Konzept. Das hat man probiert, mit <style scoped>, aber auch das ist zu kurz gedacht: was ist, wenn eine Komponente drölfzig mal auf der Seite steht? Deswegen kann man CSS (noch) nicht einfach mal so kopieren, man muss prüfen, was die gezeigten Regeln tun und sie dann für die eigene Seite adaptieren.

Rolf

[Mitleser 2.0]

+1

IMHO aktuell weiter EIN Totschlagargument, um universelle Web widgets auch heute noch via iFrame zu bauen…

[Rolf B]

Hallo Mitleser,

sorry, dafür ein -1.

Ein Widget ist im Allgemeinen integraler Teil der Seite und daher als iframe deutlich deplaziert.

Du hast IMNSHBMWO^[1] 2 realistische Alternativen:

• für Evergreen Browser als Custom Element mit Shadow DOM und lokalem Style
• wenn Du auch Alt-Browser unterstützen willst, baust Du das CSS so, dass deine Widgets eine spezifische Klasse auf dem Container-Element haben, in dem sie sich befinden, und das mitgelieferte Stylesheet setzt diese Klasse in allen Selektoren an die erste Stelle. Den Klassennamen machst Du konfigurierbar, damit die Nutzer Kollisionen mit existierenden Klassen beheben können. Wenn Du das Stylesheet sowohl als .css wie auch als .scss oder .less lieferst, wird die Anpassung für die Nutzer einfacher, dann muss man nur an einer Stelle ändern. Oder Du kapselst deine Styles im Javascript ein und generierst on the fly das Stylesheet passend zur Seite 😉

Rolf

---

1. in my not so humble but maybe wrong opinion ↩︎

[Mitleser 2.0]

sorry, dafür ein -1.

Kein Ding

• für Evergreen Browser als Custom Element mit Shadow DOM und lokalem Style

Schön. Etwaige JS-Kollisionen bleiben als Problem.

• wenn Du auch Alt-Browser unterstützen willst, baust Du das CSS so...

Kann man machen, ist aber eine Heidenarbeit. Die iFrame-Nachteile zu kompensieren kommt deutlich „günstiger.“ IMNSHBMWO

[Rolf B]

Hallo Mitleser,

angesichts der Diskussion nehme ich das -1 mal wieder raus.

Ein iframe-Nachteil wäre, dass die im iframe eingebauten Widgets sich nicht gegenseitig "sehen" können. Bzw. du sie mit Kleber-Javascript nicht so einfach verknüpfen kannst. Du kannst keine Form-Widgets bauen, deren Wert als Teil des Forms submittet wird.

Und jeder iframe wird separat vom Server geladen (es sei denn, du lädst ihn wie unser Frickl aus einer Data-URL), d.h. es gibt jedesmal einen eigenen Request und wenn die Daten mehrerer Widgets irgendwie aus einer Quelle bereitgestellt werden müssen, gibt das eine Menge I/O.

Natürlich kannst Du auf der Hauptseite einen Message-Hub bereitstellen und dir die Messages wundposten.

Aber ist das wirklich sinnvoll? Kannst Du eine Seite benennen, wo sowas gemacht wird und gut funktioniert?

Rolf

[Mitleser 2.0]

Ich kann das "aus Gründen" nicht via URL belegen. I/O und Requests aber sind kein Thema bei der Nummer. Einen iFrame kann man auch via JS erzeugen und betanken, ohne einen weiteren Request zu erzeugen.