Bootstrap 4 verwendet ja etliche !important rules.
Ich kann mich damit überhaupt nicht anfreunden, da dies eigentlich der letzte (schmutzige) “faule/hau drauf” Ausweg für mich wäre um etwas zu stylen.
Für mich persönlich wäre das ein NO-GO dieses Framework zu nutzen. Nun setzt Shopware 6 aber da drauf.
Wie sieht Ihr das? Ehrlich gesagt hab ich Bootstrap auch noch nie benutzt (auch deswegen) und kenne die “Tücken” nicht die evtl. dadurch entstehen könnten.
Ich weiß es ist sehr verbreitet und es wird jetzt beworben oder gerechtfertigt das “Entwickler” nicht Neues lernen müssten.
Das war bei Shopware 5 eigentlich auch nicht der Fall, man musste sich mMn. nur etwas in das CSS einlesen
Allerdings verwendet Bootstrap die massigen !important nur bei utility-first - Also wenn du praktisch im code stylst.
d-flex, m-r-2 usw. usw.
Hier wiederum macht das ganze natürlich Sinn. Meiner Meinung nach macht es aber keinen Sinn für das default Theme. Ich glaube aber, dass es hier so gut wie nicht verwendet wird. Denn dann läuft man eben ganz schnell in das Problem, wenn man ein Theme extended überall !importants zu haben und das dann einfach total fürn Popo ist. Dann wird wieder !important nach !important überschrieben.
Soweit ich das sehe verwendet das default Theme allerdings fast keine dieser utility-first classes. Zumindest habe ich auf anhieb nicht vieles gesehen. Aber das ist natürlich mega suboptimal - Wenn man bspw. die Navi nimmt, welche dann eben die class align-items-center hat mit !important. Willst du das ändern, müsstest du den ganzen HTML Block überschreiben, nur wiel du die class dieses einzelnen Elements ändern willst oder raus hauen wills. Eigentlich totaler Mist in meinen Augen
Für ein finales Produkt kann man es sicherlich verwenden, für den Grundbaustein auf keinen Fall - Bei Shopware. Sehe ich auch so.
Dieses utility-first geht ja gerade sehr Steil in der Szene mit dem Tailwind Framework von Adam Wathen, welcher aus der Laravel Community bekannt ist => https://tailwindcss.com/
Das ganze kann natürlich je nach Situation ganz nice sein. Aber auf keinen Fall für ein Produkt wie Shopware, wo man eben ein default Theme erweitert mit custom Stylings usw.
Ich bin generell kein Freund von Frameworks - Shopware 5 war ja da schon sehr gut fand ich ohne viel Framework Gedönse.
Bis auf ein paar Ausnahmen findest du die ganzen !importants in den utilities. Bei meiner bisherigen Arbeit bin ich, von ein paar d-none’s abgesehen, auf keine utilities gestoßen. Ich persönlich versuche mir immer eine klare Struktur mit sinnvollen Klassen aufzubauen und mit entsprechendem CSS zu versehen. Das macht für mich deutlich mehr Sinn, als das ganze über die utilities zu lösen. Die Arbeit an Projekten, in denen fast ausschließlich utilities verwendet wurden, finde ich persönlich sehr anstrengend. Shopware legt dir in dem Punkt aber keine Steine in den Weg.
schön das ich da nicht allein bin … auch bezgl. SW5 ohne Gedöhns!!
Das Prinzip “utility-first” sagt mit jetzt noch nichts (muss ich ma gucken)
aber wenn ich mir die all.css ansehe und nach !important suche finde ich 848 Übereinstimmungen … hmm fraglich was da auf uns zukommt.
In der all.css ist auch Bootstrap, deshalb die ganzen !importants. Du wirst dich sicher schnell mit dem neuen System anfreunden können. Im Ganzen ist die Entwicklung deutlich angenehmer als in SW5.
Ich bin auch kein Fan von !importants. Vielleicht kann uns ja jemand von Shopware darüber aufklären, warum die display-utilities z.B im Header oder der Navigation verwendet werden. Hat das einen besonderen Grund? Ich habe die schon an manchen Stellen entfernen müssen, weil die mit eigenen Anpassungen in Konflikt kamen, ich aber nicht mit zusätzlichen !importants arbeiten wollte.
für mich ist Bootstrap ne feine Sache, spart es mir doch sehr viel Zeit und somit Arbeit.
Aber… soweit ich sehen kann ist die bootstrap.css teil der all.css, in der bestimmt auch noch andere Shopware styles stehen, also die Bootstrap CSS ist nicht von der Shopware CSS getrennt.
Das wiederum ist dann echt doof, da ich einen Bootstrap Theme Builder wie https://bootstrap.build/app damit nicht verwenden kann. Es sollte eine bootstrap.min.css getrennt von der Shopware CSS angelegt sein. Dann im Theme Builder sich die Komponenten zurecht stylen und die bootstrap.min.css austauschen und Zack habt Ihr ein neues Theme und müsst nicht mit Gewalt bereits vorhandene !important überschreiben. Sehe ich das richtig?
Mit dem !important würde ich mir keine Gedanken machen, damit kommt man im Regelbetrieb nicht wirklich in Berührung.
Twig, Bootstrap, CSS-Präprozessoren und jQuery sind eine schlechte Wahl für das Frontend, bzw Sie sind eine gute Wahl wenn man jeden User gefallen will wegen der Kompatibilität zu alten Browsern. Ich habe keine direkten Zahlen aber ich würde schätzen, dass man für 5% Altbrowser-User einen zu tiefen Kniefall macht. 95% der User könnten auch ohne Frameworks mit den nativen JS und CSS leben und ein viel viel viel viel besseres Usererlebnis haben. Auch der „Grit“-Gedanke ist ja mittlerweile halb-tot und es ist „Modular“ angesagt. Aber nagut, Shopwares Entscheidung. Die gute Nachricht ist doch aber, jeder kann mit dem neuen Shopware viel leichter ein besseres Frontend selbst bauen. Bei meinem aktuellen Projekt wird es kein bzw nur minimal Twig, Bootstrap, SCSS und jQuery geben.
Du musst ja nicht unbedingt die vorhandenen Shopware Styles verwenden. Die halten sich zum Glück ja wirklich sehr in grenzen, sodass ma große Flexibilität hat.
Auch wenn es einige sass Dateien sind - Aber wenn du dir die custom .scss files anschaust, haben die nur extrem wenig Styles - Welche man auch nicht zwingend verwenden muss.
@brettvormkopp „Bei meinem aktuellen Projekt wird es kein bzw nur minimal Twig, Bootstrap, SCSS und jQuery geben“. Ich nehme an, dass du damit ein eigenes Base-Theme meinst bzw. entwickelst? Wie gehst du dann mit der Kompatibilität zu den ganzen PlugIns um, die ja alle auf dem Standard Storefront Theme basieren? Damit meine ich nicht die ganzen Anfänger-ich-brauche-ein-PlugIn-für-alles Teile, sondern wirklich wichtige für z.B. Zahlungsdienstleister o.ä., die alle Twig Blöcke verwenden bzw. Daten über die Controller an die Standard-Views übergeben…
Das einzige was nicht in meinem Theme überarbeitet ist, ist tatsächlich nur der Checkout Confirm. Alles andere kann man als Single Page Applikation (SPA) nachbauen. Plugin verzichte ich bewusst drauf und löse es direkt im Theme (z.b. Countdown)
… hmm fraglich was da auf uns zukommt.