Welchen nutzen haben die Bezeichner id und for im HTML

[Dieter]

Hallo alle miteinander!

Ich versuche mich in den Anfängen mit Bootstrap.

Kann mir bitte jemand sagen für was ich die Bezeichner

for="inputName"

id="inputName"

verwende. Oder kann ich dies vernachlässigen.

<div class="form-group">
    <label for="inputName" class="col-sm-2 control-label">Name</label>
    <div class="col-sm-10">
    	<input class="form-control" id="inputName" name="name" type="text" value="<?php echo htmlentities($user['name']); ?>" required>
    </div>
</div>

[dedlfix]

Tach!

Ich versuche mich in den Anfängen mit Bootstrap.

Das ist allgemeines HTML und nicht Bootstrap-spezifisch.

Kann mir bitte jemand sagen für was ich die Bezeichner

for="inputName"

id="inputName"

verwende. Oder kann ich dies vernachlässigen.

Kann man, sollte man aber nicht, weil damit wichtige Funktionalität verlorengeht.

label for und input id spielen so zusammen, dass das Label nun dem Input-Feld zugeordnet ist. Damit hat das Inputfeld nun auch logisch eine Beschriftung zugeordnet bekommen und nicht nur optisch, weil das in der Ausgabe mehr oder weniger zufällig beieinandersteht. Damit können nun auch assistive Techniken wie Screenreader zum Inputfeld die passende Beschriftung vorlesen. Außerdem kann man nun auf das Label klicken und der Cursor setzt sich ins zugeordnete Eingabefeld. Vielleicht gibts auch noch ein paar andere Eigenschaften. Weglassen bringt jedenfalls keine Vorteile.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Kann man, sollte man aber nicht,

Was ist das für eine missglückte Formulierung?

Was du sagen wolltest: Kann man nicht,

weil [ansonsten] wichtige Funktionalität verlorengeht.

Du sagst es.

LLAP 🖖

[beatovich]

hallo

Was du sagen wolltest: Kann man nicht,

Nicht?

<label>Dies ist das Label<Input name="und_ich_bin_das_assoziierte_Inputelement"></label>

Der Nachteil ist, dass man damit Freiheiten im CSS verliert.

[Gunnar Bittersmann]

@@beatovich

Was du sagen wolltest: Kann man nicht,

Nicht?

Das hast du jetzt aber schön aus dem Zusammenhang gerissen.

Der Nachteil ist, dass man damit Freiheiten im CSS verliert.

Ja?

<label>
	<span>Name:</span>
	<input name="name"/>
</label>

vs.

<span>
	<label for="name">Name:</label>
	<input name="name" id="name"/>
</span>

LLAP 🖖

[dedlfix]

Tach!

Kann man, sollte man aber nicht,

Was ist das für eine missglückte Formulierung?

Ist sie das? Ich finde sie völlig richtig, ich bin schließlich kein Extremist.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Kann man, sollte man aber nicht,

Was ist das für eine missglückte Formulierung?

Ist sie das?

Ja, IMHO.

Ich finde sie völlig richtig, ich bin schließlich kein Extremist.

Und deshalb sagst du auch immer: Klar kann man bei der Ausgabe von Daten auf htmlspecialchars() verzichten, sollte man aber nicht?

LLAP 🖖

[dedlfix]

Tach!

Und deshalb sagst du auch immer: Klar kann man bei der Ausgabe von Daten auf htmlspecialchars() verzichten, sollte man aber nicht?

Sowas würde ich nie sagen, viel zu pauschal die Aussage und damit falsch. Eine Kausalität zum Thema kann ich auch nicht erkennen.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Und deshalb sagst du auch immer: Klar kann man bei der Ausgabe von Daten auf htmlspecialchars() verzichten, sollte man aber nicht?

Sowas würde ich nie sagen, viel zu pauschal die Aussage und damit falsch.

Und wenn ich geschrieben hätte „Klar kann man bei der Ausgabe von Nutzereingaben auf htmlspecialchars() verzichten, sollte man aber nicht?“, dann wäre es wieder zu speziell gewesen?

(Dass es sich dabei um Ausgaben per <?php echo … ?> in HTML-Code hinein handelt, sollte aus dem Kontext klar sein.)

Eine Kausalität zum Thema kann ich auch nicht erkennen.

Schade.

LLAP 🖖

[dedlfix]

Tach!

@@dedlfix

Und deshalb sagst du auch immer: Klar kann man bei der Ausgabe von Daten auf htmlspecialchars() verzichten, sollte man aber nicht?

Sowas würde ich nie sagen, viel zu pauschal die Aussage und damit falsch.

Und wenn ich geschrieben hätte „Klar kann man bei der Ausgabe von Nutzereingaben auf htmlspecialchars() verzichten, sollte man aber nicht?“, dann wäre es wieder zu speziell gewesen?

Sie ist weiterhin zu pauschal und falsch.

(Dass es sich dabei um Ausgaben per <?php echo … ?> in HTML-Code hinein handelt, sollte aus dem Kontext klar sein.)

Egal, du wolltest auf etwas anderes raus, aber auch den Schuh zieh ich mir nicht an.

Eine Kausalität zum Thema kann ich auch nicht erkennen.

Schade.

Warum sollte meine Meinung zum Thema X einen Zusammenhang zu meiner Meinung zum Thema Y haben? Und warum sollten meine Meinungen absolut und pauschalisiert und ohne Beachtung der jeweiligen Umstände sein?

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Warum sollte meine Meinung zum Thema X einen Zusammenhang zu meiner Meinung zum Thema Y haben?

Es ging hier wohl nicht um Meinungen zu verschiedenen Themen, sondern um eine Formulierung.

Oder bist du der Meinung, Sicherheit einer Webanwendung ist Pflicht, Benutztbarkeit einer Webanwendung aber optional?

LLAP 🖖

[dedlfix]

Tach!

Warum sollte meine Meinung zum Thema X einen Zusammenhang zu meiner Meinung zum Thema Y haben?

Es ging hier wohl nicht um Meinungen zu verschiedenen Themen, sondern um eine Formulierung.

Und was habe ich da formuliert, eine Meinung oder vielleicht ein Gedicht?

Oder bist du der Meinung, Sicherheit einer Webanwendung ist Pflicht, Benutztbarkeit einer Webanwendung aber optional?

Sagtest du nicht gerade, es geht hier nicht um Meinungen? Jetzt also doch wieder? Außerdem versuchst du hier grad wieder meine Meinung zu pauschalisieren.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Oder bist du der Meinung, Sicherheit einer Webanwendung ist Pflicht, Benutztbarkeit einer Webanwendung aber optional?

Außerdem versuchst du hier grad wieder meine Meinung zu pauschalisieren.

„Ich pauschalisiere nie.“

Außerdem hättest du auch einfach meine Frage beantworten können.

LLAP 🖖

[dedlfix]

Tach!

Außerdem hättest du auch einfach meine Frage beantworten können.

Hätte ich tun können, wollte ich aber nicht. War mir zu provokant, und die beiden Themen sind für mich nicht gegeneinander aufwiegbar.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

und die beiden Themen sind für mich nicht gegeneinander aufwiegbar.

Für mich auch nicht. Sowohl Sicherheit als auch Benutztbarkeit sind Pflicht.

LLAP 🖖

[marctrix]

Hej dedlfix,

Kann man, sollte man aber nicht,

Was ist das für eine missglückte Formulierung?

Ist sie das? Ich finde sie völlig richtig, ich bin schließlich kein Extremist.

@Gunnar Bittersmann hat völlig recht. label gehört einem input zugeordnet (entweder per for-Attribut oder durch Verschachtelung). Sonst „kann“ man eine Webseite auch gleich ausschließlich aus div und span zusammenbauen.

Es macht dann aber keinen Sinn mehr und ist auch eigentlich kein HTML mehr sondern nur noch optisch gestalteter plain text…

Es ist auch nicht extrem, auf die Formulierung „Kann man, sollte man aber nicht“ einfach zu verzichten. 😉

Sag einfach, was das Attribut macht und dass die Zuordnung sonst nicht funktioniert, also die logische Zuordnung von Beschriftung und Feld kaputt ist.

Marc

[Gunnar Bittersmann]

@@marctrix

Es ist auch nicht extrem, auf die Formulierung „Kann man, sollte man aber nicht“ einfach zu verzichten. 😉

Oder so zu formulieren, dass deutlich wird, wie’s gemeint ist: „Kann man machen, ist dann aber halt Kacke.“

Aber das ist wohl auch schon wieder zu extrem‽

LLAP 🖖

[marctrix]

Hej dedlfix,

Kann man, sollte man aber nicht, weil damit wichtige Funktionalität verlorengeht.

Sorry für die etwas länglichen Beiträge zum Thema von mir, @dedlfix

Ich kürze die ganze Diskussion mal ab und kopiere den Betreff dieses Threads hier rein (Hervorhebung von mir):

Welchen nutzen haben die Bezeichner id und for im HTML

Die Frage nach dem „Nutzen“ habe ich bei der Beantwortung schlichtweg wörtlich genommen…

Marc

[Gunnar Bittersmann]

@@Dieter

Ich versuche mich in den Anfängen mit Bootstrap.

Bedauernswert. Wer treibt dich zu/in diesen Wahnsinn?

Kann mir bitte jemand sagen für was ich die Bezeichner

for="inputName"

id="inputName"

verwende.

Das for-Attribut dient dazu, eine Beschriftung (label) einem Eingabefeld zuzuordnen. Die Werte der Attribute müssen dazu übereinstimmen.

Oder kann ich dies vernachlässigen.

Keinesfalls. Ohne zugeordnete Beschriftung ist ein Formular für etliche Nutzer nicht bedienbar.

Die Zuordnung kann auch implizit erfolgen, wenn das input-Element innerhalb des label-Elements ist:

<label>
	Name:
	<input name="name"/>
</label>

LLAP 🖖

[beatovich]

hallo

<div class="form-group">

Hier wäre doch eventuell ein <fieldset> richtig?

[Gunnar Bittersmann]

@@beatovich

<div class="form-group">

Hier wäre doch eventuell ein <fieldset> richtig?

Nicht wirklich. Ein fieldset gruppiert mehrere zusammengehörende Eingabeelemente. Ein fieldset um ein Eingabeelement ist nutzlos, eher schädlich.

LLAP 🖖

[beatovich]

hallo

<div class="form-group">

Hier wäre doch eventuell ein <fieldset> richtig?

Nicht wirklich. Ein fieldset gruppiert mehrere zusammengehörende Eingabeelemente. Ein fieldset um ein Eingabeelement ist nutzlos, eher schädlich.

Und welchen Schaden bringt ein fieldset hier, der ein div-Element nicht mitbringt?

[Gunnar Bittersmann]

@@beatovich

Nicht wirklich. Ein fieldset gruppiert mehrere zusammengehörende Eingabeelemente. Ein fieldset um ein Eingabeelement ist nutzlos, eher schädlich.

Und welchen Schaden bringt ein fieldset hier, der ein div-Element nicht mitbringt?

AFAIK lesen (manche?) Screenreader bei jedem Eingabefeld eines fieldsets dessen legend nochmal mit vor.

Achso, du wolltest gar kein legend-Element? Hm, ich glaube, fieldset ohne legend macht generell wenig Sinn.

LLAP 🖖

[beatovich]

hallo

Achso, du wolltest gar kein legend-Element? Hm, ich glaube, fieldset ohne legend macht generell wenig Sinn.

In html5 ist legend Pflicht, auch wenn's anderswo noch als optional gilt.

Aber dein Argument ist eigentlich kein Argument, fieldset nur beim Gruppieren mehrerer Elemente zu verwenden, sondern ein Argument, es gar nicht zu verwenden. Ich weiss, nicht, ob ich das Verhalten von Screenreadern hier berücksichtigen würde.

[marctrix]

Hej beatovich,

<div class="form-group">

Hier wäre doch eventuell ein <fieldset> richtig?

Nicht wirklich. Ein fieldset gruppiert mehrere zusammengehörende Eingabeelemente. Ein fieldset um ein Eingabeelement ist nutzlos, eher schädlich.

Und welchen Schaden bringt ein fieldset hier, der ein div-Element nicht mitbringt?

Vermutlich soll ein Element mit der Klasse form-group tatsächlich etwas gruppieren — was bedeutet, das es hier fehl am Platze ist.

Bootstrap muss eben auch erlernt und nicht einfach nur in das eigene Projekt hineinkopiert werden.

Zuum Nachteil falsch verwendeter HTML-Elemente: diese bringen ja nun mal eine Logik mit, die bei falscher Verwendung Verwirrung stiftet. Für fieldset ist das beispielsweise die implizite Rolle group. Was will mir der Seitenanbieter denn mitteilen, wenn er behauptet, dass Gruppen existieren,die ich nicht erkenne? — Sicher habe ich dann etwas übersehen. Oder nicht?

Diese Fragen drängen sich unwillkürlich auf und ein Benutzer kann sich dagegen nicht wehren. Bis er es aufgibt, diese Fragen zu klären, hast du ihm schlicht Lebenszeit geklaut, die er mit etwas angenehmeren hätte verbringen können.

Was den Schaden betrifft: Als jemand, dem es wichtig ist, über die eigene Zeit selbstbestimmt zu entscheiden würde ich schon das Gefühl haben, geschädigt worden zu sein durch die Unachtsamkeit eines anderen. Nach dieser Diskussion weißt du sogar, was passiert, wenn man falsch auszeichnet und ich finde es dann schon mindestens grob fahrlässig, wenn nicht sogar vorsätzlich, dass du meine Zeit und die von hunderten und tausenden anderen verplemperst, je nachdem wie gut deine Seite läuft.

Es mögen nur Sekunden oder maximnal Minuten sein. Aber die Laune ist hin und das in der Summe aller Besucher ist dann eine ungeheure Verschwendung. Wenn der Grund schlicht Gleichgültigkeit oder gar Bequemlichkeit ist, fände ich das extrem egoistisch.

Wobei es ja einfacher wäre kein fieldset zu schreiben, statt es dort zu verwenden, wo es nicht benötigt ist. Also warum überhaupt diese Diskussion? 😉

Marc

PS: Wenn es denn ein div mit der Klasse form-group sein soll, sollte dann auch role="group" mitgegeben werden. Browser machen seltsame Dinge mit fieldset und legend. Dann muss man statt legend aber auch eine Überschrift verwenden, bitte…

[dedlfix]

Tach!

<div class="form-group">

Hier wäre doch eventuell ein <fieldset> richtig?

Nicht wirklich. Ein fieldset gruppiert mehrere zusammengehörende Eingabeelemente. Ein fieldset um ein Eingabeelement ist nutzlos, eher schädlich.

Und welchen Schaden bringt ein fieldset hier, der ein div-Element nicht mitbringt?

Vermutlich soll ein Element mit der Klasse form-group tatsächlich etwas gruppieren — was bedeutet, das es hier fehl am Platze ist.

Bezieht sich das "es" auf das div oder das fieldset?

Jedenfalls sollte man etwas kennen, bevor mal darüber urteilt, sonst ist die ganze schöne Argumentation hinfällig, weil sie vom Ziel als nicht besonders glaubwürdig und vertane Zeit das zu lesen eingestuft wird. Auf Tools herumzuhacken bringt den Probleminhaber nicht weiter und sorgt auch nicht unbedingt für die nötige Motivation.

Mein Anliegen ist es, dem Probleminhaber nicht von oben herab Vorschriften zu machen, sondern ihn da abzuholen, wo er ist und ihn mitzunehmen. Dazu fand ich, dass "kann man, sollte man aber nicht" ein guter Einstieg auf die Frage nach dem "kann man …?" ist. Mehr sollte es gar nicht sein, und die eigentliche Aussage folgte auf dem Fuße. Ebenso eine Überreaktionen aufgrund dieser einleitenden Formulierung. Es gibt kein Gesetz, dass ein Input ein Label braucht, und deshalb erläutere ich das anhand der Vorteile, weil ich darauf hoffe, dass der Leser es nun aufgrund von Verständnis für die Arbeitsweise und die Folgen einsetzt und nicht nur als unumstößliche Vorschrift.

Zurück zum Thema. Die form-group gruppiert alle Elemente, die zu einem Formularelement gehören. Das betrifft nicht nur Label und Input sondern auch alle Elemente, die Hilfetexte oder Fehlermeldungen dafür beinhalten. Semantisch gesehen bilden diese Elemente eine Komponente. Komponenten sind auch kein unbekanntes Konzept mehr, wenn es darum geht, Anwendungen für das Web zu erstellen, wozu ich auch einfache Formulare zähle.

Zuum Nachteil falsch verwendeter HTML-Elemente: diese bringen ja nun mal eine Logik mit, die bei falscher Verwendung Verwirrung stiftet. Für fieldset ist das beispielsweise die implizite Rolle group. Was will mir der Seitenanbieter denn mitteilen, wenn er behauptet, dass Gruppen existieren,die ich nicht erkenne? — Sicher habe ich dann etwas übersehen. Oder nicht?

Diese Fragen drängen sich unwillkürlich auf und ein Benutzer kann sich dagegen nicht wehren. Bis er es aufgibt, diese Fragen zu klären, hast du ihm schlicht Lebenszeit geklaut, die er mit etwas angenehmeren hätte verbringen können.

Ich kann dieser Argumentation nicht so richtig folgen, denn ich kenne niemanden, der eine Website nutzen möchte und sich dazu die Semantik der verwendeten Elemente anschaut und sich daraufhin die Frage nach dem Sinn des Lebens stellt. Screenreader-Benutzer habe ich noch nicht kennengelernt, aber auch da vermute ich Menschen, die nicht gleich in Depression verfallen, nur weil die Semantik der Elemente ihren Screenreadern eine Herausforderung gibt. (Und nein, das soll keine Aufforderung sein, ihnen das Leben absichtlich zu erschweren. Das muss ich leider dazusagen, weil sonst gleich wieder das negativst mögliche hinzuinterpretiert und mir vorgeworfen wird.)

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Es gibt kein Gesetz, dass ein Input ein Label braucht

Das ist falsch.

In den USA gilt Section 508 Amendment to the Rehabilitation Act of 1973. Zumindest für Bundesbehörden, aber AFAIK müssen auch kommerzielle Anbieter ihre Webangebote barrierefrei machen.

“In Norway, all websites are required to be accessible.” (Quelle: @CSSconfeu)

Deutschland hinkt da hinterher, aber zumindest gilt die BITV (Barrierefreie-Informationstechnik-Verordnung) für Behörden der Bundesverwaltung.

weil ich darauf hoffe, dass der Leser es nun aufgrund von Verständnis für die Arbeitsweise und die Folgen einsetzt und nicht nur als unumstößliche Vorschrift.

Da ist was dran. Man sollte seine Webangebote barrierefrei machen aus dem Selbstverständnis, niemanden auszuschließen, nicht aufgrund der Furcht vor Strafen. Hier gilt dasselbe wie dort: Wenn du die Gefahr einer Abmahnung als Begründung anführst, sagst du, dass dir dein Wohl wichtig ist, das Wohl der Nutzer deiner Seiten aber scheißegal ist.

LLAP 🖖

[dedlfix]

Tach!

Es gibt kein Gesetz, dass ein Input ein Label braucht

Das ist falsch.

In den USA gilt Section 508 Amendment to the Rehabilitation Act of 1973. Zumindest für Bundesbehörden, aber AFAIK müssen auch kommerzielle Anbieter ihre Webangebote barrierefrei machen.

“In Norway, all websites are required to be accessible.” (Quelle: @CSSconfeu)

Ach, da steht drin, dass ein Input ein Label braucht und man nicht auch auf andere Weise die Zugänglichkeit sicherstellen kann? Das wäre jedenfalls für ein Gesetz außerordentlich spezifisch.

Mir ist schon klar, dass Label die wohl einfachste Möglichkeit ist, das zu erreichen. Aber wenn der Kontext die Bedienung unterstützt wird wohl dem Gesetz auch Genüge getan sein.

dedlfix.

[marctrix]

Hej dedlfix,

Mir ist schon klar, dass Label die wohl einfachste Möglichkeit ist, das zu erreichen. Aber wenn der Kontext die Bedienung unterstützt wird wohl dem Gesetz auch Genüge getan sein.

Die Umsetzung muss WCAG-konform sein…

Marc

[Gunnar Bittersmann]

@@marctrix

Mir ist schon klar, dass Label die wohl einfachste Möglichkeit ist, das zu erreichen. Aber wenn der Kontext die Bedienung unterstützt wird wohl dem Gesetz auch Genüge getan sein.

Die Umsetzung muss WCAG-konform sein…

dedlfix wollte vielleicht darauf rumreiten, dass außer dem label-Element noch andere Möglichkeiten gibt, ein Eingabefeld WCAG-konform zu beschriften (aria-label, aria-labelledby).

Dann reite ich aber darauf rum, dass er von „Label“ sprach, nicht von label-Element.

LLAP 🖖

[marctrix]

Hej Gunnar,

dedlfix wollte vielleicht darauf rumreiten, dass außer dem label-Element noch andere Möglichkeiten gibt, ein Eingabefeld WCAG-konform zu beschriften (aria-label, aria-labelledby).

Dann reite ich aber darauf rum, dass er von „Label“ sprach, nicht von label-Element.

Das ist doch unnötig. Es gibt so viel schönere Möglichkeiten zu reiten.

Es ist auch keine geeignete Art, Kollegen für die barrierefreie Umsetzung von Webseiten zu begeistern.

Marc

[marctrix]

Hej dedlfix,

Vermutlich soll ein Element mit der Klasse form-group tatsächlich etwas gruppieren — was bedeutet, das es hier fehl am Platze ist.

Bezieht sich das "es" auf das div oder das fieldset?

Auf die Klasse, falls sie denn etwas gruppieren soll. Aber du hast recht. In der Regel möchte man sicherlich label und input gruppieren und dann ist das tatsächlich genau der richtige Weg.

Diese Möglichkeit hatte ich nicht bedacht. Das war an dieser Stelle ein ziemlich doofer Denkfehler.

Danke für die Aufklärung!

Da wir hier beim auseinanderklamüsern von Formulierungen sind: Mit dem Wörtchen "Vermutlich" habe ich meine Spekulation kenntlich gemacht. Gut, dass du es beim Zitieren nicht weggelassen hast; schade, dass du es bei Deinem Widerspruch nciht berücksichtigt, hast. Hier hätte ich eine Formulierung glücklicher gefunden wie: „@marctrix , du liegst mit Deiner Vermutung richtig, allerdings werden hier nicht zusamenghörige Felder gruppiert, sondern alles, was zu einem Feld dazu gehört, das können Dinge wie label, eine Fehlerbeschreibung u.a.m. sein. Eine semantische Gruppierung mittels fieldset oder role="group" wäre hier fehl am Platz.“

Hätte ich persönlich konstruktiver gefunden und weniger „von oben herab“…

Jedenfalls sollte man etwas kennen, bevor mal darüber urteilt,

Ja, aber man kann nicht verlangen Bootstrap oder Atomphysik bis ins letzte Detail zu kennen, wenn man es ablehnen möchte.

Sonst gäbe es ja eine Pflicht für jedermann Atombomben zu mögen…

Man darf etwas durchaus nicht mögen und ablehnen, ohne alles darüber zu wissen. Ich habe mit Bootstrap durchaus gearbeitet und kenne es leidlich und finde es trotzdem schrecklich. Aber nicht so ein beleidigtes "find-ich-doof-will-ich-mich-nicht-mit-beschäftigen"-schrecklich. Mehr so ein "habe-ich-mir-angesehen-macht-mir-aber-alles-kaputt"-schrecklich.

Es widerspricht den für mich geltenden grundlegendsten Design-Prinzipien wie:

• beschäftige dich mit etwas, bevor du es verwendest (müsste nicht so sein, wird aber häufig so verwendet)
• Trennung von Layout und Inhalt
• Benutzbarkeit für alle — gerade für diejenigen, die am stärksten vom Web profitieren

usw…

Es gibt kein Gesetz, dass ein Input ein Label braucht

Aber eine Verordnung (https://de.wikipedia.org/wiki/Barrierefreie-Informationstechnik-Verordnung) und eine EU-Richtlinie (https://ec.europa.eu/transparency/regdoc/rep/1/2015/DE/1-2015-615-DE-F1-1.PDF — sorry mein Firefox hat mir die Buttons über der Textarea geklaut), die in nationales Recht umzustezen sein wird (und beispielsweise in Österreich schon umgesetzt wurde. Dort müssen im B2B-Bereich erstellte Webseiten grundsätzlich WCAG-konform sein), wenn du schon Korinthen kacken möchtest… 😉

Auf Tools herumzuhacken bringt den Probleminhaber nicht weiter und sorgt auch nicht unbedingt für die nötige Motivation.

Auf welchen Tools hacke ich denn rum?

Meine Abneigung gegen Bootstrap ist gut begründet. Wenn ich etwas schlecht finde und die Gründe dafür angebe, hat das mit rumhacken wohl nichts zu tun.

Ich lehne ja auch Atombomben nicht ohne Grund ab. Und wenn ich damit die Motivation verderbe, bootstrap oder Atombomben zu verwenden: gut!

Dass ich Atombomben und bootstrap immer wieder in einem Atemzug nenne, finde ich amüsant. Hätte gar nicht gedacht, dass sich der Vergleich so treffend so lange durchziehen lässt. 😉

Aber witzig ist nicht Provokation. wenn ich dich provozieren will, mache ich das dann schon unmissverständlich. Insofern: no pun intended!

Bisschen Humor verträgt die Diskussion hoffentlich…

Noch etwas zu bootstrap: ich lehne es (überraschend für dich?) übrigens nciht vollständig ab. Es ist ein prima Tool für rapid prototyping, insbesondere wenn man Bootstrap Studio verwendet. Habe ich gekauft und in Verwendung!

Ich würde es nur niemals produktiv einsetzen, es sei denn, ich werde von einem Auftraggeber gezwungen. Man muss sich halt anpassen und das ganze Leben ist ein Kompromiss.

Alle Projekte, bei denen ich es produktiv im Einsatz gesehen habe würde ich übrigens als "quick & dirty" bezeichnen. Was eigentlich gar nicht Bootstrap selber anzulasten ist, sondern den Anwendern. Aber die Krux liegt in der scheinbaren Leichtigkeit, mit der sich Projekte umsetzen lassen. Lassen sie sich aber nicht. Nur wenn man es nciht ordentlich macht. Denn quick & dirty kostet nie viel Zeit. Geht auch ohne bootstrap schnell, wie der Name schon sagt…

Leider gilt das auch für viele andere Tools, die oft nur eingesetzt werden, um den Entwicklern die Arbeit zu erleichtern. Damit die nicht einmal nachdenken müssen, müssen hunderte oder tausende von Nutzern immer und immer wieder mit schlecht durchdachten Webseiten arbeiten.

Mein Anliegen ist es, dem Probleminhaber nicht von oben herab Vorschriften zu machen, sondern ihn da abzuholen, wo er ist und ihn mitzunehmen. Dazu fand ich, dass "kann man, sollte man aber nicht" ein guter Einstieg auf die Frage nach dem "kann man …?" ist.

Ich fand es nicht gelungen und habe daher einen anderen Ansatz gewählt. Mag sein, dass du Deinen Ansatz für den einzig richtigen hältst. Ich halte meinen nicht für den einzig richtigen, aber im direkten Vergleich für den besseren und habe den daher auch umgesetzt und deinem Entwurf als Alternative zur Seite gestellt.

Unterschiedliche Meinungen zu einem Thema zu hören — finde ich — bringt einen Anfänger weiter, als der Irrglaube, es gäbe den einzig richtigen Weg. Mag er selber die Argumente von Dir und mir gegeneinander abwägen und sich eine eigene Meinung bilden…

Auch ist die Provokation nicht von mir ausgegangen.

Insofern verstehe ich nicht, warum du dich von mir so angegriffen fühlst.

Zurück zum Thema. Die form-group gruppiert alle Elemente, die zu einem Formularelement gehören.

Danke für die Aufklärung!

Zuum Nachteil falsch verwendeter HTML-Elemente: diese bringen ja nun mal eine Logik mit, die bei falscher Verwendung Verwirrung stiftet. Für fieldset ist das beispielsweise die implizite Rolle group. Was will mir der Seitenanbieter denn mitteilen, wenn er behauptet, dass Gruppen existieren,die ich nicht erkenne? — Sicher habe ich dann etwas übersehen. Oder nicht?

Diese Fragen drängen sich unwillkürlich auf und ein Benutzer kann sich dagegen nicht wehren. Bis er es aufgibt, diese Fragen zu klären, hast du ihm schlicht Lebenszeit geklaut, die er mit etwas angenehmeren hätte verbringen können.

Ich kann dieser Argumentation nicht so richtig folgen, denn ich kenne niemanden, der eine Website nutzen möchte und sich dazu die Semantik der verwendeten Elemente anschaut

Ich auch nicht. Ich kenne aber Menschen, die einen Screenreader nutzen und denen das deshalb automatisch ausgegeben wird.

Offenbar ist dein Bekanntenkreis deutlich homogener als meiner. Darum hör doch ruhig mal zu, was Menschen mit einem anderen Hintergrund wahrnehmen und berichten.

und sich daraufhin die Frage nach dem Sinn des Lebens stellt.

Ziemlich provokante Formulierung für jemanden der selbst bei jedem Anlass in die Luft geht! 😂

Aber egal. Kannst du mit mir ruhig machen, ich kann das ab. So leicht lass ich mich nicht aus der Ruhe bringen…

Nur wenn dir das selber passiert, solltest du vielleicht auch ein bisschen mehr Gelassenheit an den Tag legen, wenn andere dasselbe Stilmittel verwenden. 😉

Screenreader-Benutzer habe ich noch nicht kennengelernt, aber auch da vermute ich Menschen, die nicht gleich in Depression verfallen, nur weil die Semantik der Elemente ihren Screenreadern eine Herausforderung gibt. (Und nein, das soll keine Aufforderung sein, ihnen das Leben absichtlich zu erschweren. Das muss ich leider dazusagen, weil sonst gleich wieder das negativst mögliche hinzuinterpretiert und mir vorgeworfen wird.)

Nein, jedenfalls nicht von mir. Überhaupt werfe ich selten jemandem etwas vor. Jetzt wüsste ich nur noch gerne, wo du was in meinem Posting von „Depressionen“ gelesen hast, dann können wir das auch beenden. — Oder höre ich da wieder eine klitzekleine, leicht provokante Übertreibung raus? 😉

Insofern: immer entspannt bleiben. Wir wollen doch alle nur helfen und wenn wir andere Wege für sinnvoll halten, muss man die doch nicht jedesmal komplett durchdiskutieren.

Die kann man doch einfach auch mal nebeneinander stehen lassen: die Argumente eines Bootstrap-Enthusiasten und die eines Bootstrap-Skeptikers.

Kann für Mitlesende nur von Vorteil sein!

Übrigens meine ich immer noch, ein paar schöne Beispiele für den Nutzen des Attributes for gefunden zu haben.

Schade, dass ich dich auf der sachlichen Ebene nicht von den Vorteilen einer bestmöglichen Auszeichnung überzeugen konnte - ich werde mir in Zukunft mehr Mühe geben…

Marc

[dedlfix]

Tach!

Auf Tools herumzuhacken bringt den Probleminhaber nicht weiter und sorgt auch nicht unbedingt für die nötige Motivation.

Auf welchen Tools hacke ich denn rum?

Meine Abneigung gegen Bootstrap ist gut begründet. Wenn ich etwas schlecht finde und die Gründe dafür angebe, hat das mit rumhacken wohl nichts zu tun.

Die Aussage war allgemein gehalten und ohne persönliche Ansprache. Wir führen ja hier nicht nur ein Unter-Vier-Augengespräch, weswegen ich auch die anderen Mitleser im Sinn habe.

Ich lehne ja auch Atombomben nicht ohne Grund ab. Und wenn ich damit die Motivation verderbe, bootstrap oder Atombomben zu verwenden: gut!

Es ging mir um die Motiavation, sich auf Argumente einzulassen.

Alle Projekte, bei denen ich es produktiv im Einsatz gesehen habe würde ich übrigens als "quick & dirty" bezeichnen. Was eigentlich gar nicht Bootstrap selber anzulasten ist, sondern den Anwendern.

Und warum ist dann Bootstrap die Zielscheibe und nicht nur diese speziellen Anwender? Ich finde es zum Beispiel für meine Belange gerade "quick und trotzdem nicht dirty".

Solche Generalschelte ist so altbekant wie langweilig und ich kann sie deshalb genausowenig ernst nehmen wie ähnliche Schelte an PHP, die Sprache sei totaler Mist, nur weil es Anwender gibt, die damit nicht eingermaßen ordentlich programmieren können.

Insofern verstehe ich nicht, warum du dich von mir so angegriffen fühlst.

Als angegriffen hab ich das nicht empfunden.

Ziemlich provokante Formulierung für jemanden der selbst bei jedem Anlass in die Luft geht! 😂

Wie soll ich das deuten? Witzig wegen des Smileys oder doch ernst? Jedenfalls kann ich das nicht an mir erkennen. Auf alle Fälle fehlen in der Betrachtung die Anlässe, zu denen ich mich enthalte. Und es braucht schon deutlich mehr und gewichtigere Anlässe, um überhaupt in gefährliche Sphären zu kommen.

Aber gut, wir sind hier nach wie vor mit schriftlicher Kommunikation unterwegs und da ist es nicht so einfach, genau dieselbe Stimmung beim Leser zu erzeugen, wie sie beim Schreiben beabsichtigt war.

Screenreader-Benutzer habe ich noch nicht kennengelernt, aber auch da vermute ich Menschen, die nicht gleich in Depression verfallen, nur weil die Semantik der Elemente ihren Screenreadern eine Herausforderung gibt. (Und nein, das soll keine Aufforderung sein, ihnen das Leben absichtlich zu erschweren. Das muss ich leider dazusagen, weil sonst gleich wieder das negativst mögliche hinzuinterpretiert und mir vorgeworfen wird.)

Nein, jedenfalls nicht von mir.

War auch nur vorbeugend dazugeschrieben, weil es nicht das erste mal gewesen wäre, wenn mir hier nicht g16nannte Mitleser meine Aussagen derart ergänzen.

Insofern: immer entspannt bleiben. Wir wollen doch alle nur helfen und wenn wir andere Wege für sinnvoll halten, muss man die doch nicht jedesmal komplett durchdiskutieren.

Finde ich auch, hat man meiner Antwort aber nicht gegönnt.

Schade, dass ich dich auf der sachlichen Ebene nicht von den Vorteilen einer bestmöglichen Auszeichnung überzeugen konnte

Tja, das geht auch nur schwer, wenn ich diese Meinung schon grundsätzlich habe. Nur ein paar Aspekte betrachte ich nicht ganz so kompromisslos, besonders wenn ohne Berücksichtigung des Anwendungsfalls gepredigt wird.

dedlfix.

[marctrix]

Hej dedlfix,

Auf Tools herumzuhacken bringt den Probleminhaber nicht weiter und sorgt auch nicht unbedingt für die nötige Motivation.

Auf welchen Tools hacke ich denn rum?

Meine Abneigung gegen Bootstrap ist gut begründet. Wenn ich etwas schlecht finde und die Gründe dafür angebe, hat das mit rumhacken wohl nichts zu tun.

Die Aussage war allgemein gehalten und ohne persönliche Ansprache. Wir führen ja hier nicht nur ein Unter-Vier-Augengespräch, weswegen ich auch die anderen Mitleser im Sinn habe.

Ich lehne ja auch Atombomben nicht ohne Grund ab. Und wenn ich damit die Motivation verderbe, bootstrap oder Atombomben zu verwenden: gut!

Es ging mir um die Motiavation, sich auf Argumente einzulassen.

Wenn du diese Gefahr siehst, ist es natürlich wichtig einzuschreiten! Das sollte nicht passieren.

Meine Kernaussage war halt, bootstrap erst mal hinten an zu stellen, weil html meiner Meinung nach der Anfang von allem ist, wenn man Webseiten erstellen möchte.

Alle Projekte, bei denen ich es produktiv im Einsatz gesehen habe würde ich übrigens als "quick & dirty" bezeichnen. Was eigentlich gar nicht Bootstrap selber anzulasten ist, sondern den Anwendern.

Und warum ist dann Bootstrap die Zielscheibe und nicht nur diese speziellen Anwender? Ich finde es zum Beispiel für meine Belange gerade "quick und trotzdem nicht dirty".

Habe ich gesagt: die Webseite von bootstrap bewirbt prominent solche schlecht gemachten Webseiten und alle Beispiele beschränken sich auf die Funktionalität/Darstellung. Es würde imho schon helfen, wenn es ein paar realistischere Beispiele gäbe, wie hier im Wiki, wo zwar bestimmte Techniken erklärt werden, das aber in vernünftig ausgezeichneten html-Dokumenten. Die gesamte bootstrap-Seite bietet nur div-Wüsten an, die dann halt kopiert werden.

Es ist ja auch das Versprechen, schnell fertig zu werden, ohne css oder html lernen zu müssen. Und das reicht ja auch, um optisch einigermaßen ordentlich scheinende Seiten hinzustellen, die aber nur hübsche Datenhalden sind. Ich sehe auch keinerlei Bestrebungen seitens der Entwickler irgendwie dagegen zu steuern…

Solche Generalschelte ist so altbekant wie langweilig und ich kann sie deshalb genausowenig ernst nehmen wie ähnliche Schelte an PHP, die Sprache sei totaler Mist, nur weil es Anwender gibt, die damit nicht eingermaßen ordentlich programmieren können.

Ich kenne viel mehr gute als schlechte phpler — bei den bootstraplern glaube ich anhand von dem, wie du dich her äußerst, dass du ordentliche Arbeit ablieferst. Damit bist du der einzige (!) Entwickler, den ich kenne, der bootstrap mit ordentlich ausgezeichnetem html verbindet.

Obwohl es noch eine Agentur gibt, die das in barrierefreien Webseiten einsetzen. Also der eine frontender da.

Es mag mehr geben, sicher gerade in deinem kollegenkreis, aber es hat meiner Meinung nach schon mit dem Gesamtpaket bootstrap zu tun (Selbstdarstellung, Auswahl der Referenzen, Beispiele, fehlende Hinweise auf und Beispiele für Barrierefreiheit und Semantik mit bootstrap), dass bootstrap nicht von einigen, sondern von den meisten nur dafür verwendet wird, hübschen Mist zu bauen.

War auch nur vorbeugend dazugeschrieben, weil es nicht das erste mal gewesen wäre, wenn mir hier nicht g16nannte Mitleser meine Aussagen derart ergänzen.

Ja, ist mir schon öfter passiert, dass ich den Eindruck habe, jemand unterstellt mir, dass ich mir die Gesamtheit von Gunnars Aussagen und die Art, wie er es ausdrückt aneigne, wenn ich ihm fachlich zustimme.

Aber ich finde unsere Diskussion ist hier doch noch zu einem recht versöhnlichen Ende gekommen, gehe jetzt auf den Rest auch nicht mehr im Detail ein, sondern stimme dir in den weiteren Punkten restlos zu.

Viele Grüße, schöne Wochenende und nichts für ungut!

Marc

[beatovich]

hallo

Meine Kernaussage war halt, bootstrap erst mal hinten an zu stellen, weil html meiner Meinung nach der Anfang von allem ist, wenn man Webseiten erstellen möchte.

Ich habe eigentlich keine Erfahrung mit bootstrap. Es würde mich deshalb eher interessieren, worin denn genau die Gefahren oder Tücken von bootstrap im allgemeinen und speziellen liegen. Das aber weniger in der Form eines Forum-Artikels sondern in der Form eines Wiki-Beitrags, den man verlinken kann.

[Mitleser]

Ich habe eigentlich keine Erfahrung mit bootstrap. Es würde mich deshalb eher interessieren, worin denn genau die Gefahren oder Tücken von bootstrap im allgemeinen und speziellen liegen. Das aber weniger in der Form eines Forum-Artikels sondern in der Form eines Wiki-Beitrags, den man verlinken kann.

Dafür!

[Matthias Apsel]

Hallo beatovich,

Ich habe eigentlich keine Erfahrung mit bootstrap. Es würde mich deshalb eher interessieren, worin denn genau die Gefahren oder Tücken von bootstrap im allgemeinen und speziellen liegen. Das aber weniger in der Form eines Forum-Artikels

Marctrix:

„aber es hat meiner Meinung nach schon mit dem Gesamtpaket bootstrap zu tun (Selbstdarstellung, Auswahl der Referenzen, Beispiele, fehlende Hinweise auf und Beispiele für Barrierefreiheit und Semantik mit bootstrap), dass bootstrap nicht von einigen, sondern von den meisten nur dafür verwendet wird, hübschen Mist zu bauen.“

sondern in der Form eines Wiki-Beitrags, den man verlinken kann.

Das wäre sehr schön.

Bis demnächst
Matthias

[dedlfix]

Tach!

Ich habe eigentlich keine Erfahrung mit bootstrap. Es würde mich deshalb eher interessieren, worin denn genau die Gefahren oder Tücken von bootstrap im allgemeinen und speziellen liegen.

Mal ketzerisch zusammengefasst: Es ist das gleiche wie bei einem Hammer. Man kann damit Nägel einschlagen, aber auch Köpfe und auf den eigenen Daumen. Beim Runterfallen können auch noch Fliesen und Zehen kaputtgehen. Andererseits geht bei Verwendung von Bootstrap nicht wirklich was kaputt. Im schlimmsten Fall hat man eine Website mit Verbesserungspotential.

Bootstrap ist eine Sammlung von CSS, organisiert hauptsächlich in Klassen. Aber auch grundlegendes CSS für eine durchgehende Typographie, das direkt auf den Elementen aufsetzt, beispielsweise h(1-6) oder ul/li. Dazu gibt es eine Dokumentation mit Vorschlägen, wie man HTML-Elemente zusammen mit diesen Klassen verwenden kann. Die Klassen sind so allgemein gehalten, dass sie nicht nur mit bestimmten Elementen zusammenarbeiten. Ob man eine div-Suppe erstellt oder alle Möglichkeiten von HTML5 zur Strukturierung verwendet, ist keine Vorgabe von Bootstrap. Allerdings sind die Beispiele meist auf divs aufgebaut, solange nicht eindeutig ein HTML-Element für eine bestimmte Aufgabe genommen werden kann. Soll heißen, Tabellen und Listen sind schon mit table und ul/ol/li ausgezeichnet, aber da wo man je nach letztendlichem Kontext zwischen section, footer, aside und so weiter wählen kann, ergibt es nicht viel Sinn, eine allgemeingehaltene Dokumentation mit diesen speziellen Elementen statt neutralen divs vorzubelegen. Am Ende sind nicht wenige Anwender eh nicht in der Lage an dem kopierten Beispiel-Code sinnvolle Änderungen vorzunehmen. Da finde ich es auch besser, allgemein passende divs im Ergebnis zu haben, als kaum passende Spezialelemente.

Eine der "Gefahren oder Tücken" ist also, dass die Anwender nicht genügend nachdenken oder HTML-Wissen haben, vielleicht auch zu ängstlich sind, etwas kaputt zu machen, um die in den Beispielen verwendeten divs durch für ihren Anwendungsfall geeignetere Elemente zu ersetzen.

Ein wesentlicher Bestandteil von Bootstrap ist das 12-Spalten-Grid-System, das auch responsibel ist. Bisher mit herkömmlicher Float-Technik realisiert, mittlerweile auch mit den Möglichkeiten moderner Browser mitgehend. Das sorgt dafür, dass man recht unkompliziert den Elementen der Webseite eine einheitliche Ausrichtung und Größe geben kann, und das auch für unterschiedliche Viewportgrößen. Es nimmt einem aber nicht die generelle Arbeit ab, sich über Positionen, Größen und Anordnungen auf unterschiedlich großen Viewports Gedanken zu machen.

Weiterhin gibt es Komponenten für eine ganze Reihe von Bedienelementen, die so direkt nicht in HTML zu finden sind. Die Komponenten brauchen teilweise Javascript für ihre volle Funktionalität.

Nun hat man bei einem allgemeinen Framework das Problem, dass man den Kontext beim Anwender nicht kennt. Aber wie soll man Bezeichnern eine Semantik verleihen, wenn man von dieser Bedeutung beim individuellen Verwender keine Kenntnis hat? Bei Farben ist das noch einigermaßen möglich, wenn man sich auf allgemein übliche Verwendung bezieht, wie Rot = Gefahr. Für andere Formatierelemente hat man dann Klassennamen, die diese optischen Auswirkungen repräsentieren, das so genannte präsentationsbezogene Markup.

Das ist also eine weitere "Gefahr oder Tücke", oder jedenfalls wird es gern als Kritikpunkt aufgezählt. So richtig nachvollziehen kann ich das nicht. Am Ende haben HTML-Elemente auch nur für sich eine Semantik, und die eigentliche Semantik des Anwendungsfalls geht darin auch weitgehend verloren. Eine Liste mit Links unterscheidet sich zum Beispiel nicht von einer Liste mit Mitarbeiternamen. Die Liste ist aus Sicht der Anwendung auch nur ein präsentationsbezogenes Element.

Es gibt auch noch eine Menge andere Dinge in und um Bootstrap herum, die ich nicht weiter thematisieren kann, weil ich noch keinen Bedarf hatte, mich damit zu beschäftigen.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Mal ketzerisch zusammengefasst: Es ist das gleiche wie bei einem Hammer. Man kann damit Nägel einschlagen,

Mal ketzerisch den Vergleich berichtigt: Mit dem Hammer Bootstrap schlägst du keine Nägel in die Wand, sondern Schrauben.

Andererseits geht bei Verwendung von Bootstrap nicht wirklich was kaputt.

Doch, die performance, und damit die user experience. Der ganze Bootstrap-Code (300 Kilobyte, wir sprachen drüber) muss ja erstmal übertragen und geparst werden.

Eine der "Gefahren oder Tücken" ist also, dass die Anwender nicht genügend nachdenken oder HTML-Wissen haben, vielleicht auch zu ängstlich sind, etwas kaputt zu machen, um die in den Beispielen verwendeten divs durch für ihren Anwendungsfall geeignetere Elemente zu ersetzen.

Das kann ich bestätigen. Ich hatte unlängst statt <div class="container">, <div class="row"> und <div class="col-…"> – um den Gammelcode wenigstens etwas überschaubarer zu machen – <bs-container class="container">, <bs-row class="row"> und <bs-col class="col-…"> verwendet. Dann sieht man wenigstens bei den End-Tags </bs-col></bs-row></bs-container>, welches Element da nun gerade zugeht, anstatt unleserliches </div></div></div> im Code zu haben. Das wurde nicht verstanden, dass das überhaupt nichts kaputtmacht; und ich musste die sprechenden Elementbezeichner durch divs ersetzen, weil Bootstrap macht das in den Beispielen ja auch so. 😡

Ein wesentlicher Bestandteil von Bootstrap ist das 12-Spalten-Grid-System […] Das sorgt dafür, dass man recht unkompliziert den Elementen der Webseite eine einheitliche Ausrichtung und Größe geben kann

Eben das ist nicht der Fall!

Bei Boostrap brauchst du 3fache Verschachtelung:

<div class="container">
	<div class="row">
		<div class="col-6">Item 1</div>
		<div class="col-6">Item 2</div>
	</div>
</div>

Unkompliziert geht so:

<div class="container">
	<div>Item 1</div>
	<div>Item 2</div>
</div>

und das auch für unterschiedliche Viewportgrößen.

Und hierbei ist es noch weniger der Fall.

Bootstrap: für jeden Breakpoint noch eine zusätzliche Klasse mehr.

<div class="container">
	<div class="row">
		<div class="col-12 col-sm-6 col-md-4 col-lg-3">Item 1</div>
		<div class="col-12 col-sm-6 col-md-4 col-lg-3">Item 2</div>
	</div>
</div>

Unkompliziert geht so: für obiges unkomplizierte Markup bspw.:

.containder
{
	display: grid;
	grid-template-columns: repeat(auto-fill, minmax(15em, 1fr));
}

Einfach nur die Mindestbreite der Griditems angeben – fertig. Keine media queries – das Rechnen kann man dem Rechner überlassen.

Bei Bootstrap hat man deutlich höheren Aufwand beim Erstellen des Codes; und nochmal viel höheren Aufwand bei späteren Änderungen.

LLAP 🖖

[marctrix]

Hej Gunnar,

@@dedlfix

Ein wesentlicher Bestandteil von Bootstrap ist das 12-Spalten-Grid-System […] Das sorgt dafür, dass man recht unkompliziert den Elementen der Webseite eine einheitliche Ausrichtung und Größe geben kann

Eben das ist nicht der Fall

Sehe ich natürlich genauso. Aber das sagte ich ja bereits.

Die Komponenten sind halt out-of-the-box nutzbar. Dafür muss man sich mit total bescheuerten Namen rumschlagen, wie z.B. error für rot. WTF?

Und ganz schlimm wird es, wenn der Designer später feststellt, dass ein Teil der roten Buttons bitte grau sein soll.

Tja Pech gehabt! Da steht man dann und muss zwischen zwei Übeln wählen: an alle stellen gehen, wo Buttons grau sein sollen (in beten, dass man keine vergisst) und die Klasse durch eine andere mit ebenso bescheuertem Namen ersetzen (oft will man ja einen roten Button einsetzen, obwohl der gar keine Fehlermeldung enthält) - oder man hat das Glück dass man die Buttons, die grau werden sollen durch irgendein Merkmal im html von den Buttons unterscheiden kann, die rot bleiben sollen (z.B. weil die sich in unterschiedlichen Containern befinden beispielsweise).

Dann muss man damit leben dass man haufenweise Buttons hat, die behaupten Fehler zu enthalten, was überhaupt nicht stimmt und logisch wie optisch unterschiedlich sind.

Wer soll da noch durchblicken? — unverständlicherweise kommen die Befürworter dann immer noch mit dem Argument, dass bootstrap gut kommentiert sei. Was nützt das, wenn man seinen Code so verhunzen muss, dass man dann mehr Dokumentationsaufwand für das Projekt hat, als ohne bootstrap?

Und wie soll die Doku aussehen? Soll man da hinein schreiben, dass man Buttons, die nichts mit Fehlern zu tun haben, die Klasse error mitgegeben hat und dass die mal so und mal so aussehen, je nachdem, welchen Zweck die tatsächlich haben?

.containder
{
	display: grid;
	grid-template-columns: repeat(auto-fill, minmax(15em, 1fr));
}

Dürfte für die allermeisten Fälle tatsächlich reichen, ist aber kein 12-Spalten-Grid…

Bei Bootstrap hat man deutlich höheren Aufwand beim Erstellen des Codes; und nochmal viel höheren Aufwand bei späteren Änderungen.

Und einen höheren Lernaufwand vor der ersten Benutzung!

Marc

[at]

Hallo marctrix,

ich zitiere mal nur den ersten Absatz, meine aber auch die darauf folgenden.

Die Komponenten sind halt out-of-the-box nutzbar. Dafür muss man sich mit total bescheuerten Namen rumschlagen, wie z.B. error für rot. WTF?

Ich verstehe zumindest intellektuell die Kritik an präsentationsbezogenen Klassenbezeichnungen, auch wenn ich mit ihr nicht übereinstimme. Die Kritik an semantischen Klassenbezeichnungen, noch dazu wenn es dafür keine besser geeigneten vorgefertigten Elemente oder Attribute gibt, kann ich hingegen nicht einmal nachvollziehen. Auf mich wirkt diese Kritik daher so, als sei das Verständnis für semantische Klassenbezeichnungen der anderweitig begründeten Abneigung gegenüber Bootstrap zum Opfer gefallen.

Die semantische Klassen(teil)bezeichnung – du nennst sie error, in Bootstrap heißt sie danger – steht eben nicht für rot, sondern für die Kennzeichnung eines kritischen Zustandes oder kritischer Auswirkungen, so wie <h1> auch nicht für großen, fetten Text steht, sondern für die in ihrem Kontext wichtigste Überschrift. Wenn die nun weniger groß werden soll, ersetzt sie doch hoffentlich auch niemand durch beispielsweise eine <h3>. Ebenso spricht nichts dafür, bei der Verwendung von Bootstrap semantische Klassenbezeichnungen gegen irgendetwas anderes auszutauschen.

Es ist ja durchaus nicht so, dass Bootstrap nur von Menschen verwendet wird, die gar kein CSS können. Es wird aber häufig von Menschen eingesetzt, die nicht selbst herumtüfteln wollen, bis die Bestandteile ihrer Website beispielsweise gefällige Dimensionen und Abstände zueinander haben. CSS lernt sich für viele, insbesondere Entwickler, einfacher als die Regeln übersichtlicher und harmonischer Gestaltung, wie einem immer wieder geradezu schmerzhaft vor Augen geführt wird. Elementen in bestimmten Fällen eine andere Farbe zuzuweisen, ist denen in aller Regel möglich, auch weil Bootstrap sichtlich darum bemüht ist, die Spezifität seiner CSS-Regeln gering zu halten.

MfG, at

[Henry]

Hallo at,

Auf mich wirkt diese Kritik daher so, als sei das Verständnis für semantische Klassenbezeichnungen der anderweitig begründeten Abneigung gegenüber Bootstrap zum Opfer gefallen.

Hat sicherlich Einfluss darauf.

Es wird aber häufig von Menschen eingesetzt, die nicht selbst herumtüfteln wollen, bis die Bestandteile ihrer Website beispielsweise gefällige Dimensionen und Abstände zueinander haben.

Das funktioniert aber nur, wenn bei fertigen Templates nur der Inhalt ausgetauscht wird, was ja auch in den meisten Fällen so ist. Nur, warum dann noch Bootstrap, gibt schließlich auch schöne Templates ohne Bootstrap?

Ich sehe das so, wenn in einer relativ(also simplen) überschaubaren Bootstrap-seite im Schnitt >100 mal <div> vorkommt, ist irgendwas schief gelaufen. Warum dennoch der Erfolg von Bootstrap? Nicht weil es so leicht anpassbar wäre, was es nämlich nicht ist (wenn man eigene Vorstellungen hat und nicht nur das Template 1:1 nutzt), sondern weil Menschen sich täuschen lassen, tolles Riesenbild, Schriftgrösse riesig, viele Animationen… (Sieht alles eindrucksvoll aus und ist doch in Wahrheit sehr leicht selbst zu coden) Bootstrap ist nicht nur ein Layout sondern zugleich ein Sammelsurium von Javascriptspielereien, die auch wiederum auf Jquery basieren, auch wenn sie es bootstrap-eigen suggerieren. Das sieht erst mal gut aus und macht Eindruck auf den Normaluser. Kann ich alles nachvollziehen, nicht aber bei Fachleuten, die in der Lage sein müssten gleichwertige Templates mit max 20% des Codes zu produzieren, und ohne Hilfen wie Jquery, usw… Aber, und diese Frage habe ich hier schon oft gestellt ohne bisher mal eine Antwort zu bekommen, warum haben die meisten Fachleute, selbst eine eher weniger ansehnliche Seite, fehlt die Kreativität? Dann ist natürlich auch der Hang zu fertigen Templates verständlich, muss aber dennoch nicht Bootstrap sein.>100 DIV kann nicht der richtige Weg sein. 😉

Gruss
Henry

[dedlfix]

Tach!

Es wird aber häufig von Menschen eingesetzt, die nicht selbst herumtüfteln wollen, bis die Bestandteile ihrer Website beispielsweise gefällige Dimensionen und Abstände zueinander haben.

Genau das ist mein Grund, es zu verwenden.

Das funktioniert aber nur, wenn bei fertigen Templates nur der Inhalt ausgetauscht wird, was ja auch in den meisten Fällen so ist. Nur, warum dann noch Bootstrap, gibt schließlich auch schöne Templates ohne Bootstrap?

Fertige Templates brauche ich beispielsweise nicht, ich nehme das Baukastensystem und baue mir daraus meine Oberfläche. Ein anderes Template müsste genauso komponentenbasiert sein und nicht nur sozusagen 90% fertig sein plus einzufügende Texte.

Wenn du hingegen mit fertigen Templates zufrieden bist, oder dich hauptsächlich bei den Bootstrap-Template-Anbietern umschaust (oder das für deine Zwecke zumindest dienlich sein könnte), dann hast du eine andere Herangehensweise/Notwendigkeit als ich. Dann bietet dir auch Bootstrap vermutlich nicht mehr als jedes andere "90%-Template".

Ich sehe das so, wenn in einer relativ(also simplen) überschaubaren Bootstrap-seite im Schnitt >100 mal <div> vorkommt, ist irgendwas schief gelaufen. Warum dennoch der Erfolg von Bootstrap? Nicht weil es so leicht anpassbar wäre, was es nämlich nicht ist (wenn man eigene Vorstellungen hat und nicht nur das Template 1:1 nutzt),

Wenn du 90% umschreiben musst, um zu deinen Vorstellung von Aussehen zu kommen, dann ist Bootstrap vielleicht das falsche Werkzeug für dich. Aber das muss ja nicht auf alle anderen zutreffen. Das was ich anpassen wollte, habe ich bisher ohne Probleme hinbekommen. Aber da du hier Template erwähnst, hast du vielleicht die negativen Erfahrungen mit einem (oder mehreren) speziellen Template(s) gemacht und nicht mit dem grundlegenden Baukastensystem. Das kann bei individuellen Templates durchaus so sein, dass man da hin zu 90% geht und nicht nur den Rahmen plus Bausteine hat. Diese Erfahrung teile ich übrigens auch, dass ein dem Aussehen nach für den eigenen Zweck passend erscheinendes Template einige Fummelei bedeuten kann, hat(te in dem Fall) aber mit dem eigentlichen Bootstrap nicht viel gemein.

sondern weil Menschen sich täuschen lassen, tolles Riesenbild, Schriftgrösse riesig, viele Animationen… (Sieht alles eindrucksvoll aus und ist doch in Wahrheit sehr leicht selbst zu coden)

Dazu zähle ich mich nicht. Animationen fliegen bei mir als erstes raus, wenn ich eine Projektvorlage nehme. Tolles Riesenbild kann auf der Startseite als Blickfang liegen, wenn es nicht grad eine Intranetanwendung ist, die sich nicht erst noch ihre Anwender suchen muss. Riesige Schrift ist den kleinen Mobilbildschirmen geschuldet. Überall hat die aber auch nichts zu suchen. Ich erinnere mich aber noch genau an die Zeit bevor die Mobilen ihren Siegeszug antraten, da brauchte ich eine Mindestschriftgröße im Browser, weil jede Website es damals schick fand, in 5px-Schrift daherzukommen.</div class="kleine übertreibung">^[1]

Bootstrap ist nicht nur ein Layout sondern zugleich ein Sammelsurium von Javascriptspielereien, die auch wiederum auf Jquery basieren, auch wenn sie es bootstrap-eigen suggerieren.

Nicht wenn ich es zusammen mit Angular einsetze, da verwende ich mit ngx-bootstrap eine JQuery-freie Integration von Bootstrap-Komponenten in Angular.

Abgesehen davon, braucht man für die gleichen Spielereien auf Nicht-Bootstrap-Seiten ebenfalls Javascript. Das ist also keine Besonderheit von Bootstrap. Man kann es auch ohne Javascript verwenden, wenn man diese Komponenten nicht braucht.

Das sieht erst mal gut aus und macht Eindruck auf den Normaluser. Kann ich alles nachvollziehen, nicht aber bei Fachleuten, die in der Lage sein müssten gleichwertige Templates mit max 20% des Codes zu produzieren, und ohne Hilfen wie Jquery, usw…

Die Stimmen der Fachleute kamen ja auch hier deutlich zum Vorschein, und sie schlugen in deine Kerbe.

Aber, und diese Frage habe ich hier schon oft gestellt ohne bisher mal eine Antwort zu bekommen, warum haben die meisten Fachleute, selbst eine eher weniger ansehnliche Seite, fehlt die Kreativität?

Na aber hallo, warum gibt es wohl Fachleute? Weil nicht jeder überall so gut sein kann, wie ein Fachleut auf seinem Gebiet. Kreativität im Gestalten ist genauso eine Fähigkeit wie logisches Denken fürs Programmieren. Da hat nicht jeder gleich viel in seinem Repertoire.

Dann ist natürlich auch der Hang zu fertigen Templates verständlich, muss aber dennoch nicht Bootstrap sein.>100 DIV kann nicht der richtige Weg sein. 😉

Wie gesagt, das Bootstrapverwenderbild, das du hier vom beschreibst, trifft auch mich nicht zu. Wie da allerdings die Zahlenverteilung bei den Verwendern ist, die Bootstrap als grundlegendes Komponentensystem vs. auf Bootstrap aufbauende Templates verwenden, mag ich nicht beurteilen.

dedlfix.

---

1. Wir wollen mal nicht zu viel Semantik hier reinbringen. ↩︎

[marctrix]

Hej dedlfix,

ist mir wichtig zu sagen, dass ein Plus von mir ist… 😉

Marc

[marctrix]

Hej at,

ich zitiere mal nur den ersten Absatz, meine aber auch die darauf folgenden.

Die Komponenten sind halt out-of-the-box nutzbar. Dafür muss man sich mit total bescheuerten Namen rumschlagen, wie z.B. error für rot. WTF?

Ich verstehe zumindest intellektuell die Kritik an präsentationsbezogenen Klassenbezeichnungen, auch wenn ich mit ihr nicht übereinstimme. Die Kritik an semantischen Klassenbezeichnungen, noch dazu wenn es dafür keine besser geeigneten vorgefertigten Elemente oder Attribute gibt, kann ich hingegen nicht einmal nachvollziehen.

Nach den Diskussionen zu urteilen, in denen du dich zu Bootstrap geäußert hast, denke ich mal, dass du es besser machst.

Wenn du meine anderen Postings liest, wirst du feststellen, das Bootstrap meiner hier nirgends widerlegten Meinung nach (wie viele andere Frameworks) ausschließlich dazu genutzt wird, Entwicklern die Arbeit zu machen. Nicht dazu, effizient gute Seiten zu erstellen. Seltene Ausnahmen bestätigen die Regel.

Und ich habe erläutert, warum ich der Meinung bin, dass Bootstrap selber durch sein Auftreten, die Auswahl von Vorzeige-Websites uswusf zu genau diesem Verhalten animiert.

Dein Argument klingt so wie die der Waffenlobby in Amerika (Waffen töten keine Menschen, Menschen töten Menschen) oder: nur weil Ferrari-Käufer gerne schnell fahren, ist es doch nicht die schuld von Ferrari, dass die Fahrer sich nicht an Verkehrsregeln halten.

Für mich ist es eher so, dass ich davon überzeugt bin, dass es den meisten Männern (und vielen Frauen) schwer fällt, sich in einem Ferrari an die Geschwindigkeitsbegrenzung zu halten, weil das Auto einfach nach einem mindestens gelegentlichen Tritt aufs Gaspedal schreit.

Bootstrap dagegen spricht den faulen Schweinehund in uns an. Wenn man Bootstrap verwendet ist eine Seite recht schnell “hübsch”. Wie viele Webseiten-Betreiber machen sich dann noch ernsthaft die Mühe, das Bootstrap-CSS umzuschreiben oder statt der bereitgestellten Klassen eigene zu verwenden?

Es gib keine Statistik darüber, aber ich behaupte jetzt mal rotzfrech, dass mehr als die Hälfte der Seiten, die mit Bootstrap erstellt wurden, an roten Elementen die Klasse danger stehen haben. Dabei: Gefahrenhinweise dürften in Webseiten extrem selten vorkommen.

Wozu also eine Klasse danger unter dem Deckmäntelchen von Semantik bereitstellen, wenn es in der Praxis auf den meisten Sites keine Anwendungsmöglichkeit dafür gibt? Doch wohl nur als Feigenblatt! Um hinterher Menschen wie dir die Möglichkeit geben zu können, Bootstrap stelle ja semantische Klassen bereit und die dummen Anwender benutzen sie halt falsch.

Was sollen sie denn sonst tun? Auf die schönen fertigen Komponenten verzichten und eigene schreiben? — Wozu dann überhaupt noch Bootstrap verwenden?

Insofern verstehe ich nicht, wie du Probleme haben kannst, meine Argumentation nachzuvollziehen.

Selbst das Argument mit der Ästhetik ist fadenscheinig. Wenn man dem halben Web ansieht, dass es mit 12-spalten-Grid-Systemen erstellt ist, die mehr oder weniger alle auf 960px o.ä. basieren, ist es irgendwie auch ganz schön langweilig. Da bin ich um jedes Fefes Blog, Space Jam oder Hamsterrad-Hausfrauen-Seitchen froh, das sich mal nicht an das Raster hält.

Leider ist es dann auch mit der Zugänglichkeit [1] nicht weit her, aber ich habe mich jetzt mal hier auf den Aspekt der Hübschheit bezogen…

Marc

[1] Die dürfte bei Bootstrap 4 Seiten in vielen Fällen besser sein!

PS: In die Argumentation, warum ich selber Bootstrap nciht einsetze, bin ich ja irgendwie „reingeraten“. Ich habe ja nichts dagegen, wenn jemand anders mit bootstrap arbeite, wenn er es ordentlich macht. Was ich hier nur zu Beginn der Diskussion gesagt habe: HTML und CSS muss man trotzdem lernen und meiner Meinung nach kann man (muss man aber nicht) auf Bootstrap dann ziemlich einfach verzichten.

PPS: Das Design sollte von einem Designer entwickelt werden, das Frontend von einem Frontender und das Backend von einem Backender. Wenn eine Seite doof aussieht, weil der Entwickler kein Designer ist, ist Bootstrap nicht die Lösung. In Firmen, die zu klein für Spezialisierung sind, muss man sich halt Freelancer mit ins Boot holen. Oder man macht halt halbgares Zeug, sollten dann aber auch dazu stehen und nicht so tun, als ließe sich der Mangel an Kompetenz mit einem Haufen Tools ersetzen, die in den Händen ungelernter niemals ihr volles Potential entfalten werden…

[dedlfix]

Tach!

Wenn du meine anderen Postings liest, wirst du feststellen, das Bootstrap meiner hier nirgends widerlegten Meinung nach (wie viele andere Frameworks) ausschließlich dazu genutzt wird, Entwicklern die Arbeit zu machen. Nicht dazu, effizient gute Seiten zu erstellen. Seltene Ausnahmen bestätigen die Regel.

Ist es denn bei den Frontendern so unüblich, Komponenten zu verwenden, die von anderen geschrieben wurden? Als Programmierer ist es nicht unüblich, Frameworks zu verwenden, die einem einen Großteil der nicht zum eigentlichen Anwendungsfall gehörenden Arbeit abnehmen und/oder einen Rahmen vorgeben, den man mit der Individualität der Anwendung füllt. Natürlich gibts auch da welche, die lieber alles zu Fuß entwickeln, außer der verwendeten Programmiersprache. Aus dieser Sicht jedenfalls empfinde ich Bootstrap als die Fortsetzung dieser Wiederverwendungsidee. Es muss nicht unbedingt Bootstrap sein, auch andere ähnliche Systeme, wie Material Design können dazu zählen. (Material Design hab ich mir aber noch nicht genauer angeschaut, da mag ich auch falsch liegen mit der Einschätzung.)

Bootstrap dagegen spricht den faulen Schweinehund in uns an. Wenn man Bootstrap verwendet ist eine Seite recht schnell “hübsch”.

Auch der Mangel an gestalterischer Kreativität ist es bei mir. Meine Anwendungen aus früherer Zeit entsprachen hinter den Kulissen auch bereits meinem damaligen Kenntnisstand und dem damals üblichen, hatten aber außer Funktionalität nichts zu bieten. War alles nur Intranet-Zeugs, nichts öffentliches. Aber auch damals sah die Intranetanwendung für die ganze Firma besser aus als das Werkzeug für drei Kollegen und mich, weil ich mich bei ersterer an die Vorgaben des Intranetauftritts halten konnte.

Es ist die Gesamtheit des Bootstrap-Ansatzes, der mir hilft, eine optische Konsistenz zu meiner Anwendung hinzuzufügen, die ich mit den nativen Elementen von CSS nicht so hinbekomme.

Wie viele Webseiten-Betreiber machen sich dann noch ernsthaft die Mühe, das Bootstrap-CSS umzuschreiben oder statt der bereitgestellten Klassen eigene zu verwenden?

Das würde nach meiner Ansicht der Idee des Baukastensystems auch zuwiderlaufen, wenn man sich da noch um großartige Individualität innerhalb der Bausteine kümmern müsste.

Es gib keine Statistik darüber, aber ich behaupte jetzt mal rotzfrech, dass mehr als die Hälfte der Seiten, die mit Bootstrap erstellt wurden, an roten Elementen die Klasse danger stehen haben. Dabei: Gefahrenhinweise dürften in Webseiten extrem selten vorkommen.

Vielleicht. Bei mir ist rot nur am Löschbestätigungsbutton oder Fehlermeldungen zu finden. Passt also, wie ich finde. Bei Anwendungen, die Werkzeug sind, habe ich keine großartige Intention, die Farben anders als nach dieser Einteilung und für den ungefähr vorgesehenen Zweck zu verwenden.

Wozu also eine Klasse danger unter dem Deckmäntelchen von Semantik bereitstellen, wenn es in der Praxis auf den meisten Sites keine Anwendungsmöglichkeit dafür gibt?

Seh ich nicht ganz so verbissen. Wie die Klassennamen heißen, ist doch außer für den Entwickler nicht weiter relevant? Die könnte auch ein Minifizierer problemlos ersetzen.

Um hinterher Menschen wie dir die Möglichkeit geben zu können, Bootstrap stelle ja semantische Klassen bereit und die dummen Anwender benutzen sie halt falsch.

Welche Auswirkungen hat die Semantik an der Stelle auf andere als den/die Entwickler? Stört das Besucher beim Bedienen der Seite, wenn die Begriffe falsch verwendet werden?

Was sollen sie denn sonst tun? Auf die schönen fertigen Komponenten verzichten und eigene schreiben? — Wozu dann überhaupt noch Bootstrap verwenden?

Insofern verstehe ich nicht, wie du Probleme haben kannst, meine Argumentation nachzuvollziehen.

Man könnte das auch so sehen, dass ihr die Probleme der Verwender nicht wahrhaben wollt. Wenn sie (oder ich) Bootstrap nicht verwenden, dann lösen sich die Probleme mit Bootstrap nicht auf, sondern werden durch noch größere ersetzt. Ein semantisch einwandfreier optischer Unfall verkauft sich jedenfalls nicht. Und auf Bootstrap oder ähnliche Baukästen zu verzichten, stellt mir auch noch keinen Volblut-Frontender an die Seite. Wenn ihr Bootstrap verschwinden sehen wollt, müsstet anfangen, für diese Herausforderungen Lösungen zu finden. "Nimm einen Frontender dazu" wäre aber zu einfach, jedenfalls solange der nicht genauso kostenfrei wie Bootstrap ist. All die Nachteile aufzuzählen bringt uns nicht weiter.

dedlfix.

[marctrix]

Hej dedlfix,

Wenn du meine anderen Postings liest, wirst du feststellen, das Bootstrap meiner hier nirgends widerlegten Meinung nach (wie viele andere Frameworks) ausschließlich dazu genutzt wird, Entwicklern die Arbeit zu machen. Nicht dazu, effizient gute Seiten zu erstellen. Seltene Ausnahmen bestätigen die Regel.

Ist es denn bei den Frontendern so unüblich, Komponenten zu verwenden, die von anderen geschrieben wurden?

Es gibt zu wenige Frontender, als dass ich von üblich sprechen kann. Meistens müssen Leute das Frontend mitmachen, die ohne Bootstrap o.ä. aufgeschmissen sind und dann eben so etwas abliefern, was man als div-Wüste bezeichnet.

Ich kann aber mal von mir reden. Ich bin ein großer Freund von Fertig-Lösungen, es ist nämlich ein Irrglaube, alles besser machen zu können, als andere.

Oft steckt in einer einzelnen Komponente monatelange oder jahrelange Arbeit und hunderte von Rückmeldungen aus der Community — Bugmeldungen, Feature-Requests usw.

Ich nehme dann aber gezielt einzelne Komponenten, wie ein responsives, barrierefreies Menü oder eine Lösung für Modals.

Allerdings komme ich damit nicht immer hin, denn wenn das Design wirklich individuell ist, braucht es eine Individuallösung.

Wenn die mit HTMl und CSS nicht umsetzbar ist, nehme ich mir immer Hilfe dazu, weil ich eben kein Programmierer bin und alles — den JS-Anteil in hoher Qualität abliefern möchte.

Glücklicherweise ist die Self-Community ein reichhaltiger Experten-Pool, so dass ich immer die nötige Hilfe gefunden habe.

Als Programmierer ist es nicht unüblich, Frameworks zu verwenden, die einem einen Großteil der nicht zum eigentlichen Anwendungsfall gehörenden Arbeit abnehmen und/oder einen Rahmen vorgeben, den man mit der Individualität der Anwendung füllt.

Bei uns verwenden die Backender auch Frameworks. Ziemlich abschreckend für mich, weil ich oft zu hören bekomme, wie aufwändig es doch sei, meine Vorgaben umzusetzen mit ZEND/Symfony/Timeleaf und wie die alle heißen bei PHP und JAVa und natürlich den unterschiedlichen CMSen.

Da sehe ich dasselbe Problem wie bei Bootstrap: es wird automatisch was generiert und am liebsten möchte man sich gar nicht mit der Anpassung und Konfiguration auseinandersetzen. Wenn man es doch tut, stellt man ferst, dass es dann sofort recht komplex wird. Man muss dann die ganzen Individualisierungen dokumentieren und anderen Teams bereit stellen, damit alle Zugriff haben. Im konkreten Projekt wird dafür keine Zeit für eingeplant und und irgendwie kommt dann am Ende oft etwas heraus, was für alle nur ein Kompromiss ist — jedenfalls wenn alle bemüht sind.

Dabei ist es ja nicht so, dass die Backender Dinge, die sie selber verantworten müssen, nicht hochwertig umsetzen (Sicherheit, Effizienz, Performanz usw). Nur wenn man dann, wenn die mit ihrem Kram zufrieden sind, als außenstehender kommt und sagt, man möchte jetzt noch einen aus Usability- und Accessibility-Gründen draufsetzen, sind die Gesichter lang. Was ich durchaus verstehe.

Natürlich gibts auch da welche, die lieber alles zu Fuß entwickeln, außer der verwendeten Programmiersprache. Aus dieser Sicht jedenfalls empfinde ich Bootstrap als die Fortsetzung dieser Wiederverwendungsidee. Es muss nicht unbedingt Bootstrap sein, auch andere ähnliche Systeme, wie Material Design können dazu zählen.

Dann sähen alle Websites aus, wie von Google gemacht, wird Google sicher freuen…

Bootstrap dagegen spricht den faulen Schweinehund in uns an. Wenn man Bootstrap verwendet ist eine Seite recht schnell “hübsch”.

Auch der Mangel an gestalterischer Kreativität ist es bei mir.

Und auch der Ausbildung. Design ist ja nicht umsonst ein Studiengang. Geht mir genauso, ich bin ja auch kein Designer. Ich verstehe mich als Schnittstelle (technisch) und Vermittler (menschlich) zwischen Design und Backend und kann keines von beiden, kann aber etwas (besser) was die anderen nicht/schlechter können als ich.

Es ist die Gesamtheit des Bootstrap-Ansatzes, der mir hilft, eine optische Konsistenz zu meiner Anwendung hinzuzufügen, die ich mit den nativen Elementen von CSS nicht so hinbekomme.

Dafür verwenden wir so genannte Design-Master, die eigentlich nichts anderes als Bootstrap sind, aber viel weniger können. Eben nur die Elemente beinhalten, die das Design vorsieht. Wenn eine Anwendung ein nicht vorhandenes Element/Komponente benötigt, wird diese ergänzt. Das liegt aber sicher auch an unserer Größe. Hier arbeiten ja allein in der IT mehr Menschen, als in einer mittelgroßen Agentur und wir haben zusätzlich externe Hilfe.

Mit Extract (einer Möglichkeit aus Photoshop-Dateien gezielt Formatierungen in CSS zu exportieren) hat man aber eine Möglichkeit komplett individuell gestaltete Elemente aus den ungewöhnlichsten Designs zu übernehmen, ohne das überhaupt tippen zu müssen. Man baucht nur noch das HTML selber zu schreiben (muss man bei Bootstrap ja auch, wenn es semantisch und zugänglich sein soll).

Es gibt viele Hilfen, die einem die Arbeit erleichtern, die ich selber nutze. Bis hin zur Code-Versollständigung des Editors, so dass man ja eh nicht Ballzuviel tippt.

Für mich gilt ganz klar: ich verbringe viel mehr Zeit mit Konzept (also Denkerei), als mit dem Tippen von Code, weil ich darüber nachdenke, wie bleibt mein Kram erweiterbar, was gehört in den master, was in eine Projekt.css, um projektspezifische Abweichungen/Ergänzungen zu ermöglichen usw.

Hängt sicher viel von meiner Arbeitsweise ab, dass mir nie klar geworden ist, wo Bootstrap und Co jetzt einen Vorteil bieten, der die für mich persönlich existierenden Nachteile aufwiegt.

Wie viele Webseiten-Betreiber machen sich dann noch ernsthaft die Mühe, das Bootstrap-CSS umzuschreiben oder statt der bereitgestellten Klassen eigene zu verwenden?

Das würde nach meiner Ansicht der Idee des Baukastensystems auch zuwiderlaufen, wenn man sich da noch um großartige Individualität innerhalb der Bausteine kümmern müsste.

Eben. Deshalb ist es so schwer für mich, ein Layout, das am Anfang steht, danach mit einem Baukastensystem umzusetzen, dass von dem Layout nichts weiß. Das fängt schon damit an, dass ich vermutlich seit Jahren kein System mit 12 Rasterspalten benötigt habe.

Wir brauchen eigentlich nur ganze Breite, 1/3 zu 2/3, 2/3 zu 1/3 und ganzer Viewport (für Tabellen o.ä), die aus dem System komplett ausbrechen (geht das mit Bootstrap?).

Um hinterher Menschen wie dir die Möglichkeit geben zu können, Bootstrap stelle ja semantische Klassen bereit und die dummen Anwender benutzen sie halt falsch.

Welche Auswirkungen hat die Semantik an der Stelle auf andere als den/die Entwickler? Stört das Besucher beim Bedienen der Seite, wenn die Begriffe falsch verwendet werden?

Nirgends (außer theoretisch, dass man so etwas mal Parsen könnte - aber wer tut das schon).

Aber ich als Entwickler muss ja immer wieder mal ran an den Code und dann soll es immer schnell gehen. Da bin ich schon froh, dass in meinen Seiten Elemente anhand ihrer Bedeutung unterscheidbar sind…

Man könnte das auch so sehen, dass ihr die Probleme der Verwender nicht wahrhaben wollt.

Wieso? - Ich habe ja nichts dagegen, wenn jemand anderes bootstrap verwendet (so lange zugängliche Seiten dabei raus kommen). Ich möchte es nur nicht selber anwenden müssen…

Marc

[dedlfix]

Tach!

Wir brauchen eigentlich nur ganze Breite, 1/3 zu 2/3, 2/3 zu 1/3 und ganzer Viewport (für Tabellen o.ä), die aus dem System komplett ausbrechen (geht das mit Bootstrap?).

Ja geht, man muss das Grid-System nicht verwenden. Auch ein Mischbetrieb ist möglich. Bootstrap ist da ja recht zurückhaltend. Wenn man deren Klassen nicht angibt, ist es Browser-Default (außer genereller Typographie für einige Elemente).

Den Rest habe ich gelesen, möchte aber nicht weiter darauf eingehen, außer dass es auch mal interessant ist, andere Arbeitsweisen kennenzulernen.

dedlfix.

[Gunnar Bittersmann]

@@at

Die semantische Klassen(teil)bezeichnung – […] danger steht eben nicht für rot, sondern für die Kennzeichnung eines kritischen Zustandes oder kritischer Auswirkungen

Gute Frage: Gibt es in Bootstrap semantische Klassenbezeichnungen?

Ja, die gibt es. Und nein, die gibt es nicht.

danger ist ein gutes Beispiel dafür: Hinweismeldungen bei nicht vollständig oder nicht richtig ausgefüllten Formularfeldern sollen auf rotem Hintergrund angezeigt werden. Nun haben nicht vollständig oder nicht richtig ausgefüllte Formularfelder aber keine kritischen Auswirkungen; sie sind nicht danger. Sie sind warning. Bei warning werden sie aber auf gelbem Hintergrund angezeigt …

Nun gibt es zwei Möglichkeiten, die Hinweismeldungen rot zu bekommen. Der richtige™ Weg wäre, im eigenen Stylesheet der Klasse alert-warning roten Hintergrund zu verpassen. (Und der Klasse alert-danger zusätzlich einen Totenkopf, oder blinken lassen.) Das wird aber nicht gemacht.

Stattdessen wird den Hinweismeldungen die Klasse alert-danger verpasst. (Und das denke ich mir nicht aus, das habe ich genauso erlebt.) Sie sind rot, alles schick. danger steht eben doch für rot.

Die Klassen sollten nicht *-danger und *-warning heißen, sondern gemäß ihrer Verwendung bg-red und bg-yellow. Wenn schon präsentationsbezogenes Markup, dann richtig!

Nun könnte man auf die Idee kommen und sagen: Bootstrap macht alles richtig, es wird von Entwicklern nur falsch verwendet. Unsinn! Die Entwickler verwenden es genau so, wie es ihrer Motivation entspricht, warum sie Bootstrap überhaupt verwenden – nämlich um die Darstellung im Markup zu kontrollieren, nicht per CSS. Um keine Zeile CSS schreiben zu müssen – weil sie es nicht wollen oder weil sie es gar nicht können.

Den Anwendern von Bootstrap ist da gar kein Vorwurf zu machen. Der Vorwurf geht an die Entwickler von Bootstrap: Sie haben keine oder eine falsche Vorstellung, wer denn ihre Zielgruppe ist.

Semantische Klassenbezeichnungen in Bootstrap sind ein Mythos.

LLAP 🖖

[dedlfix]

Tach!

Es ist ja auch das Versprechen, schnell fertig zu werden, ohne css oder html lernen zu müssen. Und das reicht ja auch, um optisch einigermaßen ordentlich scheinende Seiten hinzustellen, die aber nur hübsche Datenhalden sind. Ich sehe auch keinerlei Bestrebungen seitens der Entwickler irgendwie dagegen zu steuern…

Dieses Versprechen, nichts lernen zu müssen, kann ich auf der Bootstrap-Webseite nicht finden. Und was sollen die Entwickler denn anders machen? Sie sind nicht verantwortlich für das, was andere daraus machen. Wie sollen sie wirken? Nur zertifiziertes Zeug kommt in den Store und andere Anbieterplattformen werden mittels Anwenderbevormundung ausgesperrt, à la: du darfst zwar mein Gerät kaufen, aber nur ich bin darauf der Superuser und bestimme, was gut für die Welt ist?

Damit bist du der einzige (!) Entwickler, den ich kenne, der bootstrap mit ordentlich ausgezeichnetem html verbindet.

Nicht vorschnell urteilen. Ordentliche Arbeit ist für mich kein Selbstzweck. Wenn für die Zielerreichung Dinge wie aria-Attribute nicht benötigt werden, dann lass ich die weg, auch wenn andere der Meinung, das gehöre zu "ordentlich" dazu. Auch verrenke ich mich beispielsweise nicht, um eine perfekt formatierte HTML-Ausgabe hinzubekommen. Hauptsache in meiner Entwicklungsumgebung kann ich damit leicht arbeiten. Im Browser ist sowieso der DOM-Explorer das Mittel der Wahl beim Untersuchen und nur ganz selten der nackte Code.

dedlfix.

[marctrix]

Hej dedlfix,

Es ist ja auch das Versprechen, schnell fertig zu werden, ohne css oder html lernen zu müssen. Und das reicht ja auch, um optisch einigermaßen ordentlich scheinende Seiten hinzustellen, die aber nur hübsche Datenhalden sind. Ich sehe auch keinerlei Bestrebungen seitens der Entwickler irgendwie dagegen zu steuern…

Dieses Versprechen, nichts lernen zu müssen, kann ich auf der Bootstrap-Webseite nicht finden.

Nein, die Bootstrap-Klassen muss man schon verstehen.

Ich für meinen Teil würde sagen, da kann man auch gleich CSS lernen. Ist auch hervorragend dokumentiert. 😉

Und was sollen die Entwickler denn anders machen? Sie sind nicht verantwortlich für das, was andere daraus machen. Wie sollen sie wirken? Nur zertifiziertes Zeug kommt in den Store

Store? Heißt die Referenzen-Seite so?

Oder haben wir uns missverstanden?

andere Anbieterplattformen werden mittels Anwenderbevormundung ausgesperrt, à la: du darfst zwar mein Gerät kaufen, aber nur ich bin darauf der Superuser und bestimme, was gut für die Welt ist?

Du meinst so wie Apple?

Es gibt schlechtere Ansätze. Aber jeder hat seine Vor- und Nachteile.

Ich sage es mal so: wenn ich ein Tool bereit stelle, dann würde ich gerne zeigen, was für tolle Sachen Leute damit entwickelt haben.

Was Bootstrap in seinem „darauf-bin-ich-stolz“-Kasten zeigt, finde ich nicht zum vorzeigen.

Aber es geht dabei ja nur „große“ Seiten zu zeigen, die toll aussehen, um nich mehr unbedarfte Anwender anzulocken. Kein Wunder, dass die es dann mi hz besser machen.

Das fatale: durch die hohe Verbreitung dieser schlechten Beispiele und die vielen Nachahmer macht man das web signifikant schlechter!

Damit bist du der einzige (!) Entwickler, den ich kenne, der bootstrap mit ordentlich ausgezeichnetem html verbindet.

Nicht vorschnell urteilen. Ordentliche Arbeit ist für mich kein Selbstzweck.

Wie könnte es? Gut strukturiertes HTML hat ganz konkrete praktische Vorteile.

Und ein sinnvolles Element zu nehmen, statt eines bedeutungslosen ist keine Zeitersparnis.

Wenn für die Zielerreichung Dinge wie aria-Attribute nicht benötigt werden, dann lass ich die weg, auch wenn andere der Meinung, das gehöre zu "ordentlich" dazu.

Wie können die für eine Zielerreichung unnötig sein? Muss nicht jede Website von jedem bedienbar sein?

Und wie arbeitest du denn? Für vieles habe ich fertige Codeschnipsel. Da wäre es aufwändiger die aria-Attribute rauszunehmen, statt sie drin zu lassen. Wenn man sich angewöhnt hat, barrierearm zu entwickeln, wäre es ein Mehraufwand Barrieren einzubauen.

Auch verrenke ich mich beispielsweise nicht, um eine perfekt formatierte HTML-Ausgabe hinzubekommen.

Ich schreibe ein main genau so entspannt wie ein div id=”main“.

Wo soll denn da der Aufwand sein?

Hauptsache in meiner Entwicklungsumgebung kann ich damit leicht arbeiten. Im Browser ist sowieso der DOM-Explorer das Mittel der Wahl beim Untersuchen und nur ganz selten der nackte Code.

?!?

Was das bedeuten soll, kann ich nicht verstehen. Das soll doch wohl nicht heißen, wenn du es bei der Arbeit bequem hast, ist das Ziel doch erreicht?!?

Marc

[Matthias Apsel]

Hallo marctrix,

Hauptsache in meiner Entwicklungsumgebung kann ich damit leicht arbeiten. Im Browser ist sowieso der DOM-Explorer das Mittel der Wahl beim Untersuchen und nur ganz selten der nackte Code.

?!?

Was das bedeuten soll, kann ich nicht verstehen.

Da ging es lediglich um die HTML-Code-Einrückung.

Bis demnächst
Matthias

[marctrix]

Hej Matthias,

Was das bedeuten soll, kann ich nicht verstehen.

Da ging es lediglich um die HTML-Code-Einrückung.

Danke! Das macht natürlich Sinn!

Was ich noch sagen wollte: als Programmierer solltest du für Frontend gar nicht zuständig sein, @dedlfix — Programmierung und Frontend ist imho zu viel Stoff, um da auf dem laufenden zu bleiben. Da kommt man ja vor lauter lernerei gar nicht zum arbeiten. Es sei denn man nutzt bootstrap… 😢

Marc

[dedlfix]

Tach!

als Programmierer solltest du für Frontend gar nicht zuständig sein, @dedlfix — Programmierung und Frontend ist imho zu viel Stoff, um da auf dem laufenden zu bleiben. Da kommt man ja vor lauter lernerei gar nicht zum arbeiten. Es sei denn man nutzt bootstrap… 😢

Man hat nicht immer die Wahl und eine Firma, die für alles hochentwickelte Spezialisten einstellen kann, trotzdem aber ein gewisses Portfolio braucht, um wachsen zu können und nicht nur in einer Nische festzustecken. Und ja, als Allrounder kann man nicht in alle Themen gleichmäßig tief eintauchen. Flexbox und Grid hab ich mir zum Beispiel noch nicht näher angeschaut. Bootstrap sein Dank.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Und ja, als Allrounder kann man nicht in alle Themen gleichmäßig tief eintauchen. Flexbox und Grid hab ich mir zum Beispiel noch nicht näher angeschaut.

Das wäre Frontend-Entwicklung.

Und jemand, der sich Flexbox und Grid noch nicht angeschaut hat, ist wohl keiner, der sich „Allrounder“ nennen dürfte.

Bootstrap sein Dank.

Das ist nicht Frontend-Entwicklung.

Man hat nicht immer die Wahl und eine Firma, die für alles hochentwickelte Spezialisten einstellen kann

Ein Frontend-Entwickler ist ein hochentwickelter Spezialist?

„Bootstrap sei Dank, müssen wir keinen Frontend-Entwickler einstellen.“
„Also keinen, der einen Blick für Usability, Barrierefreiheit, … UX hat?“
„Nö, das ist uns alles scheißegal!“

LLAP 🖖

[dedlfix]

Tach!

Und ja, als Allrounder kann man nicht in alle Themen gleichmäßig tief eintauchen. Flexbox und Grid hab ich mir zum Beispiel noch nicht näher angeschaut.

Das wäre Frontend-Entwicklung.

Und jemand, der sich Flexbox und Grid noch nicht angeschaut hat, ist wohl keiner, der sich „Allrounder“ nennen dürfte.

Also der Duden definiert das als "wendige, vielseitig interessierte männliche Person, die Kenntnisse und Fähigkeiten auf zahlreichen Gebieten besitzt und anwendet" - "vielseitig einsetzbares Gerät". Das steht nicht, dass man dabei perfekt in all den Themen sein muss, und nach dem mir bekannten Sprachgebrauch erwartet man auch keine allumfassende Perfektion von solch einer Person oder Gegenstand.

„Bootstrap sei Dank, müssen wir keinen Frontend-Entwickler einstellen.“
„Also keinen, der einen Blick für Usability, Barrierefreiheit, … UX hat?“
„Nö, das ist uns alles scheißegal!“

Schon wieder diese Unterstellungen. Langsam nervt es.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Und jemand, der sich Flexbox und Grid noch nicht angeschaut hat, ist wohl keiner, der sich „Allrounder“ nennen dürfte.

Also der Duden definiert das …

In dem Kontext irrelevant.

… als "wendige, vielseitig interessierte männliche Person

Was hat das Geschlecht damit zu tun, Allrounder zu sein oder nicht?

Im Kontext Webentwicklung ist ein Allrounder jemand, der sich auf allen Gebieten der Webentwicklung auskennt: Serverkonfiguration, Datenbanken, serverseitiger Programmierung (z.B. PHP), clientseitiger Programmierung (JavaScript), HTML, CSS, Barrierefreiheit, Performanz, Design, …

Es mag einige Genies geben, die das drauf haben. Bei den meisten wäre ich aber skeptisch: Die haben von allem ein bisschen Ahnung, aber von nichts richtig. Oder von ein oder zwei Gebieten davon richtig Ahnung, aber von den anderen doch zu wenig, um sich wirklich Allrounder nennen zu dürfen.

Problematisch wird’s, wenn Spezialisten als Allrounder eingesetzt werden und Gebiete abdecken sollen, von denen sie eigentlich wenig verstehen.

LLAP 🖖

[dedlfix]

Tach!

Wenn für die Zielerreichung Dinge wie aria-Attribute nicht benötigt werden, dann lass ich die weg, auch wenn andere der Meinung, das gehöre zu "ordentlich" dazu.

Wie können die für eine Zielerreichung unnötig sein? Muss nicht jede Website von jedem bedienbar sein?

Das ist es ja eben. Nicht jede Website muss von jedem bedienbar sein. Eine Website ist es nicht nur, wenn das Ding im Web steht, sondern auch wenn es Webtechniken verwendet, ansonsten aber im Intranet oder anderen privaten Räumen steht. Auch für (geschlossene) Nutzergruppen, bei denen Nicht-Sehende aufgrund des Themas nicht teilhaben können, benötigen die Websites keine Screenreader-Unterstützung.

Und wie arbeitest du denn? Für vieles habe ich fertige Codeschnipsel. Da wäre es aufwändiger die aria-Attribute rauszunehmen, statt sie drin zu lassen. Wenn man sich angewöhnt hat, barrierearm zu entwickeln, wäre es ein Mehraufwand Barrieren einzubauen.

Ohne aria, war bisher nicht nötig. Wenn ich Web-Frontends erstelle, dann für Anwendungen mit bekanntem und/oder überschaubarem Nutzerkreis. Websites der allgemeine Art oder für öffentliches Publikum erstelle ich nicht, abgesehen von Anpassungen an Fertiglösungen, wie Shop-Systeme.

Auch verrenke ich mich beispielsweise nicht, um eine perfekt formatierte HTML-Ausgabe hinzubekommen.

Ich schreibe ein main genau so entspannt wie ein div id=”main“.

Wo soll denn da der Aufwand sein?

Perfekt formatiert, nicht perfekt ausgezeichnet. Der Aufwand beginnt, wenn man die Seite serverseitig zusammenbaut und neben den Einrückungen für HTML noch Einrückungen für PHP oder andere Template-Sprachen hinzukommen, die man in der Ausgabe nicht mehr sieht, wohl aber die dadurch entstandenen Tabulator- oder Leerzeichensprünge. Oder wenn Teile der Seite in separaten Template-Dateien stecken, bei denen die IDE nicht weiß (wissen kann), in welcher Verschachtlungstiefe sie letztlich landen werden, dann sieht es in der fertigen Seite auch gehüpft und gesprungen aus. Soll es ruhig, sind eh nur funktionslose Whitespace, die lediglich für die Optik und die Übersicht beim Entwickeln eingefügt werden.

dedlfix.

[marctrix]

Hej dedlfix,

Das ist es ja eben. Nicht jede Website muss von jedem bedienbar sein. Eine Website ist es nicht nur, wenn das Ding im Web steht, sondern auch wenn es Webtechniken verwendet, ansonsten aber im Intranet oder anderen privaten Räumen steht. Auch für (geschlossene) Nutzergruppen, bei denen Nicht-Sehende aufgrund des Themas nicht teilhaben können, benötigen die Websites keine Screenreader-Unterstützung.

Da wir blinde Mitarbeiter haben, muss auch unser Intranet barrierefrei sein. Aber es gibt natürlich Firmen, die Blinde nicht beschäftigen. Das Dumme: sie werden es auch in Zukunft nicht, weil man ja so viel anpassen müsste — Pech wenn man blind ist.

Auch verrenke ich mich beispielsweise nicht, um eine perfekt formatierte HTML-Ausgabe hinzubekommen.

Ich schreibe ein main genau so entspannt wie ein div id=”main“.

Wo soll denn da der Aufwand sein?

Perfekt formatiert, nicht perfekt ausgezeichnet. Der Aufwand beginnt,…

Ja, das ist tatsächlich von zweifelhaftem Nutzen! Habe gehofft, dass ich nur nicht kapiert habe, was du meinst…

Marc

[dedlfix]

Tach!

Da wir blinde Mitarbeiter haben, muss auch unser Intranet barrierefrei sein. Aber es gibt natürlich Firmen, die Blinde nicht beschäftigen. Das Dumme: sie werden es auch in Zukunft nicht, weil man ja so viel anpassen müsste — Pech wenn man blind ist.

Dafür gäbe es ja das eine oder andere Fördermittel. Es liegt nicht immer nur am Willen, es gibt auch genügend Tätigkeitsfelder, da geht es nicht ohne Augenlicht.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Nutzergruppen, bei denen Nicht-Sehende aufgrund des Themas nicht teilhaben können

?? WAS??

Bei welchen Themen sollten Nicht-Sehende aufgrund des Themas nicht teilhaben können?

Übrigens gibt es nicht nur Sehende und Nicht-Sehende, sondern auch Schlecht-Sehende. Und mit zunehmendem Alter kommen wir alle dahin.

benötigen die Websites keine Screenreader-Unterstützung.

Auch das mag für dich neu und überraschend sein: Nicht nur Nicht-Sehende oder Schlecht-Sehende benutzen Screenreader, sondern auch Bestens-Sehende mit Leseschwäche.

Ich schreibe ein main genau so entspannt wie ein div id=”main“.

Wo soll denn da der Aufwand sein?

Der Aufwand beginnt, wenn man die Seite serverseitig zusammenbaut und neben den Einrückungen für HTML noch Einrückungen für PHP oder andere Template-Sprachen hinzukommen, die man in der Ausgabe nicht mehr sieht, wohl aber die dadurch entstandenen Tabulator- oder Leerzeichensprünge.

Verstehe ich das jetzt richtig? Du willst nicht die richtigen HTML-Elemente verwenden, weil dir deine IDE deinen Code nicht richtig formatiert?

Was hast du heute zu dir genommen?

LLAP 🖖

[dedlfix]

Tach!

Bei welchen Themen sollten Nicht-Sehende aufgrund des Themas nicht teilhaben können?

Zum Beispiel Ärzte, die Röntgen- und andere Bilder beurteilen sollen.

Übrigens gibt es nicht nur Sehende und Nicht-Sehende, sondern auch Schlecht-Sehende. Und mit zunehmendem Alter kommen wir alle dahin.

Ja, aber dann werden wir nicht mehr den Tätigkeiten nachgehen können, für die man gute Seefähigkeit braucht und ist dann auch nicht mehr Teil der Nutzergruppe.

benötigen die Websites keine Screenreader-Unterstützung.

Auch das mag für dich neu und überraschend sein: Nicht nur Nicht-Sehende oder Schlecht-Sehende benutzen Screenreader, sondern auch Bestens-Sehende mit Leseschwäche.

Die sind dann auch eher weniger in zum Beispiel oben genannter Nutzergruppe vertreten.

Verstehe ich das jetzt richtig? Du willst nicht die richtigen HTML-Elemente verwenden, weil dir deine IDE deinen Code nicht richtig formatiert?

Nein, das hast du nicht richtig verstanden.

Was hast du heute zu dir genommen?

Und das musste nun wirklich nicht sein.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

… Schlecht-Sehende. Und mit zunehmendem Alter kommen wir alle dahin.

Ja, aber dann werden wir nicht mehr den Tätigkeiten nachgehen können, für die man gute Seefähigkeit braucht

Das Erfassen des Inhalts einer Webseite gehört nicht zu den Tätigkeiten, für die man eine gute Sehfähigkeit^[1] brauchen sollte. Jetzt kannst du dir freilich wieder eine spezielle Nische aus den Fingern saugen …

Bestens-Sehende mit Leseschwäche.

Die sind dann auch eher weniger in zum Beispiel oben genannter Nutzergruppe vertreten.

Was genau hat Legastenie mit Intelligenz zu tun? Warum sollte ein Legasteniker nicht ein hervorragender Radiologe sein?

Verstehe ich das jetzt richtig? Du willst nicht die richtigen HTML-Elemente verwenden, weil dir deine IDE deinen Code nicht richtig formatiert?

Nein, das hast du nicht richtig verstanden.

Da bin ich aber froh. (Darüber, dass ich das falsch verstanden habe; nicht darüber, dass ich das dann gar nicht verstanden habe.)

Was hast du heute zu dir genommen?

Und das musste nun wirklich nicht sein.

Die Alternative, es nicht durch die Blume zu sagen, hätte dir noch weniger gefallen. 😈

LLAP 🖖

---

1. Seefähigkeit? Ist das die Fähigkeit, auf hoher See seinen Mageninhalt drinzubehalten? ↩︎

[dedlfix]

Tach!

Das Erfassen des Inhalts einer Webseite gehört nicht zu den Tätigkeiten, für die man eine gute Sehfähigkeit[^see] brauchen sollte. Jetzt kannst du dir freilich wieder eine spezielle Nische aus den Fingern saugen …

Das habe ich nicht nötig. Diese und andere Nischen existieren. Ich sagte bereits, dass es sich nicht um Webseiten für breites Publikum handelt, sondern um spezielle Anwendungen, die ich erstelle.

Du kannst auch ein Computerspiel nehmen, bei dem du mit dem Screenreader keinen Zentimeter weit kommst. Was nützt es dann, wenn du einen Kalkulator für dieses Spiel mit dem Screenreader bedienen kannst?

Was hast du heute zu dir genommen?

Und das musste nun wirklich nicht sein.

Die Alternative, es nicht durch die Blume zu sagen, hätte dir noch weniger gefallen. 😈

Mir hätte es gefallen, wenn wir uns auf fachlicher Ebene unterhalten würden, ohne dass du ins Persönliche abgleitest.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Schade, um die Antwort auf die eigentlich spannende Frage hast du dich gedrückt: Warum sollte ein Legasteniker nicht ein hervorragender Radiologe sein?

Was darauf hinausläuft: Warum sollte Textinhalt auf Webseiten für Radiologen nicht per Screenreader wiedergegeben werden können?

LLAP 🖖

[Henry]

Hallo Gunnar,

was mich mal bei dieser ganzen Diskussion(weil keine Erfahrungwerte) hier interessiert ist dies:

• Wie kamen Screenreader vor Aria mit Webseiten zurecht?

• Für wen ist die Semantik und immer neue Tags praktisch hilfreich?

• Welche Vorteile haben die neuen Tags (zb. main)?

Das ist jetzt nicht irgendwie provozierend oder ironisch gemeint, sondern interessiert mich echt, weil vieles nutzt man, weil andere es empfehlen aber leider auch oft ohne zu hinterfragen. Wäre mal schön zu wissen welche Erfahrungen echte Screenreader-Nutzer haben. Oder mal anders gefragt:

Wenn die genannten Punkte absolut zu beachten sind, warum hat das W3C dies nicht als Bedingung oder zumindest als Fehler deklariert, wenn man dagegen verstößt? Also wie eine Programmiersprache, die auch nicht weiter macht wenn irgendwas essentiell richtig sein muss. Weil, hier artet eine andere Ansicht ja oft schnell zur Hexenjagd aus.

Gruss
Henry

[Gunnar Bittersmann]

@@Henry

• Wie kamen Screenreader vor Aria mit Webseiten zurecht?

Wenn du mit Webseiten vor ARIA statische Webseiten meinst: bestens – bei vernünftigem Markup. Die erste Regel der Verwendung von ARIA besagt ja: Verwende kein ARIA, wenn es ein HTML-Element für diesen Zweck gibt.

ARIA wird verwendet:

• bei dynamischen Seiten (rich Internet applications), wo Seiteninhalte erscheinen und verschwinden (nachgeladene Inhalte, Akkordeons, Tabs, Statusmeldungen, modale Dialogfenster, …)

• bei bestehenden Webseiten, die kein vernünftiges Markup verwenden, bei denen aber die Änderung von HTML-Elementen nicht (mit vertretbarem Aufwand) möglich ist

• Für wen ist die Semantik und immer neue Tags praktisch hilfreich?

Für alle.

Für Nutzer assisiver Technologien sowieso …

• Welche Vorteile haben die neuen Tags (zb. main)?

… Screenreader-Nutzer können z.B. zum Hauptinhalt springen (wenn ihr Screenreader das anbietet).

Für alle Nutzer: Ein(e) Browser(erweiterung) könnte anbieten, bei time-Elementen eine einfache Übernahme eines Termins in den Kalender zu ermöglichen.

Für Autoren: Einfaches Styling für Elementtypen. Bspw. kein Zeilenumbruch in Datum/Uhrzeit:
time { white-space: nowrap }

Wenn die genannten Punkte absolut zu beachten sind, warum hat das W3C dies nicht als Bedingung oder zumindest als Fehler deklariert, wenn man dagegen verstößt?

Es gibt die Richtlinien für barrierefreie Webinhalte (WCAG) und unterstützende Dokumente.

LLAP 🖖

[Henry]

Hallo Gunnar,

danke für die Aufklärung.

… Screenreader-Nutzer können z.B. zum Hauptinhalt springen (wenn ihr Screenreader das anbietet).

Wobei das mit dem Hauptinhalt heute oft nicht mehr so einfach zu lokalisieren ist. Oft gibt es nicht den einen Hauptinhalt, sondern vieles, daher fände ich zb. <div class="maincontent"> sinnvoller. Hinzu kommt ja lazy-loading. Du stehst doch in Kontakt mit Marco Zehe, glaube ich zumindest, könntest du ihn nicht mal zu einem Artikel motivieren, was sich so in den Jahren verändert hat und wie groß der Nutzen von neuen Tags und Aria für ihn ist?

Für alle Nutzer: Ein(e) Browser(erweiterung) könnte anbieten, bei time-Elementen eine einfache Übernahme eines Termins in den Kalender zu ermöglichen.

Auch da, anstatt wieder ein neuer Tag, hätte da nicht ein Attribut bzw. neuesAttribut bsp. <span xtype="time" datetime="2003-04-14 21:00"> gereicht. Will damit sagen, zumindest programmiere ich so in zb. php, Mache den Kern so simple als möglich, Veränderungen und Ergänzungen möglichst modular, verändere nie den Kern, wo es nicht sein muss.

Für Autoren: Einfaches Styling für Elementtypen. Bspw. kein Zeilenumbruch in Datum/Uhrzeit:
time { white-space: nowrap }

Na ja, würde ja auch gehen: [type="time"]{white-space: nowrap ;} bzw. fiktiv [xtype="time"]

Es gibt die Richtlinien für barrierefreie Webinhalte (WCAG) und [unterstützende Dokumente]

Je eben, es sind Richtlinien, also Empfehlungen und keine Must-Do, wie es hier im Forum annonciert wird. Wenn die das genau so sehen würden, hätten die doch die Macht gehabt das zu erzwingen?

Gruss
Henry

[Gunnar Bittersmann]

@@Henry

Wobei das mit dem Hauptinhalt heute oft nicht mehr so einfach zu lokalisieren ist. Oft gibt es nicht den einen Hauptinhalt, sondern vieles,

Über die Seite zerstreut?

daher fände ich zb. <div class="maincontent"> sinnvoller.

<div class="maincontent">
	<p>Hauptsächlich wäre zu sagen, dass …</p>
	<a href="#main2">lesen Sie weiter</a>
</div>
<div class="bullshit">
	<p>Das hat mit der Sache überhaupt nichts zu tun.</p>
</div>
<div class="maincontent" id="main2">
	<p>Hach, da sind Sie ja wieder. Wo waren wir stehengeblieben?</p>
</div>

Inwiefern soll das sinnvoll sein?

Auch da, anstatt wieder ein neuer Tag, hätte da nicht ein Attribut bzw. neuesAttribut bsp. <span xtype="time" datetime="2003-04-14 21:00"> gereicht.

HTML5 ist eben den umgekehrten Weg gegangen und hat aus häufig verwendeten Attributwerten wie "header", "footer", "main(content)" usw. Elementtypen gemacht. Welchen Vorteil hätte es, nur einen Elementtypen zu verwenden und die Art des Elements in einem zusätzlichen Attribut anzugeben?

<div type="maincontent">
	<div type="heading">Die Hauptsache</div>
	<div type="paragraph">Hauptsächlich wäre zu sagen, dass …</div>
</div>

gegenüber

<main>
	<h1>Die Hauptsache</h1>
	<p>Hauptsächlich wäre zu sagen, dass …</p>
</main>

Ich sehe den Nachteil, dass der Quelltext mit lauter divs schlechter lesbar wäre. (s.a. dieses Posting ab „Das kann ich bestätigen.“)

Außerdem kann man für verschiedene Elementtypen Regeln angeben; bspw. main darf nicht in header vorkommen. Wie willst du das mit Attributen machen? div darf in div vorkommen; es sei denn, es handelt sich um eines mit einem type-Attribut mit dem Wert "maincontent", welches nicht in einem solchen mit einem type-Attribut mit dem Wert "header" vorkommen darf; oder es handelt sich um …

Da kommste in Teufels Küche. HTML ist jetzt schon überfrachtet mit solchen Wenn-dann-ansonsten-Regeln – was es früher nicht gab, als HTML noch über eine einfache DTD definiert wurde.

LLAP 🖖

[marctrix]

Hej Dieter,

Ich versuche mich in den Anfängen mit Bootstrap.

In der Hoffnung, dass du noch mitliest: aus der folgenden Frage entnehme ich, dass du in HTML auch noch einigermaßen am Anfang stehst.

Daher würde ich Dir nicht raten, Bootstrap zu nutzen. Das Problem: Bootstrap verspricht, dass du zu schnellen Ergebnissen kommst. Die Wahrheit ist aber, dass es Dir das Erlernen von HTML nicht abnimmt. Du musst Bootstrap (seine ganzen Klassen, was die tun und zu welchem Verhalten sie führen), also zusätzlich zu HTML lernen.

Das Problem mit Bootstrap ist nämnlich, dass es sich „nur“ um das Aussehen einer einer Webseite kümmert.

Das eigentliche Dokument, das in HTMl geschrieben wird, muss aber zunächst einmal ordentlich ausgezeichnet werden,. sonst erkauft man sich das hübsche Aussehen nur mit zahlreichen Nachteile. Ein paar davon sind: deine Seiten sind durch Automaten schlecht analysierbar, was unter anderem dazu führt, dass du bei Suchmaschinen so weit unten landest, dass niemand deine Seite imWeb findet, dass Deine Seite für manche Menschen unbedienbar und für alle anderen schlechter als nötig bedienbar sind.

Bootstrap macht Deine Seite auch langsamer, vor allem wenn du nach dem Prinzip arbeitest: „Ich weiß nicht, was ich davon wirklich brauche, also nehme ich erst mal alles.“

An Bootstrap scheiden sich die Geister und mit der neuesten Version kann man ganz ordentliche Seiten erstellen, aber: man muss dafür HTML und Botstrap recht gut kennen!

Ich würde erst mal mit HTML beginnen. Und CSS für das Layout. Alles was Bootstrap kann, kann man auch selber umsetzen. Das zu lernen (z.B. „wie gestalte ich einen Button“ oder „wie ordne ich Elemente auf meiner Seite an“) sind jeweils überschaubare „Päckchen“. Die zu lernen bekommt jeder hin.

Am Ende kannst du dich auch noch über eine selbst gemachte Seite freuen. Der Riesen-Vorteil bei dieser Art zu arbeiten: du weißt genau, was du getan hast und kannst Deine Seite später weiter anpassen. Man hat immer wieder neue Ideen — auch solche, die sich mit Bootstrap nicht oder nur umständlich umsetzen lassen.

Bootstrap hat eigentlich nur einen Vorteil: es spart Menschen, die beruflich Webseiten entwicklen, eine Menge Zeit, weil es immer wiederkehrende Routine-Aufgaben abnimmt.

Das ließe sich auch anders realisieren, aber das führt an dieser Stelle etwas zu weit…

Kann mir bitte jemand sagen für was ich die Bezeichner

for="inputName"

id="inputName"

verwende.

Damit sorgst du dafür, dass die Bezeichnung eines Formulareldes (label) und das Formularfeld selber logisch miteinander verbunden werden. Das ist für viele Dinge nötig. Wenn du das korrekt verwendet hast, kann man beispielsweise auf das label klicken und dadurch den Fokus in das Feld setzen. Besonders praktisch, wenn das Feld eine winzige Checkbox ist. Sicher hast du dich selber auch schon mal über Seiten geärgert, wo man nciht auf „Ich habe die AGBs gelesen und akzeptiert“ klicken kann, sondern statt dessen das winzige Kästchen daneben treffen muss.

Ein anderer toller Einsatzbereich sind Fehlermeldungen. Wenn du irgendwo auf einer Webseite eine Fehlermeldung ausgibst, kannst du diese in ein label mit for-Atrtribut packen. Wenn der Benutzer dann so etwas wie z.B. „Das Feld Nachname ist nicht korrekt ausgefüllt“ anklickt, landet er direkt im betreffenden Feld und kann seine Angaben sofort korrigieren. Das funktioniert weil die Fehlermeldung und das input logisch miteinander verknüpft sind und diese Verknüpfung kann von Software (z.B. der Browser) erkannt werden.

Oder kann ich dies vernachlässigen.

Wenn du das tust, funktionieren Deine Webseiten für viele Menschen deutlich schlechter und ist für andere gar nicht mehr bedienbar.

<div class="form-group">
    <label for="inputName" class="col-sm-2 control-label">Name</label>
    <div class="col-sm-10">
    	<input class="form-control" id="inputName" name="name" type="text" value="<?php echo htmlentities($user['name']); ?>" required>
    </div>
</div>

Bootstrap benötigt all die vielen div-elemente und klassen dafür, damit alle Möglichkeiten, die Bootstrap für die Positionierung von Beschriftung und Feld existieren auch angewendet werden können. Für ein konkretes Projekt sind (nicht immer, aber) meist viel weniger Elemente nötig.

Bootstrap macht deine Webseite unnötig kompliziert und aufgebläht. — Es sei denn, du schmeißt wirklich konsequent alles Überflüssige raus, was leider selten gemacht wird…

Marc

[Gunnar Bittersmann]

@@marctrix

Das Problem mit Bootstrap ist nämnlich, dass es sich „nur“ um das Aussehen einer einer Webseite kümmert.

Bei aller Abscheu, die ich gegenüber Bootstrap emfinde: nein, das stimmt so nicht.

Bootstrap kümmert sich auch um das Aussehen einer Webseite. Es bringt bspw. ein „Grid“-System mit sich (das in der aktuellen 4er Version auf Flexbox und unzähligen media queries basiert), welches heute niemand mehr braucht.

Bootstrap bringt aber auch Komponenten mit – und diese weitgehend barrierefrei (in der aktuellen 4er Version, von veraltetem Kram davor wollen wir nicht sprechen). Vermutlich besser, als es jemand ohne Kenntnisse von HTML und ARIA hinbekommen würde.

Bspw. ein Drop-Down-Menü, das auch tatsächlich halbwegs benutzbar zu sein scheint. Nur dass dort falsch <a href="#"> anstatt <button> verwendet wird.

Bootstrap hat eigentlich nur einen Vorteil: es spart Menschen, die beruflich Webseiten entwicklen, eine Menge Zeit, weil es immer wiederkehrende Routine-Aufgaben abnimmt.

Das kann ich ich überhaupt nicht bestätigen.

Im Gegenteil: Bootstrap macht Webentwicklung deutlich zeitaufwändiger, weil man vor lauter divs im Markup kaum noch Überblick hat und weil man sich um die ganzen präsentationsbezogenen Klassen im Markup kümmern muss, anstatt das Aussehen in ein paar Zeilen CSS anzugeben.

LLAP 🖖

[marctrix]

Hej Gunnar,

@@marctrix

Bootstrap bringt aber auch Komponenten mit – und diese weitgehend barrierefrei (in der aktuellen 4er Version, von veraltetem Kram davor wollen wir nicht sprechen). Vermutlich besser, als es jemand ohne Kenntnisse von HTML und ARIA hinbekommen würde.

Mit dieser Einschränkung stimmt es weitestgehend. Daher schrieb ich ja auch, man kann es zusätzlich zu HTML gerne lernen.

Muss man dann aber auch, statt einfach nur Beispiele voller divs zusammen zu kopieren.

Bootstrap hat eigentlich nur einen Vorteil: es spart Menschen, die beruflich Webseiten entwicklen, eine Menge Zeit, weil es immer wiederkehrende Routine-Aufgaben abnimmt.

Das kann ich ich überhaupt nicht bestätigen.

Das sagen die Befürworter mit denen ich zusammen arbeiten musste aber immer wieder: „Das gibt es doch schon fertig in Bootstrap. Musst du nur noch die Größe anpassen, die Farbe, die Schriftarten und die Rahmen. Dann machst du einfach noch Schatten dazu und die Abstände weg und schon bist du fertig.“ 😂

Das wird dann oft gemacht, indem eine projekt.css hinzugefügt wird, in der Bootstrap-Angaben überschrieben werden.

Dann kommt die Designerin mit einem andere Layout und man beginnt damit, mal eben schnell die eigenen CSS-Angaben wieder zu überschreiben. Wofür heißt es denn sonst Cascading Style Sheet 😂

Und im HTML weit und breit nur divs — selbst in Projekten wo das Geld für einen Menschen vorhanden sein müsste, der saubere Auszeichnung kann; Projekte mit hunderttausenden von Besuchern, die auf der Boostrap-Seite stolz als Referenzen präsentiert werden. Schade, dass da nirgends erwähnt wird, dass man Bootstrap so nicht verwenden sollte. Die ganzen präsentationsbezogenen Klassen würden ja (wenn man es schon übers Herz bringt, die zu verwenden) auch in sauber ausgezeichnetem HTML funktionieren…

Sagen wir mal so: es erspart es, sich mit den Details von CSS auseinader zu setzen…

Das scheint mir bei den Projekten, an denen ich mitgewirkt habe, jedenfalls die Triebfeder zu sein: man muss CSS weder beherrschen, noch sich um Neuerungen kümmern.

Dabei halte ich persönlich das natürlich für eine ungute Herangehensweise.

Langfristig kostet das sicher Zeit und für qualitativ sinnvoll erachte ich das auch nicht.

Dazu müsste man aber zwei Frontender beschäftigen (wegen der Vertretungsfunktion), würde dafür dann Ressourcen bei den Programmierern frei bekommen. Ab 10 bis 12 Entwicklern sicher sinnvoll (ein Frontender auf 5-6 Programmierer). Sieht aber kein Agentur-Inhaber so…

Ist schon eine verrückte Welt… 😀

Im Gegenteil: Bootstrap macht Webentwicklung deutlich zeitaufwändiger, weil man vor lauter divs im Markup kaum noch Überblick hat und weil man sich um die ganzen präsentationsbezogenen Klassen im Markup kümmern muss, anstatt das Aussehen in ein paar Zeilen CSS anzugeben.

Wenn man CSS beherrscht, stimmt das… 😉

Daher riet ich ja auch von Anfang dazu, nicht immer gleich „alles“ können zu wollen, sondern die Lern-Häppchen in appetitlichen Brocken zu servieren: Buttons, ein erstes, konkretes Seitenlayout, usw…

Marc

[Gunnar Bittersmann]

@@marctrix

Das sagen die Befürworter mit denen ich zusammen arbeiten musste aber immer wieder: „Das gibt es doch schon fertig in Bootstrap. Musst du nur noch die Größe anpassen, die Farbe, die Schriftarten und die Rahmen. Dann machst du einfach noch Schatten dazu und die Abstände weg und schon bist du fertig.“ 😂

Ach du S… 💩

Design ist keine Fassade. Design is not veneer.

LLAP 🖖

[Henry]

Hallo Gunnar,

Design ist keine Fassade.

doch ist es. Sieht man auch in anderen Bereichen. Mode zum Beispiel, oft nicht funktionell, Aussehen ist alles, leider. Bei Webseiten sehe ich das aber anders. Für mich persönlich ist das auch immer eine Art Kunst, ähnlich einem Gemälde und so ist mir das Aussehen genau so wichtig(viell. sogar wichtiger) als der Inhalt. Aber du als US-Fan (glaube ich zumindest) kennst ja von dort noch ganz andere Beispiele aus allen Bereichen, denn dort ist Show alles, tolle Häuser von weitem von nahem Kulissenqualität, schöne alte Autos (Qualität/Detailliebe mangelhaft), mag ich trotzdem. Bin aber kein Ami-Kritiker, ich mag die.

Tja, und was Bootstrap betrifft, sind wir eh einer Meinung. Aber darüber hatte ich mich ja schon mal ausgelassen. Weiß auch nicht was ich von einem Produkt halten soll, dass sich nach außen hin als opensource-typ gibt, aber nur kostenpflichtige Templates bereitstellt, obwohl es ja auch genügend kostenlose im Netz gibt. Da finde ich den Ansatz von bspw. WP in dieser Hinsicht glaubwürdiger. Ja, und was Mark Ottos Motivation betrifft, hmmm… weiß nicht er schreibt für alistapart, da müsste er eigentlich wissen wie perfekte Harmonie von Inhalt und Design mit minimalem Code aussehen sollte.

Gruss
Henry

[Gunnar Bittersmann]

@@Henry

Design ist keine Fassade.

doch ist es.

Nein.

Mode zum Beispiel, oft nicht funktionell, Aussehen ist alles, leider.

Auf dem Laufsteg, vielleicht. Ansonsten haben Kleidungsstücke jeweils einen Zweck und werden für diesen Zweck designt.

Es gibt kein Design ohne Zweck; ansonst ist es – wie Aral Balkan immer sagt – Dekoration. Jemand, der irgendwas ohne Zweck „hübsch macht“, ist kein Designer, sondern Künstler, Dekorateur.

Bei Webseiten sehe ich das aber anders. Für mich persönlich ist das auch immer eine Art Kunst, ähnlich einem Gemälde

Design ist nicht Kunst.

und so ist mir das Aussehen genau so wichtig(viell. sogar wichtiger) als der Inhalt.

Das Aussehen transportiert den Inhalt; auch das gehört zu Design dazu.

Beim Design kommt es aber weniger drauf an, ob ein Button nun blau oder türkis ist, sondern vielmehr, ob der Button überhaupt da sein muss.

LLAP 🖖

[Henry]

Hallo Gunnar,

Auf dem Laufsteg, vielleicht. Ansonsten haben Kleidungsstücke jeweils einen Zweck und werden für diesen Zweck designt.

Glaubst du das wirklich? Wir reden jetzt hier nicht von speziellen Outdoor-Klamotten, sondern von Alltagskleidung und ist die Funktionalität fast immer dem aktuellen Modegeschmack untergeordnet. Beobachte mal, wie oft Frauen (in den letzten Jahren auch immer mehr Männer) sich den Arsch abfrierern, aber dennoch die Kleidung nicht wechseln wollen, weil ist ja schick so, dieses Halbjäckchen, was sie gerade an hat. Na ja, und von Mode der 70er(schlaghosen, etc. brauch ich gar nicht anzufangen).

Aber um das mal ganz klar zu sagen, wenn deine Aussage stimmen würde, gäbe es keine hochhackigen Schuhe, oder siehst du darin auch Zweck? Vermutlich tust du das, denn jetzt wirst du antworten wollen, es gibt ja den speziellen Zweck, Männer für den Anblick zu begeistern… (Was ich übrigens gottseidank nicht teile, für mich nur eine Modererscheinung, die allerdings schon viel zu lange anhält). Kurzum, mit Zweck meine ich allerdings einen echten Nutzen/Zweck wie Tragekomfort, Schutz, Wärme, usw…, und der ist oft nicht gegeben.

Es gibt kein Design ohne Zweck; ansonst ist es – wie Aral Balkan immer sagt – Dekoration. Jemand, der irgendwas ohne Zweck „hübsch macht“, ist kein Designer, sondern Künstler, Dekorateur.

Ja und? Gute Webdesigner kann man oft m.M.n. gerechtfertigterweise als Künstler bezeichnen, als zb. drei Farben auf einer Leinwand.

Der folgende Screenshot bringt mich zu einer anderen Frage, darf man so was einfach publizieren? Falls nicht, bitte wieder löschen.

Design ist nicht Kunst.

Darüber streiten die Gelehrten noch, genauso über den begriff Kunst allgemein. Ich mache es mir da einfach und unterscheide erst mal gar nicht und bilde mir eine (lediglich) persönliche Meinung nach Abschluss der Arbeit.

Beim Design kommt es aber weniger drauf an, ob ein Button nun blau oder türkis ist, sondern vielmehr, ob der Button überhaupt da sein muss.

Sag das mal einem Modedesigner wie Lagerfeld 😉

Gruss
Henry

[beatovich]

hallo

Die Frage ist, ist Design eine Fassade?

Wenn Design auch das bezeichnet, was für unsere Sinne unmittelbar erfahrbar ist, so bezeichnet Design auch die nur mittelbaren Eigenschaften.

Aber eins kann man über Design gewiss sagen: Es ist kein Zufallsprodukt sondern widerspiegelt im Optimalfall gewollte und gut informierte Entscheidungen. Und bereffs Webdesign ist gemeint, dass man seine Designentscheidungen auf der Basis wie der offensichtlichen wie auch der eher verborgenenen Eigenschaften fälle.

Ob jemand mit diesen Entscheidungen nicht einverstanden ist, ist eine andere Frage.

[Henry]

Hallo beatovich,

Und bereffs Webdesign ist gemeint, dass man seine Designentscheidungen auf der Basis wie der offensichtlichen wie auch der eher verborgenenen Eigenschaften fälle.

Im Grunde bestimmt das anvisierte Ziel den Ansatz. Design fürs Marketing bzw. kommerziellen Nutzen, lässt dem "Künstler" relativ wenig Spielraum, weil dort psychologische Aspekte primär abzuhandeln sind (und btw. @Gunnar gerade da ist sogar oft die Farbe des Buttons sehr wichtig. *behaupten zumindest Medienpsychologen), während rein privates bzw. künstlerisches Design alle Freiheiten genießt.

Gruss
Henry

[beatovich]

hallo

Im Grunde bestimmt das anvisierte Ziel den Ansatz. Design fürs Marketing bzw. kommerziellen Nutzen, lässt dem "Künstler" relativ wenig Spielraum, weil dort psychologische Aspekte primär abzuhandeln sind (und btw. @Gunnar gerade da ist sogar oft die Farbe des Buttons sehr wichtig. *behaupten zumindest Medienpsychologen), während rein privates bzw. künstlerisches Design alle Freiheiten genießt.

Ein Künstler ist ein Gestaltforscher, sein Werk ein Experiment. Natürlich will man sich in bestimmten Situationen nicht auf Experimente verlassen.

[Henry]

Hallo beatovich,

Ein Künstler ist ein Gestaltforscher, sein Werk ein Experiment. Natürlich will man sich in bestimmten Situationen nicht auf Experimente verlassen.

Wenn der Begriff denn so einfach zu definieren wäre. Nicht nur, dass es nahezu unbegrenzte Ansichten dazu gibt, diese ändern sich auch noch im Lauf der Zeitgeschichte.

https://de.wikipedia.org/wiki/Kunst

Gruss
Henry

[beatovich]

hallo

Wenn der Begriff denn so einfach zu definieren wäre. Nicht nur, dass es nahezu unbegrenzte Ansichten dazu gibt, diese ändern sich auch noch im Lauf der Zeitgeschichte.

Wenn Begriffe (für dich) zu schwierig sind, dann solltest du sie gar nicht erst in eine Diskussion argumentativ einführen. Das war ein Kunstschuss in den Fuss.

[Henry]

Hallo beatovich,

Wenn Begriffe (für dich) zu schwierig sind.…

ziemlich überheblich.

Das war ein Kunstschuss in den Fuss.

wohl eher für dich. Sehr anmaßend von dir deine, von irgendwoher zitierte, Definition als allgemeingültig festzulegen.

Gruss
Henry

[marctrix]

Hej Gunnar,

@@marctrix

Das Problem mit Bootstrap ist nämnlich, dass es sich „nur“ um das Aussehen einer einer Webseite kümmert.

Bei aller Abscheu, die ich gegenüber Bootstrap emfinde: nein, das stimmt so nicht.

Ja, es müsste ungefähr so heißen:

Das Problem mit Bootstrap ist nämlich, dass es sich „nur“ um das Aussehen und Verhalten einer einer Webseite kümmert.

Was eich eigentlich sagen wollte: nicht um die semantisch korrekte Strukturierung.

Es ging mir letztendlich um die sepraration of concerns. Es käme mir aber albern vor, diesen Begriff in einem Atemzug mit Bootstrap namentlich zu erwähnen… 😂

Marc