nicht angemeldet
Camping_RIDER
Rolf B
Matthias Scharwies
Camping_RIDER
Matthias Apsel
Gunnar Bittersmann
Gunnar Bittersmann
Rolf B
Gunnar Bittersmann
Matthias Scharwies
Aloha ;)
Wie ich sehe, hast du das, was wir in Dortmund diskutiert haben, dort mittels custom-Element für die lines und - tatsächlich - <br/> gelöst. Gefällt mir!
Grüße,
RIDER
Hallo Camping_RIDER,
sehr enigmatisch. Könntest Du einen Nichtteilnehmer kurz abholen? Was ist das Problem, was soll durch das (nicht weiter deklarierte) Custom Element erreicht werden und wie wirkt es sich im Codepen aus? Ich sehe nämlich keinen Unterschied, wenn ich die x-l entferne.
Rolf
Servus!
Hallo Camping_RIDER,
sehr enigmatisch. Könntest Du einen Nichtteilnehmer kurz abholen? Was ist das Problem,
Texte sollen mit HTML ja semantisch ausgezeichnet werden. Deshalb sollten anstelle von br ja eigentlich nur neue p-Absätze ausgezeichnet und nicht mit <br/><br/>formatiert werden.
Der einzige Anwendungsfall für br sind Gedichte und Adressen, wobei bei den Gedichten ja eigentlich ein line-Element, wie es wohl in XHTML2 vorgesehen war (die hatten auch ein nl (navigation list) anmstelle von nav vor), semantischer wäre.
Was soll durch das (nicht weiter deklarierte) Custom Element erreicht werden und wie wirkt es sich im Codepen aus? Ich sehe nämlich keinen Unterschied, wenn ich die x-l entferne.
Problem: Bei Screenreadern wird der Zeilenumbruch im Gedicht mitgelesen. 😟
Rolf
Herzliche Grüße
Matthias Scharwies
Aloha ;)
Könntest Du einen Nichtteilnehmer kurz abholen?
Gerne. Es ging im Rahmen des Barrierefreiheit-Workshops darum, wann und wie br semantisch verwendet werden kann und nicht zu Präsentationszwecken, da br ein Element mit schwer einsichtiger Semantik ist (siehe auch der diesbezügliche Wikiartikel).
Wir haben uns dann über die Anwendungsfälle von br unterhalten, konkret die Trennung von Zeilen in Gedichten, Liedern oder Adressangaben. Hier stand dann im Raum, ob es überhaupt sinnvoll ist, die Trennung zwischen den Zeilen auszuzeichnen (br) oder ob nicht sinnvollerweise die Zeilen ausgezeichnet werden (span) um die Zusammengehörigkeit zu markieren.
Gunnar hatte als Argument angeführt, dass man letzteres oft sowieso machen müsse, da man im ersteren Fall keine Handhabe hat, um die Zeilen zu stylen - und der Zeilenumbruch kann ja via css erzwungen werden. Damit wäre die Verwendung von br an der Stelle sinnlos und weniger mächtig als die Alternative, was die Sinnhaftigkeit von br damit wieder infrage stellt.
Mein Argument war dann letztlich im Zwiegespräch mit Gunnar, dass ich es eigtl. notwendig finde, beides zu machen, also die Zeilen und die Trennung auszuzeichnen, da die Semantik von span zwar eine Zusammengehörigkeit der darinliegenden Inhalte, aber keine Trennung zum umliegenden Inhalt beinhaltet. Daher ist es aus meiner Warte semantisch notwendig beides zu tun: die Zeilen als zusammengehörig auszuzeichnen und mit br eine Zäsur zwischen den Zeilen zu kennzeichnen.
Nun hat Gunnar das im verlinkten Beispiel so gelöst wie ich vorgeschlagen hatte, allerdings mit custom-Element statt span, was ich an der Stelle für einen semantischen Vorteil halte, da einem custom-Element die Nicht-Trennung zum umgebenden Inhalt nicht so anhaftet wie einem span.
Deshalb mein Lob für die semantische Auszeichnung, weil ich sie für sehr gelungen halte.
Grüße,
RIDER
Hallo Camping_RIDER,
Mein Argument war dann letztlich im Zwiegespräch mit Gunnar, dass ich es eigtl. notwendig finde, beides zu machen, also die Zeilen und die Trennung auszuzeichnen, da die Semantik von span zwar eine Zusammengehörigkeit der darinliegenden Inhalte, aber keine Trennung zum umliegenden Inhalt beinhaltet.
… wie man es bei der Verwendung von hr ja auch macht.
Bis demnächst
Matthias
Hallo Matthias Apsel,
Mein Argument war dann letztlich im Zwiegespräch mit Gunnar, dass ich es eigtl. notwendig finde, beides zu machen, also die Zeilen und die Trennung auszuzeichnen, da die Semantik von span zwar eine Zusammengehörigkeit der darinliegenden Inhalte, aber keine Trennung zum umliegenden Inhalt beinhaltet.
… wie man es bei der Verwendung von
hrja auch macht.
alt: Das br-Element (break, englisch für Umbruch) repräsentiert einen Zeilenumbruch.
neu: Das br-Element (break, englisch für Umbruch) repräsentiert einen logischen Bruch innerhalb eines Textes. Visuell wird ein Zeilenumbruch dargestellt.
Meinungen?
Bis demnächst
Matthias
Aloha 😉
alt: Das br-Element (break, englisch für Umbruch) repräsentiert einen Zeilenumbruch.
neu: Das br-Element (break, englisch für Umbruch) repräsentiert einen logischen Bruch innerhalb eines Textes. Visuell wird ein Zeilenumbruch dargestellt.
Meinungen?
Vielleicht: „Visuell wird standardmäßig ein Zeilenumbruch dargestellt.“?
Grüße,
RIDER
Hallo Camping_RIDER,
Vielleicht: „Visuell wird standardmäßig ein Zeilenumbruch dargestellt.“?
Das br-Element (break, englisch für Unterbrechung) repräsentiert einen logischen Bruch innerhalb eines Textes. Visuell wird standardmäßig ein Zeilenumbruch gesetzt.
Damit ist auch dieses präsentationsbezogene Element semantisch umgewidmet. Wir sollten das dem W3C vorschlagen.
Im Wiki stehtstand: Das <br>-Element wird in den Browsern standardmäßig als Zeilenumbruch dargestellt, kann aber auch anders, z.B. als horizontaler Abstand, dargestellt werden.
Mit br { display: none } erreicht man, dass die Zeilen nicht umbrochen werden, aber den horizontalen Abstand habe ich auf die Schnelle ohne zusätzliche line-Elemente nicht erreichen können.
Bis demnächst
Matthias
Aloha ;)
Mit
br { display: none }erreicht man, dass die Zeilen nicht umbrochen werden, aber den horizontalen Abstand habe ich auf die Schnelle ohne zusätzliche line-Elemente nicht erreichen können.
Hm, da muss ich mal basteln. Gehen sollte es, denn das Beispiel stammt nicht von mir sondern aus der Spec.
Grüße,
RIDER
Hallo Camping_RIDER,
Hm, da muss ich mal basteln. Gehen sollte es, denn das Beispiel stammt nicht von mir sondern aus der Spec.
While line breaks are usually represented in visual media by physically moving subsequent text to a new line, a style sheet or user agent would be equally justified in causing line breaks to be rendered in a different manner, for instance as green dots, or as extra spacing. (https://www.w3.org/TR/html5/textlevel-semantics.html#the-br-element)
Ich lese das als „es wäre genauso gerechtfertigt, die Zeilenumbrüche als grüne Punkte darzustellen.“ Dass dies nur mit dem br-Element gehen würde, steht da nicht.
Bis demnächst
Matthias
Aloha ;)
Ich lese das als „es wäre genauso gerechtfertigt, die Zeilenumbrüche als grüne Punkte darzustellen.“ Dass dies nur mit dem br-Element gehen würde, steht da nicht.
Richtig. Das hatte ich an der Stelle fehlinterpretiert.
Grüße,
RIDER
Aloha ;)
Mit
br { display: none }erreicht man, dass die Zeilen nicht umbrochen werden, aber den horizontalen Abstand habe ich auf die Schnelle ohne zusätzliche line-Elemente nicht erreichen können.
Nach einigem Testen muss ich dir Recht geben. Mein Browser ignoriert jegliche Angabe, die ich mache - außer br { display: none }.
Mit zusätzlichen line-Elementen lässt sich allerdings etwas erreichen, so kann man die br-Elemente via css ausblenden lassen (und dadurch den Zeilenumbruch vermeiden) und alle line-Elemente, die auf ein br folgen entsprechend gestalten. Damit greift man br dann ja doch wieder auf und erreicht somit das selbe, wie wenn es möglich wäre, br selbst darzustellen.
Vielleicht wäre es demnach gut, im br-Artikel die Empfehlung auszusprechen, immer sowohl die Zäsur (br) als auch den solchermaßen getrennten Inhalt (x-line) auszuzeichnen.
Grüße,
RIDER
Aloha ;)
Vielleicht wäre es demnach gut, im br-Artikel die Empfehlung auszusprechen, immer sowohl die Zäsur (br) als auch den solchermaßen getrennten Inhalt (x-line) auszuzeichnen.
Die schönste Lösung wäre eigentlich, wenn uns die HTML-Spec entsprechende line-Elemente gäbe, die auch eine entsprechende semantische Bedeutung haben. Dann könnte man dafür auch gut und gerne br (genauso wie hr?) abschaffen.
Grüße,
RIDER
Aloha ;)
Mit zusätzlichen line-Elementen lässt sich allerdings etwas erreichen, so kann man die br-Elemente via css ausblenden lassen (und dadurch den Zeilenumbruch vermeiden) und alle line-Elemente, die auf ein br folgen entsprechend gestalten. Damit greift man br dann ja doch wieder auf und erreicht somit das selbe, wie wenn es möglich wäre, br selbst darzustellen.
Das dämliche daran ist: Dann hat man dem Ganzen zwar semantisch Genüge getan, aber da Screenreader ja mit display:none; ausgezeichneten Content ignorieren hat man damit die nicht-sehenden wieder von der Information ausgeschlossen, dass da eine inhaltliche Zäsur vorliegt. Ätzend!
Grüße,
RIDER
@@Camping_RIDER
Das dämliche daran ist: Dann hat man dem Ganzen zwar semantisch Genüge getan, aber da Screenreader ja mit
display:none;ausgezeichneten Content ignorieren hat man damit die nicht-sehenden wieder von der Information ausgeschlossen, dass da eine inhaltliche Zäsur vorliegt. Ätzend!
Dann musst du es nur richtig™ machen: visuell verstecken. So wie gestern früh schon.
LLAP 🖖
Aloha ;)
Dann musst du es nur richtig™ machen: visuell verstecken. So wie gestern früh schon.
Leider nein! Versuch das mal. br ignoriert die Angaben einfach.
Grüße,
RIDER
@@Camping_RIDER
Leider nein! Versuch das mal.
brignoriert die Angaben einfach.
Ich bin dem Irrtum aufgesessen, Firefox wäre das Maß aller Dinge‽ 😉
LLAP 🖖
Aloha ;)
Nach einigem Testen muss ich dir Recht geben. Mein Browser ignoriert jegliche Angabe, die ich mache - außer
br { display: none }.
Nach ein wenig Recherche bin ich auf den Kniff gestoßen, content zu verwenden - und siehe da, es geht doch!
Leider nur mit Webkit.
Grüße,
RIDER
@@Camping_RIDER
Nach ein wenig Recherche bin ich auf den Kniff gestoßen,
contentzu verwenden - und siehe da, es geht doch!
Du bist dem Irrtum aufgesessen, WebKits wären das Maß aller Dinge‽ 😉
LLAP 🖖
Aloha ;)
Du bist dem Irrtum aufgesessen, WebKits wären das Maß aller Dinge‽ 😉
Ich sehe, wir haben eine Gemeinsamkeit 😉
Ich hatte es auch schon gemerkt und reineditiert 😂
Man könnte jetzt allerdings aus dem visuellen Verstecken für Firefox und dem content-Kniff für Webkits eine "browserübergreifend" funktionierende Maßnahme zusammenstellen - oder nicht?
Grüße,
RIDER
@@Camping_RIDER
Man könnte jetzt allerdings aus dem visuellen Verstecken für Firefox und dem content-Kniff für Webkits eine "browserübergreifend" funktionierende Maßnahme zusammenstellen - oder nicht?
Hab ich im Pen mal so gemacht.
LLAP 🖖
Hallo Camping_RIDER,
Nach ein wenig Recherche bin ich auf den Kniff gestoßen,
contentzu verwenden - und siehe da, es geht doch!Leider nur mit Webkit.
Die Verwendung von content für br-Elemente sieht mir nach einem Bug aus.
Bis demnächst
Matthias
Aloha ;)
Die Verwendung von
contentfürbr-Elemente sieht mir nach einem Bug aus.
Naja. Ja. Aber der Umstand, dass sich die Webkits weigern, die br-Elemente via position aus ihrem Kontext zu reißen und damit den Effekt des Zeilenumbruchs zu negieren ist mMn auch als Bug zu sehen.
Demnach also ein Bug, der einen Bug fixt. Oder?
Grüße,
RIDER
Hallo Camping_RIDER,
Naja. Ja. Aber der Umstand, dass sich die Webkits weigern, die br-Elemente via
positionaus ihrem Kontext zu reißen und damit den Effekt des Zeilenumbruchs zu negieren ist mMn auch als Bug zu sehen.Demnach also ein Bug, der einen Bug fixt. Oder?
Im FF geht auch float. Im IE oder Edge funktioniert keiner der Tricks.
Bis demnächst
Matthias
@@Matthias Apsel
Die Verwendung von
contentfürbr-Elemente sieht mir nach einem Bug aus.
Sag das den Webkit-Entwicklern.
br { content: none } stellt ja nur den Zustand wieder her, der für ein leeres Element zu erwarten ist.
LLAP 🖖
Hallo Gunnar Bittersmann,
br { content: none }stellt ja nur den Zustand wieder her, der für ein leeres Element zu erwarten ist.
br { content: none } tut es ja nicht. Der Wert muss verschieden von none sein.
Bis demnächst
Matthias
@@Matthias Apsel
br { content: none }stellt ja nur den Zustand wieder her, der für ein leeres Element zu erwarten ist.
br { content: none }tut es ja nicht. Der Wert muss verschieden vonnonesein.
Oops, da hab ich ja doppelt geirrt. Ich dachte, none sei der Defaultwert für content. Ist es nicht, normal ist es.
Aber auch br { content: normal } tut es nicht; es muss ein Leerstring sein.
LLAP 🖖
Hallo Gunnar Bittersmann,
Aber auch
br { content: normal }tut es nicht; es muss ein Leerstring sein.
Es kann irgendein String sein.
Bis demnächst
Matthias
hallo
neu: Das br-Element (break, englisch für Umbruch) repräsentiert einen logischen Bruch innerhalb eines Textes. Visuell wird ein Zeilenumbruch dargestellt.
logisch ist ziemlich nichtssagend.
Hallo beatovich,
logisch ist ziemlich nichtssagend.
Vorschläge?
Bis demnächst
Matthias
hallo
Hallo beatovich,
logisch ist ziemlich nichtssagend.
Vorschläge?
Das br Element repräsentiert einen Zeilen-Umbruch im phrasing content.
Hallo beatovich,
Das br Element repräsentiert einen Zeilen-Umbruch im phrasing content.
Der präsentationsbezoge Aspekt soll ja grade in den Hintergrund gedrängt werden. Die Frage ist doch, warum ein fester Zeilenumbruch gesetzt werden soll.
Bis demnächst
Matthias
hallo
Hallo beatovich,
Das br Element repräsentiert einen Zeilen-Umbruch im phrasing content.
Der präsentationsbezoge Aspekt soll ja grade in den Hintergrund gedrängt werden. Die Frage ist doch, warum ein fester Zeilenumbruch gesetzt werden soll.
Weil du sonst das Web brechen würdest.
@@Camping_RIDER
Nun hat Gunnar das im verlinkten Beispiel so gelöst wie ich vorgeschlagen hatte, allerdings mit custom-Element statt span, was ich an der Stelle für einen semantischen Vorteil halte, da einem custom-Element die Nicht-Trennung zum umgebenden Inhalt nicht so anhaftet wie einem span.
?? Ein custom element hat per se dieselbe Semantik wie ein span oder div – nämlich gar keine. Jedenfalls für eine Maschine (Browser); für menschliche Code-Leser mag x-l aussagekräftiger sein als span (wobei es dann vielleicht besser x-line heißen sollte).
Ein Grund für das custom element ist Faulheit: <x-l> ist kürzer als <span class="line">. Was auch der Lesbarkeit des Codes zugutekommt.
Ein anderer Grund ist, dass AFAIK Google die Häufigkeit der Verwendung von Elementtypen (also auch von custom elements) trackt und damit Zahlen in der Hand hat, die für eine mögliche Einführung neuer Elementtypen in den HTML-Standard sprechen könnten. Vielleicht kommt ja doch noch in HTML irgendwann ein l-Element wie es in XHTML 2 vorgesehen war.
LLAP 🖖
@@Rolf B
Was ist das Problem, was soll durch das (nicht weiter deklarierte) Custom Element erreicht werden und wie wirkt es sich im Codepen aus?
In jenem Pen gar nicht; ich hatte das bewusst rausgehalten, um nicht vom eigentlichen Thema abzulenken.
Ich habe jenen Pen mal geforkt und erweitert, damit das Problem sichtbar wird:
Es gibt zweierlei Zeilenumbrüche: die vom Gedicht/Lied/… vorgegebenen und die durch beschränkte Breite auftretenden. Zur Unterscheidung soll bei ersteren die nächste Zeile wieder vorne beginnen, bei zweiteren die nächste Zeile eingerückt werden.
Die Einrückung kriegt man ohne Element für die Zeilen nicht hin. (Mir jedenfalls war es nicht geglückt.)
LLAP 🖖
Hallo Gunnar,
Die Einrückung kriegt man ohne Element für die Zeilen nicht hin. (Mir jedenfalls war es nicht geglückt.)
Ist in der Mache...
https://drafts.csswg.org/css-text-3/#valdef-text-indent-each-line
p.poem {
white-space: pre-wrap;
padding-left: 3em;
text-indent: -2em each-line;
}
Rolf
@@Rolf B
Ist in der Mache...
https://drafts.csswg.org/css-text-3/#valdef-text-indent-each-line
Ah, danke, kannte ich noch nicht.
Dumm nur, dass das noch kein Browser unterstützt (außer Chrome eines experimentierfreudigen Besitzers).
p.poem { white-space: pre-wrap; padding-left: 3em; text-indent: -2em each-line; }
Nö, dann nicht mit padding und negativem text-indent, sondern positivem ergänzt um das Schlüsselwort hanging.
p.poem
{
white-space: pre-wrap;
text-indent: 2em hanging each-line;
}
☞ Beispiel (in Chrome; Experimental Web Platform features flag setzen)
LLAP 🖖
Hallo Gunnar,
hm, da habe ich wohl vor einem Jahr mal das Experimentierflag gesetzt und dann vergessen...
hanging - ja klar patsch
Rolf
@@Camping_RIDER
Wie ich sehe, hast du das, was wir in Dortmund diskutiert haben, dort mittels custom-Element für die lines und - tatsächlich -
<br/>gelöst. Gefällt mir!
Ja. Ich muss es nur noch auf meinen eigenen Seiten so machen. Da gibt’s auch noch mehr zu tun: das Menü gehört im HTML nach oben – mit Skip-Link.
Und Georgia Pro als Webfont einbinden. Aber woher nehmen, wenn nicht stehlen?
LLAP 🖖
Servus!
Aloha ;)
Wie ich sehe, hast du das, was wir in Dortmund diskutiert haben, dort mittels custom-Element für die lines und - tatsächlich -
<br/>gelöst. Gefällt mir!
@@Gunnar Bittersmann
custom elements werden in der nächsten Version des Firefox (FF63, die wohl in 4-6 Wochen kommt) endlich unterstützt. (→ caniuse)
Bis jetzt haben wir nur etwas von 1UnitedPower im Blog: Web Components – eine Einführung vom Dezember 2014.
Hättest du Lust einen neuen Blog-Beitrag zu schreiben?
Herzliche Grüße
Matthias Scharwies
@@Matthias Scharwies
custom elements […]
Hättest du Lust einen neuen Blog-Beitrag zu schreiben?
Ja, ich hab noch den einen oder anderen auf dem Schirm. Aber nicht darüber.
LLAP 🖖
Servus!
@@Matthias Scharwies
custom elements […]
Hättest du Lust einen neuen Blog-Beitrag zu schreiben?
Ja, ich hab noch den einen oder anderen auf dem Schirm.
Vielen Dank im Voraus!
Aber nicht darüber.
Schade. Ob 1UP noch mal zum Webdesign zurückkehrt? (→ Kreuzberger Sprayer-Gang „One United Power“ )
Herzliche Grüße
Matthias Scharwies
Schade. Ob 1UP noch mal zum Webdesign zurückkehrt?
Webentwicklung begeistert mich nach wie vor, aber hauptberuflich habe ich nun andere Pfade eingeschlagen, weil sie mich zufriedener machen, eine Rückkehr in naher Zukunft schließe ich eher aus.
Es ist ein kleines Hobby von mir urbane Foto-Dokumentationen aufzuzeichnen, als Schüler war ich auch mal mit meiner Kamera in Berlin unterwegs und da haben es mir die 1UP-Graffitis angetan - da war mein Hormonhaushalt zugegebenermaßen etwas überdosiert mit pupertärem Rebellentum. Heute habe ich nicht mehr ganz so viele Sympathien für Provokationskunst übrig - weil sie meistens doch relativ leicht durchschaubar und monoton ist. Leider ist das vermutlich auch eine der Ursachen für den immer waghalsigeren und extremeren Aktionismus.