Druckbare Version
Kommt natürlich auch drauf an, was genau du erreichen willst mit der Mehrspaltigkeit. Einfach mehrere Text (oder sonstige) Elemente nebeneinander stellen? Könnte man mit einem Gridsystem machen. Ist natürlich nicht so flexibel wie dein Ansatz mit subcolumns, weil man beim Grid eben eine feste Anzahl von "Spalten" hat und in der Regel nicht mal eben eine "Zeile" fünfspaltig und eine andere siebenspaltig machen kann, mit Spalten, die alle gleich breit sind. Insofern verstehe ich auch die Frage (noch?) nicht, wie man "sowas" richtig macht. Was genau wäre denn "sowas"?
Du könntest ja auch ein Textelement mehrspaltig darstellen wollen, um z.B. eine optimale Spaltenbreite für Fließtext herzustellen, zwecks besserer Lesbarkeit. Das kann CSS3 schon, leider aber nicht alle Browser oder zumindest mal wieder nur mit Präfix (CSS multiple column layout).
Meine Frage ist ganz allgemein gemeint. Ich betreibe Contao nur hobbymässsig - weil es mir Spass macht. Beim Thema "Spalten" dachte ich mir schon lange, subcolums könnte für diejenigen sein, die es halt nicht besser können ;) Ein Contao-Kenner hätte da viel bessere Ansätze. Zumal subcolumns zwar in meiner 3.5.3 funktioniert, aber offiziell nur bis 3.3.5 kompatibel ist.Zitat:
Zitat von tab
Aber nach der Antwort von tab stelle ich fest, dass es offensichtlich nicht einfach DIE Lösung gibt.
Mit CSS habe ich hier auch schon experimentiert. Beim über die ganze Breite laufenden Titel bin ich dann angestanden, bzw. die beiden Youtube-Elemente rechts sind dann ganz nach oben auf die Höhe des Titels gerutscht.
Dann sind wir ja schon mal zwei.Zitat:
Zitat von peter.fl
Das mit den Spalten hat mich auch mal interessiert:
https://www.youtube.com/watch?v=IKqGtXFR6BE
Dann scheinst Du dabei irgendwas falsch gemacht oder übersehen haben. Denn die Spaltenformatierung mit CSS3 funktioniert bei Blockelementen eigentlich perfekt, und in so ziemlich allen modernen Browsern inkl. verschiedener wie z. B. Dolphin, die in diesen Übersichtstabellen fürgewöhnlich garnicht erwähnt sind. Dass man teils noch Präfixe braucht, finde ich bei der kurzen Regel nicht dramatisch. Verwende ich schon lange und als Fallback ein eigenes Javascript, welches ebenfalls kein Grid benötigt. Der besondere Vorteil von CSS3 ist halt, dass der Content einschl. Text dynamisch durch die Spalten fließt, was gewöhnliche Spaltensets nicht können. Ausnahme daher, wenn er garnicht fließen soll, um z. B. enthaltene Bilder parallel auszurichten. Auf Grids steh ich halt nicht, wenn vermeidbar. Übrigens seh ich unter Deinem Link keine Spaltenformatierung mit CSS3. Scheint YAML zu sein. Woran der Überlappungsfehler liegt, hab ich jetzt nicht geguckt.Zitat:
Noch am Rande zum Thema ...
Bei resp. Layout ist daneben aut. Silbentrennung von Bedeutung. Vor allem schmale Spalten sehen ohne einfach nicht gut aus. Da finde ich die CSS3-Unterstützung bislang noch unzureichend. So manche Browser könnens noch garnicht oder machen für meinen Geschmack zuviele Trennungsfehler. Deshalb verwende ich dafür eine lokale JS-Bibliothek. Die trennt so gut wie nie falsch, kann ca. 15 Sprachen und funktioniert auch in älteren Browserversionen und den meisten Mobilbrowsern, soweit noch nicht total antik.
@soweit_ok,
das klingt ja interessant, kannst du sagen, welche JS-Bibliothek du für die Silbentrennung einsetzt?
Hallo Peter, du könntest Dir auch mal die Erweiterung aus dem Hause Rocksolid ansehen:rocksolid-columns. Unter Composer Paketverwaltung lässt die sich auch installieren
@soweit_ok
Im Moment sind die Spalten mit subcolumns eingerichtet. Ich hatte mal mit CSS3 Versuche gemacht. Das Problem mit dem Titel über der ganzen Breite bzw. den nach oben gerutschten Youtube-Elementen hatte ich dem Umstand zugeordnet, dass "Musik sehen" in einem separaten Inhaltselement definiert ist. Und wenn ich mich recht erinnere, können mit CSS3 nur Titel, die im gleichen Element wie der Text stehen als "über die ganze Breite laufend" definiert werden. Aber es ist schon eine Weile her... ich werde es wieder probieren.
@VGT
rocksolid_colums war mir bislang nicht bekannt. Etwas zum Testen auf meinem XAMPP.
Ja, subcolumns baut auf YAML. Zumindesten, als ich es das letzte mal gesehen habe.
Spalten kann man auch noch mit CSS flex machen http://the-echoplex.net/flexyboxes/
Oder einfach floaten mit Breiten- und Höhenangabe (oder display:inline-block;). Dann hat man auch direkt einen Mobile-Fallback.
Die CSS display:table...; Eigenschaften wären auch noch eine Möglichkeit.
Von auto hyphenate über JS würde ich abraten, das macht dir an jeder Stellen wo man trennen könnte ein &_shy; (ohne Unterstrich) in deinen Quelltext. Sieht doof aus wenn man den Quelltext ansieht, bläht ihn auf und wenn man Text aus der Seite kopiert und irgendwo einfügt, hat man diese ganzen &_shy;s da drin.
Na klar, die hier:Zitat:
Zitat von 3dr
http://code.google.com/p/hyphenator/
Es gibt eine Erweiterung dafür, allerdings nur bis Contao 2.11.17.
https://contao.org/de/erweiterungsli...030019.de.html
Mit Contao 3 nicht mehr kompatibel, man kann das Plugin aber auch problemlos ohne Erweiterung einbinden. Oder Du passt sie für Cto. 3 an, was nicht allzu schwierig sein dürfte, denn die tut außer die Dateien zu laden, ja nicht mehr als im BE-Seitenverwaltungsformular die zwei Felder anzubieten zur Aktivierung und zur Eingebe der Mindestanzahl der Zeichen, ab wann getrennt werden soll, und das CSS einzubinden. Letztere kann man aber auch als Aufrufparameter übergeben. Erfahrungsgemäß ist statt der standardmäßig 6 nur 2 genauso okay, hab dadurch keine messbare Performanceeinbuße feststellen können. In den Artikeln (oder auch mal nur für einzelne Blockelemente im Template) aktivierst die die Trennung dann mittels der CSS-Klasse "hyphenate". Wie Du es einbinden musst, ist unter dem Git-Link beschrieben, und es gibt daneben mindestens einen diesbezgl. Thread für Contao 2, woraus Du es auch für Version 3 ableiten kannst. Es muss halt das JS geladen werden, und wenn ich mich recht erinnere, gibts für den Aufruf des Dictionary die zwei Möglichkeiten, dass es entweder mit Sprachparameter vom Plugin aufgerufen wird, was dann z. B. nur die deutschen Vokaleln ausliest, oder man extrahiert selber den benötigten Sprachteil daraus und lädt diese Datei dann selber und braucht den Sprachparameter so natürlich nicht, weil nur noch die eine Sprache enthalten.
Bin mir jetzt nicht sicher - wenn ich mich nicht täusche, lade ich das Plugin (nicht die Dictionary-Datei) mittels kleinem Patch direkt aus dem Contao Core, indem ich den Quelltext inline einlese. Weiß aber nicht mehr genau, ob ich das wieder herausnahm und doch wieder im head lade. Das Plugin alleine ist nicht allzu groß, kann man deshalb ohne nennenswerten Performanceverlust so machen. Vorteil dabei, dass Google Pagespeed einmal weniger wegen blockiertem Rendering meckert und vielleicht ein paar Pünktchen mehr vergibt. Ob´s auch eine bessere Ladezeit ergibt, ist schwer zu sagen - dafür sind die Unterschiede in Relation zur normalen Varianz zu gering.
Falls Du Probleme mit der Einbindung haben solltest (kann wg. einer Kurzreise ein paar Tage keinen Support geben), ist eigentlich nicht schwierig und recht flott erledigt, kannst Du ja auch mal in den Modul-Dateien der 2.x Erweiterung anschauen, wie die es machen. Falls Du nicht sowieso auch noch 2.x Webseiten hast, wo es ebenfalls einbauen möchtest. Dafür würde ich dann die Erweiterung nehmen, arbeitet einwandfrei.
Edit: Du kannst als Fallback auch zusätzlich im CSS die CSS3-Silbentrennungsregel hinterlegen. Macht keinen Unterschied, denn die CSS-Silbentrennung wird vom JS übersteuert. Ich mache es nicht, weil ich anhand von Tests sah, wenn in einem seltenen exotischen Mobilbrowser mal das Plugin nicht lief, funktionierte auch die CSS-Silbentrennung darin nicht. Wer unbedingt mit sowas surfen will, braucht eben keine Silbentrennung. :-)
@soweit_ok,
vielen Dank für die schnelle Antwort und die Links, damit komme ich gut zurecht, und schöne Reise;)
Das von mir genannte Plugin arbeitet on the fly, macht kein &_shy; in den Quelltext. Vermutlich meinst Du das Javascript zur serverseitigen Silbentrennung ähnlichen Namens. Die testete ich vor geraumer Zeit auch schon mal, und die änderte nämlich den HTML-Quellcode. Davon halte ich auch nichts. Wenn man mal was ändern will, hat man dann dieses ganze Geschwurbel drinstehen. Oder müsste vor dem Editieren die Dinger mit "nichts" ersetzen - erklär das mal den Kundenredakteuren, dann denken die, man hätte nicht mehr alle Latten am Zaun.Zitat:
Zitat von Andreas
Ok, kein &_shy;, da wir auf utf-8 sind mittlerweile direkt das unicode-Zeichen für das soft hyphen https://de.wikipedia.org/wiki/Weiches_Trennzeichen
Hier ein Auszug aus der WorkingExample.html von mnater/Hyphenator.
Code:<p class="hyphenate text" lang="de">
Deutsch*spra*chi*ge Bei*spiel*tex*te ha*ben na*tür*li*cher*wei*se län*ge*re Wort*zu*sam*men*set*zun*gen als eng*lisch*spra*chi*ge. Aber auch <span lang="en">“hy*phen*ation”</span> ist ein ziem*lich lan*ges Kom*po*si*tum.
</p>
Ah so, dann hab ich das wohl geträumt oder wollte die Community veralbern. :eek: Siehst Du im HTML-Code der Screenshots irgendwelche soft hyphens, egal ob UTF8 oder Unicode? ;)Zitat:
Zitat von Andreas
Anhang 16634 Anhang 16635
Sorry für die schlechte Bildqualität, musste wg. der 100kb-Uploadbegrenzung so stark komprimieren.
Hey, was soft hyphens sind, weiß ich selber. Hab zwar den JS-Code des Plugins nicht darauf inspiziert, doch jedenfalls haut es mir keine in den HTML-Quellcode. Sonst würde ich es nicht verwenden. Falls ich mich richtig erinnere, tut das die serverseitige Variante. Bin mir aber nicht mehr sicher, schon zu lange her, dass ich sie testete und die Doku dieses ganzen Zeugs las.
Edit: Eben fällt mir wieder ein, ich glaub die WorkingExample.html ist ein Online-Tool, wo man in eine Box Text reinkopieren kann, dann das Trennzeichen auswählen, Buttonklick, und in der rechten Box erscheint dann das Ergebnis, mit dem man den eigenen HTML-Quelltext ersetzt. Für Leute gedacht, die Plugin & Dictionary nicht ihrer Webseite einbinden wollen oder können, und ein Copy&Paste-Tool kann´s ja logischerweise nicht anders erledigen als durch Einfügen von soft hypens an den möglichen Trennstellen. Mit der zu installierenden Lösung hat das nichts zu tun.
Nein, die WorkingExample.html ist die Beispielseite von dem von dir erwähnten mnater/Hyphenator https://github.com/mnater/Hyphenator...ngExample.html. Da sind keine soft hyphens drin, erst nach JS.
In deinen Bildern zeigst du den Quellcode beim Einpflegen. Natürlich pflegst du den Code nicht mit den soft hyphens ein, die soll der Hyphenator ja erst da rein bringen. JS ändert den Text erst im FE. Vor JS sieht die WorkingExample.html auch so aus.
Schau dir deinen Quellcode im FE an, da siehst du auch die soft hyphens, sonst wüsste der Browser ja auch nicht, wo er trennen soll, wenn keine drin wären.HTML-Code:Vorher:
<p class="hyphenate text" lang="de">
Deutschsprachige Beispieltexte haben natürlicherweise längere Wortzusammensetzungen als englischsprachige. Aber auch <span lang="en">“hyphenation”</span> ist ein ziemlich langes Kompositum.
</p>
Nachher:
<p class="hyphenate text" lang="de">
Deutsch*spra*chi*ge Bei*spiel*tex*te ha*ben na*tür*li*cher*wei*se län*ge*re Wort*zu*sam*men*set*zun*gen als eng*lisch*spra*chi*ge. Aber auch <span lang="en">“hy*phen*ation”</span> ist ein ziem*lich lan*ges Kom*po*si*tum.
</p>
Anhang 16636
Deine Argumentation ist ja plausibel, denn irgendwie muss es das JS ja nunmal dem Browser sagen. Eigentlich wollte ich gestern ebenfalls noch hinzufügen, es passiert ja im FE. Mittels soft hyphens, wie man annehmen könnte, aber nunmal definitiv nicht. Zumindest nicht bei mir, wie oben zu sehen.
Auf meinen eigenen Webseiten verwende ich halt grundsätzlich überall Silbentrennung, nur nicht in der Navi. Hab allerdings einen Kunden, die wollten es sogar auch in der Randspalten-Navigation, weil sie etliche Downloaddokumente mit langen Bezeichnungen dort bereitstellen. Auch da nirgends irgendeine FE-Codeveränderung. Falls Du es nicht glauben magst, kann ich die Links posten und ihr könnt es euch gern online ansehen. Und wie gesagt, keine CSS3-Silbentrennung - lässt sich schließlich ebenfalls leicht nachprüfen. Na ja, jedenfalls sah ich die unterschiedlichen silbengetrennten HTML-Quellcodes insgesamt schon ungezählte Male, logisch, da hätten mir soft hyphens schließlich auffallen müssen. Sooo blind kann kein Mensch sein. Wie Du im Screenshot siehst, sind da aber eben keine, absolut null. Tut mir leid, was anderes kann ich nicht sagen, egal von welchen Texten ich mir den Quellcode anzeigen lasse. Ich verarsch euch doch nicht.
Um es nochmals zu belegen, zeigt der Screenshot diesmal zusammen mit der Browserausgabe einen Quellcode-Teil, ganz normal mit der Browserfunktion "Quellcode anzeigen" aufgerufen. Auch mit Firebug, Webdeveloper u. a. Entwicklertools dasselbe. Auf die Bitte von 3dr hatte ich extra nachgeschaut, welches Plugin ich genau verwende. Es müsste dieses sein, denn falls es andere geben sollte, kenne ich die nicht, außer wie schon erwähnt, eine serverseitige Lösung, aber die verwende ich nicht, weil sie bei meinen Tests nicht gut funktionierte.
Morgen bin ich nicht da, doch Die. werde ich nochmal genau in einer meiner Installationen überprüfen, ob ich garantiert dasselbe JS einbinde. Für mich selber könnte es mir egal sein, funktioniert bestens wie ich´s mir wünsche und gut. Falls also identisch, und ich bin mir da eigentlich sehr sicher, sollten wir vielleicht mal im JS-Code gucken, was genau es wirklich macht. Immerhin interessant, das mal aufzuhellen. Kann doch nicht sein, dass dasselbe Skript auf meinen Webseiten etwas anders macht als auf anderen.
Erstmal vorweg: Wenn der Kunde so eine Trennung möchte, ist dieser Hyphenator bestimmt eine gute Wahl. Ich wollte nur darauf hingewiesen haben, dass man dann nach JS diese Trenner im Text hat. Früher mit shy hat man sie sofort gesehen, das Unicode-Zeichen sieht man oft nicht. Ich würde das also nicht grundsätzlich in jede Website einbauen, nur wenn's sein muss.
Du siehst die Zeichen nicht, weil die Quelltextanzeige entweder den Code vor JS anzeigt, oder nach JS und diese Zeichen nicht anzeigt. Der Browser zeigt sie ja auch nicht an.
Firebug z.B. zeigt HTML nach JS an, zeigt die Zeichen in der normalen Ansicht nicht, aber in der Bearbeiten-Ansicht.
http://mnater.github.io/Hyphenator/WorkingExample.html
Anhang 16637
In der Bearbeiten-Ansicht hab ichs tatsächlich noch nicht überprüft, die verwende ich normalerweise nicht. Ja, Du hast recht, gut versteckt, sah es jetzt auch. Danke für die Info.Zitat:
Zitat von Andreas
Hm, hin und wieder kopierte ich zum Einfügen auch schon Text direkt von der Webseite. Hatte ich noch nie da drin. Na ja okay, in der Bearbeiten-Ansicht wär´s also natürlich so, doch muss man ja nicht daraus kopieren.Zitat:
Sieht doof aus wenn man den Quelltext ansieht, bläht ihn auf und wenn man Text aus der Seite kopiert und irgendwo einfügt, hat man diese ganzen &_shy;s da drin.
Siehst Du sonst noch irgendwelche Nachteile? Vielleicht übersehe ich was, doch mir fielen bislang keine ein. Bei der Bearbeitung im BE störts nicht, mit Entwicklertools ansonsten auch nicht. Die Suchmaschinen ignorieren das soft hyphen.
Ist halt ein weiteres Script und wenn ich manchmal sehe, was die Leute sich so alles an Scripts auf die Seite hauen, wird mir manchmal ganz schwindelig.
Damals mit dem shy ist es mir halt immer mal wieder ins Auge gefallen und das fand ich sehr doof. Aber wenn die Suchmaschinen das ignorieren ist es ja OK. Da es allerdings schon einige Jahre her ist, bin ich mir jetzt auch nicht mehr ganz sicher, ob ich das damals nicht serverseitig eingefügt hatte. Glaube ich aber nicht.
Suchmaschinen: Die untersuchen doch sowieso vor JS soviel ich weiß, oder?
Überlegte ich gestern auch und vermute ich ebenfalls. Ganz sicher bin ich allerdings nicht. Dementsprechend wäre ja aller mit JS generierter Text, z. B. innerHTML, von den Suchergebnissen ausgeschlossen. Gut, könnte ich mit leben. Überschreibe/erzeuge zwar oft Formatierungen im DOM, doch so gut wie nie Inhalte.Zitat:
Zitat von Andreas
Hmmh, mit dem Laden von Skripten geize ich natürlich ebenfalls. Nur was nötig ist. Wenn die CSS3-Trennung mal in allen wichtigen Browsern unterstützt wird, auch mobil, fliegts natürlich raus. Bis dahin schätze ich diese Lösung auf eigenen Webseiten sehr und Kunden müssen es halt für sich entscheiden.
[QUOTE=soweit_ok;385734Dementsprechend wäre ja aller mit JS generierter Text, z. B. innerHTML, von den Suchergebnissen ausgeschlossen.[/QUOTE]
Zumindest Google versucht mittlerweile auch die Skripte (und auch CSS) zu verarbeiten. Vermutlich eher deshalb, weil damit viel Schindluder getrieben wurde, was vor den Suchmaschinen verborgen blieb, die nur den HTML-Quelltext durchsuchten.
Das stimmt so wohl nicht, jedenfalls heutzutage. Habe aber noch nicht ausreichend dazu recherchiert.Zitat:
Zitat von Andreas
Für alte Hasen und Urgesteine kalter Kaffee, für mich ein Erfolgserlebnis: Silbentrennung mit CSS3 funktioniert. Ich wusste gar nicht, dass es das gibt.
Mit CSS3 und Spalten (dem ursprünglichen Thema) habe ich wieder geübt - aber den Erfolg noch nicht gefunden.
Ja, es funktioniert mit einigen Browsern, mit vielen aber leider nicht (z.B. auch Google Chrome). Für schmalere Spalten mit Fließtext muß man deswegen vorsichtig sein mit der Verwendung von Blocksatz. Wenn da die Silbentrennung nicht geht, sieht das besch****n aus und ich nehme dann im Zweifel lieber auch den Blocksatz mit raus.
Ja, da musst du einige Eigenschaften kennenlernen, siehe hier https://developer.mozilla.org/en-US/...SS/CSS_Columns Beachte auch das Menü auf der linken Seite.Zitat:
Zitat von peter.fl
Ich denke, dass diese column-Eigenschaften hauptsächlich für Fließtext entwickelt wurden und nicht um Spalten-Layouts umzusetzen. Aber wenn's auch mit eigebauten Videos usw. funktioniert? Nun denn. Siehe auch https://drafts.csswg.org/css-multicol/
Wie tab schon schrieb, nicht in allen Browsern. Sonst hätten wir die Diskussion über das JS-Plugin ja garnicht gebraucht. ;)Zitat:
Zitat von peter.fl
Na klar hast Du den Erfolg damit gefunden, der Spaltenumbruch funktioniert doch. Das allein ersetzt aber nicht alle sonstigen nötigen Formatierungen. Zunächst solltest Du die Überschrift "Musik sehen" nicht in den Block platzieren, sondern darüber. Das nächste Problem sind die Video-Links. Unterhalb einer gewissen Breite umbricht nämlich der Linktext. Muss er ja auch, aber dafür musst Du Dir was einfallen lassen. Vielleicht einen eigenen Container dafür, in den zwei Zeilen reinpassen. Hat der Link je verfügbarer Breite nur eine Zeile, bleibt das untere Containerstückchen eben leer. Kannst Du ja hübsch anmalen oder so. Mach ich in fluiden Galerien mit den Bildunterschriften auch immer so. Und ist der Link so lang, dass auch zwei Zeilen nicht mehr reichen, dann eben Pünktchen Pünktchen Pünktchen und den kompletten Titel im title-Tag anzeigen. Sonst zerhaut Dir das die horizontale Übereinstimmung, bei schmalerem Viewport. Und zuguterletzt hast Du zwar den Spaltenumbruch auf eine Pixelzahl festgelegt und gibst dem Video 100 % Breite, aber dem Video-Container eine feste Pixelbreite. Du musst dafür sorgen, dass das Video-Tumbnail auf 100 % der Spaltenbreite skaliert.Zitat:
Mit CSS3 und Spalten (dem ursprünglichen Thema) habe ich wieder geübt - aber den Erfolg noch nicht gefunden.
Kann man so nicht sagen. Den Spalten ist an sich egal, was enthalten ist, Texte, Bilder, Videos, was auch immer. Allerdings kann bei unterschiedlichen Inhalten vorkommen (auch bereits durch Überschriften sowie unterschiedliche Schriftgrößen u. -fonts) , dass die Schriftlinien der Spalten nicht mehr auf einer Höhe sind. Und man kann es halt bei fluiden Layouts auch nicht ausgleichen. Weiterer Nebeneffekt ist, dass dadurch bei Resize und Fließen des Inhalts durch die Spalten der untere Rand der Spalten nicht immer exakt auf einer Höhe bleibt. Kann ja nicht, bei verschiedenartigen Inhalten. Man muss also schon ggf. auf die Komposition des Inhaltsmix achten und den dafür gewünschten Skalierungsbereich. Alles geht nunmal damit nicht, für so manches aber eben eine schöne Alternative. Statische Spalten im fluiden resp. Layout haben ja ebenfalls Nachteile, bei Inhaltsmix sogar dieselben meist noch deutlich schlimmer.Zitat:
Zitat von Andreas
@tab
Bei arg schmalen Spalten oder entsprechend großen (Über-)Schriften schaut Blocksatz ja sogar mit Silbentrennung sch.... aus. Wenn´s die Wörter zu weit auseinander treibt. Um nicht nur die Spaltenbreite berücksichtigen zu können, sondern auch die Relation von Spaltenbreite <=> Schriftgröße (wenn ich nur unterhalb einer kritischen Spaltenbreite linksbündig will), nehme ich Javascript statt Mediaqueries, weils ggü. MQ den Vorteil hat, Attributwerte abfragen und darauf reagieren zu können. Nur beim Font nützt das nichts, weil man nicht, ohne auch noch für jeden verwendeten Font wissen zu müssen, wie breit er jeweils läuft und selbst wenn, müsste man auch noch zwischen Prozent, px, em, rem unterscheiden. Aber okay, man kann´s auch übertreiben. Dafür würde ich mir jedenfalls manchmal Kerning für HTML wünschen.
Na ja, die für Print geltenden typographischen Regeln sind im Webdesign eh nicht so streng. Augenschmerzen verursacht bloß, wenn manche Webdesigner beim Layouten nicht beachten, was eigentlich einwandfrei umgesetzt werden könnte.
Ist ein schwieriges Thema. Zu schmale Spalten sind für Fließtext m.E. einfach gar nicht geeignet. Aber manchmal lässt es sich halt nicht vermeiden. Klar, auch bei Blocksatz mit Silbentrennung sieht das gelegentlich Sch***** aus. Aber jedenfalls besser als Blocksatz ohne Silbentrennung, was man ja auch oft sieht. Manchmal verzichte ich dann auch lieber komplett auf den Blocksatz, was dann auch nicht gut aussieht, aber halt das kleinste Übel ist.Zitat:
Zitat von soweit_ok
Ich meine dafür wäre dann column-span:all; zuständig. Dann kann man es in dem Block lassen. Muss man natürlich sehen, ob das von den gewünschten Browsern unterstützt wird.Zitat:
Zitat von soweit_ok
@Andreas
Genau, das dachte ich mir auch, column-span:all;. Die Schriftfarbe des Titels reagiert (dies zur Kontrolle des Selektors), aber der Titel über die ganze Breite nicht.
Ja, wird von Firefox noch nicht unterstützt.
Spräche hier doch eigentlich aber auch nichts dagegen, die Überschrift über den Block mit der Videoliste zu platzieren?
@VGT
Ich habe hier subcolums durch rocksolid-colums ersetzt. Es funktioniert für meine Begriffe prima. column-span: all; habe ich ad acta gelegt, da es, mindestens bei mir, nicht auf allen Browser funktioniert.
Edit: Vergessen zu erwähnen habe ich, dass ich die Erweiterung via ER gemacht habe.
Ja, wenn du damit klar kommst, ist das ne gute Lösung. Ich glaube subcolumns ünterstützt auch noch keine Unterscheidung der Spaltenanordnung für kleine Devices im Gegensatz zu rocksolid, oder?
column-... kannst du benutzen, wenn du Fließtext gleichmäßig in mehrere Spalten aufteilen möchtest, so wie in einer Zeitung. Eine übergeordnete Headline musst du dann außerhalb platzieren.
Genau, es lassen sich Anordnungen für Desktop, Tablet und Mobile definieren.Zitat:
Zitat von Andreas
Mit subcolumns?Zitat:
Zitat von peter.fl
Ups - nein, mit rocksolid_columns lassen sich Anordnungen für Desktop, Tablet und Mobile definieren.Zitat:
Zitat von Andreas
Anhang 16664
Hallo Peter es liegt mir fern Werbung für rocksolid zu machen, aber gerade für Leute, die nicht von der Webseitenprogrammierung leben müssen, finde ich von diesen Jungs Preis, Leistung und Support auf obersten Niveau. Alle Kauftemplates und die Plugins sind auf aktuellem Contao-Versionsstand. Und deshalb reicht mir dieses Angebot (Kauftemplate) vollends für eine Vereinswebseite, weil von denen vieles mitgeliefert wird und ich benötige deshalb auch keine speziellen Erweiterungen die irgendwann nicht mehr kompatibel sind. Aber so hat jeder seine eigenen Ansprüche. Freut mich, dass ich Dir etwas helfen konnte.Zitat:
Ich habe hier subcolums durch rocksolid-colums ersetzt.
Es geht hier um Spalten. Wenn man nicht das Grid-System von Contao benutzen möchte benötigt man mehr oder weniger eine Erweiterung. Die hast du auch in den RS-Templates, nämlich genau dieses rocksolid-columns. Nichts gegen Rocksolid, aber wenn du nicht nur den Core benutzt, machst du dich immer abhängig. In diesem Fall vom Theme und den RS-Erweiterungen.Zitat:
Zitat von VGT
Nun habe ich etwas mit display:inline-table; experimentiert und das da hinbekommen. Für den Mann von der Strasse ein Erfolg ;)Zitat:
Zitat von Andreas
Ganz langsam glaube ich, dass sich auch mit Bordmitteln spaltenmässsig einiges machen lässt.
Soviel zum Stand meines Irrtums.
Ja, so rumspielen ist immer das Beste, was man machen kann, dabei lernt man das.
inline-table würde ich nicht nehmen, das ist wie ne Tabelle mit dem Unterschied, dass die Tabelle keinen Absatz erzeugt http://www.css4you.de/display.html. Also das ist dafür gedacht, wenn du eine Tabelle im Inline-Kontext anzeigen möchtest.
Da würdest du dann besser inline-block zusammen mit vertical-align:top; benutzen.
@Andreas, alles klar und habe es auch vorher bedacht; aber wie gesagt für meinen Fall reicht das völlig aus, wenn man neben- und ehrenamtlich eine Vereinsseite öhne viel Gedöns bearbeitetZitat:
aber wenn du nicht nur den Core benutzt, machst du dich immer abhängig