Twitter Bootstrap CSS-Debugging (Verschiebung)

[zwelch]

Hallo Forum, ich benötige etwas Hilfe. Ich Verwende für ein aktuelles Projekt erstmalig Twitter Bootstrap (http://getbootstrap.com/). Code zu posten scheint mir jetzt nicht besonders sinnvoll zu sein, deswegen poste ich lieber 2 Links die das Problem besser beschreiben:

So soll es eigentlich aussehen:
http://ns1.lanconvention.de/application/test_1.html
Ein Carousel, und dador die Navigation.

Aber ich möchte gerne das ich 2 Zeilen für einen Menüeintrag haben wie z.B. unter folgendem Link:
http://ns1.lanconvention.de/application/test_2.html
Die 2 Zeilen funktionieren an sich auch (Discover / great projects), aber sobald ich diese einfüge (Line 21), dann verschiebt sich das Carousel ganz eigenartig und das CSS dahinter ist so mächtig das ich dem Problem nicht auf die Spur komme.

Hat vllt. jmd. von euch eine Idee wie ich das Problem lösen könnte?
zwelch

[Gunther]

Hi!

Hat vllt. jmd. von euch eine Idee wie ich das Problem lösen könnte?

Dein "aktuelles" Problem resultiert aus Zeile 11 in 'style.css':

  
.nav li a > span {  
    display: block;  
}

Eine Möglichkeit (keine Lösung!) wäre bspw.:

  
.nav li a > span {  
    clear: left;  
    float: left;  
}

Aber ehrlich gesagt habe ich schon lange kein solches "Gefrickel" mehr gesehen - kein Wunder, dass du da schon jetzt nicht mehr durchblickst.

Auch das HTML Markup könnte sowohl verschlankt, als auch in Hinsicht auf die Semantik überarbeitet werden.

Gruß Gunther

[Gunnar Bittersmann]

@@Gunther:

nuqneH

Auch das HTML Markup könnte sowohl verschlankt, als auch in Hinsicht auf die Semantik überarbeitet werden.

Was der Verwendung von Bootstrap widerspricht.

Qapla'

[Gunther]

@@Gunnar:

nuqneH

Auch das HTML Markup könnte sowohl verschlankt, als auch in Hinsicht auf die Semantik überarbeitet werden.

Was der Verwendung von Bootstrap widerspricht.

FACK! ;-)

Gruß Gunther

[molily]

Auch das HTML Markup könnte sowohl verschlankt, als auch in Hinsicht auf die Semantik überarbeitet werden.

Was der Verwendung von Bootstrap widerspricht.

Jein. Man kann es auch in diesem Sinne einsetzen:
http://blog.pamelafox.org/2012/12/a-tale-of-two-bootstraps-lessons.html
http://ruby.bvision.com/blog/please-stop-embedding-bootstrap-classes-in-your-html

Mathias

[Gunnar Bittersmann]

@@molily:

nuqneH

Jein. Man kann es auch in diesem Sinne einsetzen:
http://blog.pamelafox.org/2012/12/a-tale-of-two-bootstraps-lessons.html
http://ruby.bvision.com/blog/please-stop-embedding-bootstrap-classes-in-your-html

Und man erhält riesig aufgeblähten CSS-Code, da LESS bei

.foo { /* Deklarationen (darf’s auch ein bisschen mehr sein?) */ }  
.bar { .foo; }  
.baz { .foo; }  
.quz { .foo; }

ganze Codeblöcke verdoppelt, verdreifacht … und

.foo { /* Deklarationen (darf’s auch ein bisschen mehr sein?) */ }  
.bar { /* Deklarationen (darf’s auch ein bisschen mehr sein?) */ }  
.baz { /* Deklarationen (darf’s auch ein bisschen mehr sein?) */ }  
.quz { /* Deklarationen (darf’s auch ein bisschen mehr sein?) */ }

generiert.

Ich wollte schon was von „minderwertigen CSS-Präprozessor“ ranten, aber seit Version 1.4.0 kann LESS auch Extends. Na endlich. Sollte LESS etwa noch zu einer ernstzunehmenden Alternative zu Sass werden?

Welche LESS-Version verwendet Bootstrap 3?

Qapla'

[molily]

Hallo!

Ich wollte schon was von „minderwertigen CSS-Präprozessor“ ranten, aber seit Version 1.4.0 kann LESS auch Extends.

Ja. Siehe auch http://css-tricks.com/the-extend-concept/.

Welche LESS-Version verwendet Bootstrap 3?

Ich habe das Repo geklont und »npm install« ausgeführt, dabei wurde LESS 1.3.3 installiert.  Aber das ist irrelevant, das hindert einen nicht daran, 1.4.x zu verwenden und von den Bootstrap-Deklarationen per extend abzuleiten.

LESS verwendet extend selbst nicht, sondern auschließlich Mixins. Ansonsten würde der Code zwar DRY werden, aber der Code für ein Modul auseinandergezogen. Was ich persönlich in Kauf nehmen würde, alle anderen aber verwirren würde, denke ich.

Mathias

[zwelch]

Das "Gefrickel" ist ja nicht von mir. Das sind Beispiele von der offiziellen Bootstrap-Seite. Ich fand das System an sich nicht schlecht wegen der Responsiv-Geschichte und man sich so kaum um mobile Endgeräte kümmern muss. Gibt es denn bessere/Vergleichbare Alternativen, welche weniger "Gefrickel" sind?

[Gunther]

Hi!

Das "Gefrickel" ist ja nicht von mir. Das sind Beispiele von der offiziellen Bootstrap-Seite. Ich fand das System an sich nicht schlecht wegen der Responsiv-Geschichte und man sich so kaum um mobile Endgeräte kümmern muss.

Das "Problem" aus meiner Sicht daran ist, dass dieses "System" auf gewissen Annahmen/ Voraussetzungen basiert/ beruht.

Solange du diese "erfüllst" und mit dem vorgegebenen "Spielraum" auskommst, solange mag das in Ordnung sein und "funktionieren".

Aber wehe, wenn nicht ...!
Änderungen und Erweiterungen gestalten sich dann imho "schwieriger", als wenn du von vornherein dein eigenes "System" entwickelt hättest.

Gibt es denn bessere/Vergleichbare Alternativen, welche weniger "Gefrickel" sind?

AFAIK nicht. Das liegt imho auch in der Natur der Sache. Ein responsives Layout ist in noch viel stärkerem Maße von den individuellen Gegebenheiten einer Website abhängig, als das bei "Standard-Layouts" der Fall ist.

Aus diesem Grunde würde ich auch bezweifeln, dass es (zumindest in absehbarer Zukunft) ein solches geben wird.

Gruß Gunther

[molily]

Hi,

Änderungen und Erweiterungen gestalten sich dann imho "schwieriger", als wenn du von vornherein dein eigenes "System" entwickelt hättest.

Bootstrap ist in LESS geschrieben, benutzt also selbst definierte Mixins, um Code zu erzeugen, und ist relativ modular. Es basiert selbst auf anderen Stylesheets wie reset.css. Es ist eigentlich kein Problem, Teile daraus zu nehmen, aufzuräumen und anzupassen, sofern man denn LESS benutzt.

Mathias

[Gunther]

Hi Mathias!

Änderungen und Erweiterungen gestalten sich dann imho "schwieriger", als wenn du von vornherein dein eigenes "System" entwickelt hättest.

Bootstrap ist in LESS geschrieben, benutzt also selbst definierte Mixins, um Code zu erzeugen, und ist relativ modular. Es basiert selbst auf anderen Stylesheets wie reset.css. Es ist eigentlich kein Problem, Teile daraus zu nehmen, aufzuräumen und anzupassen, sofern man denn LESS benutzt.

Das mag sein, aber ich hätte bei meiner Aussage vielleicht besser noch explizit dazu geschrieben, dass sie sich auf "User mit eher etwas geringeren CSS Kenntnissen" bezieht.

Denn prinzipiell soll ein Framework ja in erster Linie dazu dienen, dass ich ausschließlich mit dem Framework arbeiten kann, ohne eben selbst in die dem Framework zugrundeliegende "Technik" einsteigen muss, bzw. mich mit dieser auskennen muss.

Aus eigener Erfahrung ist jQuery so ein Beispiel für mich.
Persönlich verwende ich eigentlich ausschließlich jQuery und schreibe selber keinen reinen Javascript Code.

Anwender, die selber mit LESS oder SASS arbeiten, werden vermutlich keine Schwierigkeiten haben, sich die entsprechenden Teile aus Bootstrap herauszusuchen oder ihre gewünschten Anpassungen vorzunehmen.

Aber diese Gruppe war halt nicht gemeint, sondern eher die Anwender, die eben nicht über entsprechend tiefgehende CSS Kenntnisse verfügen. Und die stehen eigentlich sofort "auf dem Schlauch", sobald sie irgendetwas ändern oder ergänzen wollen (wie auch schon einige Threads hier im Forum in jüngerer Vergangenheit gezeigt haben).

Und da ich jetzt einfach mal behaupte, dass bei einem responsiven Layout dieser Fall früher oder später eintreten wird, ist das "Problem" also schon vorprogrammiert.

Und wenn der Fall dann eingetreten ist, ist das Problem eigentlich doppelt groß, da die User dann nämlich erst einmal das eigentliche Framework komplett "durchblicken" müssten, um ihr eigentliches Anliegen/ Problem lösen zu können.

Ferner darf man auch nicht vergessen, dass CSS in der Theorie ja noch halbwegs "zu verstehen" ist, der Anwender in der Praxis aber mit ganz anderen "Problemen" konfrontiert wird, speziell mit den "Macken & Bugs" der verschiedenen Browser und - versionen. Und auch hier steigt die Zahl der Kandidaten bei einem responsiven Layout "sprunghaft" an.

Gruß Gunther

[Gunnar Bittersmann]

@@zwelch:

nuqneH

Ich fand das System an sich nicht schlecht wegen der Responsiv-Geschichte

„Nicht schlecht“ heißt auber auch nicht „gut“. Von „gut“ ist Bootstrap weit entfernt. Es teilt in Geräteklassen ein (Phone, Tablet, Desktop, Desktop).

Wenn man responsive Design vernünftig macht, setzt man Breakpoints aber nicht nach irgendwelchen gerade aktuellen Geräten, sondern entsprechend seinen Inhalten.

Qapla'

[molily]

Hallo,

Es teilt in Geräteklassen ein (Phone, Tablet, Desktop, Desktop).

Ach was. Das muss jedes fertig einsetzbare Responsive-Grid-Framework tun: Breakpoints vordefinieren. Alles andere ist kein »Framework«, sondern ein DIY-Baukasten. Das ist Bootstrap AUCH.

Wenn einem diese nicht zusagen, sollte man Bootstrap nehmen und im LESS-Code die Breakpoints und Grid-Schrittweite anpassen. Das sind jeweils Variablen.

Wenn man responsive Design vernünftig macht, setzt man Breakpoints aber nicht nach irgendwelchen gerade aktuellen Geräten, sondern entsprechend seinen Inhalten.

Das wird von einflussreichen Personen so vertreten, ich halte es aber für Quatsch. Es sind viele Faktoren zu beachten. Es ist nicht sinnvoll, Breakpoints rein nach den Inhalten zu setzen und die verwendeten Geräte außer Acht zu lassen. Es ist genauso unsinnig, es umgekehrt zu machen.

Responsive Design macht man, weil es eine Vielfalt von Geräten gibt. Trotzdem gibt es einflussreiche Geräteklassen, die sich auch auf die Viewport-Verteilung auswirken. 320 CSS-Pixel als Viewportbreite auf Mobilgeräten bspw. ist auf vielen Geräten seit über 6 Jahren konstant, es ist nur die Device-Pixel-Ratio gestiegen.

Würde man eine Statistik machen, so ergäbe sich eine Kurve, aber auch sichtbare »Treppenstufen« (vgl. meine Erhebung von 2006). Die Breakpoints müssen sich nicht genau danach richten, sie können auch irgendwo dazwischen stehen, klar. Aber man sollte die Viewportgrößen der wichtigsten Geräte im Auge behalten.

Eine Website wird immer an den aktuellen Markt angepasst, und das ist gut so, schließlich soll sie in den heutigen Browsern/Geräten gut funktionieren. Kein Responsive Design wird in 3-4 Jahren noch gleich gut funktionieren, selbst wenn sich die Breakpoints nach dem Inhalt richten. Sowieso wird keine Website 3-4 Jahre inhaltlich gleich bleiben.

Mathias

[Gunther]

Hallo,

Es teilt in Geräteklassen ein (Phone, Tablet, Desktop, Desktop).

Ach was. Das muss jedes fertig einsetzbare Responsive-Grid-Framework tun: Breakpoints vordefinieren. Alles andere ist kein »Framework«, sondern ein DIY-Baukasten. Das ist Bootstrap AUCH.

Wenn einem diese nicht zusagen, sollte man Bootstrap nehmen und im LESS-Code die Breakpoints und Grid-Schrittweite anpassen. Das sind jeweils Variablen.

Ja, und dann auch gleich noch von Pixeln auf (R)EMs/ Prozentwerte wechseln, die Schriftgrößen ebenfalls entsprechend ändern und und und ...!

Was bleibt dann eigentlich noch "übrig", bzw. warum sollte man dann überhaupt erst Bootstrap verwenden? :-P

Wenn man responsive Design vernünftig macht, setzt man Breakpoints aber nicht nach irgendwelchen gerade aktuellen Geräten, sondern entsprechend seinen Inhalten.

Das wird von einflussreichen Personen so vertreten, ich halte es aber für Quatsch. Es sind viele Faktoren zu beachten. Es ist nicht sinnvoll, Breakpoints rein nach den Inhalten zu setzen und die verwendeten Geräte außer Acht zu lassen. Es ist genauso unsinnig, es umgekehrt zu machen.

Da stimme ich dir zu.
Aber jede neue "Technik" bringt auch meistens ihre "neuen Thesen, Paradigmen & Co." mit sich.

"Mobile first" ist auch eine davon. Imho genauso "unsinnig" wie die Geschichte mit den Breakpoints. Ich halte es immer für angebracht, das "Ganze" im Vorfeld zu überdenken und zu planen, denn je nachdem was ich bei unterschiedlichen Viewportgrößen an verschiedenen Darstellungen erreichen möchte, muss ich dass in meiner HTML Struktur berücksichtigen. Und die kann dabei ganz "anders" ausfallen, als sie es nur für "mobile" sein müsste.

BTW: Wo fängt "mobile" dabei eigentlich an und wo hört es auf?

Gruß Gunther

[Gunnar Bittersmann]

@@Gunther:

nuqneH

Aber jede neue "Technik" bringt auch meistens ihre "neuen Thesen, Paradigmen & Co." mit sich.

Und ihre Nicht-Versteher. m(

Qapla'

[Gunther]

@@Gunnar:

nuqneH

Aber jede neue "Technik" bringt auch meistens ihre "neuen Thesen, Paradigmen & Co." mit sich.

Und ihre Nicht-Versteher. m(

OMG! Und das bei ...

[Der Autor] "beschäftigt sich beruflich und privat seit 2005 neben der Webprogrammierung auch mit der Entwicklung von Mobile und Native Apps. Er ist Rich Media Innovation Specialist bei Google und Autor des Buches "Spiele programmieren für iPhone und iPad" (dpunkt-Verlag). Außerdem ist er Gastdozent an der Popakademie Baden-Württemberg und der Filmschule Köln. Auf Mobile Zeitgeist schreibt er dementsprechend hauptsächlich über Trends und Entwicklungen in Mobile Entertainment "

Besonders gelungen finde ich die Bezeichnung "Rich Media Innovation Specialist"! *ROFL*
Na ob der Arbeitsplatz da noch lange besteht ...?

Gruß Gunther

[molily]

Hi!

Und ihre Nicht-Versteher. m(

Klar besteht der Artikel hauptsächlich aus Missverständnissen. Aber die empirischen Untersuchungen sind durchaus interessant. Sie zeigen erst einmal, dass Responsive Design äußerst schwierig ist und noch nicht sehr etabliert. Das Thema Navigation und Usability von Mobilseiten steckt halt noch in den Kinderschuhen. Es bilden gerade erst Patterns heraus.

Dass viele responsiven Seiten hinsichtlich UX und Performance schlecht umgesetzt sind, glaube ich sofort. Der große Fehlschluss ist allerdings von der schlechten Praxis darauf zu schließen, dass Responsive Design an sich unmöglich und zum Scheitern verurteilt ist.

Mathias

[molily]

Ja, und dann auch gleich noch von Pixeln auf (R)EMs/ Prozentwerte wechseln, die Schriftgrößen ebenfalls entsprechend ändern und und und ...!

Bootstrap verwendet px-Schriftgrößen, ja. Das wird auch über Variablen gesteuert.

REM finde ich witzlos solange ich ohnehin einen px-Fallback für ältere Browser einbauen muss. Dann habe ich nichts gewonnen gegenüber einer Sass-Funktion, die einen rem-Faktor entgegennimmt und nur px-Werte ausspuckt.

Was bleibt dann eigentlich noch "übrig", bzw. warum sollte man dann überhaupt erst Bootstrap verwenden? :-P

Rhetorische oder ernsthafte Frage? (Ich will hier niemanden überzeugen, höchstens aufklären. Wenn niemand daran interessiert ist, mache ich mir auch nicht die Mühe, es zu schreiben.)

Bootstrap setzt viele sinnvolle Defaults, z.B. typographisch, und bietet einen Haufen an Strukturierungen, die man so oder ähnlich fast immer braucht (Buttons, Formulare, verschiedene Widgets). Natürlich kann man das auch selbst schreiben, oder einfach die fertigen Komponenten verwenden und ggf. anpassen.

"Mobile first" ist auch eine davon. Imho genauso "unsinnig" wie die Geschichte mit den Breakpoints. Ich halte es immer für angebracht, das "Ganze" im Vorfeld zu überdenken und zu planen, denn je nachdem was ich bei unterschiedlichen Viewportgrößen an verschiedenen Darstellungen erreichen möchte, muss ich dass in meiner HTML Struktur berücksichtigen. Und die kann dabei ganz "anders" ausfallen, als sie es nur für "mobile" sein müsste.

»Mobile First« hat ja verschiedene Bedeutungen, über die sich jeweils streiten lässt:

• Ausrichtung des Seitenkonzepts auf Mobilgeräte unter der Annahme, dass Mobilnutzung bald dominiert. Die Grundfunktionen der Site müssen auch auf Mobilgeräten funktionieren, die bisher als technisch eingeschränkt wahrgenommen wurden. Das heißt reduzieren der Site auf das Wesentliche.
• Beim Schreiben des CSS wird ein kleiner Viewport als Standard angenommen, nicht als »Ausnahme«. Nicht eingeschränkte Styles gelten für alle Viewports und erzeugen auf kleinen Viewports bereits sinnvolle Resultate. Per Media-Queries werden Styles für größere Viewports hinzugefügt. Z.B. Darstellung in mehreren Spalten, größere Schrift, höher aufgelöste Grafiken.
  usw.

BTW: Wo fängt "mobile" dabei eigentlich an und wo hört es auf?

»Mobile first« ist nach Ansicht vieler eine unglückliche Wortwahl. Einige plädieren daher für »Content First«.

Mathias

[Gunnar Bittersmann]

@@molily:

nuqneH

»Mobile first« ist nach Ansicht vieler eine unglückliche Wortwahl. Einige plädieren daher für »Content First«.

No, Me First. ;-)

Qapla'

[Gunther]

Hi Mathias!

REM finde ich witzlos solange ich ohnehin einen px-Fallback für ältere Browser einbauen muss. Dann habe ich nichts gewonnen gegenüber einer Sass-Funktion, die einen rem-Faktor entgegennimmt und nur px-Werte ausspuckt.

Also abgesehen vom IE 8 - für welche Browser "musst" du denn heutzutage noch einen Fallback einbauen? Und warum muss der in Pixeln sein (und nicht % oder em)?
Und jetzt sag' bitte nicht Opera Mini. ;-)

Was bleibt dann eigentlich noch "übrig", bzw. warum sollte man dann überhaupt erst Bootstrap verwenden? :-P

Rhetorische oder ernsthafte Frage? (Ich will hier niemanden überzeugen, höchstens aufklären. Wenn niemand daran interessiert ist, mache ich mir auch nicht die Mühe, es zu schreiben.)

Nein, durchaus ernsthafte Frage.

Bootstrap setzt viele sinnvolle Defaults, z.B. typographisch, und bietet einen Haufen an Strukturierungen, die man so oder ähnlich fast immer braucht (Buttons, Formulare, verschiedene Widgets). Natürlich kann man das auch selbst schreiben, oder einfach die fertigen Komponenten verwenden und ggf. anpassen.

OK, also im Prinzip eine weitere "Sammlung" a là HTML5 Boilerplate, normalize.css & Co.
Ich frage mich generell, ob Grid-Systeme im RWD überhaupt sinnvoll sind?

"Mobile first" ist auch eine davon. Imho genauso "unsinnig" wie die Geschichte mit den Breakpoints. Ich halte es immer für angebracht, das "Ganze" im Vorfeld zu überdenken und zu planen, denn je nachdem was ich bei unterschiedlichen Viewportgrößen an verschiedenen Darstellungen erreichen möchte, muss ich dass in meiner HTML Struktur berücksichtigen. Und die kann dabei ganz "anders" ausfallen, als sie es nur für "mobile" sein müsste.

»Mobile First« hat ja verschiedene Bedeutungen, über die sich jeweils streiten lässt:

• Ausrichtung des Seitenkonzepts auf Mobilgeräte unter der Annahme, dass Mobilnutzung bald dominiert. Die Grundfunktionen der Site müssen auch auf Mobilgeräten funktionieren, die bisher als technisch eingeschränkt wahrgenommen wurden. Das heißt reduzieren der Site auf das Wesentliche.

Das lasse ich jetzt mal mehr oder weniger unkommentiert - nur soviel:
Alles was nicht wesentlich ist auf einer Seite, könnte man auch als "überflüssig" bezeichnen. ;-)

• Beim Schreiben des CSS wird ein kleiner Viewport als Standard angenommen, nicht als »Ausnahme«. Nicht eingeschränkte Styles gelten für alle Viewports und erzeugen auf kleinen Viewports bereits sinnvolle Resultate.

Interessanter Ansatz - wie soll das funktionieren!?

Per Media-Queries werden Styles für größere Viewports hinzugefügt. Z.B. Darstellung in mehreren Spalten, größere Schrift, höher aufgelöste Grafiken.

Ich persönlich verfolge da einen anderen Ansatz:
Die "Standard-Styles" gelten für Browser, die keine MQs verstehen (aktuell bspw. noch der IE 8) und beziehen sich auf eine fixed-width Version (bspw. 980px).
Alle relevanten Mobile Browser verstehen MQs - insofern sehe ich keinen Sinn darin, Basis-Styles zu schreiben, die "auf kleinen Viewports bereits sinnvolle Resultate" erzeugen.

BTW: Wo fängt "mobile" dabei eigentlich an und wo hört es auf?

»Mobile first« ist nach Ansicht vieler eine unglückliche Wortwahl. Einige plädieren daher für »Content First«.

Ja, und dass es auf den "Inhalt ankommt" war und ist doch schon immer so gewesen.
Also nix neues, außer einer neuen "Parole" (oder wie immer man das auch bezeichnen mag), die mehr Verwirrung/ Irritation stiftet, denn irgendeinen "sinnvollen Gehalt" hat.

Gruß Gunther