nicht angemeldet Felix Riesterer
Matthias Scharwies
Felix Riesterer
Gunnar Bittersmann
Gunnar Bittersmann
JürgenB
dedlfix
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
Liebe Mitlesende,
es gab hier im Forum in den letzten Wochen einmal eine Anfrage, ob man mal eben ein Tic-Tac-Toe-Spiel in JavaScript schreiben und im Forum posten könne. Für mich las sich damals die Frage so, als ob ein(e) Schüler(in) mit einer Hausaufgabe extrem knapp dran war. Als ich meine 7-Minuten-aufwendige Antwort posten wollte, war der Thread schon wieder entfernt worden.
Da dachte ich mir damals, den Post könnte ich zu einem richtigen Artikel ausbauen. Da ich gerade Weihnachtsferien habe und dem allgemeinen Aufruf nach Anfänger-Tutorials insbesondere für JavaScript einen Beitrag spendieren wollte, isser nun im Wiki und möchte kritisiert und verbessert werden:
JavaScript/Tutorials/TicTacToe
Liebe Grüße,
Felix Riesterer.
Servus!
Da ich gerade Weihnachtsferien habe und dem allgemeinen Aufruf nach Anfänger-Tutorials insbesondere für JavaScript einen Beitrag spendieren wollte, isser nun im Wiki und möchte kritisiert und verbessert werden:
Perfekt, da gibt's nix dran zu kritisieren! Vielen Dank!
Herzliche Grüße
Matthias Scharwies
Lieber Matthias,
Perfekt, da gibt's nix dran zu kritisieren! Vielen Dank!
vielen Dank für das dicke Lob! Trotzdem werde ich den Teil "Was fehlt noch?" etwas ergänzen.
Liebe Grüße,
Felix Riesterer.
Hallo Felix Riesterer,
Perfekt, da gibt's nix dran zu kritisieren! Vielen Dank!
vielen Dank für das dicke Lob! Trotzdem werde ich den Teil "Was fehlt noch?" etwas ergänzen.
Dem dicken Lob schließe ich mich an, gleichwohl ich einige Formatierungen zu kritisieren habe, die ich aber im Artikel selbst verändern werde.
Frage: Welche Browser beabsichtigst du zu berücksichtigen? Danach richtet sich, ob ich td:after zu td::after ändere.
Bis demnächst
Matthias
Lieber Matthias,
Dem dicken Lob schließe ich mich an,
danke!
gleichwohl ich einige Formatierungen zu kritisieren habe, die ich aber im Artikel selbst verändern werde.
Das nenne ich konstruktiv! (gell, Gunnar?)
Frage: Welche Browser beabsichtigst du zu berücksichtigen? Danach richtet sich, ob ich
td:afterzutd::afterändere.
Öhm... ist das eine entweder-oder-Entscheidung? Können die einen Browser nur mit einem Doppelpunkt und die anderen nur mit zweien? Im Zweifelsfall möchte ich die moderneren Browser unterstützen.
Liebe Grüße,
Felix Riesterer.
Hallo,
Frage: Welche Browser beabsichtigst du zu berücksichtigen? Danach richtet sich, ob ich
td:afterzutd::afterändere.Öhm... ist das eine entweder-oder-Entscheidung? Können die einen Browser nur mit einem Doppelpunkt und die anderen nur mit zweien? Im Zweifelsfall möchte ich die moderneren Browser unterstützen.
meines Wissens interpretieren neuere Browser, die ::after verstehen, auch die eigentlich falsche Schreibweise mit nur einem Doppelpunkt wie gewünscht. Es ist dann eher ein didaktischer Spagat, sich einzureden, dass man der Rückwärtskompatibilität zuliebe absichtlich einen formalen Fehler macht.
So long,
Martin
@@Der Martin
Öhm... ist das eine entweder-oder-Entscheidung? Können die einen Browser nur mit einem Doppelpunkt und die anderen nur mit zweien?
Öhm, die Frage hättest du dir leicht selbst beantworten können. :after ist eine in CSS Level 2 festgelegte Schreibweise. Welchen Sinn hätte es, die Unterstützung dafür in modernen Browsern aufzugeben und damit bestehende Seiten, die diese Schreibweise verwenden, kaputtzumachen?
Ab Level 3 werden Pseudoelemente und Pseudoklassen anhand der Anzahl der Doppelpunkte unterschieden.
meines Wissens interpretieren neuere Browser, die ::after verstehen, auch die eigentlich falsche Schreibweise mit nur einem Doppelpunkt wie gewünscht. Es ist dann eher ein didaktischer Spagat, sich einzureden, dass man der Rückwärtskompatibilität zuliebe absichtlich einen formalen Fehler macht.
Nein, man macht keinen formalen Fehler. Die Schreibweise aus Level 2 bleibt auch weiterhin aus Gründen der Rückwärtskompatibilität gültig. Euch beiden hätte ich eigentlich zugetraut, mal einen Blick in die Spec zu werfen.
Welche Schreibweise also verwenden? Ich würde sagen, dass Browser, die Level 3 nicht verstehen, inzwischen irrelevant sind. Jedenfalls nicht mehr relevant als Browser, die generierten Inhalt generell nicht können. Wenn man also weitgehend abwärtskompatibel sein will, muss man die Kreuze und Kreise sowieso als richtigen Inhalt in die td-Elemente setzen.
TL;DR: ::after mit 2 Doppelpunkten ist völlig OK.
LLAP 🖖
Hallo,
meines Wissens interpretieren neuere Browser, die ::after verstehen, auch die eigentlich falsche Schreibweise mit nur einem Doppelpunkt wie gewünscht. Es ist dann eher ein didaktischer Spagat, sich einzureden, dass man der Rückwärtskompatibilität zuliebe absichtlich einen formalen Fehler macht.
Nein, man macht keinen formalen Fehler. Die Schreibweise aus Level 2 bleibt auch weiterhin aus Gründen der Rückwärtskompatibilität gültig.
ja, sie bleibt gültig, bezeichnet aber eine Pseudoklasse, kein Pseudoelement. Das ist der formale Fehler, den man hier akzeptieren würde, weil man weiß, dass die Browser den Bezeichner für die nicht existierende Pseudoklasse :after automatisch als Bezeichner für das Pseudoelement interpretiert.
Euch beiden hätte ich eigentlich zugetraut, mal einen Blick in die Spec zu werfen.
Ja und? Da heißt es im ersten Abschnitt:
"For compatibility with existing style sheets, user agents must also accept the previous one-colon notation for pseudo-elements introduced in CSS levels 1 and 2."
Also genau, was ich sagte: Richtig wäre die Schreibweise mit zwei Doppelpunkten, der Kompatibilität zuliebe wird aber die Schreibweise mit nur einem Doppelpunkt ebenfalls akzeptiert.
Welche Schreibweise also verwenden? Ich würde sagen, dass Browser, die Level 3 nicht verstehen, inzwischen irrelevant sind.
Keine Ahnung, welche das noch sein könnten.
Wenn man also weitgehend abwärtskompatibel sein will, muss man die Kreuze und Kreise sowieso als richtigen Inhalt in die
td-Elemente setzen.
Das halte ich ebenso wie Matthias im vorliegenden Beispiel sowieso für semantisch richtiger. Denn sie repräsentieren ja die Spielsteine, die beim klassischen Tic-Tac-Toe ja auch noch physisch auf das Spielfeld gelegt wurden.
So long,
Martin
@@Der Martin
[Die Schreibweise aus Level 2 mit einem Doppelpunkt] bleibt gültig, bezeichnet aber eine Pseudoklasse, kein Pseudoelement.
Nein. Nicht, wenn der CSS-Parser folgende Regel intus hat: Interpretiere :after so, als stünde dort ::after.
Im von dir angeführten Abschnitt der Spec (Hervorhebung von mir):
“For compatibility with existing style sheets, user agents must also accept the previous one-colon notation for pseudo-elements introduced in CSS levels 1 and 2.”
LLAP 🖖
Hallo Gunnar Bittersmann,
[Die Schreibweise aus Level 2 mit einem Doppelpunkt] bleibt gültig, bezeichnet aber eine Pseudoklasse, kein Pseudoelement.
Nein. Nicht, wenn der CSS-Parser folgende Regel intus hat: Interpretiere
:afterso, als stünde dort::after.
Naja doch. Im Quelltext stünde :after. Der menschliche Leser desselben liest „Pseudoklasse after“. So habe ich Martin verstanden und das sehe ich auch so.
Bis demnächst
Matthias
@@Matthias Apsel
Naja doch. Im Quelltext stünde
:after. Der menschliche Leser desselben liest „Pseudoklasse after“.
Ein menschlicher Leser könnte so denken. Oder auch nicht.
Ein anderer könnte sich nie merken, wieviele Doppelpunkte für Pseudoklasse bzw. -element stehen, sich folglich nicht um deren Anzahl scheren, sondern denken: after erzeugt ein Ding, das vorher nicht da war – also ein Pseudoelement.
Im Gegensatz zu bspw. last-of-type, das ein vorhandenes Ding (das Element, auf das es angewandt wird) beurteilt: ist es das letzte seiner Art? Beurteilt = klassifiziert, also eine Pseudoklasse.
LLAP 🖖
Hallo,
Naja doch. Im Quelltext stünde
:after. Der menschliche Leser desselben liest „Pseudoklasse after“.Ein menschlicher Leser könnte so denken. Oder auch nicht.
Ein anderer könnte sich nie merken, wieviele Doppelpunkte für Pseudoklasse bzw. -element stehen, sich folglich nicht um deren Anzahl scheren, sondern denken:
aftererzeugt ein Ding, das vorher nicht da war – also ein Pseudoelement.
wenn du so argumentierst, führst du aber die mit CSS3 eingeführte Unterscheidung (ein Doppelpunkt: Pseudoklasse, zwei Doppelpunkte: Pseudoelement) ad absurdum. Dann hätte man bei einer einheitlichen Notation bleiben und die Unterscheidung ausschließlich anhand des Bezeichners treffen können.
Ciao,
Martin
@@Der Martin
wenn du so argumentierst, führst du aber die mit CSS3 eingeführte Unterscheidung (ein Doppelpunkt: Pseudoklasse, zwei Doppelpunkte: Pseudoelement) ad absurdum. Dann hätte man bei einer einheitlichen Notation bleiben und die Unterscheidung ausschließlich anhand des Bezeichners treffen können.
Nun ja, ich wollte nur darauf hinaus, dass es unterschiedliche menschliche Leser geben könnte.
Ich weiß jetzt auch nicht, was die Motivation war, in Level 3 unterschiedliche Schreibweisen für Pseudoklassen und Pseudoelemente einzuführen. Ob es nun technische Gründe waren, zwischen denen zu unterscheiden; oder einfach nur, um bei Entwicklern das Bewusstsein dafür zu schaffen, dass Pseudoklassen und Pseudoelemente verschiedene Dinge sind.
LLAP 🖖
Lieber Martin,
Wenn man also weitgehend abwärtskompatibel sein will, muss man die Kreuze und Kreise sowieso als richtigen Inhalt in die
td-Elemente setzen.Das halte ich ebenso wie Matthias im vorliegenden Beispiel sowieso für semantisch richtiger.
semantisch? Bei einem Spielfeld? Wollte ich sie bewegen, so wie Spielfiguren in Brettspielen, dann würde ich dafür andere Elemente nutzen. So aber "färbe" (das Beschriften sehe ich als eine abgeleitete Einfärbung an) ich doch nur ein Feld passend ein. Und damit ist es mMn eine Darstellungsfrage, welche wiederum mit CSS gelöst werden sollte.
Denn sie repräsentieren ja die Spielsteine, die beim klassischen Tic-Tac-Toe ja auch noch physisch auf das Spielfeld gelegt wurden.
Echt? Ich kenne das Spiel ausschließlich als auf Schmierzetteln notiertes Pen&Paper-Spiel. Immerhin schreibt die Wikipedia etwas von einem echten Brett...
Liebe Grüße,
Felix Riesterer.
Aloha ;)
Wenn man also weitgehend abwärtskompatibel sein will, muss man die Kreuze und Kreise sowieso als richtigen Inhalt in die
td-Elemente setzen.Das halte ich ebenso wie Matthias im vorliegenden Beispiel sowieso für semantisch richtiger.
semantisch? Bei einem Spielfeld? Wollte ich sie bewegen, so wie Spielfiguren in Brettspielen, dann würde ich dafür andere Elemente nutzen. So aber "färbe" (das Beschriften sehe ich als eine abgeleitete Einfärbung an) ich doch nur ein Feld passend ein. Und damit ist es mMn eine Darstellungsfrage, welche wiederum mit CSS gelöst werden sollte.
Meiner Meinung nach ist es allgemein gesprochen ab einem gewissen Punkt (nämlich ab dem, an dem offensichtliche Fehler oder ganz ungünstige Elementwahl erledigt sind) müßig, sich über Semantik weiter den Kopf zu zerbrechen, vor allem wenn es um JavaScript-generierte (dynamische) Inhalte geht.
Im vorliegenden Beispiel wird durch das Setzen der entsprechenden Klasse im HTML/DOM die Änderung auch semantisch wirkungsvoll umgesetzt, im Sinne einer Zugehörigkeitsmarkierung (die von O/X beanspruchten Felder) und damit ist das auch ein sinnvoller Einsatz des class-Attribut. Theoretisch wäre es besser, wenn der Klassenname etwas deskriptiver wäre (z.B. marked-O statt O), gerade in einem Anfängertutorial fällt das dann aber unter KISS.
Die Frage, ob jetzt tatsächlich den Spielstein repräsentierende Elemente zum Einsatz kommen sollten statt reiner Markierung der Zelle ist keinesfalls semantisch, sondern lediglich im Kontext des Modellentwurfs zu sehen, also inwiefern physikalisch-physische Elemente im virtuellen Raum direkt (X bzw. Spielstein tatsächlich in der Zelle) oder nur ihrem Sinn nach (Markierung der Zelle) wiedergegeben werden.
Semantisch müsste man sich eher fragen, ob ein Tic-Tac-Toe-Spielfeld eine Tabelle ist, die tabellarische Daten enthält - mMn nämlich nicht. Korrekter wäre da sicherlich ein div-Container mit span-Elementen, am einfachsten formatiert per flexbox. Aber auch das fällt im Zweifelsfall unter KISS und die meinige oben formulierte Prämisse, dass bei dynamisch generierten/geprägten Inhalten die Semantik eine eher untergeordnete Rolle spielt - schon allein, da Maschinenlesbarkeit im vorliegenden Beispiel kaum (zumindest nicht über das was sowieso schon umgesetzt ist hinaus) relevant ist.
Grüße,
RIDER
@@Camping_RIDER
Theoretisch wäre es besser, wenn der Klassenname etwas deskriptiver wäre (z.B.
marked-OstattO)
Hehe, sag ich doch.
gerade in einem Anfängertutorial fällt das dann aber unter KISS.
Nein, auch gerade in einem Anfängertutorial sollten sprechende Namen verwendet werden.
Das kann statt marked-O oder piece-o in dem Fall auch durchaus ein deutschsprachiger Bezeichner sein.
Semantisch müsste man sich eher fragen, ob ein Tic-Tac-Toe-Spielfeld eine Tabelle ist, die tabellarische Daten enthält - mMn nämlich nicht.
LLAP 🖖
Aloha ;)
Theoretisch wäre es besser, wenn der Klassenname etwas deskriptiver wäre (z.B.
marked-OstattO)Hehe, sag ich doch.
Stimmt - ich habe wie oft schon während dem initialen Thread-Lesen geantwortet statt zuerst alle Antworten zu lesen ;)
gerade in einem Anfängertutorial fällt das dann aber unter KISS.
Nein, auch gerade in einem Anfängertutorial sollten sprechende Namen verwendet werden.
Ja, geschenkt. Du hast damit prinzipiell Recht.
Semantisch müsste man sich eher fragen, ob ein Tic-Tac-Toe-Spielfeld eine Tabelle ist, die tabellarische Daten enthält - mMn nämlich nicht.
Da halte ich es dann doch mit @JürgenB und der von ihm zitierten Aussage. Oder um mich selbst zu zitieren...
Aber auch das fällt [...] [unter] meinige oben formulierte Prämisse, dass bei dynamisch generierten/geprägten Inhalten die Semantik eine eher untergeordnete Rolle spielt
Fakt ist, dass es für beide Sichtweisen sinnvolle Argumente gibt (auch die Interpretation als Matrix stelle ich im Übrigen in Frage, ohne das ausdiskutieren zu wollen, denn auch eine Matrix bevorzugt bestimmte Richtungen - insofern gebe ich dir Recht, dass eine Matrix einer Tabelle entspricht, aber nicht darin, dass ein TicTacToe-Feld eine Matrix darstellt) und dann sollte man da nicht verbohrt darauf pochen, dass es das semantisch richtige Element für die Darstellung gibt, sondern vielmehr akzeptieren, dass das Spielfeld aus guten Gründen sowohl als Tabelle dargestellt werden kann als auch aus guten Gründen gerade nicht als Tabelle dargestellt werden kann. Das ist dann eine Frage der persönlichen Einstellung und nichts, worüber man objektive Empfehlungen abgeben kann.
Grüße,
RIDER
@@Felix Riesterer
gleichwohl ich einige Formatierungen zu kritisieren habe, die ich aber im Artikel selbst verändern werde.
Das nenne ich konstruktiv! (gell, Gunnar?)
Du fändest es konstruktiv, wenn ich deinen Artikel im Wiki bearbeiten würde? Ich habe da Bedenken. Genereller Art. Das betrifft das Wiki an sich: Ich glaube nicht, dass das die richtige Basis für solche Artikel ist.
Wenn mehrere Personen solch einen Artikel umschreiben, läuft er Gefahr, zu einem Flickenteppich zu werden. Jeder Flicken für sich durchaus korrekt, aber sie ergeben kein einheitliches Ganzes. Ständige Wechsel – ein stilistisches Durcheinander. Sogar der vom ursprünglichen Autor angedachte rote Faden durch den Artikel könnte verlorengehen.
IMHO sollten solche Artikel in der Verantwortung eines Autors bleiben (der auch im Artikel als Autor genannt sein sollte). Änderungs-/Ergänzungswünsche können außerhalb des Artikels (des Entwurfs) diskutiert werden. So wie hier in diesem Thread.
Hier kam ja auch einiges zusammen. Wäre die Diskussion auch so fruchtbar, wenn jeder einfach sein Zeug am Artikel im Wiki editiert hätte?
Der Autor kann in der Diskussion aufkommende Gedanken in den Artikel einpflegen – in seiner Sprache, passend zum Rest des Artikels, so dass dieser am Ende immer noch wie aus einem Guss daherkommt.
LLAP 🖖
Lieber Gunnar,
je mehr ich über diese Antwort nachdenke, desto scheinheiliger erscheint sie mir.
Du fändest es konstruktiv, wenn ich deinen Artikel im Wiki bearbeiten würde?
Darum geht es doch: Wir benötigen Mitarbeit im Wiki. Alles, was unsere Inhalte verbessert oder aktuell macht, ist nützlich und somit im Interesse von SELFHTML.
Ich glaube nicht, dass das die richtige Basis für solche Artikel ist.
Was soll eine "richtige" Basis für "solche" Artikel sein? Dass da nur einer schreibt? Als ob einer immer das Wissen gepachtet hätte...
Wenn mehrere Personen solch einen Artikel umschreiben, läuft er Gefahr, zu einem Flickenteppich zu werden.
Auch die Bibel ist in dieser Hinsicht ein Flickenteppich. Das hat sie aber trotzdem nicht daran gehindert, für eine der mitgliederstärksten Weltreligionen zu sorgen.
Jeder Flicken für sich durchaus korrekt, aber sie ergeben kein einheitliches Ganzes. Ständige Wechsel – ein stilistisches Durcheinander. Sogar der vom ursprünglichen Autor angedachte rote Faden durch den Artikel könnte verlorengehen.
Dafür ist das Forum da. Hier kann diskutiert werden, wenn sich ein Autor unsicher ist, ob und wie seine Bearbeitung einem Artikel schaden könnte. Deine Einwände, ich nannte sie Korinthen, sind völlig ungefährlich einzupflegen, denn Du willst typographische Richtigkeit. Also nochmal: Tue es einfach, anstatt hier herumzuwieseln! Das würde Deinen Argumenten wesentlich mehr Gewicht geben, anstatt Deine Glaubwürdigkeit infrage zu stellen!
IMHO sollten solche Artikel in der Verantwortung eines Autors bleiben (der auch im Artikel als Autor genannt sein sollte). Änderungs-/Ergänzungswünsche können außerhalb des Artikels (des Entwurfs) diskutiert werden. So wie hier in diesem Thread.
Genau, und Du musst Dir die Finger nicht schmutzig machen. Gerade Du, der im Wesentlichen nur typographische Probleme hat. Das klingt nicht wirklich ehrlich!
Hier kam ja auch einiges zusammen. Wäre die Diskussion auch so fruchtbar, wenn jeder einfach sein Zeug am Artikel im Wiki editiert hätte?
Wieso jeder? Ich habe nur ein Problem damit, dass Du Deine typographischen Kritikpunkte nicht selbst umsetzen wolltest. Matthias Apsel hat bereits einiges in dieser Hinsicht verbessert, der Rest kam dann von mir. Wieso nicht von Dir?
Der Autor kann in der Diskussion aufkommende Gedanken in den Artikel einpflegen – in seiner Sprache, passend zum Rest des Artikels, so dass dieser am Ende immer noch wie aus einem Guss daherkommt.
Ein Anfänger, der mit diesem Artikel lernen will, kümmert sich einen Dreck darum, ob der Artikel aus einem Guss ist, oder nicht. Deine Argumentation klingt für mich nach wie vor nach einer faulen Ausrede, sich im Wiki nicht die Finger schmutzig zu machen. Dabei könnte das Wiki Deine Mitarbeit sehr gut gebrauchen. Nicht nur in typographischer Hinsicht, sondern auch in inhaltlicher!
Tue mal was für's Wiki, dann empfinde ich Deine Einwände hier im Forum weniger als Korinthen.
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
je mehr ich über diese Antwort nachdenke, desto scheinheiliger erscheint sie mir.
Das scheint nur so. Sie ist von bis hinten ehrlich.
Darum geht es doch: Wir benötigen Mitarbeit im Wiki. Alles, was unsere Inhalte verbessert oder aktuell macht, ist nützlich und somit im Interesse von SELFHTML.
Über Artikel im Forum zu diskutieren ist auch Mitarbeit, nur eine andere From als Artikel im Wiki umzuschreiben.
Was soll eine "richtige" Basis für "solche" Artikel sein? Dass da nur einer schreibt? Als ob einer immer das Wissen gepachtet hätte...
Eben nicht. Deshalb wird ja diskutiert. Und der Autor kann das Wissen von anderen aus der Diskussion in den Artikel einpflegen.
Auch die Bibel ist in dieser Hinsicht ein Flickenteppich.
Verschiedene Artikel können durchaus von verschiedenen Autoren stammen. Hier geht es aber darum, ob ein Artikel von jedermann editiert werden sollte.
Deine Einwände, ich nannte sie Korinthen, sind völlig ungefährlich einzupflegen, denn Du willst typographische Richtigkeit.
Du hast mein Posting von vorn bis hinten gelesen? Oder doch eher von hinten nach vorn und bei „LLAP 🖖“ aufgehört?
Um Typographie ging es lediglich in der Fußnote.
Also nochmal: Tue es einfach, anstatt hier herumzuwieseln! Das würde Deinen Argumenten wesentlich mehr Gewicht geben, anstatt Deine Glaubwürdigkeit infrage zu stellen!
Wenn man im Wiki stillschweigend Änderungen vornimmt, ist man glaubwürdig, wenn man im Forum diskutiert, ist man unglaubwürdig? Die Logik dahinter musst du mir mal erklären.
Genau, und Du musst Dir die Finger nicht schmutzig machen. Gerade Du, der im Wesentlichen nur typographische Probleme hat.
S.o. Und wenn du denkst, es ginge mir um die Sauberkeit meiner Finger, hast du mich gründlich missverstanden.
Wieso jeder? Ich habe nur ein Problem damit, dass Du Deine typographischen Kritikpunkte nicht selbst umsetzen wolltest.
Diese wären wirklich Änderungen, die auch andere im Wiki selbst durchführen könnten, ohne dass das der Homogenität des Artikels schaden würde. Aber s.o.
Matthias Apsel hat bereits einiges in dieser Hinsicht verbessert, der Rest kam dann von mir. Wieso nicht von Dir?
Aus genau dem Grund, den ich hier zur Diskussion stelle.
Ein Anfänger, der mit diesem Artikel lernen will, kümmert sich einen Dreck darum, ob der Artikel aus einem Guss ist, oder nicht.
Soll heißen? Für Anfänger genügen auch schlechte Artikel? Die Logik dahinter musst du mir mal erklären.
Deine Argumentation klingt für mich nach wie vor nach einer faulen Ausrede, sich im Wiki nicht die Finger schmutzig zu machen. Dabei könnte das Wiki Deine Mitarbeit sehr gut gebrauchen. Nicht nur in typographischer Hinsicht, sondern auch in inhaltlicher!
Das hängt sicher vom Thema ab, aber i.d.R. würde ich nicht wollen, dass andere in meinen Artikeln herumeditiern. Was natürlich nicht heißt, dass andere nicht ihren Senf dazugeben und einen Artikel verbessern sollten, im Gegegenteil. Nur würde ich deren Anmerkungen gern selbst einbauen.
Das war übrigens bei meinem Artikel für den Webkrauts-Adventskalender der Fall; der erschien auch nicht in seiner Urfassung. Es gab Feedback per E-Mail oder in Kommentaren, was noch fehlt oder was geändert werden sollte. An einigen Stellen hat der Editor-in-chief im Artikel Hand angelegt, wobei ich seine Änderungen dann nochmals mit meinen Worten umgeschrieben habe. Es sei denn, sie waren so, wie ich es auch gesagt hätte.
Tue mal was für's Wiki, dann empfinde ich Deine Einwände hier im Forum weniger als Korinthen.
LLAP 🖖
Lieber Gunnar,
je mehr ich über diese Antwort nachdenke, desto scheinheiliger erscheint sie mir.
Das scheint nur so. Sie ist von bis hinten ehrlich.
Du glaubst offensichtlich Deine eigenen Ausreden. Schade. Dem Wiki ist damit nicht geholfen.
Über Artikel im Forum zu diskutieren ist auch Mitarbeit, nur eine andere From als Artikel im Wiki umzuschreiben.
Wenn es um Meinungen geht, ja. Wenn es um das Fördern von Verständnis geht, ja. Wenn es um das Korrigieren von offensichtlichen Fehlern geht, dann ist eine Diskussion hier nur zum Teil hilfreich. Wirklich nützlich wäre ein zweigleisiges Vorgehen, das eine aktive Mitarbeit im Wiki (also wirklich dort, nicht nur hier) einschließt. Aber da sehe ich bei Dir bisher Fehlanzeige.
Ich habe mir sagen lassen, dass das bei der Mitgliederversammlung thematisiert wurde. Du hattest etwas versprochen, aber bis heute sieht man davon keine Wirkung. Stattdessen übst Du Dich weiter darin, als arbeitsscheuer Besserwisser wahrgenommen zu werden.
Eben nicht. Deshalb wird ja diskutiert. Und der Autor kann das Wissen von anderen aus der Diskussion in den Artikel einpflegen.
Es ist ein Wiki-Artikel. Da gehört es zur Natur der Sache, dass es nicht den einen Autor gibt, sondern eine Autorengemeinschaft. Offensichtlich kannst Du nicht im Team arbeiten, wenn Dir eine Autorengemeinschaft dermaßen gegen Deine Natur geht.
Verschiedene Artikel können durchaus von verschiedenen Autoren stammen. Hier geht es aber darum, ob ein Artikel von jedermann editiert werden sollte.
Nein, Dir geht es darum. Alle die, die in einem Wiki bereits aktiv mitgearbeitet haben, sehen dieses Problem offensichtlich nicht, denn sie arbeiten. Du nicht. Du hast da offensichtlich ein Problem. Ob das jetzt irgend so ein Elfenbeinturm ist, aus dem Du Deine Welt betrachtest, oder ob es Dein Ego nicht verkraftet, wenn andere Dein Werk dadurch verschlechtern, indem sie Änderungen darin vornehmen, sei einmal dahin gestellt.
Du hast mein Posting von vorn bis hinten gelesen? Oder doch eher von hinten nach vorn und bei „LLAP 🖖“ aufgehört?
Du versuchst Deinen Standpunkt dadurch zu halten, indem Du Polemik einsetzt? Anscheinend schwant Dir doch ein bisschen, dass Du hier einen sehr einseitigen Blick forcierst.
Um Typographie ging es lediglich in der Fußnote.
Da siehst Du mal, wie bei mir die Quintessenz Deines Postings angekommen ist. Wenn Du weiterhin darauf bestehst, dass Deine Äußerungen hier unfehlbar sind, und dass es nur die gekrümmte Wahrnehmung der hier Lesenden ist, die Missverständnisse erzeugen, dann hast Du ein wesentliches Element von Kommunikation nicht verstanden. Und wenn dem so ist, dann hast Du da dringenden Handlungsbedarf!
Wenn man im Wiki stillschweigend Änderungen vornimmt, ist man glaubwürdig, wenn man im Forum diskutiert, ist man unglaubwürdig? Die Logik dahinter musst du mir mal erklären.
Nein. Für Dich ausbuchstabiert:
Wenn man ausschließlich im Forum kritisiert, aber offensichtlich nicht bereit ist, im Wiki diese Kritik aktiv umzusetzen, macht man sich unglaubwürdig. Unglaubwürdig hinsichtlich der Bereitschaft hier wirklich inhaltlich in der Doku mitzuwirken.
Du darfst ja offen zugeben, dass Du das Wiki nur mit der Beißzange anfassen würdest, und dass Du keinesfalls irgendwelche Änderungen darin vornehmen wirst. Das wäre OK. Aber dann tue nicht so, als verhielte es sich anders herum!
S.o. Und wenn du denkst, es ginge mir um die Sauberkeit meiner Finger, hast du mich gründlich missverstanden.
Du hast Dir dafür jedenfalls die größte Mühe gegeben.
Wieso jeder? Ich habe nur ein Problem damit, dass Du Deine typographischen Kritikpunkte nicht selbst umsetzen wolltest.
Diese wären wirklich Änderungen, die auch andere im Wiki selbst durchführen könnten, ohne dass das der Homogenität des Artikels schaden würde. Aber s.o.
Genau, nur Du nicht. Damit Du nicht im Wiki editieren musst. Denn das vermeidest Du wie der Teufel das Weihwasser. Diesen Anschein verteidigst Du mit Händen und Füßen.
Soll heißen? Für Anfänger genügen auch schlechte Artikel? Die Logik dahinter musst du mir mal erklären.
Du setzt Autorengemeinschaft bei einem Artikel mit schlechter Qualität gleich. Das ist überheblich! Das impliziert, dass Deine Artikel nur dann maximale Qualität haben, wenn sie ausschließlich aus Deiner Feder stammen, und dass Du dieses Prinzip auch auf alle fremden Artikel überträgst.
Pfui!
Das hängt sicher vom Thema ab, aber i.d.R. würde ich nicht wollen, dass andere in meinen Artikeln herumeditiern. Was natürlich nicht heißt, dass andere nicht ihren Senf dazugeben und einen Artikel verbessern sollten, im Gegegenteil. Nur würde ich deren Anmerkungen gern selbst einbauen.
Damit Du die Hoheit über Deinen Artikel behältst. Schon klar. Ich hatte vorhin Dein Ego angedeutet. Kein teamfähiges Konzept!
Das war übrigens bei meinem Artikel für den Webkrauts-Adventskalender der Fall; der erschien auch nicht in seiner Urfassung. Es gab Feedback per E-Mail oder in Kommentaren, was noch fehlt oder was geändert werden sollte. An einigen Stellen hat der Editor-in-chief im Artikel Hand angelegt, wobei ich seine Änderungen dann nochmals mit meinen Worten umgeschrieben habe. Es sei denn, sie waren so, wie ich es auch gesagt hätte.
Das ist in meinen Augen schiere Eitelkeit. Wenn ich in einem Wiki schreibe, bin ich nur Teil eines größeren Ganzen, einer Autorengemeinschaft. Wenn das mit meinem Ego nicht zusammenpasst, dann veröffentliche eben nur auf einer Plattform, die mir gehört.
Warst Du bei den Webkrauts vielleicht inkonsequent?
Nein, ich bin heute zu Dir ehrlicher als sonst, will heißen: ich verkneife mir jetzt nichts aus Höflichkeit. Ich sage Dir, was mir hier nicht passt. Das muss Dir nicht schmecken. Aber ich muss es loswerden. Falls Dir inhaltliche Parallelen zu anderer, Dir bereits angetragener Kritik auffallen, so sind diese keineswegs zufällig, sondern konsequent.
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
Du glaubst offensichtlich Deine eigenen Ausreden. Schade. Dem Wiki ist damit nicht geholfen.
Du glaubst offensichtlich, dass meine Einwände Ausreden wären. Schade. Der Diskussion ist damit nicht geholfen.
Es ist ein Wiki-Artikel. Da gehört es zur Natur der Sache, dass es nicht den einen Autor gibt, sondern eine Autorengemeinschaft.
So ist es. Ebendeshalb ja mein Bedenken, ob eine Autorengemeinschaft das Richtige für diese Art von Artikeln ist.
(Ob das technisch als Wiki umgesetzt ist, ist dabei nicht von Belang.)
Offensichtlich kannst Du nicht im Team arbeiten, wenn Dir eine Autorengemeinschaft dermaßen gegen Deine Natur geht.
Unsinn. Artikel im Forum zu besprechen und auf Argumente anderer einzugehen ist auch Teamarbeit.
Hier geht es aber darum, ob ein Artikel von jedermann editiert werden sollte.
Nein, Dir geht es darum.
Natürlich geht mir es darum, ob ich es für mich sinvoll finde, Artikel im Wiki zu bearbeiten, und ob ich das tun sollte. Ich halte aber niemanden davon ab, der das für sinnvoll erachtet.
Dir geht es darum, mich zu etwas zu bewegen, was ich nicht so sinnvoll finde.
oder ob es Dein Ego nicht verkraftet, wenn andere Dein Werk dadurch verschlechtern, indem sie Änderungen darin vornehmen, sei einmal dahin gestellt.
Wenn du meine Postings richtig lesen würdest, hätte dir auffallen sollen, dass es mir um die Artikel geht, nicht um irgendjemandes Ego.
(Was in dem Falle im Übrigen dein Ego wäre, da es ja um deinen Artikel geht.)
Du hast mein Posting von vorn bis hinten gelesen? Oder doch eher von hinten nach vorn und bei „LLAP 🖖“ aufgehört?
Du versuchst Deinen Standpunkt dadurch zu halten, indem Du Polemik einsetzt?
Mal der Reihe nach: Ich merkte an:
Matthias Apsel
Der Martin
Camping_RIDER
Auge
MudGuard
Tabellenkalk<tbody>Du reduzierst das auf:
Ich sage: Ähm, da war noch mehr.
Du darauf: „Polemik!“
Geht das (Trauer-)Spiel noch weiter?
Du darfst ja offen zugeben, dass Du das Wiki nur mit der Beißzange anfassen würdest, und dass Du keinesfalls irgendwelche Änderungen darin vornehmen wirst. Das wäre OK.
OK, ich gebe zu, dass ich das Wiki, wenn’s um solche Artikel geht, die IMHO eher geschlossen sind, mit der Beißzange anfassen würde.
Das heißt nicht, dass ich das Wiki für andere Arten von Dokumentationen unpassend finden würde.
Soll heißen? Für Anfänger genügen auch schlechte Artikel? Die Logik dahinter musst du mir mal erklären.
Du setzt Autorengemeinschaft bei einem Artikel mit schlechter Qualität gleich. Das ist überheblich!
Und schon wieder biegst du meine Aussage um.
Deine war: „Ein Anfänger … kümmert sich einen Dreck darum, ob der Artikel aus einem Guss ist, oder nicht.“
Meine Frage daraufhin: Für Anfänger genügen auch Artikel, die nicht aus einem Guss sind? Was für mich „schlechte Artikel“ sind.
Ob eine Autorengemeinschaft nun zwangsläufig zu einem Artikel führt, der nicht aus einem Guss ist, ist ja gerade Gegenstand der Diskussion.
Das impliziert, dass Deine Artikel nur dann maximale Qualität haben, wenn sie ausschließlich aus Deiner Feder stammen, und dass Du dieses Prinzip auch auf alle fremden Artikel überträgst.
Zumindest hier hast du verstanden, dass es nicht um meine Artikel geht.
Das ist in meinen Augen schiere Eitelkeit. Wenn ich in einem Wiki schreibe, bin ich nur Teil eines größeren Ganzen, einer Autorengemeinschaft. Wenn das mit meinem Ego nicht zusammenpasst, dann veröffentliche eben nur auf einer Plattform, die mir gehört.
Nochmals: weder „Eitelkeit“ noch „Ego“. Und die Plattform, wo der Artikel erscheint, muss auch nicht dem Autor gehören.
Nein, ich bin heute zu Dir ehrlicher als sonst, will heißen: ich verkneife mir jetzt nichts aus Höflichkeit.
Das sagt mir durchaus zu.
Ich sage Dir, was mir hier nicht passt.
Und das ist auch gut so. Und ich sagte dir, wenn ich denke, dass du damit falsch liegst.
LLAP 🖖
Hallo Gunnar Bittersmann, @Felix Riesterer
Um mich mal hier einzuklinken:
Diese Diskussion ist leider weder zielführend noch hilfreich.
Zielführend und hilfreich sind bzw. waren
<tbody>
Deshalb möchte ich euch bitten, diese Diskussion hier abzubrechen. Sie wird in schriftlicher Form zu nichts führen. In mündlicher Form wären, da bin ich sicher[1], alle Vorbehalte und -würfe schon ausgeräumt.
Bis demnächst
Matthias
Ich glaube, euch beide soweit zu kennen. ↩︎
@@Matthias Apsel
Gunnars fachliche und formale Hinweise dazu
1. irreführende Erklärung zu<tbody>
— erledigt
Mit der Erklärung sind auch die <tbody>-Tags verschwunden. Ich hätte sie drin gelassen; ich finde es keine gute Idee, optionale Tags wegzulassen.
2. Gehören Kreise und Kreuze in den Inhalt?
— diskussionswürdig, hat in dem Artikel selbst nichts verloren
Stimmt, das Aufzeigen mehrerer Möglichkeiten sicher nicht.
— mein Vorschlag war, Klassen und Inhalt statt Klassen und Pseudoinhalt zu verwenden
Ja, das wäre wohl auch mein Favorit.
Die begründete Wahl pro Pseudoinhalt wäre aus Gründen der Einfachheit auch durchaus möglich; nur fehlt die Begründung nach wie vor.
3. mögliche Vereinfachung des Stylesheets
— eingearbeitet
Nicht wirklich. Es ist nicht eingearbeitet, sondern steht nachträglich. Wenn sich der Artikel an Anfänger richtet, halte ich es für keine gute Idee erst zu zeigen, wie man es nicht so gut macht und dann im Nachgang zu sagen: „April, April, wir haben euch reingelegt. So geht’s richtig!“ Es sollte gleich die bessere Variante gezeigt werden, keine andere.
Wobei einiges auch für Felix’ ursprüngliche Variante spricht, dass Klassenbezeichner und Pseudoinhalt entkoppelt sind. Dann könnte man auch .tic-tac-toe .x::after { content: "❌" } schreiben. (Allerdings wären auch ‘❌’ und ‘⭕’ als Klassenbezeichner möglich.) Und man könnte (sollte?) auch sprechendere Klassenbezeichner wie ‘piece-x’ und ‘piece-o’ verwenden. Oder auch gar keine, sondern data-piece="x" (in JavaScript: ….dataset.piece = 'x').
Ich halte es nicht für sinnvoll, einem Anfänger mehrere Varianten anzubieten und ihn orientierungslos dastehen zu lassen, welche er nun nehmen sollte. Und jede davon zu begründen, würde wohl den Rahmen des Artikels sprengen – und vom eigentlichen Ansinnen ablenken.
Also sollte sich jemand für eine Variante (für die in diesem Kontext beste) entscheiden – und dieser Jemand ist am besten der Autor des Artikels.
4. Typographie — erledigt
Heißt in dem Fall: unter den Tisch gekehrt?
In mündlicher Form wären, da bin ich sicher, alle Vorbehalte und -würfe schon ausgeräumt.
Bei einem Treffen hätten wir das nicht verbal, sondern mit Fäusten ausgetragen. Zuschauende hätten Wetten abgeben können.
Der Ausgang des Kampfes hätte sich nach den abgegebenen Wetteinsätzen gerichtet. Felix und ich hätten uns den Gewinn geteilt.
LLAP 🖖
Hallo Gunnar Bittersmann,
1. irreführende Erklärung zu
<tbody>
— erledigtMit der Erklärung sind auch die
<tbody>-Tags verschwunden. Ich hätte sie drin gelassen; ich finde es keine gute Idee, optionale Tags wegzulassen.
Es ist gängige Praxis, einfache Tabellen ohne tbody-tags zu notieren. Wozu das Markup aufblähen?
3. mögliche Vereinfachung des Stylesheets
— eingearbeitetNicht wirklich. Es ist nicht eingearbeitet, sondern steht nachträglich. Wenn sich der Artikel an Anfänger richtet, halte ich es für keine gute Idee erst zu zeigen, wie man es nicht so gut macht und dann im Nachgang zu sagen: „April, April, wir haben euch reingelegt. So geht’s richtig!“ Es sollte gleich die bessere Variante gezeigt werden, keine andere.
Sehe ich nicht so. Die bessere Variante ist oft die weniger gut verständliche. In dem Fall ist es die attr-Funktion, die es unnötig verkompliziert.
Und man könnte (sollte?) auch sprechendere Klassenbezeichner wie ‘
piece-x’ und ‘piece-o’ verwenden.
Das ist auf jeden Fall ein Punkt, der umgesetzt werden sollte.
4. Typographie — erledigt
Heißt in dem Fall: unter den Tisch gekehrt?
Kommt darauf an was du meinst.
Bis demnächst
Matthias
@@Matthias Apsel
Mit der Erklärung sind auch die
<tbody>-Tags verschwunden. Ich hätte sie drin gelassen; ich finde es keine gute Idee, optionale Tags wegzulassen.Es ist gängige Praxis, einfache Tabellen ohne tbody-tags zu notieren. Wozu das Markup aufblähen?
Mit dem Argument könnte man auch die <body>- und </body>-Tags weglassen.
Das Weglassen von <tbody> und </tbody> könnte zu dem Irrglauben führen, dass tr-Elemente Kinder von table wären. Insbesondere wenn JavaScript im Spiel ist, könnte das fatal sein. (@MudGuard Hi Nostradamus, long time, no see.)
Sehe ich nicht so. Die bessere Variante ist oft die weniger gut verständliche. In dem Fall ist es die attr-Funktion, die es unnötig verkompliziert.
Das sehe ich nicht so. Ist aber irrelevant wegen:
Und man könnte (sollte?) auch sprechendere Klassenbezeichner wie ‘
piece-x’ und ‘piece-o’ verwenden.
- Das große ẞ?
- geschenkt, ich glaube, das gibts in dem Artikel gar nicht.
Nein, die Threaddrift kaum auf, als sich Felix von einem verlinkten Tweet aus noch einen weiter hoch hangelte.
- Kreuze statt x, Kreise statt o?
Ja, das meinte ich.
- ich würde auf jeden Fall die Buchstaben lassen, Warum soll sich ein Anfänger die Mühe machen, diese Zeichen herauszusuchen und dabei Gefahr zu laufen, dass Editor oder Entwicklertools nur das Ersatzzeichen für ein nicht vorhandenes Zeichen anzeigen? Eventuell wird es nicht mal im Browser korrekt dargestellt.
Es müssen nicht ❌ und ⭕ sein. Aber × und ○ (U+25CB WHITE CIRCLE; das sollte in der Größe besser zu × passen als ◯) dürften kaum Darstellungsprobleme bereiten.
Und wie ich eben schon sagte: Die Verwendung vernünftig aussehender Zeichen fügt dem Artikel null Komplexität hinzu, schadet also nicht. Nutzt aber.
LLAP 🖖
Aloha ;)
Das Weglassen von
<tbody>und</tbody>könnte zu dem Irrglauben führen, dasstr-Elemente Kinder vontablewären. Insbesondere wenn JavaScript im Spiel ist, könnte das fatal sein.
Ohne die Verlinkung bewerten zu wollen: damit hast du Recht, es verschleiert im JS-Bereich, dass man noch über weitere parentNodes iterieren muss, was potenziell fatal ist; besser ist es also, <tbody> gleich explizit zu notieren, damit man es im JS-Bereich nicht übersieht/vergisst.
Und wie ich eben schon sagte: Die Verwendung vernünftig aussehender Zeichen fügt dem Artikel null Komplexität hinzu, schadet also nicht. Nutzt aber.
Hier widerspreche ich deutlich. Die Verwendung von Unicode ist - gerade für Anfänger, aber auch für einige Fortgeschrittene - eben nicht selbstverständlich, und damit entsteht Komplexität. Und der Nutzen ist dann doch in diesem Fall eher fraglich. Zumindest ist der Fall nicht so gelagert, dass durch die Verwendung von Buchstaben statt entsprechender Zeichen ein Nachteil[1] entsteht, und daher gibt es keinen Grund, in speziell diesem Artikel die potenziell irritierende Verwendung von Unicode-Zeichen zu propagieren.
Im Gegenteil: Ich halte hier das Verlangen, Unicode einzusetzen, eher für prinzipien-bedingt übertrieben. Nur, weil Unicode-Zeichen in vielen Fällen angebracht sind heißt das nicht, dass man sie überall (in diesem Fall: anstatt anderer Unicode-Zeichen) verwenden muss.
Grüße,
RIDER
Auch nicht semantischer Art, das zeigt schon der Umstand, dass das × als Multiplikationszeichen klassifiziert ist - insofern sind hier weder x noch × einander aus solchen Gründen vorzuziehen. ↩︎
@@Camping_RIDER
Die Verwendung von Unicode ist - gerade für Anfänger, aber auch für einige Fortgeschrittene - eben nicht selbstverständlich
Doch, sie ist so selbstverständlich, dass man dazu noch nie was von Unicode gehört haben muss. Es ist ab HTML 4.0 gar nicht möglich, nicht Unicode zu verwenden.
Auch nicht semantischer Art, das zeigt schon der Umstand, dass das × als Multiplikationszeichen klassifiziert ist - insofern sind hier weder x noch × einander aus solchen Gründen vorzuziehen.
Das stimmt. Der Grund ist einfach, dass × als Kreuz besser aussieht als x und ○ als Kreis besser als o. Und dass ich keinen Grund sehe, nicht × und ○ im Stylesheet als Wert für content zu verwenden.
LLAP 🖖
Hallo Gunnar,
Das stimmt. Der Grund ist einfach, dass × als Kreuz besser aussieht als x und ○ als Kreis besser als o. Und dass ich keinen Grund sehe, nicht × und ○ im Stylesheet als Wert für
contentzu verwenden.
und wie löst man das Farbproblem unter OS X?
Gruß Jürgen
@@JürgenB
Das stimmt. Der Grund ist einfach, dass × als Kreuz besser aussieht als x und ○ als Kreis besser als o. Und dass ich keinen Grund sehe, nicht × und ○ im Stylesheet als Wert für
contentzu verwenden.und wie löst man das Farbproblem unter OS X?
Bei den Zeichen × und ○ gibt es kein Farbproblem.
LLAP 🖖
Hallo
Bei den Zeichen × und ○ gibt es kein Farbproblem.
ach so, ich habe bei dem Posting an einem Windows-Rechner gesessen.
Wo finde ich denn diese Zeichen?
Gruß Jürgen
@@JürgenB
Zeichen × und ○ …
Wo finde ich denn diese Zeichen?
In diesem Posting. Irgendwo in diesem Thread findest du auch die Codepoints. Ansonsten findest du sie in Zeichentabellen – z.B. in der deines Betriebssystems.
Wenn du meinst „wo finde ich denn diese Zeichen auf meiner Tastatur?“ – Vermutlich gar nicht. Aber das trifft auf die überwältigende Mehrheit aller Zeichen zu.
LLAP 🖖
Aloha ;)
Die Verwendung von Unicode ist - gerade für Anfänger, aber auch für einige Fortgeschrittene - eben nicht selbstverständlich
Doch, sie ist so selbstverständlich, dass man dazu noch nie was von Unicode gehört haben muss. Es ist ab HTML 4.0 gar nicht möglich, nicht Unicode zu verwenden.
Guter Witz. Du weißt ganz genau, dass das vollkommen an dem vorbeigeht, was ich (und andere) sagen wollen. Spätestens dann, wenn ich ein Zeichen nicht mehr über meine Tastatur erreichen kann ist das erhöhte Komplexität. Bitte hör auf, Aussagen mit voller Absicht[1] falsch zu verstehen - das erschwert die Kommunikation massiv. Und erhöht nicht gerade meine Lust, weiterzudiskutieren[2].
Auch nicht semantischer Art, das zeigt schon der Umstand, dass das × als Multiplikationszeichen klassifiziert ist - insofern sind hier weder x noch × einander aus solchen Gründen vorzuziehen.
Das stimmt. Der Grund ist einfach, dass × als Kreuz besser aussieht als x und ○ als Kreis besser als o.
Das ist ausschließlich persönliche Vorliebe und nichts, was in allgemeine Empfehlungen (wie sie ein Tutorial zwangsläufig darstellt) einfließen muss oder sollte.
Und dass ich keinen Grund sehe, nicht × und ○ im Stylesheet als Wert für
contentzu verwenden.
Ich glaube nicht, dass ich den offensichtlichen Grund noch einmal nennen muss, nachdem außer dir in dieser Diskussion bisher alle anderen der Meinung waren, dass tatsächlich Komplexität entsteht. Selbst wenn du das persönlich anders siehst ist es nicht besonders anständig, zu ignorieren, dass andere einen Grund nennen. Immerhin geht es hier nicht darum, was für dich persönlich Komplexität erzeugt oder nicht, sondern ob man von einem allgemeinen Standpunkt her davon ausgehen kann, dass Komplexität erzeugt wird.
Ich mag dir keine böse Absicht unterstellen[3], aber dennoch ist es nicht besonders zielführend oder konstruktiv, wenn man gebetsmühlenartig ausschließlich seine eigene Meinung wiederholt, ohne der Meinung anderer auch gebührenden Platz einzuräumen.
Grüße,
RIDER
@@Camping_RIDER
Guter Witz.
Keine Pointe.
Du weißt ganz genau, dass das vollkommen an dem vorbeigeht, was ich (und andere) sagen wollen. Spätestens dann, wenn ich ein Zeichen nicht mehr über meine Tastatur erreichen kann ist das erhöhte Komplexität.
Nein, ich weiß nicht, was du sagen willst. Ich weiß, was du sagst. Und das ist jetzt schon das zweite Mal binnen kurzer Zeit, dass du nicht das sagst, was du willst. Du meinst „ein Nicht-ASCII-Zeichen per Tastatur eingeben“, sagst aber „Unicode verwenden“.
Bei n00bs würde ich versuchen zu entschlüsseln, was gemeint ist. Bei dir erwarte ich aber eine korrekte Ausdrucksweise und rate nicht wild herum.
Bitte hör auf, Aussagen mit voller Absicht falsch zu verstehen
Ich hab nie damit angefangen.
Das stimmt. Der Grund ist einfach, dass × als Kreuz besser aussieht als x und ○ als Kreis besser als o.
Das ist ausschließlich persönliche Vorliebe
Nicht nur meine. Kann sein, dass die falschen™ Leute kennst.
dass tatsächlich Komplexität entsteht.
Wobei nun genau? Beim Kopieren und Einfügen von 'content: "×"', was ja unglaublich komplexer ist als das Kopieren und Einfügen von 'content: "x"'?
Beim Abtippen, wobei die Tipse statt 'content: "×"' einfach 'content: "x"' tippt?
Und wer wirklich '×' tippen will, der weiß, dass sein Betriebssystem sowas wie die Zeichentabelle (um mal den Windows-Namen dafür zu verwenden) bereitstellt. Was denkst du, wie oft ich die verwende‽
aber dennoch ist es nicht besonders zielführend oder konstruktiv, wenn man gebetsmühlenartig ausschließlich seine eigene Meinung wiederholt
Dann ist also mit einem baldigen Ende der Komplexitäts-Mühle zu rechnen?
LLAP 🖖
Aloha ;)
Guter Witz.
Keine Pointe.
Gut, da auch mir gerade das Lachen im Hals stecken geblieben ist.
Du meinst „ein Nicht-ASCII-Zeichen per Tastatur eingeben“, sagst aber „Unicode verwenden“.
Und sowohl du als auch alle anderen Mitleser haben offenbar kein Problem damit zu verstehen, was ich sagen will. Trotzdem beharrst du wie wild darauf, dass ich mich korrekt und entsprechend verklausuliert ausdrücke und das ist dir offensichtlich wichtig genug, mich lediglich aufgrund der Formulierung und nicht etwa aufgrund des Inhalts oder des offenkundigen Sinns dahinter in eine Diskussion zu verwickeln. Es tut mir leid, aber dafür ist mir meine Zeit dann doch auch irgendwie zu schade. Ich wünsche mir Konstruktivität, und die drückt sich auch darin aus, dass man andere auch dann versucht zu verstehen, wenn sie nicht exakt das sagen, was sie offensichtlich meinen. Das betrifft nicht nur n00bs sondern jegliche Kommunikation, andernfalls tritt man ausschließlich wegen Formulierungen auf der Stelle.
Das stimmt. Der Grund ist einfach, dass × als Kreuz besser aussieht als x und ○ als Kreis besser als o.
Das ist ausschließlich persönliche Vorliebe
Nicht nur meine. Kann sein, dass die falschen™ Leute kennst.
Mag sein, aber bezogen auf die in diesem Thread Beteiligten stehst du damit tatsächlich offenbar alleine - zumindest insofern, dass alle anderen es nicht derart gravierend finden, dass man das damit einhergehende Problempotenzial (Komplexität) riskieren sollte.
dass tatsächlich Komplexität entsteht.
Wobei nun genau? Beim Kopieren und Einfügen von '
content: "×"', was ja unglaublich komplexer ist als das Kopieren und Einfügen von 'content: "x"'?Beim Abtippen, wobei die Tipse statt '
content: "×"' einfach 'content: "x"' tippt?
Auch hier erwähnst du nur deine Sichtweise und vergisst dem Platz einzuräumen, dass du sehr wohl darauf hingewiesen wurdest, dass nicht nur entweder kopiert oder abgetippt sondern auch mal beides gemischt wird. Das ist genau das, was ich als Gebetsmühle bezeichne - du wiederholst das und genau und ausschließlich das, was deine Meinung widerspiegelt und lässt alle anderen Überlegungen, auf die du durchaus von verschiedenen Seiten hingewiesen wurdest, außen vor.
Und wer wirklich '×' tippen will, der weiß, dass sein Betriebssystem sowas wie die Zeichentabelle (um mal den Windows-Namen dafür zu verwenden) bereitstellt. Was denkst du, wie oft ich die verwende‽
Doch, glaube ich dir. Ich mache das auch. Gelegentlich. Ist mir im Übrigen jedes Mal ein Graus. Außerdem ist die Zeichentabelle so gut wie keinem Anfänger ein Begriff. Es kann doch gut vorkommen, dass einem Anfänger auffällt, dass da im Tutorial irgend so ein anderes Zeichen als x vorkommt - er ist dann erstmal irritiert. Wenn er das Zeichen tippen will weiß er nicht wie - wenn du die Zeichentabelle als Vorwissen bezeichnest, dann hattest du schon lange nicht mehr mit wirklichen Anfängern zu tun. Das ist Komplexität (z.B. schon allein die entstehende Irritation, wenn ihm der Unterschied zwischen × und x auffällt), die im Rahmen eines Tutorials, das einen ganz anderen Lehrstoff zugrunde liegen hat, nicht sinnvoll ist.
aber dennoch ist es nicht besonders zielführend oder konstruktiv, wenn man gebetsmühlenartig ausschließlich seine eigene Meinung wiederholt
Dann ist also mit einem baldigen Ende der Komplexitäts-Mühle zu rechnen?
Ich finde es sehr schade, dass du meine durchaus konstruktiv gemeinte Kritik[1] mit einer Provokation[2] erwiderst ohne dabei auch nur ansatzweise darauf einzugehen, ob an meiner Kritik nun was dran ist oder nicht.
Grüße,
RIDER
meine Lust zu antworten schwindet nämlich tatsächlich rapide - und ich gehe jetzt davon aus, dass es hoffentlich auch in deinem Interesse ist, dass strittige Punkte auf Augenhöhe diskutiert und nicht einfach mangels Lust am Diskussionsstil mit Schweigen im Walde quittiert werden ↩︎
Wenn vor meiner Haustüre ein Laubblatt liegt und vor deiner ein großer Laubhaufen, ich dich dann darauf hinweise, dass du vielleicht mal das Laub wegfegen solltest und du dann erwiderst "du könntest auch mal dein Laub wegfegen", an deinem Laubhaufen aber nichts zu ändern gedenkst[3], dann ist das Provokation. - Zumal mir dein Laubhaufen im Grunde genommen egal wäre, wenn ich nicht um dein Wohl besorgt und davon überzeugt wäre, dass du damit Besucher abschreckst an deiner Haustüre zu klingeln. ↩︎
Und ja, das unterstelle ich jetzt einfach mal, auch im Hinblick auf das weitere Treten von Gebetsmühlen in deiner Antwort. ↩︎
@@Camping_RIDER
Und sowohl du als auch alle anderen Mitleser haben offenbar kein Problem damit zu verstehen, was ich sagen will.
Und das sagst du, nachdem ich gerade dargelegt hatte, dass auf mich das Gegenteil zutrifft‽
Nochmals: Ich verstehe das, was du sagst, nicht das was du sagen willst. Wenn dir daran liegt verstanden zu werden, bringe bitte beides in Einklang.
Mag sein, aber bezogen auf die in diesem Thread Beteiligten stehst du damit tatsächlich offenbar alleine - zumindest insofern, dass alle anderen es nicht derart gravierend finden, dass man das damit einhergehende Problempotenzial (Komplexität) riskieren sollte.
Dann ist es ja gut, dass ich nicht am Artikel im Wiki rumeditiert habe. Wenn ich das getan hätte, hätten andere womöglich gedacht: ja, so kann man’s auch machen. Und niemand hätte sich getraut, meine Änderungen rückgängig zu machen (sie wären ja nicht falsch gewesen).
Felix hätte sich vielleicht ein bisschen geärgert, dass die Verwendung von Zeichen, die sich nicht so einfach auf der Tastatur eingeben lassen, den Fokus seines Artikels vom eigentlichen Thema ablenkt.
Womit wir wieder beim Thema wären, dass ich der Ansicht bin, dass in sich geschlossene Artikel in der Autorenschaft eines einzelnen (oder weniger) sein sollten.
LLAP 🖖
Lieber Gunnar,
Nochmals: Ich verstehe das, was du sagst, nicht das was du sagen willst. Wenn dir daran liegt verstanden zu werden, bringe bitte beides in Einklang.
ich hatte Dir ja schon Handlungsbedarf in dieser Hinsicht attestiert. Du darfst gerne mal die Wikipedia in Sachen Kommunikationsmodelle befragen und Dich an den Faszinationen der Sprechakt-Theorie ergötzen. Was aber voraussetzt, dass Du den Handlungsbedarf überhaupt einzusehen bereit bist.
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
Nochmals: Ich verstehe das, was du sagst, nicht das was du sagen willst. Wenn dir daran liegt verstanden zu werden, bringe bitte beides in Einklang.
[…] Was aber voraussetzt, dass Du den Handlungsbedarf überhaupt einzusehen bereit bist.
Es geht hier nicht im Allgemeinen darum, wie genau ich die Ausdrucksweise von irgendwem nehme; sondern im Speziellen darum, dass ich bei Camping_RIDER (und einigen anderen hier) eine genaue Ausdrucksweise erwarte. „Erwarte“ nicht im Sinne von „verlange“, sondern im Sinne von „ich käme gar nicht auf die Idee, dass er ertwas anderes meinen könnte als das, was er sagt“.
Bloß gut, dass Camping_RIDER nichts mit Gebieten zu tun hat, wo es auf genauen Ausdruck ankommt – Mathematik z.B. ;-)
LLAP 🖖
Aloha ;)
Es geht hier nicht im Allgemeinen darum, wie genau ich die Ausdrucksweise von irgendwem nehme; sondern im Speziellen darum, dass ich bei Camping_RIDER (und einigen anderen hier) eine genaue Ausdrucksweise erwarte. „Erwarte“ nicht im Sinne von „verlange“, sondern im Sinne von „ich käme gar nicht auf die Idee, dass er ertwas anderes meinen könnte als das, was er sagt“.
Nanana, auf Spezialbehandlung verzichte ich gerne. Außerdem bin ich verwundert, da du offenbar selbst dann nicht auf diese Idee kommst, wenn man dich ausdrücklich darauf hinweist - das wäre ja meiner Erinnerung nach auch nicht das erste mal gewesen.
Bloß gut, dass Camping_RIDER nichts mit Gebieten zu tun hat, wo es auf genauen Ausdruck ankommt – Mathematik z.B. ;-)
Nicht umsonst fällt es der Mathematik schwer, einfach verständliche Aussagen zu formulieren. Wenn du deine Aussagen gerne auf mathematischem Niveau siehst - bitte. Ich bin ganz froh darüber, dass meine Aussagen diesen Anspruch nicht erheben wollen. Außerdem würde ich solche Aussagen dann schon mit "Mathematik" taggen - immerhin ist das nicht das einzige Gebiet mit dem ich zu tun habe[1] ;)
Aber wie Felix schon sagte[2]:
Was aber voraussetzt, dass Du den Handlungsbedarf überhaupt einzusehen bereit bist.
Grüße,
RIDER
@@Camping_RIDER
Nanana, auf Spezialbehandlung verzichte ich gerne.
Mir widerstrebt es, Leute für dümmer zu halten als sie sind. Dass ich bei dir von einer genaueren Ausdruckweise als bei anderen ausgehe, ist keine Abwertung, sondern eine Aufwertung für dich.
Nicht umsonst fällt es der Mathematik schwer, einfach verständliche Aussagen zu formulieren.
Einfach verständlich != eindeutig verständlich. Für letzteres hat die Mathematik ihre Formelsprache.
Die natürliche Sprache ist desöfteren nicht eindeutig. Das kann zu Missverständnissen führen – die sich meist ausräumen lassen. Das wäre auch in diesem Fall nicht weiter tragisch gewesen, wenn du nicht darauf bestanden hättest, ich würde dich absichtlich falsch verstehen.
LLAP 🖖
Aloha ;)
Nanana, auf Spezialbehandlung verzichte ich gerne.
Mir widerstrebt es, Leute für dümmer zu halten als sie sind. Dass ich bei dir von einer genaueren Ausdruckweise als bei anderen ausgehe, ist keine Abwertung, sondern eine Aufwertung für dich.
Darauf zu setzen, dass das Gegenüber in einer Konversation seine Interpretationsgabe gebraucht ist kein Zeichen von Dummheit, sondern eine natürliche Eigenschaft von Konversation.
Nicht umsonst fällt es der Mathematik schwer, einfach verständliche Aussagen zu formulieren.
Einfach verständlich != eindeutig verständlich. Für letzteres hat die Mathematik ihre Formelsprache.
Genau[1]. Wie du schon sagtest ist natürliche Sprache nicht eindeutig. Deshalb wundert es mich, warum du so darauf versessen bist, mir den Anspruch auf eindeutige Sprache zunächst zu unterstellen und daraufhin nahezu aufzuzwingen[2].
Die natürliche Sprache ist desöfteren nicht eindeutig. Das kann zu Missverständnissen führen – die sich meist ausräumen lassen. Das wäre auch in diesem Fall nicht weiter tragisch gewesen, wenn du nicht darauf bestanden hättest, ich würde dich absichtlich falsch verstehen.
Nun, dieser Eindruck drängt(e) sich mir auf. Immerhin hast du bei nahezu jeder meiner Aussagen, die du für Ungenauigkeit kritisierst, direkt und teils ohne Aufforderung auch die korrekte Interpretation mitgeliefert. Sollte das ein Missverständnis gewesen sein tut es mir leid, dass ich von Absicht deinerseits ausgegangen bin - du solltest dann aber eventuell auch in Erwägung ziehen, die vorangegangenen Postings noch einmal durchzuschauen und dir zu überlegen, ob nicht doch irgendwie gearteter kommunikativer Handlungsbedarf besteht, wenn du die Intention meiner Aussagen nicht zügig verstanden hast[3], wie ich angenommen hatte.
Ich habe nicht vor, irgendwelche Schuldzuweisungen, Angriffe oder Anspielungen los zu werden und das war auch bisher eigentlich nicht mein Ziel[4]; nicht zuletzt ist Kommunikation immer Interpretationssache auf beiden Seiten. Ich bitte lediglich darum, nicht in Diskussionen über Formulierungen verwickelt zu werden, wenn die Bedeutungsintention einfach ersichtlich ist[5], im Zweifelsfall hilft auch Nachfrage.
Für den vergangenen Fall können wir das gerne als Misverständnis ad acta legen, ich bin nur nicht auf eine Wiederholung erpicht.
Grüße,
RIDER
Die Mathematik versucht aber auch, statt gewöhnlicher Sprache eine Zeichensprache beziehungsweise deren Transliteration zu verwenden, bei der jedem Zeichen eine eindeutige Bedeutung zukommt. Das ist genau dem Umstand geschuldet, dass Sprache ohne genaue Bedeutungsdefinition gar nicht geeignet ist, eindeutige Aussagen zu treffen. Die Sprache der Mathematik hat daher soviel mit Kommunikation und natürlicher Sprache zu tun wie Äpfel mit Birnen - beides ist Fallobst. Deshalb käme ich ja auch nie auf die Idee, beide in ihrem Anspruch aneinander angleichen zu wollen. ↩︎
oder wie sonst soll man zunächst den Seitenhieb in Richtung Mathematik und daraufhin die obige Aussage, Stichwort dumm, verstehen, wobei sich letztere so liest als ob nicht-eindeutige Sprache ein Zeichen oder zumindest Begleitumstand irgendwie-gearteter Dummheit sei? - Ich hoffe mal, dass ich letzteres überinterpretiere. ↩︎
ich sage nicht, dass die Problematik bei dir liegen muss; sie kann genauso gut bei mir liegen - ich bilde mir lediglich ein, ausreichend deutlich gewesen zu sein; ob du dem Bedeutung beimessen möchtest liegt bei dir. ↩︎
Mein Ziel war, wie auch schon in einem früheren Posting ausdrücklich geschrieben, die konstruktive Kritik im Sinne einer Veränderung, weil ich die Ist-Situation als ungünstig empfand. ↩︎
Ohne dabei eine objektive Wertung zu formulieren, ob das im hier geschehenen Fall gegeben war - das soll mir jetzt mal egal sein, es bringt nichts, darüber in Streit zu verfallen. ↩︎
Hallo Felix
Lieber Gunnar, je mehr ich über diese Antwort nachdenke, desto scheinheiliger erscheint sie mir.
Als scheinheilig sehe ich das nicht. Es geht um zwei unterschiedliche Ansichten. Bereits Aristoteles hat zwischen Meinung und Wissen unterschieden. Und darum geht es: Meine Meinung gehört mir, mein allgemeines Wissen teile ich mit anderen.
Ein Artikel, in dem ich über meine Meinung schreibe, ist mein Artikel und ich habe ihn allein zu verantworten. Er kann von anderen kommentiert, aber nicht nach deren Meinung umgeschrieben werden.
Bei einem Artikel über allgemeines Wissen verhält es sich anders. Viele verfügen über das gleiche Wissen, sie sind höchsten unterschiedlicher Meinung, wie es vermittelt werden kann. Solche Artikel können im Kollektiv geschrieben und überarbeitet werden.
Wir benötigen Mitarbeit im Wiki. Alles, was unsere Inhalte verbessert oder aktuell macht, ist nützlich und somit im Interesse von SELFHTML.
Was soll eine "richtige" Basis für "solche" Artikel sein? Dass da nur einer schreibt? Als ob einer immer das Wissen gepachtet hätte...
Ich verfolge die Entwicklung mit grossem Interesse. Ich würde mich gern davon überraschen lassen, dass Leute bereit sind, ihre Texte in ein Kollektiv einzubringen. Ich halte das nicht für unmöglich, aber für extrem schwierig. Die offensichtlich mangelnde Bereitschaft in diesem Wicki zu schreiben bestätigt diese Schwierigkeit.
Mit besten Grüssen
Richard
@@Richard Rüfenacht
Bei einem Artikel über allgemeines Wissen verhält es sich anders. Viele verfügen über das gleiche Wissen, sie sind höchsten unterschiedlicher Meinung, wie es vermittelt werden kann. Solche Artikel können im Kollektiv geschrieben und überarbeitet werden.
Das kann gutgehen. Oder auch nicht. Womöglich kriegt man die unterschiedlichen Stile, das Wissen zu vermitteln, nicht unter einen Hut; es kommt nichts Halbes und nichts Ganzes raus. Dann wäre es wohl besser, es gibt mehrere Artikel, die das Wissen auf unterschiedliche Art vermitteln.
LLAP 🖖
Hallo Gunnar
Womöglich kriegt man die unterschiedlichen Stile, das Wissen zu vermitteln, nicht unter einen Hut; es kommt nichts Halbes und nichts Ganzes raus.
Ja, die Erfahrung bestätigt das. Aber die Hoffnung auf eine Lösung bleibt.
Dann wäre es wohl besser, es gibt mehrere Artikel, die das Wissen auf unterschiedliche Art vermitteln.
Das ist eine mögliche Lösung. Allerdings entsteht dadurch die Schwierigkeit, aus der Vielzahl der Artikel den richtigen – den für die jeweils suchende Person richtigen – zu finden.
Mit besten Grüssen
Richard
Hallo
Bei einem Artikel über allgemeines Wissen verhält es sich anders. Viele verfügen über das gleiche Wissen, sie sind höchsten unterschiedlicher Meinung, wie es vermittelt werden kann. Solche Artikel können im Kollektiv geschrieben und überarbeitet werden.
Das kann gutgehen. Oder auch nicht. Womöglich kriegt man die unterschiedlichen Stile, das Wissen zu vermitteln, nicht unter einen Hut; es kommt nichts Halbes und nichts Ganzes raus. Dann wäre es wohl besser, es gibt mehrere Artikel, die das Wissen auf unterschiedliche Art vermitteln.
Es ist genausowenig Raketentechnik, durch verschiedene Autoren vorgenommene Korrekturen, so sich sich als zutreffend herausgestellt haben, stilistisch zu vereinheitlichen.
Tschö, Auge
@@Auge
Das kann gutgehen. Oder auch nicht. Womöglich kriegt man die unterschiedlichen Stile, das Wissen zu vermitteln, nicht unter einen Hut; es kommt nichts Halbes und nichts Ganzes raus. Dann wäre es wohl besser, es gibt mehrere Artikel, die das Wissen auf unterschiedliche Art vermitteln.
Es ist genausowenig Raketentechnik, durch verschiedene Autoren vorgenommene Korrekturen, so sich sich als zutreffend herausgestellt haben, stilistisch zu vereinheitlichen.
Es sollte klargeworden sein, dass es sich hierbei nicht nur um verschiedene Sprachstile, sondern um grundsätzlich verschiedene konzeptionelle Ansätze handeln könnte.
Von denen jeder seine Berechtigung hat, aber ein Mix daraus nichts Brauchbares ergibt.
LLAP 🖖
Hallo
Ein Artikel, in dem ich über meine Meinung schreibe, ist mein Artikel …
Bei einem Artikel über allgemeines Wissen verhält es sich anders. …
Unsere Fachartikel fallen doch wohl in die zweite Kategorie, oder?
… Viele verfügen über das gleiche Wissen, sie sind höchsten unterschiedlicher Meinung, wie es vermittelt werden kann. Solche Artikel können im Kollektiv geschrieben und überarbeitet werden.
Dass das von Seiten Gunnars nicht geschieht, ist Felix' Punkt. Inwiefern er damit an jeder von ihm kritisierten Stelle richtig liegt, sei mal dahingestellt.
Wir benötigen Mitarbeit im Wiki. Alles, was unsere Inhalte verbessert oder aktuell macht, ist nützlich und somit im Interesse von SELFHTML.
Was soll eine "richtige" Basis für "solche" Artikel sein? Dass da nur einer schreibt? Als ob einer immer das Wissen gepachtet hätte...
Na eben nicht. Deshalb fordert Felix ja die Mitarbeit ein.
Ich verfolge die Entwicklung mit grossem Interesse. Ich würde mich gern davon überraschen lassen, dass Leute bereit sind, ihre Texte in ein Kollektiv einzubringen. Ich halte das nicht für unmöglich, aber für extrem schwierig. Die offensichtlich mangelnde Bereitschaft in diesem Wicki zu schreiben bestätigt diese Schwierigkeit.
Meiner Meinung nach liegt die wenige Mitarbeit nicht nur an der mangelnden Bereitschaft, Texte in ein Kollektiv einzubringen. Das wird auf einige fachlich potente Menschen zutreffen, die sich sagen, dass ihr Text ihrer ist oder auf Menschen, die die Lizenzbestimmungen nicht deuten können. Ich glaube aber, dass da mehr [1] Menschen sind, die mitarbeiten wollen, sich aber nicht trauen, sich der zwangsläufig aufpoppenden Kritik zu stellen. Beim hier normalen rauhen Ton, den ich ja auch gerne mal pflege, ist das keineswegs ehrenrührig. Andererseits hilft ein „Ihr müsst keine Angst vor uns haben.“ so auch nicht.
Tschö, Auge
Ich bitte darum, aus „einige“ vs. „mehr“ kein Zahlenverhältnis ableiten zu wollen. ↩︎
Lieber Gunnar,
so ’ne Idee vom Businesscasper
gefällt mir! Und nein, das große "scharf-s" hat noch immer nichts in GROSSSCHRIFT zu suchen. Da finde ich es toll, dass ß bei text-transform: uppercase zu "SS" wird! Und das sollte meiner Meinung nach auch so bleiben, auch wenn irgendwelche sprachfernen UTF-Kasper diesen Großbuchstaben erfunden haben.
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
Und nein, das große "scharf-s" hat noch immer nichts in GROSSSCHRIFT zu suchen.
Wo sonst? Man braucht es nur in Versalschrift.
auch wenn irgendwelche sprachfernen UTF-Kasper diesen Großbuchstaben erfunden haben.
Das ist gleich doppelt Unsinn.
Zum einen ist UTF-irgendwas kein Zeichensatz; du meinst Unicode.
Zum anderen gab es das große ẞ schon lange vor Unicode – seit 1879. Und in Unicode gibt es das noch gar nicht so lange – erst seit Version 5.1 (2008).
Die Herausgeber des Dudens würde ich auch nicht als „sprachferne Kasper“ bezeichnen.
(Quelle: Wikipedia)
LLAP 🖖
Aloha ;)
Zum anderen gab es das große ẞ schon lange vor Unicode – seit 1879. Und in Unicode gibt es das noch gar nicht so lange – erst seit Version 5.1 (2008).
In diesem Punkt steckst du leider in einer Apfel-bedingten Filterblase - aus praktischen Gründen. Der Umstand, dass Unicode ein solches Zeichen kennt ist nur dann hilfreich, wenn auch die Schriftart (oder deren Vervollständigung) das entsprechend umsetzt. Ich sehe unter Android hier im Postingtext nur ein Kästchen (wie so oft bei ausgefalleneren Unicode-Zeichen). Damit ist das vom Duden im Wikipedia-Artikel zitierte Ziel
Die Verwendung zweier Buchstaben für einen Laut ist nur ein Notbehelf, der aufhören muss, sobald ein geeigneter Druckbuchstabe für das große ß geschaffen ist.
zumindest für das Web (im Printbereich mag anderes gelten) noch nicht erreicht, da sonst potenziell User ausgeschlossen werden. Hier ist es also durchaus vertretbar (auch nach Formulierung des Duden) Ersatzzeichen zu verwenden.
Dass es oft zweischneidig ist, mit Unicode zu argumentieren, zeigt schon die an anderer Stelle diskutierte Sache mit den in manchen Systemen rot gefärbten x und o...
Grüße,
RIDER
@@Camping_RIDER
Zum anderen gab es das große ẞ schon lange vor Unicode – seit 1879. Und in Unicode gibt es das noch gar nicht so lange – erst seit Version 5.1 (2008).
In diesem Punkt steckst du leider in einer Apfel-bedingten Filterblase
Den Einstieg hast du schon mal versaut. Nachdem ich sagte, dass das Aufkommen des großen ẞ rein gar nichts mit Computern zu tun hat, kommst du mit – Computern. Mehr noch: mit Smartphones, die es kaum länger gibt als das ẞ in Unicode.
aus praktischen Gründen.
Wenn du meinst, der Einsatz des ẞ sei (noch) problematisch, weil einige verkorkste Systeme das nicht darstellen können, dann sag das doch gleich.
Ich sehe unter Android hier im Postingtext nur ein Kästchen (wie so oft bei ausgefalleneren Unicode-Zeichen).
Ich hab glücklicherweise kein Gerät zur Hand, um das zu verifizieren. ;-)
zumindest für das Web (im Printbereich mag anderes gelten) noch nicht erreicht
Zählt ein Aufdruck auf einem Bus zum Printbereicht?
LLAP 🖖
Aloha ;)
Den Einstieg hast du schon mal versaut. Nachdem ich sagte, dass das Aufkommen des großen ẞ rein gar nichts mit Computern zu tun hat, kommst du mit – Computern. Mehr noch: mit Smartphones, die es kaum länger gibt als das ẞ in Unicode.
Es ging mir auch ganz konkret um die Frage, was wir im Webbereich mit dem großen ẞ anfangen sollen (unter Windows wirds übrigens dargestellt, auch im Chrome); alles andere ist zwar schön und gut aber für die Fragestellung hier eher irrelevant.
aus praktischen Gründen.
Wenn du meinst, der Einsatz des ẞ sei (noch) problematisch, weil einige verkorkste Systeme das nicht darstellen können, dann sag das doch gleich.
Wollte ich damit ;) Du solltest aber erwähnen, dass das "einige verkorkste Systeme" einen sehr großen Anteil der Endgeräte betrifft; in deiner Aussage hört sich das vernachlässigbar an (was es nicht ohne weitere Annahmen ist).
zumindest für das Web (im Printbereich mag anderes gelten) noch nicht erreicht
Zählt ein Aufdruck auf einem Bus zum Printbereicht?
Mit Printbereich wollte ich all das bezeichnen, was nicht auf das Vorhandensein einer bestimmten Schriftart beim Client setzt, also ja. Im Übrigen, damit wir uns da nicht falsch verstehen: Über meine persönliche Meinung, ob man im Printbereich ẞ einsetzen sollte, habe ich nichts gesagt (habe ich auch in diesem Rahmen nicht vor), lediglich zugestanden, dass es da mehr und anderen Diskussionsbedarf als im Webbereich gibt ;)
Grüße,
RIDER
@@Camping_RIDER
Du solltest aber erwähnen, dass das "einige verkorkste Systeme" einen sehr großen Anteil der Endgeräte betrifft; in deiner Aussage hört sich das vernachlässigbar an
„Einige verkorkste Systeme“ war qualitativ gemeint (Betonung auf „verkorkste“), nicht quantitativ (Betonung auf „einige“). Man verzeihe mir meine ungenaue Ausdrucksweise. 😈
was nicht auf das Vorhandensein einer bestimmten Schriftart beim Client setzt
Dann erledigt sich ja das Nichtvorhandensein des ẞ auf verkorksten Systemen mit dem nächsten Update.
Oh – verkorkste Systeme bekommen ja gar keine Updates …
LLAP 🖖
PS: Mein System braucht auch ein Update; mir fehlt auch ein Zeichen:
Aloha ;)
PS: Mein System braucht auch ein Update; mir fehlt auch ein Zeichen:
Wenns mal nur ein Zeichen wäre - mir fehlen ständig welche. So gut wie immer, wenn du ein nicht-ASCII-Zeichen benutzt sehe ich nur Kästchen. Gut, dass mich meine Interpretationsfähigkeit befähigt, sehr gut zu erraten, welches Zeichen du da benutzt hast.
Auch an dieses Kästchen habe ich mich gewöhnt - ich sehe das Symbol auf keinem meiner zig verschiedenen Systeme.
Ansonsten finde ich die Kästchen nicht schlimm - sie sind mir eine stete Mahnung dafür, dass Unicode zwar sinnvoll ist (Aufhebung der Kodierungs-Problematik bei konsequenter Verwendung), aber weit davon entfernt ist, eine eierlegende Wollmilchsau zu sein (wie es gelegentlich gerne gehandelt wird).
Grüße,
RIDER
Hallo,
Auch an dieses Kästchen habe ich mich gewöhnt - ich sehe das Symbol auf keinem meiner zig verschiedenen Systeme.
das ist weniger vom System, als vielmehr von der verwendeten bzw. den verfügbaren Schriftarten abhängig. Hier im Posting-Text, wo mein Browser Courier New als Festbreitenschrift verwendet, sehe ich für den Vulkanier-Gruß auch nur ein Klötzchen; in den meisten anderen Schriften passt es aber.
Ansonsten finde ich die Kästchen nicht schlimm - sie sind mir eine stete Mahnung dafür, dass Unicode zwar sinnvoll ist (Aufhebung der Kodierungs-Problematik bei konsequenter Verwendung), aber weit davon entfernt ist, eine eierlegende Wollmilchsau zu sein (wie es gelegentlich gerne gehandelt wird).
Aber fast. ;-)
Es fehlt ja in dem Fall nur der letzte Schritt in der Verarbeitungskette: Die Darstellung. Aber die Information, welches Zeichen dort stehen soll, bleibt stets erhalten.
So long,
Martin
Hallo Martin,
das ist weniger vom System, als vielmehr von der verwendeten bzw. den verfügbaren Schriftarten abhängig. Hier im Posting-Text, wo mein Browser Courier New als Festbreitenschrift verwendet, sehe ich für den Vulkanier-Gruß auch nur ein Klötzchen; in den meisten anderen Schriften passt es aber.
font-family:Consolas,Monaco,"DejaVu Sans Mono","Bitstream Vera Sans Mono","Andale Mono","Droid Sans Mono","Lucida Console",monospace;monospace im Speziellen ist der Browser angehalten, eine Monospace-Schrift zu suchen, die alle verwendeten Zeichen abdeckt. Kann er also eine Glyphe nicht finden, soll er sie in einer anderen Schrift suchen.LG,
CK
Moin Christian,
das ist weniger vom System, als vielmehr von der verwendeten bzw. den verfügbaren Schriftarten abhängig. Hier im Posting-Text, wo mein Browser Courier New als Festbreitenschrift verwendet, sehe ich für den Vulkanier-Gruß auch nur ein Klötzchen; in den meisten anderen Schriften passt es aber.
1. es wird nicht Courier New verwendet:
font-family:Consolas,Monaco,"DejaVu Sans Mono","Bitstream Vera Sans Mono","Andale Mono","Droid Sans Mono","Lucida Console",monospace;
ich habe mir jetzt nicht die Mühe gemacht, die ganze Kaskade zu verfolgen bzw. den Quelltext anzusehen, aber Dragenfly gibt mir als Computed Style für die Posting-Textarea "Courier New" an, obwohl - und hier wundere ich mich selbst auch - DejaVu Sans Mono die erste Schrift in der Aufzählung ist, die auch auf meinem System verfügbar ist, und genau diese Schrift in meinem Opera sogar als Default für Monospace eingestellt ist. Das Schriftbild sieht aber eher nach Lucida Console aus.
Könnte aber sein, dass das eine generelle Voreinstellung in meinem Opera ist, der ja meinem Wunsch entsprechend das Styling von Formularelementen nur sehr eingeschränkt zulässt.
Der Textblock mit der normalen Posting-Ansicht (auch Vorschau) ist allerdings in DejaVu Sans Mono, wie ich es erwarten würde.
3. die Glyphe, die Gunnar verwendet, ist das vulkanische „live long and prosper” – diese Glyphe ist noch sehr neu und bisher in keiner mir bekannten freien Schrift enthalten. Deshalb siehst du dort das Kästchen.
So wird's wohl sein. Ich habe das Zeichen aber auch schon korrekt dargestellt gesehen, weiß aber nicht mehr, in welchem Kontext oder auf welchem Rechner. Könnte eventuell auf einem Windows-PC gewesen sein.
So long,
Martin
@@Christian Kruse
- die Glyphe, die Gunnar verwendet, ist das vulkanische „live long and prosper” – diese Glyphe ist noch sehr neu und bisher in keiner mir bekannten freien Schrift enthalten. Deshalb siehst du dort das Kästchen.
Liegt es nicht daran, dass manche Browser (oder OS?), wenn sie in keinem der in der Kette angegebenen Font eine Glyphe für ein bestimmtes Zeichen finden, auch noch in anderen auf dem System installierten Fonts danach suchen, während andere Browser (OS?) das nicht tun?
Das würde die Beobachtung von Dem Martin erklären:
Hier im Posting-Text […] sehe ich für den Vulkanier-Gruß auch nur ein Klötzchen; in den meisten anderen Schriften passt es aber.
Bei mir auf dem Mac wird das LLAP-Zeichen auch im Posting-Text dargestellt. Auf dem iPhone wie gezeigt nicht; das könnte sich aber mit einem Update auf iOS 9 ändern.
Wobei mir noch etwas unklar ist, ob ich das OS auf dem 4S wirklich updaten sollte. Meinungen?
LLAP 🖖
PS: Der Ausdruck „die Glyphe, die Gunnar verwendet“ trifft es auch nicht ganz, IMHO. Ich verwende keine Glyphen, sondern Zeichen. Der Browser/das OS des Lesers verwendet beim Rendern Glyphen zu den Zeichen aus dem jeweiligen Font.
Hallo Gunnar,
- die Glyphe, die Gunnar verwendet, ist das vulkanische „live long and prosper” – diese Glyphe ist noch sehr neu und bisher in keiner mir bekannten freien Schrift enthalten. Deshalb siehst du dort das Kästchen.
Liegt es nicht daran, dass manche Browser (oder OS?), wenn sie in keinem der in der Kette angegebenen Font eine Glyphe für ein bestimmtes Zeichen finden, auch noch in anderen auf dem System installierten Fonts danach suchen, während andere Browser (OS?) das nicht tun?
Ich würde vermuten, dass das jeder Browser macht; ich habs aber nicht geprüft, mein Wissen kommt aus der W3C-Recommendation.
Aber die LLAP-Glyphe ist z.B. in der Symbolas-Schrift (die am häufigsten verwendete Schrift im Linux-Bereich) einfach (noch) nicht enthalten. Es gibt zZ keine mir bekannte freie Schrift mit einer Glyphe für dieses Zeichen. Damit ist die Chance, dass auf z.B. Linux zu sehen, gleich null.
Bei mir auf dem Mac wird das LLAP-Zeichen auch im Posting-Text dargestellt. Auf dem iPhone wie gezeigt nicht; das könnte sich aber mit einem Update auf iOS 9 ändern.
Ja, die „neuen” Zeichen (dazu gehört VULCAN SALUTE) wurden erst mit iOS 9 eingeführt.
Wobei mir noch etwas unklar ist, ob ich das OS auf dem 4S wirklich updaten sollte. Meinungen?
Ich habe mit iOS 9 nur gute Erfahrungen gemacht, das erste Release seit langem, bei dem ich nicht viel zu meckern habe.
PS: Der Ausdruck „die Glyphe, die Gunnar verwendet“ trifft es auch nicht ganz, IMHO.
Ja, das ist eine Ungenauigkeit in der Sprache gewesen, ich musste das Posting schnell zuende tippen, weil das Telefon klingelte. Man verzeihe mir diesen Ausrutscher. 😀
LG,
CK
Aloha ;)
- die Glyphe, die Gunnar verwendet, ist das vulkanische „live long and prosper” – diese Glyphe ist noch sehr neu und bisher in keiner mir bekannten freien Schrift enthalten. Deshalb siehst du dort das Kästchen.
Liegt es nicht daran, dass manche Browser (oder OS?), wenn sie in keinem der in der Kette angegebenen Font eine Glyphe für ein bestimmtes Zeichen finden, auch noch in anderen auf dem System installierten Fonts danach suchen, während andere Browser (OS?) das nicht tun?
Ich würde vermuten, dass das jeder Browser macht; ich habs aber nicht geprüft, mein Wissen kommt aus der W3C-Recommendation.
Chrome / Android - nein. Nachweislich ist zumindest ein Teil der Zeichen (z.B. ẞ) in einer Schriftart verfügbar (im Titel wirds gerendert) und trotzdem im monospace-Bereich nicht verwendet.
@edit: an Android liegts nicht direkt, unter Firefox gehts (und den Standardbrowser hab ich glaub entsorgt, kann das also nicht prüfen). Ist also wirklich Browsersache.
Grüße,
RIDER
Hallo,
Aber die LLAP-Glyphe ist z.B. in der Symbolas-Schrift (die am häufigsten verwendete Schrift im Linux-Bereich) einfach (noch) nicht enthalten. Es gibt zZ keine mir bekannte freie Schrift mit einer Glyphe für dieses Zeichen. Damit ist die Chance, dass auf z.B. Linux zu sehen, gleich null.
Gute Nachrichten: inzwischen ist sie es.
LG,
CK
Hallo,
3. die Glyphe, die Gunnar verwendet, ist das vulkanische „live long and prosper” – diese Glyphe ist noch sehr neu und bisher in keiner mir bekannten freien Schrift enthalten. Deshalb siehst du dort das Kästchen.
Liegt es nicht daran, dass manche Browser (oder OS?), wenn sie in keinem der in der Kette angegebenen Font eine Glyphe für ein bestimmtes Zeichen finden, auch noch in anderen auf dem System installierten Fonts danach suchen, während andere Browser (OS?) das nicht tun?
ja, ich glaube, das ist so. Zumindest kann ich durch eigene Beobachtung bestätigen, dass z.B. Firefox (sowohl Windows als auch Linux) fehlende Zeichen ggf. auch aus einer anderen Schrift holt, Opera Classic (sowohl Windows als auch Linux) aber offenbar nicht. Ist das Zeichen nirgends aufzutreiben, zeigt Firefox ja auch den Code im Kästchen an, Opera nur ein leeres Kästchen.
Das würde die Beobachtung von Dem Martin erklären:
Hier im Posting-Text […] sehe ich für den Vulkanier-Gruß auch nur ein Klötzchen; in den meisten anderen Schriften passt es aber.
Nein, eher nicht. Ich habe das im Follow-Up schon relativieren müssen: Auf meinen Linux-PCs finde ich in der Tat keine Schrift, in der das Zeichen enthalten ist. Meine Erinnerung an eine korrekte Darstellung stammt vermutlich von einem Windows-PC.
PS: Der Ausdruck „die Glyphe, die Gunnar verwendet“ trifft es auch nicht ganz, IMHO. Ich verwende keine Glyphen, sondern Zeichen. Der Browser/das OS des Lesers verwendet beim Rendern Glyphen zu den Zeichen aus dem jeweiligen Font.
... erklärte der Experte fürs Ausscheiden von Trockenweinbeeren. ;-)
Ciao,
Martin
@@Der Martin
... erklärte der Experte fürs Ausscheiden von Trockenweinbeeren. ;-)
Genau der. ;-)
LLAP 🖖
Hallo Camping_RIDER,
‚LLAP □‘ könnte auch für ‚LLAP q.e.d.‘ stehen
*duck* und *weg*
Bis demnächst
Matthias
Hi,
Die Verwendung zweier Buchstaben für einen Laut ist nur ein Notbehelf, der aufhören muss, sobald ein geeigneter Druckbuchstabe für das große ß geschaffen ist.
Welchen Buchstabe sieht denn der Autor für die Laute "sch", "ch", "eu", "ei" usw. vor? Das muß ja wohl aufhören.
A propo "muß": hier sind am Ende neuerdings zwei Buchstaben für den einen Laut vorgesehen, wo bisher nur ein Zeichen[1] war.
cu,
Andreas a/k/a MudGuard
das "ß" ist eine Ligatur aus zwei Buchstaben ("es+zett"), nicht wirklich ein Buchstabe. ↩︎
Hallo MudGuard,
das "ß" ist eine Ligatur aus zwei Buchstaben ("es+zett"), nicht wirklich ein Buchstabe.
War. Inzwischen ist es als Buchstabe kategorisiert.
LG,
CK
@@MudGuard
Welchen Buchstabe sieht denn der Autor für die Laute "sch", "ch", "eu", "ei" usw. vor? Das muß ja wohl aufhören.
Ist ein Diphtong denn ein Laut?
A propo "muß": hier sind am Ende neuerdings zwei Buchstaben für den einen Laut vorgesehen, wo bisher nur ein Zeichen war.
Das trifft auf „Menü“ auch zu.
das "ß" ist eine Ligatur aus zwei Buchstaben ("es+zett"), nicht wirklich ein Buchstabe.
Das ü ist eine Ligatur aus zwei Buchstaben (u+e), nicht wirklich ein Buchstabe.
LLAP 🖖
Lieber Gunnar,
Ist ein Diphtong denn ein Laut?
es ist ein Doppellaut (daher das "di" in Diphtong), aber ein Phonem.
Liebe Grüße,
Felix Riesterer.
@@MudGuard
A propo "muß": hier sind am Ende neuerdings zwei Buchstaben für den einen Laut vorgesehen
A propos „a propo“: hier ist am Ende nicht erst neuerdings ein Buchstabe für gar keinen Laut vorgesehen. SCNR.
LLAP 🖖
Hallo Gunnar Bittersmann,
A propos „a propo“: hier ist am Ende nicht erst neuerdings ein Buchstabe für gar keinen Laut vorgesehen. SCNR.
Apropos „a propos“: Dies ist im Deutschen nicht erst neuerdings ein Wort. SCNR2
Bis demnächst
Matthias
Hallo
Zum anderen gab es das große ẞ schon lange vor Unicode – seit 1879.
Bestandteil der amtlich verbindlichen deutschen Rechtschreibung ist das große ẞ bis heute nicht. Es existiert, aber es ist nicht gültig und selbst der Duden schrieb lange Zeit, dass das Zeichen "fehlt". Unzweifelhaft ist, dass der Bedarf nach einem großen ẞ schon lange besteht.
Die Herausgeber des Dudens würde ich auch nicht als „sprachferne Kasper“ bezeichnen.
(Quelle: Wikipedia)
Beurteile das Buch nicht nur nach seinem Einband. Dem Duden war bewusst, dass es kein offizielles großes ẞ gab. Das Titelblatt gehorcht den eigenen Regeln nicht - vermutlich ein Marketing-Gag, um dem eigenen Bedarf nach diesem Zeichen Nachdruck zu verleihen.
Zudem verweist Du auf einen Duden, in dem die Wörter Weltreise, Kreuzfahrt, ficken und Arschkriecher nicht vorkamen. Das ist zumindest ein wenig „lebensfern“.
Das ü ist eine Ligatur aus zwei Buchstaben (u+e), nicht wirklich ein Buchstabe.
Was veranlasst Dich zu dieser Aussage, irgendwelche Belege? Die Ligatur aus a+e ist doch ein æ und nicht etwa das ä.
Grüße
@@Bai Se Wey
Das ü ist eine Ligatur aus zwei Buchstaben (u+e), nicht wirklich ein Buchstabe. Quelle
Was veranlasst Dich zu dieser Aussage, irgendwelche Belege?
Die Ligatur aus a+e ist doch ein æ und nicht etwa das ä.
Eine, nicht die. ;-)
LLAP 🖖
Es kommt zwar nicht drauf an, aber dieser Wikipedia-Artikel sagt nicht direkt, dass es sich technisch gesehen um eine Ligatur handelt, oder übersehe ich etwas? Denn nur auf diese Spitzfindigkeit wollte ich hinaus. Mithilfe des Artikels zu Ligaturen lässt sich die Frage auch nicht zweifelsfrei klären. Umlaute finden keine Erwähnung. Da wird mein innerer Pedant aber unruhig schlafen ;-)
Hi there,
Früher wurde, wer nichts wurde, Wirt. Heute wird, wer nichts wird, Betriebswirt...
Aloha ;)
Früher wurde, wer nichts wurde, Wirt. Heute wird, wer nichts wird, Betriebswirt...
Du meinst wohl den Betriebswirt in Stellung eines "Manager of extralaboral affairs"?
Grüße,
RIDER
@@Felix Riesterer
Das
tbody-Element muss sein, damit die Semantik einer Tabelle erhalten bleibt.
Wie bitte? Das tbody-Element muss sein, weil HTML das so vorschreibt.
Die <tbody>- und </tbody>-Tags müssen allerdings nicht sein. Das tbody-Elementobjekt wird auch ohne die Tags im DOM angelegt.
Die gewählte Formulierung „damit die Semantik einer Tabelle erhalten bleibt“ halte ich für irreführend.
Mit der
content-Eigenschaft wird das Symbol für den jeweiligen Spieler in der Tabellenzelle angezeigt, obwohl im HTML-Code kein solcher Inhalt steht. Es ist ein reines Darstellungselement …
Das leuchtet nicht ein. Die Felder werden im Laufe des Spiels mit x und o[1] gefüllt; das ist also Inhalt.
Entweder implementiert man das so, dass x und o tatsächlich Textinhalte der td-Elemente sind, oder man lässt sich eine gute Begründung dafür einfallen, warum man das anders implementiert, obwohl das eigentlich Inhalt wäre.
Wenn man sich für letzteres entscheidet:
.tic-tac-toe .o:after { content: "o"; display: block; text-align: center; } .tic-tac-toe .x:after { content: "x"; display: block; text-align: center; }
Das ist unnötig kompliziert; es geschieht ja in beiden Fällen dasselbe: der Klassenbezeichner wird als generierter Inhalt verwendet.
.tic-tac-toe td::after {
content: attr(class);
display: block;
text-align: center;
}
LLAP 🖖
Willst du uns ein x für ein Kreuz vormachen? Und ein o ist kein Kreis. Dafür sollten doch besser Symbole wie × U+00D7 MULTIPLICATION SIGN oder ❌ U+17EC CROSS MARK und ◯ 25EF LARGE CIRCLE oder ⭕ U+2B55 HEAVY LARGE CIRCLE verwendet werden. ↩︎
Hallo Gunnar,
ist das eigentlich normal, das die Zeichen in Rot erscheinen? Oder hat nur mein Safari eine „Macke“?
Gruß Jürgen
Hallo JürgenB,
ist das eigentlich normal, das die Zeichen in Rot erscheinen? Oder hat nur mein Safari eine „Macke“?
Das ist die Syntaxhervorhebung für Zeichenketten.
Bis demnächst
Matthias
Hallo Matthias,
ist das eigentlich normal, das die Zeichen in Rot erscheinen? Oder hat nur mein Safari eine „Macke“?
Das ist die Syntaxhervorhebung für Zeichenketten.
Jürgen sprach von der Darstellung von ❌und ⭕, die unter OS X rot gerendert werden. Ich denke, das liegt an OS X.
LG,
CK
Hallo,
Jürgen sprach von der Darstellung von ❌und ⭕, die unter OS X rot gerendert werden. Ich denke, das liegt an OS X.
das denke ich auch. Leider kann man die Zeichen mit CSS auch nicht umfärben.
Gruß Jürgen
Hallo,
das denke ich auch. Leider kann man die Zeichen mit CSS auch nicht umfärben.
aber vielleicht kannst du einen anderen Zeichensatz wählen?
Gruß
Kalk
Aloha ;)
Jürgen sprach von der Darstellung von ❌und ⭕, die unter OS X rot gerendert werden. Ich denke, das liegt an OS X.
Nein - oder ja, aber nicht ausschließlich. Das ❌ ist auch unter Chrome/Android rot (das ⭕ nicht)...
Grüße,
RIDER
@@JürgenB
Hallo Gunnar,
ist das eigentlich normal, das die Zeichen in Rot erscheinen? Oder hat nur mein Safari eine „Macke“?
Im Firefox sind sie unter OS X auch rot. Keine Frage des Browsers, sondern des Betriebssystems und der Fonts, die verwendet werden. Diese Zeichen kommen aus einem Font, wo Zeichen ihre eigene Farbe haben – wie das auch bei Emojis der Fall ist.
Wenn das Rot nicht passt: Ein Kreuz und ein Kreis sind in SVG ein Einzeiler. Farbe und Strichstärke lassen sich dann mit CSS angeben.
LLAP 🖖
Lieber Gunnar,
Wenn das Rot nicht passt: Ein Kreuz und ein Kreis sind in SVG ein Einzeiler.
LOL wo (bitte genau!) möchtest Du diesen notieren?
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
Wenn das Rot nicht passt: Ein Kreuz und ein Kreis sind in SVG ein Einzeiler.
LOL wo (bitte genau!) möchtest Du diesen notieren?
Wie wär’s mit hier?
Kreuz:
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1 1">
<line x1="0.1" y1="0.1" x2="0.9" y2="0.9"/>
<line x1="0.1" y1="0.9" x2="0.9" y2="0.1"/>
</svg>
Kreis:
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1 1">
<circle cx="0.5" cy="0.5" r="0.4" fill="none"/>
</svg>
Anmerkungen:
xmlns="http://www.w3.org/2000/svg" entfallen.Im Stylesheet:
svg
{
width: 2em;
height: 2em;
}
circle, line
{
stroke: currentColor;
stroke-width: 0.1;
}
Da man die Symbole Kreuz und Kreis mehrmals benötigt, wird man sie aber besser einmal definieren und dann wiederverwenden:
<svg xmlns="http://www.w3.org/2000/svg" style="display: none">
<defs>
<symbol id="circle" viewBox="0 0 1 1">
<circle cx="0.5" cy="0.5" r="0.4" fill="none"/>
</symbol>
<symbol id="cross" viewBox="0 0 1 1">
<line x1="0.1" y1="0.1" x2="0.9"y2="0.9"/>
<line x1="0.1" y1="0.9" x2="0.9"y2="0.1"/>
</symbol>
</defs>
</svg>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<use xlink:href="#circle"/>
</svg>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<use xlink:href="#cross"/>
</svg>
Anmerkung:
xmlns:xlink="http://www.w3.org/1999/xlink" darf bei der Einbettung von SVG in HTML entfallen, sodass dann <svg><use xlink:href="#circle"/></svg> wirklich nur ein Einzeiler ist.LLAP 🖖
Lieber Gunnar,
LOL wo (bitte genau!) möchtest Du diesen notieren?
Wie wär’s mit hier?
mir wäre es im Kontext des HTML-Dokuments aus dem Wiki-Artikel lieber gewesen. Denn genau die Einbettung in das HTML-Dokument und insbesondere die Nutzung aus JavaScript heraus leuchtet mir noch nicht ganz ein.
Liebe Grüße,
Felix Riesterer.
Aloha ;)
LOL wo (bitte genau!) möchtest Du diesen notieren?
Wie wär’s mit hier?
mir wäre es im Kontext des HTML-Dokuments aus dem Wiki-Artikel lieber gewesen.
Verständlich, ich fand das auch unkonstruktiv.
Denn genau die Einbettung in das HTML-Dokument und insbesondere die Nutzung aus JavaScript heraus leuchtet mir noch nicht ganz ein.
Ich halte es für machbar, den SVG-Einzeiler als String im JavaScript vorzuhalten und dann per innerHTML einzufügen.
Insgesamt ist das alles aber nichts, was in einem Anfängertutorial getan werden sollte (weder Unicode noch SVG) solange es nicht explizit darum geht. X und O zu verwenden ist im Sinne der didaktischen Reduktion das einzig richtige, was man an der Stelle tun kann - andernfalls verliert der Artikel den Fokus. Das mag zielgruppenabhängig in Ordnung sein, aber nicht bei dieser Zielgruppe (die Anfänger, mindestens erkennbar an der kleinschrittigen Erklärung).
Grüße,
RIDER
@@Camping_RIDER
Insgesamt ist das alles aber nichts, was in einem Anfängertutorial getan werden sollte (weder Unicode noch SVG) solange es nicht explizit darum geht.
Man verwendet sowieso Unicode. X ist genauso ein Unicode-Zeichen wie × und ❌.
X und O zu verwenden ist im Sinne der didaktischen Reduktion das einzig richtige, was man an der Stelle tun kann - andernfalls verliert der Artikel den Fokus.
Nein.
.piece-x::after { content: "X" } ist um nichts einfacher oder verständlicher als .piece-x::after { content: "×" }.
Die Verwendung vernünftig aussehender Zeichen fügt dem Artikel null Komplexität hinzu, schadet also nicht. Nutzt aber.
LLAP 🖖
Hallo
X und O zu verwenden ist im Sinne der didaktischen Reduktion das einzig richtige, was man an der Stelle tun kann - andernfalls verliert der Artikel den Fokus.
Nein.
Meiner Meinung nach doch.
Die Verwendung vernünftig aussehender Zeichen fügt dem Artikel null Komplexität hinzu, schadet also nicht.
Der Anfänger, an den sich der Artikel ja richtet, ist im Normalfall nicht in der Lage, die Zeichen abseits von Copy'n'Paste zu erzeugen. Genau an der Stelle ist die Komplexität mit „X“ und „O“ bzw. „x“ und „o“ geringer.
Tschö, Auge
@@Auge
Der Anfänger, an den sich der Artikel ja richtet, ist im Normalfall nicht in der Lage, die Zeichen abseits von Copy'n'Paste zu erzeugen. Genau an der Stelle ist die Komplexität mit „X“ und „O“ bzw. „x“ und „o“ geringer.
Der Anfänger wird entweder den Code per Copy’n’Paste aus dem Artikel übernehmen (vermutlich die Mehrheit) oder – falls er doch abtippt – ein × als x lesen und dann eben x tippen.
Spricht also nichts dagegen, im Artikel × zu verwenden.
LLAP 🖖
Hallo Gunnar,
Der Anfänger, an den sich der Artikel ja richtet, ist im Normalfall nicht in der Lage, die Zeichen abseits von Copy'n'Paste zu erzeugen. Genau an der Stelle ist die Komplexität mit „X“ und „O“ bzw. „x“ und „o“ geringer.
Der Anfänger wird entweder den Code per Copy’n’Paste aus dem Artikel übernehmen (vermutlich die Mehrheit) oder – falls er doch abtippt – ein × als x lesen und dann eben x tippen.
Nein, meiner Beobachtung nach (ich habe mal versucht meinem Bruder und meinem Beinahe-Schwager HTML beizubringen) mischt sich das. Ein Teil wird copy'n'pasted, ein Teil wird von Hand getippt.
Spricht also nichts dagegen, im Artikel × zu verwenden.
Ich sehe das so wie Auge und Camping.
LG,
CK
@@Christian Kruse
Der Anfänger wird entweder den Code per Copy’n’Paste aus dem Artikel übernehmen (vermutlich die Mehrheit) oder – falls er doch abtippt – ein × als x lesen und dann eben x tippen.
Nein, meiner Beobachtung nach (ich habe mal versucht meinem Bruder und meinem Beinahe-Schwager HTML beizubringen) mischt sich das. Ein Teil wird copy'n'pasted, ein Teil wird von Hand getippt.
Das wäre ein Argument, wenn '×' öfter im Quelltext vorkommen würde und dann jeweils übereinstimmen müsste. Bspw. im JavaScript ….className = 'piece-×'; und im CSS .piece-×::after { content: "×" }.
Das soll es aber gar nicht. '×' käme an genau einer Stelle vor, nämlich in .piece-x::after { content: "×" }.
Dein Argument, dass die Verwendung von '×' usw. problematisch wäre, löst sich damit in Luft auf.
Spricht also nichts dagegen, im Artikel × zu verwenden.
Ich sehe das so wie Auge und Camping.
Oder übersehe ich da was?
LLAP 🖖
Hallo Gunnar,
Dein Argument, dass die Verwendung von '×' usw. problematisch wäre, löst sich damit in Luft auf.
Ich habe nicht argumentiert. Ich habe dir meine Sichtweise mitgeteilt. An einer Diskussion habe ich kein Interesse, denn die ist müssig :)
LG,
CK
@@Felix Riesterer
mir wäre es im Kontext des HTML-Dokuments aus dem Wiki-Artikel lieber gewesen. Denn genau die Einbettung in das HTML-Dokument und insbesondere die Nutzung aus JavaScript heraus leuchtet mir noch nicht ganz ein.
SVG kann man auf (mindestens) zwei verschiedene Arten einbinden:
Da kann aus externen Dateien sein
.piece-x { background-image: url(cross.svg) }
.piece-o { background-image: url(cirvle.svg) }
Da heißt zusätzliche HTTP-Requests für die SVGs. Man kann sie auch als Data-URLs ins Stylesheet einbinden:
.piece-x { background-image: url('data:image/svg+xml,<svg …></svg>') }
.piece-o { background-image: url('data:image/svg+xml,<svg …></svg>') }
Funktioniert so nicht im IE (Edge weiß ich grad nicht). Der IE ist da etwas strenger und erwartet den <svg …></svg>-Teil prozent-escapet. (Kann man ihm nicht mal verübeln.)
.piece-x { background-image: url('data:image/svg+xml,%3Csvg …%3E%3C/svg%3E') }
.piece-o { background-image: url('data:image/svg+xml,%3Csvg …%3E%3C/svg%3E') }
Ich habe wegen besserer Lesbarkeit hier mal darauf verzichtet.
Kann man das in einem Anfängertutorial so anbieten? Ja, natürlich. Gegenüber der Variante mit ‘x’ und ‘o’ bleibt der HTML- und JavaScript-Code völlig gleich; es ändert sich lediglich die Darstellung.
Für einen Anfänger mag der Code im Stylesheet unverständlich sein; aber das ist
.piece-x::after { content: "x" }
.piece-o::after { content: "o" }
ebenfalls. Der Anfänger wird bei beidem einfach so hinnehmen, das der Code zur Darstellung von Kreuzen und Kreisen dient. Die Länge der betreffenden Zeilen im Stylesheet ist dabei nicht von Belang.
Wie Camping_RIDER schon sagte, kann man das SVG <svg><use xlink:href="#cross"/></svg> (bzw. "#circle") einfach dynamisch per innerHTML als Inhalt in die td-Elemente setzen.
Die Definition der Symbole steht statisch im HTML.
LLAP 🖖
Aloha ;)
Kann man das in einem Anfängertutorial so anbieten? Ja, natürlich.
Nein, so pauschal eben nicht. Ja, man kann so etwas in einem Anfängertutorial machen. Aber nur, wenn die SVG-Einbindung per Data-URL auch mit zu den Lernzielen gehört. Ansonsten ist didaktische Reduktion das Schlüsselwort und eine Data-URL (per Empfehlung dazu verdonnert, auch noch prozentkodiert zu werden) ist massiv irritierend im Vergleich zu einem einzelnen Zeichen. Das gutgläubige "das Voodoo was der da tut um Kreise zu erzeugen wird schon irgendwie stimmen" ist eben genau das, was man im Anfängertutorial tunlichst vermeiden und nicht etwa als Stilmittel einsetzen sollte.
Selbst wenn du fachlich mit deiner Sichtweise richtig liegst ist das didaktischer Selbstmord an der Stelle. Das einzige, was die Einbettung in HTML noch besser macht als die in CSS ist, dass es für einen Anfänger nachvollziehbarer ist, wenn SVG in HTML eingebunden wird (da man Data-URLs sonst kaum sieht und sie für einen Anfänger eher wie Voodoo aussehen - wie übrigens das Pseudoelement auch ein wenig), aber auch hier ist jeder Grundsatz der didaktischen Reduktion auf das Wesentliche verletzt.
Und da wir schon festgestellt haben, dass du SVG/Unicode-Lösungen nur präferierst, weil die Zeichen deiner Meinung nach schicker aussehen ist das ganz sicher nicht wesentlich genug für eine unbedingte Erwähnung im Anfängertutorial.
Grüße,
RIDER
@@Camping_RIDER
Kann man das in einem Anfängertutorial so anbieten? Ja, natürlich.
Nein, so pauschal eben nicht. Ja, man kann so etwas in einem Anfängertutorial machen. Aber nur, wenn die SVG-Einbindung per Data-URL auch mit zu den Lernzielen gehört.
Das ist Unsinn. Die SVG-Einbindung per Data-URL gehört genausowenig mit zu den Lernzielen wie es die Generierung von Inhalt mit Pseudoelementen tut. Ebendas sagte ich schon gerade.
Genauso, wie man stillschweigend Generierung von Inhalt mit Pseudoelementen verwenden würde, könnte man stattdessen auch SVG-Einbindung per Data-URL verwenden. Kein Unterschied.
Außer dass die visuelle Darstellung bei SVGs deutlich besser ist. Und gerade Anfänger freuen sich, wenn das Ergebnis schön aussieht.
LLAP 🖖
Liebe(r) Gunnar,
vielen Dank für die leckeren Korinthen! ;-)
Wie bitte? Das
tbody-Element muss sein, weil HTML das so vorschreibt.
Dann solltest Du im Wiki auf der Tabellen-Seite im Bereich einfache Tabellen das aber so korrigieren! Ich habe mich im Wortlaut absichtlich etwas vage daran orientiert.
Die
<tbody>- und</tbody>-Tags müssen allerdings nicht sein. Dastbody-Elementobjekt wird auch ohne die Tags im DOM angelegt.
Unter obigem Link steht: "Beachten Sie: Die meisten Browser ergänzen ein fehlendes tbody-Element automatisch, [...]". Gilt Deine Aussage bezüglich des DOM uneingeschränkt? Also ab IE > 6?
Sollten wir nun besser diesen Satz und das Tag aus dem Tutorial gänzlich und ersatzlos streichen? Dann haben wir diese Frage ganz vom Tisch und müssen nix erklären. Für die Funktionsweise des Scripts (und der Selektoren im CSS) hat <tbody> keinerlei Auswirkungen.
Die gewählte Formulierung „damit die Semantik einer Tabelle erhalten bleibt“ halte ich für irreführend.
Dann mach sie doch besser! Oder weg. Siehe oben.
Mit der
content-Eigenschaft wird das Symbol für den jeweiligen Spieler in der Tabellenzelle angezeigt, obwohl im HTML-Code kein solcher Inhalt steht. Es ist ein reines Darstellungselement …Das leuchtet nicht ein. Die Felder werden im Laufe des Spiels mit
xundo[1] gefüllt; das ist also Inhalt.
Ist es ein tabellarischer Inhalt? Darf er überhaupt so ausgezeichnet werden? Könnte man das Dokument sonst nicht automatisiert verarbeiten? Wandert die Seite in den Suchergebnissen sonst zu weit nach hinten?
Das in der Fußnote (siehe [1:1]) war von Dir jetzt eigentlich zu erwarten... ist aber für einen Anfänger sowas von schnuppe. Dagegen könnte man aber argumentieren, dass bei der Gestaltung(!) jegliche Freiheit bleibt, da man sowohl Deine schönen Sonderzeichen nehmen, oder sogar später passende SVG-Grafiken verwenden kann. Die Darstellung wird ja nun mit CSS geregelt, und das finde ich in diesem Anfänger-Tutorial irgendwie sehr passend.
Entweder implementiert man das so, dass
xundotatsächlich Textinhalte dertd-Elemente sind, oder man lässt sich eine gute Begründung dafür einfallen, warum man das anders implementiert, obwohl das eigentlich Inhalt wäre.
Kein Inhalt. Ist nur eine Darstellungsfrage, wer jetzt wo zuerst geklickt/getapped hat. Sollte man später animierte gif-Grafiken verwenden wollen, dann wären deren alt-Attributwerte der "Inhalt". Und dann müsste man wieder das Script anpassen. Dabei ging es doch nur um die Darstellung!
Nö, kein Inhalt. Bestenfalls "generierter Inhalt".
Das ist unnötig kompliziert; es geschieht ja in beiden Fällen dasselbe: der Klassenbezeichner wird als generierter Inhalt verwendet.
.tic-tac-toe td::after { content: attr(class); display: block; text-align: center; }
Schöne Verkürzung! Das könnte man im Tutorial noch anbieten. Diese Verkürzung ist aber nur dann von echtem Nutzen, wenn man die Darstellung bei den Zeichen belässt, die man als "generierten Inhalt" anzeigen lässt. Stellt man auf andere Darstellungsmöglichkeiten um, ist sie nicht mehr nützlich.
<I> Wenn Du nun Deine Verbesserungen in meinem Tutorial vorgenommen hast, darfst Du die Erweiterung für Fortgeschrittene und Hardliner schreiben, bei der echte Inhalte frei konfigurierbar in die Tabellenzellen geschrieben werden. So mit "all the bells and whistles". Und vergiss bitte nicht, ein Spiel erneut startbar zu machen! </I>
Liebe Grüße,
Felix Riesterer.
Hallo Felix,
schöner Artikel.
Ich habe dazu - aus Interesse, nicht als Kritik - zwei Fragen:
Muss das Script wirklich noch mit „//<![CDATA[ …“ versteck werden?
Warum benutzt du für die Inhalte der Spielfelder Pseudoelemente und nicht die Feldinhalte?
Gruß Jürgen
Lieber JürgenB,
- Muss das Script wirklich noch mit „//<![CDATA[ …“ versteck werden?
mir ist von einem Muss nichts bekannt. Aber ich mache das so. Da ich mich mit Validatoren zuwenig auskenne, weiß ich nicht, ob es völlig überflüssig (geworden) ist. Aber dafür haben wir ja das Forum.
- Warum benutzt du für die Inhalte der Spielfelder Pseudoelemente und nicht die Feldinhalte?
Weil ich der Einfachheit halber (Anfänger-Tutorial) nur die className-Eigenschaft prüfen will. Da die Tabelle als Element ohnehin schon eine kritisierbare Wahl ist (warum kein <div>, warum kein <aside>?), und weil ich die Darstellung mit CSS realisieren will (ja, vielleicht will man später SVG-Grafiken anstelle der Zeichen benutzen), habe ich mich so entschieden.
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
- Muss das Script wirklich noch mit „//<![CDATA[ …“ versteck werden?
Das hat nichts mit Verstecken zu tun; verstecken ginge mit <!--.
Das hat was damit zu tun, dass in XHTML (application/xhtml+xml o.ä.) der Inhalt von script PCDATA ist; in HTML (text/html) aber CDATA. Will man das vereinheitlichen, damit das gleich verarbeitet wird, egal ob der polyglotte Code als XHTML oder als HTML verarbeitet wird, muss man das auch für XHTML auf CDATA setzen.
Genau das wird mit <![CDATA[ gemacht. Durch das vorangestellte // wird es in JavaScript-Code (was der Inhalt des script-Elements ja ist) zu einem Kommentar; stört also den JavaScript-Interpreter nicht weiter.
mir ist von einem Muss nichts bekannt. Aber ich mache das so. Da ich mich mit Validatoren zuwenig auskenne, weiß ich nicht, ob es völlig überflüssig (geworden) ist.
Mit Validität hat das auch nichts zu tun. Und ja, wenn man HTML-Code nicht als XHTML verarbeiten lassen will (was i.a.R. der Fall ist), dann ist das völlig überflüssig.
Und selbst wenn man das auch als XHTML verarbeiten lassen will, wäre die Kennzeichnung als CDATA nur erforderlich, wenn es einen Unterschied zwischen PCDATA und CDATA gäbe; z.B. wenn < oder & im JavaScript vorkommen.
- Warum benutzt du für die Inhalte der Spielfelder Pseudoelemente und nicht die Feldinhalte?
Weil ich der Einfachheit halber (Anfänger-Tutorial) nur die className-Eigenschaft prüfen will.
Das könnte als „gute Begründung“ herhalten. Vielleicht genau das im Text kurz erwähnen.
Da die Tabelle als Element ohnehin schon eine kritisierbare Wahl ist
Ein Spielfeld mit 3 × 3 Feldern: 3 Zeilen, 3 Spalten. Ich hätte jede andere Wahl als table kritisiert. Der Geist Cheatahs ist bei mir.
LLAP 🖖
Hallo Gunnar Bittersmann,
@Felix Riesterer
- Warum benutzt du für die Inhalte der Spielfelder Pseudoelemente und nicht die Feldinhalte?
Weil ich der Einfachheit halber (Anfänger-Tutorial) nur die className-Eigenschaft prüfen will.
Das könnte als „gute Begründung“ herhalten. Vielleicht genau das im Text kurz erwähnen.
Ich denke schon, dass die gesetzten Zeichen tatsächlich Inhalte sind. Warum nicht beides verknüpfen?
<td class="X">X</td>
Bis demnächst
Matthias
Lieber Gunnar,
Der Geist Cheatahs ist bei mir.
und derselbe äußerte einst: JavaScript ist wunderbar geeignet, die DOM-Objekte auf eine Weise zu verändern, die in CSS genutzt werden kann.
Liebe Grüße,
Felix Riesterer.
Aloha ;)
Da die Tabelle als Element ohnehin schon eine kritisierbare Wahl ist
Ein Spielfeld mit 3 × 3 Feldern: 3 Zeilen, 3 Spalten. Ich hätte jede andere Wahl als
tablekritisiert.
Nicht alles was Zeilen und Spalten hat ist eine Tabelle. Schon das drei Zeilen drei Spalten ist lediglich Interpretation der 9 Felder. Inwiefern sind denn horizontal und vertikal Vorzugsrichtungen in dieser Feldstruktur, in der auch diagonal gewonnen werden kann? Und im Übrigen gibt auch das Zitat
Der Geist Cheatahs ist bei mir.
diese Interpretation nicht her, sie widerspricht ihr sogar. Es geht Cheatah um tabellarrische Daten - und wo bitte siehst du die in x und o? Symbole sind nur dann tabellarische Daten (imho und afais), sofern Zeile und Spalte jeweils einem Sinn zugeordnet sind (bspw. in einer Relationstabelle, vergleichbar mit einer Adjazenzmatrix), hier, bei Tic-Tac-Toe, ergibt sich der Sinn allerdings erst aus der gegenseitigen Positionierung von x und o (und nicht nur auf Zeile/Spalte beschränkt) - und damit ist das alles andere als tabellarisch.
Grüße,
RIDER
@@Camping_RIDER
Ein Spielfeld mit 3 × 3 Feldern: 3 Zeilen, 3 Spalten. Ich hätte jede andere Wahl als
tablekritisiert.Nicht alles was Zeilen und Spalten hat ist eine Tabelle.
Es ist eine Matrix.
Schon das drei Zeilen drei Spalten ist lediglich Interpretation der 9 Felder.
Zeilen und Spalten haben beim Tic-Tac-Toe eine Bedeutung.
Inwiefern sind denn horizontal und vertikal Vorzugsrichtungen in dieser Feldstruktur, in der auch diagonal gewonnen werden kann?
Auch Haupt- und Nebendiagonale der Matrix haben beim Tic-Tac-Toe eine Bedeutung.
Es geht Cheatah um tabellarrische Daten
table ist wohl das, was in HTML einer Matrix am nächsten kommt.[1] Mir nahe genug.
und wo bitte siehst du die in x und o?
Ob Tabelle oder nicht bezieht sich wohl eher auf die Felder denn auf deren Inhalte.
Symbole sind nur dann tabellarische Daten (imho und afais), sofern Zeile und Spalte jeweils einem Sinn zugeordnet sind
Sind sie IMHO, s.o.
LLAP 🖖
Du willst nicht MathML dafür bemühen, oder? In einem Anfängertutorial? ↩︎
Hallo,
ich würde das hier ganz pragmatisch sehen. Das Spielfeld sieht aus wie eine Tabelle. Warum soll ich hier „irgendwelche“ Elemente nehmen, und diese dann per CSS dazu bringen, wie eine Tabelle auszusehen. Außerdem wüsste ich auch nicht, welche semantische Bedeutung ich den Spielfeldern geben sollte, am ehesten wahrscheinlich inputs. Aber da wären mir (pragnmatisch) zu viele Klimmzüge nötig, um sie wie ein Tic-Tac-Toe-Spielfeld aussehen zu lassen.
Gruß Jürgen
PS Hat hier nicht vor einiger Zeit mal jemand geschrieben: Wenn man länger als einige Minuten ohne eindeutiges Ergebnis darüber diskutieren kann, welches Element das richtige ist, dann ist es egal, welches man nimmt.
Hallo
Nicht nur, dass das Spielfeld wie eine Tabelle aussieht, es bedarf – und da möchte ich @Camping_RIDER in seiner Interpretation der Interpretation der neun Felder widersprechen –, der expliziten Einteilung in drei Zeilen und drei Spalten. Also ähnlich einem zu kleinen Schachbrett mit den Feldern A1 bis C3.
Das ließe sich aber nur über Umwege und mit Klimmzügen mit Divs und/oder Spans mit Flexbox (oder vergleichbaren Techniken) darstellen. Nichts, was ich für sinnvoll halte; erst recht in einem Anfängertutorial.
Tschö, Auge
Aloha ;)
Hat hier nicht vor einiger Zeit mal jemand geschrieben: Wenn man länger als einige Minuten ohne eindeutiges Ergebnis darüber diskutieren kann, welches Element das richtige ist, dann ist es egal, welches man nimmt.
Dem stimme ich uneingeschränkt zu.
Grüße,
RIDER
@@JürgenB
Außerdem wüsste ich auch nicht, welche semantische Bedeutung ich den Spielfeldern geben sollte, am ehesten wahrscheinlich inputs.
Am beste solche, die nur die jeweiligen Symbole als Eingabe zulassen. Bei '0' und '1' ginge das mit <input type="number" min="0" max="1"/>. Ansonsten bieten sich select oder Gruppen mit jeweils zwei Radiobuttons an.
Aber da wären mir (pragnmatisch) zu viele Klimmzüge nötig, um sie wie ein Tic-Tac-Toe-Spielfeld aussehen zu lassen.
Ich bin schon am Basteln. Stay tuned…
LLAP 🖖
@@Gunnar Bittersmann
Aber da wären mir (pragnmatisch) zu viele Klimmzüge nötig, um sie wie ein Tic-Tac-Toe-Spielfeld aussehen zu lassen.
Nicht weiter schlimm, wenn man etwas trainiert ist.
Ich bin schon am Basteln. Stay tuned…
Puh, endlich fertig.
LLAP 🖖
Hallo Felix,
- Warum benutzt du für die Inhalte der Spielfelder Pseudoelemente und nicht die Feldinhalte?
Weil ich der Einfachheit halber (Anfänger-Tutorial) nur die className-Eigenschaft prüfen will. Da die Tabelle als Element ohnehin schon eine kritisierbare Wahl ist (warum kein <div>, warum kein <aside>?), und weil ich die Darstellung mit CSS realisieren will (ja, vielleicht will man später SVG-Grafiken anstelle der Zeichen benutzen), habe ich mich so entschieden.
interessanter Ansatz. Ich hätte die „x“ und „o“ als Inhalt in die TDs geschrieben.
Ich wäre übrigens nie auf die Idee gekommen, die Tabelle zu hinterfragen. Aus meiner (!) Sicht die einzige sinnvolle Wahl. Aber die Diskussion zeigt ja, das es da auch andere Meinungen gibt.
Gruß Jürgen
Tach!
Da dachte ich mir damals, den Post könnte ich zu einem richtigen Artikel ausbauen. Da ich gerade Weihnachtsferien habe und dem allgemeinen Aufruf nach Anfänger-Tutorials insbesondere für JavaScript einen Beitrag spendieren wollte, isser nun im Wiki und möchte kritisiert und verbessert werden:
Ich würde es gern sehen, wenn die Instantiierungen anonymer Funktionen durch die Variante 2, also die IIFE-Schreibweise ausgetauscht würden. Diese Schreibweise trifft man doch heutzutage häufiger in der freien Wildbahn an (soll heißen, die new-Schreibweise hab ich für diesen Zweck so noch nicht bewusst wahrgenommen). Ich hab da mal eben einen Erläuterungsartikel dazu geschrieben, siehe obigen Link.
Das MDN sagt, dass querySelectorAll() eine non-live NodeList liefert und keine lebendige. Dieses Detail ist aber für den Artikel nicht weiter relevant, weil die Anzahl der Spiele auf der Seite sich nicht im laufenden Betrieb ändern wird. Es ist sicher auch wenig sinnvoll, mehr als ein Spiel auf die Seite zu bringen, solange man eh nur zwei Personen abwechselnd agieren lässt. Anders wäre es, wenn ein Spielleiter alle Spiele in einem Netzwerk überwachen möchte und da welche hinzukommen oder wegfallen. Aber das ist kein Thema für einen Einsteigerartikel. Jedenfalls könnte man dem Spiel auch eine ID statt einer Klasse vergeben. Es sei denn, du möchtest nur einen Grund haben, warum das eigentliche Spiel in einer Funktion (TicTacToe) ausgelagert ist. Aber das könnte man auch mit guter Strukturierung und Bilden von Zuständigkeitseinheiten begründen.
Statt for mit der Zählvariable i fände ich ja forEach() ausdrucksstärker, vor allem, weil man dann nicht games[i] sondern game zur Repräsentation eines einzelnen Spiels hat. Dummerweise liefert querySelectorAll() kein Array sondern eine NodeList, und die hat keine Array-Methoden. Was aber geht, wäre for...of, was aber auf Microsoft-Seite erst im Edge-Browser verfügbar ist. Jedenfalls kommt man damit an die Ausdrucksstärke von forEach heran.
Es gibt einen entscheidenden Unterschied zwischen
var foo = function() {...};
und
function foo() {...};
Wenn man eine Funktion als Variable anlegt, muss die Ausführung des Codes an der Stelle vorbeigekommen sein, damit diese Funktionsvariable existiert. Als "ordentliche" Funktion kann sie auch irgendwo im Code hinter ihren Aufrufen stehen, weil sie dann quasi zur Compile-Zeit gefunden und erstellt wird und somit generell zur Laufzeit zur Verfügung steht (natürlich auch nur innerhalb des Scopes).
Variablen-/Parameternamen bitte ausschreiben. Bei i als allgemein übliche Laufvariable ist das noch kein Problem (besser: forEach/for...of verwenden, wenn möglich), aber el und e sind gerade für Anfänger, die nicht wissen, was die Funktionen für Parameter erwarten, erklärungsbedürftig. Also lieber element und event nehmen. Das gilt im Prinzip auch für Code, der nicht nur Anfängern gewidmet ist. Für absichtlich unleserlichen Code gibt es Uglifier ;)
Im Gegensatz zu querySelectorAll() erzeugt getElementsByTagName() (egal ob von document oder element) diesmal wirklich eine live list, allerdings keine NodeList, sondern eine HTMLCollection (die aber leider auch nicht von Array erbt).
In check() ist es besser, statt !finished nur auf finished zu prüfen und in dem Fall die Funktion zu verlassen. Das reduziert eine Einrückungsebene, besonders weil es keinen Else-Zweig gibt oder genereller Code nach diesem if kommt.
"Es hat einen Sinn, die Variablendeklaration an den Anfang der Funktion zu setzen und nicht erst im Anweisungsblock des if-Statements. Das ist gute Programmierertradition, da damit der Code für andere übersichtlicher wird." - Njein, kann man so sehen, kann man aber auch anders sehen. Besser sind kleinere lokale übersichtliche Scopes, statt dass man im Großen versucht den globalen Scope zu meiden, im kleinen aber Variablen im gesamten Scope rumliegen hat. Im Falle von i ist es sogar unübersichtlicher, weil i nur ganz lokal benötigt wird und nicht in der gesamten Funktion. Dafür hat man sich auch in der kommenden JavaScript-Version das Schlüsselwort let ausgedacht, das den Scope von Variablen nochmal deutlich einschränken kann. Ansonsten muss man sagen: Kommt drauf an. Manchmal benötigt man eine Variable wirklich im gesamten Scope und manchmal eben nicht.
Zur Ermittlung ob full oder nicht, kann man nach dem ersten false die Schleife abbrechen, "fuller" wird es nämlich mit den anderen Werten auch nicht. Noch besser wäre es, every() zu nehmen, was im vorliegenden Ansatz wieder daran krankt, dass eine HTMLCollection kein Array ist.
"Wenn wir prüfen wollen, ob der String leer ist, genügt es nicht mit dem ==-Operator zu prüfen, da JavaScript intern Wertetypen umrechnen kann, um verschiedene Typen miteinander zu vergleichen." - Oh doch, das genügt in dem Fall vollkommen, weil beim Vergleich von zwei Strings (hier className mit einem Stringliteral) kein anderer Wertetyp beteiligt ist. Anders sähe der Fall aus, wenn ein Integer oder Boolean beteiligt wäre - ist aber nicht. Es hat schon seinen Sinn, warum man === bevorzugt, aber die Begründung passt an der Stelle nicht. Das hier ist eher nur ein Fall von "mach ich immer so, mach ich hier auch so". className ist definiert als string, und selbst wenn man da 0 (Integer-Literal) reinschreibt, kommt "0" (String) beim Lesen raus.
"In diesem if-Statement werden zwei Werte mit einem logischen Oder verknüpft. Hier macht man sich die automatische Typumwandlung von JavaScript zunutze." - Ist das nicht etwas inkonsequent? Einerseits die automatische Typkonvertierung mithilfe von === vermeiden (abgesehen von obigem Sinn-Argument für den dortigen Fall) und andererseits darauf zu bauen? Abgesehen von dieser Stichelei, pfeif ich persönlich auf solche Konsistenzen aus niederen Beweggründen. Ich brauche die Erfahrungswerte, die ich bekomme, wenn ich in solche potentiellen Fehlerquellen reintappe. Es bringt mir nichts, solche Stellen mit der Konsequenz selbst aufgestellter Regeln zu vermeiden, um den Kopf frei für andere Dinge zu haben, wenn ich sie dann im Falle eines Falles nicht mehr erkenne. Die Problematik verschwindet ja nicht aus der Welt, egal wie sehr man sich im Einzelnen darum bemühen mag.
Für script und style, obwohl ihr Inhalt als CDATA definiert ist, gab es in HTML4 die Sonderregel, dass darin (sprich bis zum ersten </) kein Markup interpretiert wurde ("Although ..."). Die Verwendung eines //<![CDATA[...//]]>-Blocks ist laut Standard nicht notwendig. Vielleicht gab/gibt es einige Situationen, für die die Browser das brauchen, aber da ist mir auch noch keine über den Weg gelaufen. In HTML5 ist das Regelwerk von script gehörig aufgebohrt worden (und ich hab keine Lust das alles zu lesen), aber dass nun darin Markup interpretiert wird, kann ich mir nicht vorstellen. Der CDATA-Rahmen kann also weg. Und type="text/javascript" ist der Standard-Wert und kann damit auch weggelassen werden.
Bis hier waren das Anmerkungen von mir (doch so viele?), die, wenn sie überzeugend waren, gern eingearbeitet werden können. Wenn nicht, bin ich auch nicht traurig. Abseits davon hier noch eine weitere Bemerkung der Vollständigkeit halber. Wenn man es "richtig" macht, stochert man lieber nicht in der Ausgabe herum, um Werte für die Geschäftslogik zu bekommen. Wenn man an der Ausgabe Änderungen vornehmen möchte (zum Beispiel statt Tabelle was anderes), muss man durch die Geschäftslogik durchlaufen und dort alle Element- und/oder Klassennamen ändern. Besser ist, man hat eine separate Datenhaltung. Der kann man dann auch einen sprechenden Namen geben und muss sich den Sinn der Programmelemente nicht aus dem Kontext erarbeiten. In dem Fall wäre für das Spielfeld ein Array of Arrays mit jeweils drei Elementen angebracht. Diese Datenhaltung nimmt man nun zum Berechnen des Spielstandes und auch als Datengrundlage für die Darstellung. Dann muss man nicht fragen, ob und welcher className gesetzt ist, man setzt ihn einfach entsprechend dieses Spielfeld-Array-Inhalts. Damit macht man dann auch einen deutlichen Schritt hin zum EVA-Prinzip. Wenn man das Spiel mit AngularJS erstellen wollte, sähe man den Vorteil einer solchen Trennung noch deutlicher, denn da ist schon vom Konzept her die Ausgabe von der Geschäftlogik abgekoppelt. Die Spiel-Logik sitzt im Controller, oder ausgelagert in einem Service, und die View (sprich die Angular-Direktiven im HTML) bekommen das Spielfeld (oder die Werte daraus, die für sie von Interesse sind) hingereicht und kümmert sich selbst um die Darstellung. Für die Klick-Events gibt es auch ein paar entsprechende Wege. Statt Spielfeld-Datenhaltung wäre es deutlich umständlicher, die Werte aus dem DOM auszulesen, wenn man das auf Angular-Weise tun wollen würde.
dedlfix.
Servus!
@dedlfix vielen Dank für Deine hilfreichen Anmerkungen!
Das MDN sagt, dass querySelectorAll() eine non-live NodeList liefert und keine lebendige.
Hättest du Zeit und Lust etwas zum Thema node list irgendwo hier
eine eigene Unterseite (oder ein Kapitel im noch zu schreibenden Grundlagenartikel) zu erstellen? Das mit dem Fragezeichen ist, glaub ich unsere schwächste Stelle im Wiki.
Herzliche Grüße
Matthias Scharwies
Tach!
Hättest du Zeit und Lust etwas zum Thema node list irgendwo hier
eine eigene Unterseite (oder ein Kapitel im noch zu schreibenden Grundlagenartikel) zu erstellen? Das mit dem Fragezeichen ist, glaub ich unsere schwächste Stelle im Wiki.
Ich muss sagen, dass ich an der Stelle kein Experte bin, wobei ich andererseits auch vermute, dass ich auf dem Feld einer der Einäugigen unter den Blinden bin. Uns fehlt einfach einer vom Schlage molily. Was das Thema anbelangt, bin ich nur Anwender. Ich weiß, wie ich mich durch das DOM bewegen kann und in welcher Dokumentation ich Details zu Methoden und Eigenschaften finde. Dass so etwas wie eine NodeList und HTMLCollection existiert, weiß ich nur, weil ich damit mal auf die Nase gefallen bin, als ich darüber forEach()en wollte.
Wie dem auch sei, so habe ich doch versucht, in verlinkter Seite ein paar Formulierungen zu verbessern. (Beispielsweise sind Attribute kein Nachfahre von Node (mehr). Attribute passen nicht in das eigentliche Knotengefüge des Baums und das hat man mittlerweile korrigiert.) Dabei ist mir aufgefallen, dass meiner Ansicht nach das Thema generell ziemlich verkehrt erläutert wird, und ich hab das erstmal gelassen, um zunächst hier Rückfrage zu halten. Da ist von einem node-Objekt die Rede, welches nach meinem Dafürhalten aber nicht existiert. Stattdessen handelt es sich eigentlich um Node (mit großem N) und das ist "nur" ein Interface. Dieses bildet die Grundlage für ein paar spezialisierte Interfaces (Document, Element, CharacterData (mit Text und Comment als Nachfahren) und weitere). Am Ende der Nahrungskette stehen dann irgendwelche konkreten HTML-Elemente (div, body, p, span und wie sie nicht alle heißen), und die haben alle das Node-Interface und gegebenenfalls weitere spezialisierte Interfaces implementiert (sowie weitere elementspezifische Dinge hinzugefügt bekommen). Das mag jetzt eigenartig klingen, weil JavaScript das Konzept Interface nicht kennt, doch es ist durchaus nicht falsch, es auf diese Weise zu erläutern. Die Spezifikation tut dies, das MDN auch und es ist intern vermutlich auch so implementiert, bevor am Ende der JavaScript-Wrapper drübergestülpt wurde.
Es kann aber auch gut sein, dass ich mich grad kolossal irre und das node-Objekt doch existiert oder mit der JavaScript-Brille geschaut doch als Objekt erklärt werden kann, oder auch was ganz anderes in meiner Betrachtungen falsch ist. Ich bitte freundlich darum, mich in dem Fall zu korrigieren, oder mich auch zu bestätigen.
dedlfix.
Servus!
Tach!
Hättest du Zeit und Lust etwas zum Thema node list im Wiki [zu schreiben]?
Ich muss sagen, dass ich an der Stelle kein Experte bin, wobei ich andererseits auch vermute, dass ich auf dem Feld einer der Einäugigen unter den Blinden bin.
Da sprichst Du ein wahres Wort gelassen aus! Aber was sollen wir machen? Warten, bis jemand Fähiges kommt und uns mit noch starke Schwächen den Mangel, der uns durchaus bewusst ist, aufzeigt? Selber verbessern, auch auf die Gefahr hin, dass man evtl. etwas Falsches schreibt, was dann auch wieder negativ auf SelfHTML zurückfällt?
Dabei ist mir aufgefallen, dass meiner Ansicht nach das Thema generell ziemlich verkehrt erläutert wird, und ich hab das erstmal gelassen, um zunächst hier Rückfrage zu halten. Da ist von einem node-Objekt die Rede, welches nach meinem Dafürhalten aber nicht existiert.
Das ist Stefan Münz aus dem Jahre 2003; auch die Literatur (Addison-Wesley von 2012), die ich habe, spricht von einem Node-Objekt, wobei das W3C vom Node interface redet.
Das war meine Schuld, dass ich den Text aus der Doku 8.12 übertragen und gehofft hatte, dass jemand sich dieser Bereiche annähme.
Herzliche Grüße
Matthias Scharwies
Tach!
Da sprichst Du ein wahres Wort gelassen aus! Aber was sollen wir machen? Warten, bis jemand Fähiges kommt und uns mit noch starke Schwächen den Mangel, der uns durchaus bewusst ist, aufzeigt? Selber verbessern, auch auf die Gefahr hin, dass man evtl. etwas Falsches schreibt, was dann auch wieder negativ auf SelfHTML zurückfällt?
Man kann ja als "Kompromiss" erstmal zu klären versuchen, was richtig ist, und dann loslegen. Fehler oder Verbesserungsmöglichkeiten entstehen dann auch noch, aber man will ja später auch noch was zu tun haben ;)
Dabei ist mir aufgefallen, dass meiner Ansicht nach das Thema generell ziemlich verkehrt erläutert wird, und ich hab das erstmal gelassen, um zunächst hier Rückfrage zu halten. Da ist von einem node-Objekt die Rede, welches nach meinem Dafürhalten aber nicht existiert.
Das ist Stefan Münz aus dem Jahre 2003; auch die Literatur (Addison-Wesley von 2012), die ich habe, spricht von einem Node-Objekt, wobei das W3C vom Node interface redet.
Kannst du das Buch mal konkreter benennen? Wenn ich seinen Inhalt finde, kann ich vielleicht besser einschätzen, inwieweit man dessen Aussagen trauen kann.
Das war meine Schuld, dass ich den Text aus der Doku 8.12 übertragen und gehofft hatte, dass jemand sich dieser Bereiche annähme.
Das empfinde ich nicht als schlimm oder gar schämenswürdig. Ich entnehme aus der vorgetragenen Historie zumindest, dass diese Formulierungen vermutlich damals mangels besseren Wissens entstanden sind und zugunsten der Interface-Geschichte ersetzt werden können. Hat jemand dagegen Einwände vorzubringen?
dedlfix.
Servus!
Man kann ja als "Kompromiss" erstmal zu klären versuchen, was richtig ist, und dann loslegen. Fehler oder Verbesserungsmöglichkeiten entstehen dann auch noch, aber man will ja später auch noch was zu tun haben ;)
Das stimmt - Schnellschüsse sind nie gut!
Kannst du das Buch mal konkreter benennen? Wenn ich seinen Inhalt finde, kann ich vielleicht besser einschätzen, inwieweit man dessen Aussagen trauen kann.
Erfolgreich JavaScript lernen von Ralph Steyer
Mir ist bei den Event-Handlern wie onclick, die Stefan Münz seinerzeit unter HTML eingeordnet hatte, und die heute als z.B. click-Event ganz klar unter JavasCript zu finden sind, bewusst geworden, wie sich manche Begriffe und Begrifflichkeiten ändern.
Das empfinde ich nicht als schlimm oder gar schämenswürdig. Ich entnehme aus der vorgetragenen Historie zumindest, dass diese Formulierungen vermutlich damals mangels besseren Wissens entstanden sind und zugunsten der Interface-Geschichte ersetzt werden können. Hat jemand dagegen Einwände vorzubringen?
Ich habe zumindest den Einführungstext erneuert und ein paar Links hinzugefügt. Es wäre toll, wenn wir die ToDos im Laufe der Zeit abarbeiten könnten.
dedlfix.
Herzliche Grüße
Matthias Scharwies
Tach!
Erfolgreich JavaScript lernen von Ralph Steyer
Kurz reingeschaut, nehme ich an, dem Autor ist auch nicht geläufig, dass es sich um Interfaces handelt. Wenn man der Amazon-Inhaltssuche glauben darf, kommt das Wort dreimal vor. Einmal, so scheint es, in der Liste der reservierten Schlüsselwörter, einmal als Bestandteil von API (und da geht es um irgendwelche Google-APIs) und die dritte Fundstelle ist das Stichwortverzeichnis. Die Seitenzahl verweist auf das Kapitel Datentypen im Teil "Elementare Javascript-Grundstrukturen" (Was ist der Unterschied zwischen elementar und grund(legend)?) Im Gegensatz dazu spricht die MDN-Übersichtsseite zum DOM durchgehend von Interfaces. (Nein, alle werden nicht den Weg ins Wiki finden! Nur ein paar wesentliche, also elementare Grund-Interfaces sozusagen.)
dedlfix.
Hallo Matthias Scharwies,
Aber was sollen wir machen? Warten, bis jemand Fähiges kommt und uns mit noch starke Schwächen den Mangel, der uns durchaus bewusst ist, aufzeigt? Selber verbessern, auch auf die Gefahr hin, dass man evtl. etwas Falsches schreibt, was dann auch wieder negativ auf SelfHTML zurückfällt?
Und ich würde das auch nicht ganz so schwarz sehen, wie ich das dort oben hinauslese. Kopf hoch!
Das war meine Schuld, dass ich den Text aus der Doku 8.12 übertragen und gehofft hatte, dass jemand sich dieser Bereiche annähme.
Da würde ich nicht von Schuld sprechen. Eher bin ich dankbar, dass du dir die Mühe gemacht hast.
Bis demnächst
Matthias
Servus!
Aber was sollen wir machen?
- Jemanden bezahlen, der nachweislich Ahnung hat?
Hab' ich auch schon dran gedacht und sogar vorgeschlagen, aber wie soll man sowas durchführen? Und gute Mathe-Nachhilfe kostet 25-50€/h (Englisch nur 7,50 - 20€/h). Was müsste man dann für einen guten Grundlagenartikel hinblättern?
Und ich würde das auch nicht ganz so schwarz sehen, wie ich das dort oben hinauslese. Kopf hoch!
Das war meine Schuld, dass ich den Text aus der Doku 8.12 übertragen und gehofft hatte, dass jemand sich dieser Bereiche annähme.
Da würde ich nicht von Schuld sprechen. Eher bin ich dankbar, dass du dir die Mühe gemacht hast.
Ja, danke, einerseits sind die Lücken gestopft, aber irgendwie geht's nicht weiter.
Bis demnächst
Matthias
Herzliche Grüße
Matthias Scharwies
Aloha ;)
- Jemanden bezahlen, der nachweislich Ahnung hat?
Würde ich aus Gründen nicht machen wollen und wäre dann wohl auch (meiner Einschätzung nach) wenn-dann eines Mitgliederversammlungsbeschlusses mit vorhergehender mündlicher Diskussion würdig; immerhin wäre das eine starke Veränderung zur bisherigen Praxis.
Grüße,
RIDER
Lieber dedlfix,
vielen Dank für Deine vielen wertvollen Denkanstöße!
Ich würde es gern sehen, wenn die Instantiierungen anonymer Funktionen durch die Variante 2, also die IIFE-Schreibweise ausgetauscht würden.
sagte nicht Crockford, er möge es nicht, wenn die Argumente-Klammer außerhalb der umspannenden Klammern läge? So á la "da hängen die Eier 'raus"?
(function (param) { ... } (value));
// anstatt
(function (param) { ... }) (value);
Aber das ist meines Erachtens ziemlich egal. Gerade für Anfänger ist es das. Inwiefern ich damit Anfängern den Einstieg in die Instanziierung von Objekten mit dem Schlüsselwort new verbaue... da bin ich als Pädagoge eher gelassen, denn meine Erfahrung zeigt, dass man bereits Bekanntes durchaus in neue Kontexte einzuordnen lernt.
Ich hab da mal eben einen Erläuterungsartikel dazu geschrieben, siehe obigen Link.
Und schon wieder hat das Wiki inhaltlich gewonnen. Danke dafür!
Das MDN sagt, dass querySelectorAll() eine non-live NodeList liefert und keine lebendige. Dieses Detail ist aber für den Artikel nicht weiter relevant, weil die Anzahl der Spiele auf der Seite sich nicht im laufenden Betrieb ändern wird.
Ungeachtet dessen muss ich das dann korrigieren. Leider bleibt es eine NodeList und wird kein Array, sodass die schönen Iterationsmethoden wie forEach leider nicht zur Verfügung stehen.
Es ist sicher auch wenig sinnvoll, mehr als ein Spiel auf die Seite zu bringen, solange man eh nur zwei Personen abwechselnd agieren lässt.
Um aber die Unabhängigkeit der Objekte bzw. den Scope von Funktionen und Variablen zu zeigen, wäre es durchaus sinnvoll - immerhin ist es ein Tutorial, bei dem Anfänger grundsätzlich etwas lernen sollen, nicht nur zielgerichtet für das eine Ergebnis.
Jedenfalls könnte man dem Spiel auch eine ID statt einer Klasse vergeben. Es sei denn, du möchtest nur einen Grund haben, warum das eigentliche Spiel in einer Funktion (TicTacToe) ausgelagert ist. Aber das könnte man auch mit guter Strukturierung und Bilden von Zuständigkeitseinheiten begründen.
Wenn mehr als ein Spiel auf der Seite möglich sein soll, dann braucht es eine Klasse anstelle einer ID. Und das Fass "ID versus Klasse" wollte ich nicht aufmachen. Das soll gerne in einem anderen Tutorial besprochen werden. Warum soll man z.B. nicht verschiedene Spielstände zum Weiterspielen anbieten können? Das geht nur mit einer Klasse anstelle einer ID!
Statt for mit der Zählvariable i fände ich ja forEach() ausdrucksstärker, vor allem, weil man dann nicht
games[i]sonderngamezur Repräsentation eines einzelnen Spiels hat. Dummerweise liefert querySelectorAll() kein Array sondern eine NodeList, und die hat keine Array-Methoden. Was aber geht, wäre for...of, was aber auf Microsoft-Seite erst im Edge-Browser verfügbar ist. Jedenfalls kommt man damit an die Ausdrucksstärke von forEach heran.
Das mit Iterationsmethoden und Callback-Funktionen empfinde ich als ein kleines bisschen fortgeschrittener, als es ein reines Anfänger-Tutorial im Kern verkraftet. Bei der "Was fehlt noch?"-Rubrik könnte man solche Gedanken anbringen. Oder man schreibt gleich ein ganz anders konstruiertes Beispiel und macht ein Anfänger-II-Tutorial daraus. Magst Du (<I>) ...?
Es gibt einen entscheidenden Unterschied zwischen
var foo = function() {...};und
function foo() {...};
Ja. Den habe ich bewusst vorenthalten. Mir war im Kontext des Tutorials zunächst wichtig anzudeuten (nicht: genau darzulegen!), dass sich ein Funktionsbezeichner wie eine gewöhnliche Variable verhält. Wann die Funktion definiert wird, und wann ihr Code ausführbar zur Verfügung steht, ist selbstverständlich bei den Schreibweisen höchst unterschiedlich.
Variablen-/Parameternamen bitte ausschreiben. Bei i als allgemein übliche Laufvariable ist das noch kein Problem (besser: forEach/for...of verwenden, wenn möglich), aber el und e sind gerade für Anfänger, die nicht wissen, was die Funktionen für Parameter erwarten, erklärungsbedürftig. Also lieber element und event nehmen. Das gilt im Prinzip auch für Code, der nicht nur Anfängern gewidmet ist. Für absichtlich unleserlichen Code gibt es Uglifier ;)
Guter Einwand! Das werde ich verbessern. Auch an den Beispieldateien.
In check() ist es besser, statt
!finishednur auffinishedzu prüfen und in dem Fall die Funktion zu verlassen. Das reduziert eine Einrückungsebene, besonders weil es keinen Else-Zweig oder generellen Code nach diesem if kommt.
Hmm. Ja. Im Prinzip schon. Aber dann müsste ich return einführen. Das habe ich zwar implizit schon getan, indem ich Rückgabewerte von Methoden in Variablen ablege, wie ich aber mitten aus einer Funktion aussteige, egal ob mit oder ohne Rückgabewert, wollte ich nicht ohne konkreten Anlass einführen.
"Es hat einen Sinn, die Variablendeklaration an den Anfang der Funktion zu setzen und nicht erst im Anweisungsblock des if-Statements. Das ist gute Programmierertradition, da damit der Code für andere übersichtlicher wird." - Njein, kann man so sehen, kann man aber auch anders sehen.
Stimmt, kann man. Aber wenn man die Sache mit dem Scope üben will, dann ist es einleuchtend, wenn man die Deklaration an oberster Stelle des Scopes vornimmt. Findest Du nicht?
Besser sind kleinere lokale übersichtliche Scopes, statt dass man im Großen versucht den globalen Scope zu meiden, im kleinen aber Variablen im gesamten Scope rumliegen hat. Im Falle von
iist es sogar unübersichtlicher, weilinur ganz lokal benötigt wird und nicht in der gesamten Funktion.
Bedeutet das, dass Du gerne noch mehr Funktionen verschachteln möchtest? Hier in diesem konkreten Anfänger-Tutorial? Oder war das eher eine allgemeine Marschrichtung für erfahrenere JavaScriptler?
Dafür hat man sich auch in der kommenden JavaScript-Version das Schlüsselwort let ausgedacht, das den Scope von Variablen nochmal deutlich einschränken kann. Ansonsten muss man sagen: Kommt drauf an. Manchmal benötigt man eine Variable wirklich im gesamten Scope und manchmal eben nicht.
Aha! Dann wäre das offensichtlich etwas für forgeschrittenere Tutorials. Aber gut, dass Du das angesprochen hast, denn diese neuesten ECMA-Script-Standards habe ich noch nicht so auf dem Schirm. Insbesondere let kenne ich aus BASIC auf dem C64...
Zur Ermittlung ob full oder nicht, kann man nach dem ersten false die Schleife abbrechen, "fuller" wird es nämlich mit den anderen Werten auch nicht.
Tja, dann müsste ich break einführen. Wollte aber sparsam darin sein, was ich alles auf einen echten Anfänger los lasse.
Noch besser wäre es, every() zu nehmen, was im vorliegenden Ansatz wieder daran krankt, dass eine HTMLCollection kein Array ist.
Eben. Warum nur um Himmels Willen hat man das so gemacht?? Diese ganzen NodeLists haben diese bequemen Iterationsmethoden nicht. Was haben die sich dabei nur gedacht? Ist es das live, dass eine Iterationsmethode scheitern ließe? Das will mir nicht einleuchten.
"Wenn wir prüfen wollen, ob der String leer ist, genügt es nicht mit dem ==-Operator zu prüfen, da JavaScript intern Wertetypen umrechnen kann, um verschiedene Typen miteinander zu vergleichen." - Oh doch, das genügt in dem Fall vollkommen, weil beim Vergleich von zwei Strings (hier className mit einem Stringliteral) kein anderer Wertetyp beteiligt ist. Anders sähe der Fall aus, wenn ein Integer oder Boolean beteiligt wäre - ist aber nicht.
Es könnte eine Klasse "0" oder "000000" benutzt werden - extrem unwahrscheinlich, aber irgendwie hielt ich es für nötig, die Typsicherheit bei Vergleichen von beiden Seiten aus vorzuführen. Es sollte einmal ein typsicherer Vergleich nötig sein und einmal ein lose typisierter. Hättest Du bessere Beispiele gewusst, um das Problem zu veranschaulichen? Ich habe hier eher pädagogisch denn maximal effizient programmierend entschieden.
className ist definiert als string, und selbst wenn man da 0 (Integer-Literal) reinschreibt, kommt "0" (String) beim Lesen raus.
Genau, und "0" ist falsy, ebenso wie "00000".
Ist das nicht etwas inkonsequent? Einerseits die automatische Typkonvertierung mithilfe von
===vermeiden (abgesehen von obigem Sinn-Argument für den dortigen Fall) und andererseits darauf zu bauen?
Es war eine pädagogische Entscheidung, um die Problematik der Typ(un)sicherheit in JavaScript schon einem Anfänger zu vermitteln.
Abgesehen von dieser Stichelei, pfeif ich persönlich auf solche Konsistenzen aus niederen Beweggründen.
Hehe, und ich mache sie mir pädagogisch zunutze.
Ich brauche die Erfahrungswerte, die ich bekomme, wenn ich in solche potentiellen Fehlerquellen reintappe.
Eben.
Gut, dass wir darüber diskutiert haben.
Die Verwendung eines
//<![CDATA[...//]]>-Blocks ist laut Standard nicht notwendig. Vielleicht gab/gibt es einige Situationen, für die die Browser das brauchen, aber da ist mir auch noch keine über den Weg gelaufen. In HTML5 ist das Regelwerk von script gehörig aufgebohrt worden (und ich hab keine Lust das alles zu lesen), aber dass nun darin Markup interpretiert wird, kann ich mir nicht vorstellen. Der CDATA-Rahmen kann also weg. Undtype="text/javascript"ist der Standard-Wert und kann damit auch weggelassen werden.
Das ist alles schön und gut, wenn kein String in der Form "</script>" enthalten ist. Bastele ich einen CDATA-Block darum, habe ich kein Problem. Ohne diesen Block könnte mir das um die Ohren fliegen (und ist es in der Vergangenheit auch). Daher mache ich das immer dran. Es stört nicht und fördert ungefragt und unbenötigt die XHTML-Kompatibilität.
Wenn man es "richtig" macht, stochert man lieber nicht in der Ausgabe herum, um Werte für die Geschäftslogik zu bekommen. Wenn man an der Ausgabe Änderungen vornehmen möchte (zum Beispiel statt Tabelle was anderes), muss man durch die Geschäftslogik durchlaufen und dort alle Element- und/oder Klassennamen ändern. Besser ist, man hat eine separate Datenhaltung.
Darüber hatte ich mir im Vorfeld einige Gedanken gemacht. Ich hatte ein Array mit den 3x3 Feldern, wobei jedes Array-Element, welches für ein Feld stand, ein Objekt war, welches unter anderem das betroffene Elementobjekt enthielt. Etwas in dieser Richtung:
var board = [
[
{
element: <HTMLTableCellElement>,
value: "x"
},
{
element: <HTMLTableCellElement>,
value: ""
},
{
element: <HTMLTableCellElement>,
value: "o"
}
], // weitere Arrays für Zeilen 2 & 3
];
Ich habe dann festgestellt, dass das Prüfen und Ermitteln von Gewinner oder Unentschieden für einen Anfänger unnötig kompliziert wird. Deshalb habe ich mich für eine Anfänger-Lösung mit der className-Eigenschaft entschieden.
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
sagte nicht Crockford, er möge es nicht, wenn die Argumente-Klammer außerhalb der umspannenden Klammern läge? So á la "da hängen die Eier 'raus"?
Jedenfalls könnte man dem Spiel auch eine ID statt einer Klasse vergeben. […]
Wenn mehr als ein Spiel auf der Seite möglich sein soll, dann braucht es eine Klasse anstelle einer ID.
Mehr als ein Spiel auf der Seite finde ich schon etwas an den Haaren herbeigezogen. Warum sollte man das wollen?
Und will man das wirklich in diesem Tutorial für Anfänger?
Warum nicht einfach document.querySelector() (ohne All)? Das gibt ein Elementobjekt zurück (wenn solch ein Element existiert) – fertig. IMHO im Rahmen dieses Artikels ausreichend.
LLAP 🖖
Tach!
Ich würde es gern sehen, wenn die Instantiierungen anonymer Funktionen durch die Variante 2, also die IIFE-Schreibweise ausgetauscht würden.
sagte nicht Crockford, er möge es nicht, wenn die Argumente-Klammer außerhalb der umspannenden Klammern läge? So á la "da hängen die Eier 'raus"?
Der kann ja sagen, was er will, am Ende hat er zwar viel Erfahrung, aber er ist genausowenig Gott oder Gesetzgeber wie ich. (Will sagen, er hat das Recht auf die Wahrheit nicht gepachtet und ich will mir das auch auf keinen Fall anmaßen.) Sein Argument zeigt auch nur eine Vorliebe und ist kein technisch begründeter Einwand. (Es sei denn, du hast den Teil weggelassen. Ich kannte bis eben nicht, dass er sich dazu in der Form geäußert hat, geschweige denn, wie er es konkret getan hat. Insofern will ich da jetzt nicht zu viel Gewicht drauflegen.) Bei einer Funktion an sich ist jedenfalls auch keine zusammenhaltende Klammer drumherum, da hängt quasi alles raus, also das Schlüsselwort function und dazu die Parameterliste und der Funktionskörper. (Und hey, es gibt Kontexte, da sind heraushängende Eier kein Makel. An Ostersträuchen beispielsweise.)
Aber das ist meines Erachtens ziemlich egal. Gerade für Anfänger ist es das. Inwiefern ich damit Anfängern den Einstieg in die Instanziierung von Objekten mit dem Schlüsselwort
newverbaue... da bin ich als Pädagoge eher gelassen, denn meine Erfahrung zeigt, dass man bereits Bekanntes durchaus in neue Kontexte einzuordnen lernt.
Ich sag mal, das new hat seinen Platz an einer ganz anderen Stelle. Es ist besser da aufgehoben, wo es darum geht, mehrere Instanzen von einem Funktionsobjekt (anderswo Klasse genannt) zu erzeugen. Hier geht es nur um das Erzeugen eines Scopes, und dass man das nur hinbekommt, indem man eine Funktion so komisch notiert und aufruft, ist schon eigenartig genug. Doch das ist die gängige Praxis, und insofern sag ich mal, ganz weg mit der new-Version, sagen dass das eine IIFE ist, man sie für den Scope braucht, Verweis auf das Glossar hinzufügen und gut ist.
Warum soll man z.B. nicht verschiedene Spielstände zum Weiterspielen anbieten können? Das geht nur mit einer Klasse anstelle einer ID!
Ok, das ist ein nicht ganz dummes Anwendungsbeispiel. Wenn du das in einem Nebensatz als Beispiel erwähnst, wird das auch klarer, warum du da eine Klasse verwendet hast, und zeigt auch, dass eine ID für andere Anwendungsfälle ebenfalls möglich wäre.
Das mit Iterationsmethoden und Callback-Funktionen empfinde ich als ein kleines bisschen fortgeschrittener, als es ein reines Anfänger-Tutorial im Kern verkraftet.
Einverstanden. Aber zumindest die for-of-Version ist verständlich und auch schöner als for mit i. Die könnte man erwähnen und hätte somit auch noch drin, dass man leider auf manche Dinge noch verzichten muss, um Kompatibilität mit alten Browsers zu bewahren - ein nicht ganz unwichtiges Thema, wenn es um Javascript geht.
Bei der "Was fehlt noch?"-Rubrik könnte man solche Gedanken anbringen. Oder man schreibt gleich ein ganz anders konstruiertes Beispiel und macht ein Anfänger-II-Tutorial daraus. Magst Du (<I>) ...?
In der Tat, den funktionale Ansatz nur in einem solchen "Ausblick"-Absatz zu erwähnen, damit kann ich mich anfreunden. Zum Rest ... prokrastinieren wir das mal etwas.
In check() ist es besser, statt
!finishednur auffinishedzu prüfen und in dem Fall die Funktion zu verlassen. Das reduziert eine Einrückungsebene, besonders weil es keinen Else-Zweig oder generellen Code nach diesem if kommt.Hmm. Ja. Im Prinzip schon. Aber dann müsste ich
returneinführen. Das habe ich zwar implizit schon getan, indem ich Rückgabewerte von Methoden in Variablen ablege, wie ich aber mitten aus einer Funktion aussteige, egal ob mit oder ohne Rückgabewert, wollte ich nicht ohne konkreten Anlass einführen.
Etwas abzubrechen, weil die Bedingungen eine Fortführung nicht erlauben, ist kein unübliches Vorgehen. Das muss auch nicht ausgewalzt werden. Es reicht zu sagen, dass bei erfüllter Bedingung die Funktion mit dem return verlassen werden kann. Das verstehen Anfänger vermutlich auch, denke ich.
"Es hat einen Sinn, die Variablendeklaration an den Anfang der Funktion zu setzen und nicht erst im Anweisungsblock des if-Statements. Das ist gute Programmierertradition, da damit der Code für andere übersichtlicher wird." - Njein, kann man so sehen, kann man aber auch anders sehen.
Stimmt, kann man. Aber wenn man die Sache mit dem Scope üben will, dann ist es einleuchtend, wenn man die Deklaration an oberster Stelle des Scopes vornimmt. Findest Du nicht?
Im Prinzip ja. Das zeigt zwar deutlicher, dass die Variablen im gesamten Scope verfügbar sind, reißt mir aber (in einigen, nicht in allen Fällen) Deklaration und Anwendungsgebiet unnötig auseinander.
Besser sind kleinere lokale übersichtliche Scopes, statt dass man im Großen versucht den globalen Scope zu meiden, im kleinen aber Variablen im gesamten Scope rumliegen hat. Im Falle von
iist es sogar unübersichtlicher, weilinur ganz lokal benötigt wird und nicht in der gesamten Funktion.Bedeutet das, dass Du gerne noch mehr Funktionen verschachteln möchtest? Hier in diesem konkreten Anfänger-Tutorial? Oder war das eher eine allgemeine Marschrichtung für erfahrenere JavaScriptler?
Man muss Gründe nicht an den Haaren herbeiziehen, man muss sich auch nicht totstrukturieren, und man muss nicht den Aufmerksamkeitsbogen in einem Anfängertutorial überspannen, indem man zu viele zwar wichtige, aber nicht überlebenswichtige Details einbaut. Insofern, nein, ich möchte nicht schachteln, um des Schachtelns willen. Das kann gern so bleiben, wie es jetzt ist. Das wäre eher ein Thema für die Fortgeschrittenen. Da passt dann zur Erklärung des funktionalen Ansatzes, dass sich damit auch hervorragend kleine Scopes bilden, für Dinge, die nur dort lokal benötigt werden.
Zur Ermittlung ob full oder nicht, kann man nach dem ersten false die Schleife abbrechen, "fuller" wird es nämlich mit den anderen Werten auch nicht.
Tja, dann müsste ich
breakeinführen. Wollte aber sparsam darin sein, was ich alles auf einen echten Anfänger los lasse.
Totsparen sollte man sich auch nicht. Das einzelne break bläht den Code nicht unnötig auf, und sinnvoll ist es außerdem.
Warum nur um Himmels Willen hat man das so gemacht?? Diese ganzen NodeLists haben diese bequemen Iterationsmethoden nicht. Was haben die sich dabei nur gedacht?
Das MDN beantwortet die Frage auch nicht wirklich, obwohl es sie doch konkret formuliert. Why is NodeList not an Array? Da wird auch nur erwähnt, dass NodeList Array nicht in der Prototype-Chain von Nodelist ist.
"Wenn wir prüfen wollen, ob der String leer ist, genügt es nicht mit dem ==-Operator zu prüfen, da JavaScript intern Wertetypen umrechnen kann, um verschiedene Typen miteinander zu vergleichen." - Oh doch, das genügt in dem Fall vollkommen, weil beim Vergleich von zwei Strings (hier className mit einem Stringliteral) kein anderer Wertetyp beteiligt ist.
Es könnte eine Klasse "0" oder "000000" benutzt werden - extrem unwahrscheinlich,
Auch dann gibt es in JavaScript kein Problem. In PHP ergibt "0" == "000" zwar true, weil PHP auch in String Zahlen zu erkennen versucht, JavaScript lässt sowas aber kalt, solange nicht etwas vom Typ Number eine Konvertierung erforderlich macht.
aber irgendwie hielt ich es für nötig, die Typsicherheit bei Vergleichen von beiden Seiten aus vorzuführen. Es sollte einmal ein typsicherer Vergleich nötig sein und einmal ein lose typisierter. Hättest Du bessere Beispiele gewusst, um das Problem zu veranschaulichen?
Hab ich im Moment nicht.
className ist definiert als string, und selbst wenn man da 0 (Integer-Literal) reinschreibt, kommt "0" (String) beim Lesen raus.
Genau, und "0" ist falsy, ebenso wie "00000".
Nein, "0" ist true. Das zeigt sich ganz eindeutig an der Konsole bei doppelter Negation. !!"0" und !!"000" ergibt true, !!0 ergibt false.
Die Verwendung eines
//<![CDATA[...//]]>-Blocks ist laut Standard nicht notwendig.Das ist alles schön und gut, wenn kein String in der Form "</script>" enthalten ist.
Ein </ von anderen Elementen als script reicht in der Theorie auch schon, und das dürfte ein häufigerer Anwendungsfall sein als script im script-Block.
Bastele ich einen CDATA-Block darum, habe ich kein Problem. Ohne diesen Block könnte mir das um die Ohren fliegen (und ist es in der Vergangenheit auch).
Ja, aber, ... da fliegen auch noch ganz andere Dinge los, wenn man das mit dem Kontextwechsel generell noch nicht so intus hat.
Wenn man es "richtig" macht, stochert man lieber nicht in der Ausgabe herum, um Werte für die Geschäftslogik zu bekommen. [...] Besser ist, man hat eine separate Datenhaltung.
Darüber hatte ich mir im Vorfeld einige Gedanken gemacht. Ich hatte ein Array mit den 3x3 Feldern, wobei jedes Array-Element, welches für ein Feld stand, ein Objekt war, welches unter anderem das betroffene Elementobjekt enthielt. Etwas in dieser Richtung:
var board = [ [ { element: <HTMLTableCellElement>, value: "x" }, { element: <HTMLTableCellElement>, value: "" }, { element: <HTMLTableCellElement>, value: "o" } ], // weitere Arrays für Zeilen 2 & 3 ];
Das krankt immer noch daran, dass es Geschäftslogikdinge mit Ausgabedingen mixt.
Ich habe dann festgestellt, dass das Prüfen und Ermitteln von Gewinner oder Unentschieden für einen Anfänger unnötig kompliziert wird. Deshalb habe ich mich für eine Anfänger-Lösung mit der
className-Eigenschaft entschieden.
Versuch das mal - zumindest in Gedanken - mit einem reinen Datenarray als Grundlage umzusetzen. Wie würden dann die Berechnungen aussehen und wie sieht dann die Ausgabe aus? So kompliziert stell ich mir das nicht vor. Und man hätte eine saubere Trennung der Verantwortlichkeiten. Pädagogisch gesehen könnte man natürlich auch erstmal das "Kuddelmuddel" zeigen, um daraus zu lernen, dass es einen besseren Weg gibt, der einerseits zeigt, dass bei Erweiterungen nicht das gesamte Konstrukt gefährdet oder in Mitleidenschaft gezogen wird, andererseits durch die Trennung man etwas mehr Arbeit mit der Übersicht hat, was sich aber letzten Endes eher als Vorteil herausstellt, mehrere kleine Einheiten als eine große zu haben. - Das wäre dann aber auch ein Thema für einen Fortsetzungsartikel.
dedlfix.
fleißig fleißig mein Lieber.
Hier hab ich vor Einiger Zeit (um 2004) mal aufgeschrieben, welche Überlegungen zum Programmieren eines Forum notwendig sind. Weniger spektakulär als ein Spiel. pl
Lieber Rolf (pl ist wieder eine neue Sockenpuppe von Dir...),
fleißig fleißig mein Lieber.
vielen Dank für Dein Lob!
Hier hab ich vor Einiger Zeit (um 2004) mal aufgeschrieben, welche Überlegungen zum Programmieren eines Forum notwendig sind. Weniger spektakulär als ein Spiel.
Könntest Du Dir vorstellen, diesen Artikel zu einem Fortgeschrittenen-Tutorial zu machen und hier ins Wiki zu stellen?
Liebe Grüße,
Felix Riesterer.
hi Felix,
Könntest Du Dir vorstellen, diesen Artikel zu einem Fortgeschrittenen-Tutorial zu machen und hier ins Wiki zu stellen?
Meine Hilfe fürs SelfWiki habe ich mehr als einmal angeboten.
PS: Was sind denn Sockenpuppen? Sind das nicht die, die im SelfForum immer Fragen zu Wiki-Artikeln stellen? Ich finds schade, was aus Selfhtml geworden ist. Für mich war das früher die erste Adresse in Sachen HTML und Zubehör. Was geblieben ist, sind Erinnerungen.
@@pl
PS: Was sind denn Sockenpuppen?
„Was sind …“-Fragen sind üblicherweise prädestiniert dafür, der Suchmaschine seiner Wahl gestellt zu werden.
Lass mich das für dich ente-ente-gehen: Sockenpuppe (Netzkultur)
LLAP 🖖
Da ich gerade Weihnachtsferien habe und dem allgemeinen Aufruf nach Anfänger-Tutorials insbesondere für JavaScript einen Beitrag spendieren wollte, isser nun im Wiki und möchte kritisiert und verbessert werden
Klasse Tutorial! Das werde ich bei Zeiten mal nachbauen und ggf. ausführlicheres Feedback geben. Mein erster Eindruck: interessantes Thema und einwandfrei erklärt. Daumen hoch :)
@@Felix Riesterer
… möchte kritisiert und verbessert werden:
Nachdem die Diskussion etwas ausgeschweift ist, zurück zum Artikel. Was wäre noch zu verbessern?
Nun, das Markup. Es ist so gut wie nicht vorhanden. Nur leere Tabellenzellen. Aber was sollten die auch für Inhalt haben?
Dazu fragen wir uns, was denn die Gundfunktionalität ist: Ganz einfach die Auswahl von Kreuz oder Kreis in jedem Feld.
Jede Zelle hat initial keinen Wert und kann durch Nutzerinteraktion mit ❌ (×, x) oder ⭕ (○, o) befüllt werden. Für 0 und 1 hatte ich schon eine Möglichkeit angedeutet.
Aber das passende UI-Element zur Auswahl ist ein Drop-Down-Menü. Das Innere der Tabellenzellen wäre also:
<td>
<label for="top-left">top left field</label>
<select id="top-left">
<option></option>
<option value="x" aria-label="x">❌</option>
<option value="o" aria-label="o">⭕</option>
</select>
</td>
Und so sieht’s aus. Nicht besonders schön, aber völlig funktional. So funktional, wie es mit HTML eben sein kann.
Das kann sogar ein Blinder bedienen. (Und das ist wörtlich gemeint. ♿️ Deswegen auch das aria-label-Attribut.)
Das Aussehen können wir ja verbessern. Aussehen heißt CSS.
legend wird visuell versteckt; die select-Box wird größer und ihren Rahmen los. (War das jetzt schon ein Zeugma?) Das war’s dann auch schon im Wesentlichen mit dem Styling.
Sieht schon besser aus, aber die Funktionalität ist noch unterste Stufe. Jeder Spieler ist selbst dafür verantwortlich, dass er sein Symbol auswählt, und beide dafür, dass sie abwechselnd ziehen.
Hier (erst!!) kommt nun JavaScript ins Spiel.
if (document.querySelector)
Außer in alten Browsern. Aber das ist völlig OK – progressive enhancement. Die Grundfunktionalität ist ja auch in alten Browsern gegeben.
{
document.documentElement.classList.add('js');
Wenn JavaScript ausgeführt wird, bekommt das html-Element eine Klasse js.
In einer booleschen Variablen isPlayerXMoving wird festgehalten, wer am Zug ist. Die Tabelle bekommt einen Eventhandler verpasst. (Und nicht etwa jedes select einen eigenen – wir nutzen event delegation.) Darin passiert folgendes:
function ticTacToeClickHandler(event)
{
var targetElement = event.target;
if (targetElement.nodeName == 'SELECT')
… nur für select-Elemente; nicht da, wo das Event sonst noch so vorbeibubblet.
{
targetElement.blur();
Der Fokus wird schnell wieder vom select-Element weggenommen, damit das Aufklappen nicht (oder kaum) zu sehen ist. Aus demselben Grund werden per Stylesheet auch die options ausgeblendet, mehr dazu später.
if (!targetElement.disabled)
{
targetElement.value = isPlayerXMoving ? 'x' : 'o';
targetElement.disabled = true;
Das Feld erhält, wenn es noch frei ist, den entsprechenden Wert – je nachdem, wer gerade am Zug war. Dann wird es disablet, damit es nicht noch einmal ausgewählt werden kann.
isPlayerXMoving = !isPlayerXMoving;
}
}
}
Der nächste Spieler ist am Zug.
Um die nun nicht benötigten option-Elemente auszublenden, erhält das Stylesheet noch eine Ergänzung:
.js #tic-tac-toe option
{
display: none;
}
Diese Regel wirkt nur dann, wenn ein Vorfahrenelement die Klasse js hat. Das ist nur dann der Fall, wenn JavaScript ausgeführt wird, da wir diese Klasse fürs html-Element ja erst mit JavaScript gesetzt hatten.
Und so haben wir das Grundkonstrukt progressively enhanced – erst das Aussehen, dann das Verhalten; mit schon ansehnlichem Ergebnis.
Bei Ausfall von JavaScript oder CSS funktioniert die Grundfunktionalität immer noch – und zwar auch, wenn CSS ausfällt, JavaScript aber ausgeführt wird. Dann sieht das Feld wieder ungestylt aus, das JavaScript sorgt aber schon dafür, dass in den disableten selects nicht erneut auswählt werden kann.
Jetzt fehlt noch die Abfrage, ob ein Spieler „was auf die Reihe gekriegt hat“ – aber die sei mal out of scope dieses Postings.
selects sind recht störrisch gegenüber Styling. WebKits können nicht die Schriftgröße der options kleiner setzen als die des selects. Auch die Positionierung des Drop-Downs innerhalb des Feldes ist Frickelei, wenn jeder Browser da etwas andere Vorstellungen hat.
Beschäftigen wir uns lieber mit etwas anderem:
Eine Auswahl von einer Option aus mehreren kann auch durch eine Gruppe von Radiobuttons geschehen.
Entgegen früheren HTML-Versionen, wo ohne Nutzerinteraktion der erste Radiobutton einer Gruppe als vorausgewählt galt, wenn keiner als selected gekennzeichnet war (woran sich Browser aber nicht gehalten haben), sieht HTML5 explizit vor, dass initial kein Radiobutton ausgewählt sein muss.
Das Innere der Tabellenzellen wäre hier derart:
<td>
<fieldset>
<legend>top left field</legend>
<input type="radio" name="top-left" id="top-left-x">
<label for="top-left-x">x</label>
<input type="radio" name="top-left" id="top-left-o">
<label for="top-left-o">o</label>
</fieldset>
</td>
Wieder nicht besonders schön, aber funktioniert. Und ist blind bedienbar. ♿️
Und wieder setzen wir progressive enhancement ein, um Darstellung und Verhalten schrittweise zu verbessern. Zuerst wieder das Styling:
Die Radiobuttons werden ausgeblendet, fieldset büßt seinen Rahmen ein und auch hier wird legend wieder visuell versteckt – und der Labeltext auch; dafür kommt SVG zum Einsatz. Und nicht outline für :focus vergessen!
Die Magie liegt nun darin:
#tic-tac-toe :checked + label::after
{
left: 0;
width: 100%;
height: 100%;
z-index: -1;
}
Wenn ein Radiobutton ausgewählt wird, wird das zugehörige Label vergrößert, so dass es das ganze Feld ausfüllt.
/* transition: width, height, left 0.1s; */
Diese Vergrößerung könnte man auch animieren; die betreffende Codezeile ist aber auskommentiert, denn diese Animation ist nicht gerade performant. Besser ist es, transition bspw. auf transform anzuwenden.
@supports (transform: scale(1))
{
Dazu fragen wir ab, der der Browser transform denn kann. (Andernfalls würden wir die Vergrößerung in alten Browsern nicht mehr haben.)
#tic-tac-toe label::after
{
width: 100%;
height: 100%;
transform: scale(0.25);
transition: transform 0.1s;
}
Initial werden die Label verkleinert, damit sie nebeneinander passen.
#tic-tac-toe label[for$="-x"]::after
{
transform-origin: left top;
}
#tic-tac-toe label[for$="-o"]::after
{
left: 0;
transform-origin: center top;
}
Nebeneinander, nicht aufeinander! Deshalb haben sie verschiedene Streckungszentren.
#tic-tac-toe :checked + label::after
{
transform: scale(1);
}
}
Und bei ausgewähltem Radiobutton füllt das zugehörige Label das ganze Feld.
Doch bei dieser Darstellung kommt wohl kaum noch jemand drauf, dass man hier Radiobuttons auswählt.
Das Label für den nicht ausgewähltem Radiobutton soll natürlich noch verschwinden und auch die Wer-ist-am-Zug?-Logik implementiert werden.
Auch hier wieder ein Eventhandler und event delegation.
function ticTacToeClickHandler(event)
{
var targetElement = event.target;
if (targetElement.nodeName == 'INPUT')
{
targetElement.parentNode.disabled = true;
switchPlayer();
}
}
Ähnlich wie oben, nur dass die Gruppe der Radiobuttons mittels deren Elternelement (das wäre hier fieldset) disablet wird. Und dass hier der Code, der initial auch einmal ausgeführt werden muss, in die Funktion switchPlayer ausgelagert ist.
function switchPlayer()
{
isPlayerXMoving = !isPlayerXMoving;
Der nächste ist dran.
for (var i = 0; i < xInputElements.length; i++)
{
xInputElements[i].disabled = !isPlayerXMoving;
}
for (var i = 0; i < oInputElements.length; i++)
{
oInputElements[i].disabled = isPlayerXMoving;
}
}
Wenn der Spieler am Zug ist, der die Kreuze macht, werden die Kreuz-Radiobuttons enablet; die Kreis-Radiobuttons disablet. Für den anderen Spieler entsprechend andersrum.
Im Stylesheet sind noch einige Anpassungen nötig. Damit diese nur greifen, wenn JavaScript ausgeführt wird, wieder mit .js im Selektor.
.js #tic-tac-toe label::after
{
left: 0;
width: 100%;
height: 100%;
transform: scale(1);
opacity: 0;
transition: none;
z-index: 1;
}
Die Label lassen wir das gesamte Feld ausfüllen, damit die Spieler überall im Feld clicken können.
.js #tic-tac-toe :disabled + label::after,
.js #tic-tac-toe :disabled > label::after
{
z-index: 0;
opacity: 0;
cursor: not-allowed;
}
Label von disableten Radiobuttons werden nicht angezeigt. Dass dann das Feld nicht anclickbar ist, wird durch einen entsprechenden Cursor angezeigt.
.js #tic-tac-toe :checked + label::after
{
opacity: 1;
}
Label von ausgewählten Radiobuttons werden angezeigt.
Das Ganze sieht damit so aus – Radiobuttons progressively enhanced.
Auch diese Lösung funktioniert, wenn JavaScript interpretiert wird, CSS aber nicht. disablete Radiobuttons können nicht ausgewählt werden und werden ausgegraut dargestellt.
An der Stelle käme dann wieder die Erkennung des Spielendes hinzu, um die wir uns in diesem Posting nicht kümmern wollen.
--
Kümmern wir uns lieber um die grundsätzliche Frage: Sollte das alles in einem Tutorial für Anfänger stehen?
Ja, unbedingt!! Wie sonst sollen Anfänger das Prinzip von progressive enhancement verinnerlichen, wenn es ihnen in Tutorials nicht so vorgemacht wird? Kein Anfänger wird nach einem solchen JavaScript-Tutorial noch ein zweites lesen, denn die Lösung „funzt“ ja. Nur dass sie eben nicht funktioniert.
Wollen wir die nächste Generation von Entwicklern heranzüchten, die das dreiundzwölfzigste JavaScript-Framework entwickeln, ohne die geringste Ahnung von HTML zu haben? Was man dem erzeugten Code auch ansieht und das Ergebnis zu Lasten von UX und Barrierefreiheit, also zu Lasten der Nutzer geht?
LLAP 🖖
Tach!
Kümmern wir uns lieber um die grundsätzliche Frage: Sollte das alles in einem Tutorial für Anfänger stehen?
Ja, unbedingt!! Wie sonst sollen Anfänger das Prinzip von progressive enhancement verinnerlichen, wenn es ihnen in Tutorials nicht so vorgemacht wird? Kein Anfänger wird nach einem solchen JavaScript-Tutorial noch ein zweites lesen, denn die Lösung „funzt“ ja. Nur dass sie eben nicht funktioniert.
Ja, das gehört in einen Anfängerartikel. Aber in dem Artikel geht es nicht um das Vorstellen einer Lösung zu einem bestimmten Problem, sondern darum, das Entwickeln mit Javascript zu zeigen. Insofern ist nicht zu erwarten, dass die Kundschaft (hauptsächlich) des Spiels wegen dieses Tutorial liest. Und selbst wenn man ein TicTacToe-Spiel in der erweiterbaren Version des Ursprungsartikels in seine Webseite einbaut, was geht der Welt dann verloren? Nichts entscheidendes.
Ich findes es durchaus legitim, mit einer einfach aussehenden/gehaltenen Variante anzufangen und am Ende auf Fortsetzungen zu verweisen. Was nützt es denn, dem Anfänger einen steilen Berg vorzusetzen, wenn nur die wenigsten gleich die große Schwierigkeit in Angriff nehmen und sie auch auf Anhieb meistern können? Wird es nicht eher so sein, dass viele den Anstieg gar nicht beurteilen können und dann auf halbem Wege stecken bleiben? Es ist auch nicht praxisfern, dass Projekte blauäugig angefangen werden, um dann festzustellen, dass man größere Umbauten vornehmen muss, um weiterzukommen. Warum soll man nicht zeigen, dass das Leben als Programmierer auch solche Situationen bereithält, und nicht sofort die beste Lösung entsteht? - Meiner Meinung nach gibt es sowie zu wenige Artikel, die zeigen, wie man in Fehlerfällen vorgehen kann, geschweige denn, wie man aus eingefahrenen Situationen wieder herauskommt. Für letzteres kann man da leider wenig allgemeingültige Aussagen treffen. - Üblicherweise braucht es jemanden mit viel Erfahrung, um ein System erstmal so am Reißbrett zu entwerfen, dass es ohne Um- und Irrwege am Ende ein vorzeigbares wird.
Es ist nicht anzunehmen, dass die Anfänger erkennen, dass der ideale aber vielleicht etwas beschwerlichere Weg der beste ist. Ebensowenig ist anzunehmen, dass sie sofort alle Feinheiten des Ideals vollständig erlernen und auch in ihren eigenen Projekten anwenden. Wichtig ist aber, dass man ein Bewusstsein schafft, dass es sowas wie Barrierefreiheit gibt und dass das nicht nur so genannte "Behinderte" betrifft, sondern auch jede Menge "normale" Menschen Einschränkungen der einen oder anderen Art haben oder im Laufe des Lebens bekommen und damit ebenso Nutznießer sind oder werden.
Wollen wir die nächste Generation von Entwicklern heranzüchten, die das dreiundzwölfzigste JavaScript-Framework entwickeln, ohne die geringste Ahnung von HTML zu haben?
Nicht übertreiben mit den Argumenten! Extreme sind zwar sehr plakativ, bringen aber selten genügend Kraft mit, um die anderen Beteiligten aus ihrer Masseträgheit zu bringen.
dedlfix.
@@dedlfix
Aber in dem Artikel geht es nicht um das Vorstellen einer Lösung zu einem bestimmten Problem, sondern darum, das Entwickeln mit Javascript zu zeigen. Insofern ist nicht zu erwarten, dass die Kundschaft (hauptsächlich) des Spiels wegen dieses Tutorial liest.
Full ACK. Eben deshalb sollen ja Grundlagen des Entwickelns mit Javascript vermittelt werden. Zu den Grundlagen gehört unbedingt: wann setzt man JavaScript ein und wie setzt man JavaScript richtig ein?
Ich findes es durchaus legitim, mit einer einfach aussehenden/gehaltenen Variante anzufangen und am Ende auf Fortsetzungen zu verweisen.
Welche meiner einfach aussehenden/gehaltenen Varianten hättest du denn gern: die mit den selects oder die mit den Radiobuttons? ;-)
Es ist nicht anzunehmen, dass die Anfänger erkennen, dass der ideale aber vielleicht etwas beschwerlichere Weg der beste ist.
Doch, es ist schon anzunehmen, dass jeder erkennt, dass der ideale Weg auch der beste ist. [grins]
Aber ja, es erkennt womöglich nicht jeder, dass nicht unbedingt der leichteste Weg der beste ist. Das soll aber nicht heißen , dass man die Anfänger auf den leichtesten Weg (ver)führt. Weil eben viele dann nicht mehr von diesem abkommen werden und auf Ewigkeit in die Irre laufen.
Wichtig ist aber, dass man ein Bewusstsein schafft, dass es sowas wie Barrierefreiheit gibt und dass das nicht nur so genannte "Behinderte" betrifft, sondern auch jede Menge "normale" Menschen Einschränkungen der einen oder anderen Art haben oder im Laufe des Lebens bekommen und damit ebenso Nutznießer sind oder werden.
Und das nicht in Extra-Artikeln, die nur diejenigen lesen, die sowieso schon ein Bewusstsein dafür haben, sondern dort, wo die Zielgruppe ist: in Artikeln wie diesem, den Anfänger lesen, die noch nie einen Gedanken an Barrierefreiheit „verschwendet“ haben.
Wollen wir die nächste Generation von Entwicklern heranzüchten, die das dreiundzwölfzigste JavaScript-Framework entwickeln, ohne die geringste Ahnung von HTML zu haben?
Nicht übertreiben mit den Argumenten!
Och, komm! Entwicklern von Framworks, die solchen Output erzeugen, würde ich jetzt nicht wirklcih Kenntnisse über HTML nachsagen.
LLAP 🖖
Lieber Gunnar,
Full ACK. Eben deshalb sollen ja Grundlagen des Entwickelns mit Javascript vermittelt werden. Zu den Grundlagen gehört unbedingt: wann setzt man JavaScript ein und wie setzt man JavaScript richtig ein?
die kommen - Überraschung - nicht an erster Stelle. Wenn ein Anfänger sich mit dem Konzept von Schleifen und Verzweigungen auseinandersetzen muss, wenn er sich mit dem Konzept der ereignisbasierten Programmierung beschäftigen muss, dann ist das mit der Zugänglichkeit oder dem Sinn/Unsinn der Verwendung von JavaScript für diesen Zweck absolut nachrangig. Das Tutorial will zeigen, wie man anfangen kann. Wenn man dann angefangen hat, dann kann man darauf aufbauen. Wenn man nämlich verstanden hat, dass sich bei dem Beispiel nur eine klitzekleine Eigenschaft eines ansonsten leeren Elements verändert, und dass man das mit ausreichender Sehkraft visuell wahrnehmen muss, weil es sonst keinen Anhaltspunkt für den gegenwärtigen Spielstand gibt, dass dieses aber sehbehinderte Menschen ausschließt, dann kann das erst der x.te Schritt sein, keinesfalls einer der ersten.
Wenn man über den Sinn der Verwendung von JavaScript für diesen speziellen Fall diskutieren will, dann bitte in einem Tutorial, das sich genau diesen Aspekt zum zentralen Thema gemacht hat. Denn das ist alles andere als Anfänger-Lektüre. Ein Anfänger kann und weiß noch nichts (oder kaum etwas), und fängt bei (fast) Null an. Wenn man da schon ins Philosophieren über ARIA und semantic Markup verfällt, wird der Anfänger weiter ziehen und sich ein weniger überladenes Tutorial suchen.
Ich findes es durchaus legitim, mit einer einfach aussehenden/gehaltenen Variante anzufangen und am Ende auf Fortsetzungen zu verweisen.
Da wird jeder Praktiker im Lehrbetrieb zustimmen.
Welche meiner einfach aussehenden/gehaltenen Varianten hättest du denn gern: die mit den
selects oder die mit den Radiobuttons? ;-)
Die im Artikel gewählte. Die ist minimalistisch, um die Funktionsweise von JavaScript in kleinsten Schritten und Portionen näher zu bringen. Alles andere kann bestenfalls darauf aufbauen, denn wo noch nix is, kann man auch nix anflanschen.
Es ist nicht anzunehmen, dass die Anfänger erkennen, dass der ideale aber vielleicht etwas beschwerlichere Weg der beste ist.
Doch, es ist schon anzunehmen, dass jeder erkennt, dass der ideale Weg auch der beste ist. [grins]
Diese Aussage kann nur mit Kontext gültig sein. Wo das technische Verständnis für die Hintergründe fehlt, ist der Weg schlicht ungangbar. Da drängt sich einem Praktiker im Lehrbetrieb der Verdacht des aus dem sprichwörtlichen Elfenbeinturm Predigenden auf...
Das soll aber nicht heißen , dass man die Anfänger auf den leichtesten Weg (ver)führt. Weil eben viele dann nicht mehr von diesem abkommen werden und auf Ewigkeit in die Irre laufen.
Es entscheidet allein der Lernende, ob und was er lernen will. Das kannst Du ihm nicht abnehmen. Das gleiche gilt für Kommunikation. Du bestimmst nicht, wie Dein Gegenüber Deine Worte aufzufassen hat. Aber ob Du das je einsehen wirst...?
Wichtig ist aber, dass man ein Bewusstsein schafft, dass es sowas wie Barrierefreiheit gibt und dass das nicht nur so genannte "Behinderte" betrifft, sondern auch jede Menge "normale" Menschen Einschränkungen der einen oder anderen Art haben oder im Laufe des Lebens bekommen und damit ebenso Nutznießer sind oder werden.
Richtig. Aber das muss man jemandem anbieten. Das bedeutet, dass man ihm die Wahl lässt, sich dafür zu interessieren, oder es eben nicht zu tun. Durch Überfrachtung eines pädagogisch bewusst simpel gehaltenen Technik-Beispiels, das einzig und allein der Vermittlung von technischen Zusammenhängen dient (und keinesfalls "best practice" für sich in Anspruch nimmt, das ist auch wieder Aufbau-Stoff), erreicht man durch die implizite Bevormundung des freiwillig Lernenden bestenfalls, dass er die Bereiche nicht einordnen kann oder will, und die Abschnitte überspringt, oder dass er im schlimmsten Fall einfach aufgibt.
Und das nicht in Extra-Artikeln, die nur diejenigen lesen, die sowieso schon ein Bewusstsein dafür haben, sondern dort, wo die Zielgruppe ist: in Artikeln wie diesem, den Anfänger lesen, die noch nie einen Gedanken an Barrierefreiheit „verschwendet“ haben.
Nein. Hinweise ja, Aufblähung des Lernstoffes nein. An entsprechender Stelle einfließen zu lassen, dass aus didaktischer Reduktion heraus gewisse Apsekte ausgelassen wurden, ist ein legitimes Mittel, Interessierte zu vertiefender Lektüre zu locken. Damit (und nur damit) kannst Du den meisten Lerntypen gerecht werden. Wer aus dem einfachen Beispiel zu den komplexen Beispielen schrittweise geführt werden will, der hat ein schlankes Tutorial, das er linear erarbeiten kann. Wer gerne gleich die Deluxe-Variante will, obwohl er sie nicht auf Anhieb verstehen kann, der bekommt jeden Aspekt für sich in einem eigenen Tutorial zum sofortigen Nachschlagen dazu gereicht.
Und das musst Du einfach schlucken: Wenn ein Anfänger für sich entscheidet, dass er auf dem erreichten Wissensstand bleiben will, dann wird er das. Auch wenn im Artikel entweder nur Verweise darauf stehen, dass die gerade erarbeitete Lösung viele Mängel hat, oder wenn im Artikel sogar eine Version erarbeitet wird, die diese Mängel von vornherein behebt - vorausgesetzt, er erduldet die damit nicht unwesentlich erhöhte Komplexität anstatt sofort aufzugeben.
Wollen wir die nächste Generation von Entwicklern heranzüchten, die das dreiundzwölfzigste JavaScript-Framework entwickeln, ohne die geringste Ahnung von HTML zu haben?
Nicht übertreiben mit den Argumenten!
Och, komm! Entwicklern von Framworks, die solchen Output erzeugen, würde ich jetzt nicht wirklcih Kenntnisse über HTML nachsagen.
Diese Diskussion verliert die Verhältnismäßigkeit. Das geht über meinen Wunsch an Feedback deutlich hinaus. Außerdem werden weder Entwickler noch Nutzer solcher Frameworks dieses Anfänger-Tutorial lesen.
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
Full ACK. Eben deshalb sollen ja Grundlagen des Entwickelns mit Javascript vermittelt werden. Zu den Grundlagen gehört unbedingt: wann setzt man JavaScript ein und wie setzt man JavaScript richtig ein?
die kommen - Überraschung - nicht an erster Stelle.
Achso, Grundlagen kommen nicht an erster Stelle. Ich hab auch eine Überraschung für dich: In der Fahrschule musst du erst Theorie pauken, vorher kommst du gar nicht in ein Auto rein.
Wenn ein Anfänger sich mit dem Konzept von Schleifen und Verzweigungen auseinandersetzen muss, wenn er sich mit dem Konzept der ereignisbasierten Programmierung beschäftigen muss, dann ist das mit der Zugänglichkeit oder dem Sinn/Unsinn der Verwendung von JavaScript für diesen Zweck absolut nachrangig.
Wenn ein Fahrschüler sich mit dem Konzept von Kuppeln und Schalten auseinandersetzen muss, wenn er sich mit dem Konzept des ereignisbasierten Bremsens beschäftigen muss, dann ist das mit der Vorfahrt oder dem Sinn/Unsinn der Beachtung von Verkehrsregeln für diesen Zweck absolut nachrangig. Wirklich?
Das Tutorial will zeigen, wie man anfangen kann.
Völlig richtig. Die Frage ist: Wie fängt man an? Mit den Grundlagen oder mit der Missachtung aller Grundlagen?
Wenn man dann angefangen hat, dann kann man darauf aufbauen. Wenn man nämlich verstanden hat, dass sich bei dem Beispiel nur eine klitzekleine Eigenschaft eines ansonsten leeren Elements verändert, und dass man das mit ausreichender Sehkraft visuell wahrnehmen muss, weil es sonst keinen Anhaltspunkt für den gegenwärtigen Spielstand gibt, dass dieses aber sehbehinderte Menschen ausschließt, dann kann das erst der x.te Schritt sein, keinesfalls einer der ersten.
Diese Lehrmethode kannst du in deiner Schule durchziehen. Dort ist sie angebracht. Dort siehst du deine Schüler nächste Woche wieder und kannst an der Stelle weitermachen, wo du vorige Stunde aufgehört hast. Hier ist aber nicht deine Schule. Hier kannst du nicht davon ausgehen, dass die Schüler wiederkommen, d.h. weitere Artikel lesen. Deshalb muss der erste Artikel bereits progressive enhancement und Barrierefreiheit anreißen. Welcher denn sonst, wenn nicht der erste?
Wenn man über den Sinn der Verwendung von JavaScript für diesen speziellen Fall diskutieren will, dann bitte in einem Tutorial, das sich genau diesen Aspekt zum zentralen Thema gemacht hat.
Nein, das funktioniert nicht. Du kannst nicht einem Anfänger sagen: „Wenn du dich mit Barrierefreiheit rumärgern willst – aber sei gewarnt: das ist sehr kompliziert! – dann kannst du [Link zu Artikel] lesen. Du musst dir das aber nicht antun.“ Vielmehr muss vermittelt werden: Es ist deine verdammte Aufgabe, dich mit Barrierefreiheit zu beschäftigen. Von Anfang an. (Sonst machst du’s nie.)
Denn das ist alles andere als Anfänger-Lektüre. Ein Anfänger kann und weiß noch nichts (oder kaum etwas), und fängt bei (fast) Null an. Wenn man da schon ins Philosophieren über ARIA und semantic Markup verfällt, wird der Anfänger weiter ziehen und sich ein weniger überladenes Tutorial suchen.
Diene Argumentation ist abstrus. Du sagst sinngemäß: Es gibt schlechte Tutorials da draußen. Ich könnte ein gutes schreiben, aber damit wärt ihr überfordert. Aber ich will, dass ihr meins lest. Also setze ich ein weiteres schlechtes Tutorial neben die anderen.
Welche meiner einfach aussehenden/gehaltenen Varianten hättest du denn gern: die mit den
selects oder die mit den Radiobuttons? ;-)Die im Artikel gewählte. Die ist minimalistisch,
Nein, die ist nicht vorhanden. <div onclick="…"> (bzw. td) ist keine Schaltfläche. Dieses Wissen gehört zu den Grundlagen – bevor man auch nur eine Zeile JavaScript schreibt.
Alles andere kann bestenfalls darauf aufbauen, denn wo noch nix is, kann man auch nix anflanschen.
Eben. Wo keine Schaltfläche – also nix – ist …
Und warum du mit den Worten „alles andere kann bestenfalls darauf aufbauen“ etwas ganz anderes meinst als progressive enhancement, entzieht sich meinem Verständnis.
Es ist nicht anzunehmen, dass die Anfänger erkennen, dass der ideale aber vielleicht etwas beschwerlichere Weg der beste ist.
Doch, es ist schon anzunehmen, dass jeder erkennt, dass der ideale Weg auch der beste ist. [grins]
Diese Aussage kann nur mit Kontext gültig sein.
?? Die Ironie in dem Satz war, dass „ideal“ und „beste“ Synonyme sind. (Für mich jedenfalls.)
Es entscheidet allein der Lernende, ob und was er lernen will.
Ob ja, was nein. Habt ihr in deiner Schule keine Lehrpläne? Den Umfang des Lernstoffs bestimmt der Lehrer bzw. übergeordnete Instanzen. Der Schüler kann gar nicht überblicken, was er denn lernen sollte. Es liegt in der Verantwortung des Lehrers (…), das Wichtige rauszusuchen.
In einem PHP-Artikel kannst du übrigens auch nicht sagen: Kinder, ihr könnt drauflosschreiben, wie ihr wollt. Das mit htmlspecialchars kriege mer später.
Richtig. Aber das muss man jemandem anbieten. Das bedeutet, dass man ihm die Wahl lässt, sich dafür zu interessieren, oder es eben nicht zu tun.
Falsch.
Wie würdest du jemanden nennen, der sagt: Du darfst hier nicht mitspielen, denn du bist behindert? Ich würde ihn Arschloch nennen.
Und jetzt kommst du und sagst: Kommt her, Kinder, ich zeige euch, wie man ein Arschloch wird.
Dir liegt daran, dass 93 von 100 Schüler am Ende prahlen können: Ich hab in 15 Minuten ein Tic-Tac-Toe gebaut! Mir liegt daran, dass 86 von ihnen am Ende sagen können: Ich hab in 20 Minuten ein Tic-Tac-Toe gebaut und du, mein Freund, kannst auch mitspielen.
Das macht 86 Freunde glücklich. Wenn dabei noch 7 Schüler auf der Strecke bleiben, die dann eben kein JavaScript lernen, nehm ich das dafür mehr als billigend in Kauf. Das macht die Welt eher besser als schlechter, wenn diese 7 ein anderes Betätigungsfeld für sich entdecken.
Aber vielleicht kriegt man ja auch diese 7 noch dazu, Freude daran zu haben, mit ihren Freunden zu spielen und diese nicht auszuschließen? Versuchen sollte man’s.
LLAP 🖖
Lieber Gunnar,
Es entscheidet allein der Lernende, ob und was er lernen will.
Ob ja, was nein. Habt ihr in deiner Schule keine Lehrpläne? Den Umfang des Lernstoffs bestimmt der Lehrer bzw. übergeordnete Instanzen. Der Schüler kann gar nicht überblicken, was er denn lernen sollte. Es liegt in der Verantwortung des Lehrers (…), das Wichtige rauszusuchen.
du kennst anscheinend den "geheimen Lehrplan" nicht. Und ob Schüler auch immer das lernen, was sie eigentlich müssen, und ob sie das so tun, wie man es ihnen aufgetragen hat, zeigen die Zensuren in den Leistungsmessungen. Da gibt es oft genug Ergebnisse unterhalb von 4,0. In diesen Fällen sagt das Bewertungssystem "nicht bestanden", was effektiv "nicht gelernt" bedeutet.
Klar habe ich einen vorgegebenen Lernstoff zu vermitteln. Aber nehmen meine Schüler den auch auf? Und wenn sie's nicht tun, dann kommen sehr schnell die Eltern, die mir den Vorwurf machen, ich hätte ihre Kinder (die's ja anscheinend nicht wissen wollten, denn sie hätten ja können) zu wenig motiviert. Lernt der Schüler nicht, ist es die Schuld des Lehrers.
Ein bisschen kann man sich an der Schule auf einen Lernzwang verlassen, denn um die Aussicht auf eine gut bezahlte Beschäftigung zu erhöhen, braucht es hochwertige Bildungsabschlüsse. Damit man diese bekommt, muss man den vorgesetzten Lernstoff schlucken und ihn so lernen, dass die Vorgaben der jeweiligen Lehrkraft erfüllt werden, denn die von dieser Lerhrkraft vergebenen Bewertungen eröffnen den Weg zu einem solchen Bildungsabschluss. Da gibt es also eine gewisse extrinsische Motivation abseits reiner Freiwilligkeit und privaten Neigungen/Hobbies/Interessen.
So viel zur Lebensrealität an der Schule.
Im Internet ein Tutorial nutzen, um etwas herauszufinden und damit etwas zu basteln, basiert auf reiner Freiwilligkeit und privaten Hobby-Interessen. Da kommt anschließend niemand und droht damit, nicht in die nächsthöhere Klasse zu versetzen. Da kann man nicht auf eine extrinsische Motivation bauen, denn die gibt es nicht. Wenn man möchte, dass sich interessierte Anfänger und Laien des Tutorials bedienen, dann darf man die Hemmschwellen nicht zu hoch ansetzen. Wie hoch dabei zu hoch ist, das ist mein Argument in unserer Diskussion. Dein Argument ist, dass mein Argument nicht gelten darf, da Zugänglichkeit ein unabdingbares Muss in einem Anfägertutorial zu sein hat, egal wie sehr das die Komplexität und die Hemmschwellen erhöht, da die Anfänger sonst zu Arschlöchern werden.
Und hier werden wir uns nicht einig.
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
Wenn man möchte, dass sich interessierte Anfänger und Laien des Tutorials bedienen, dann darf man die Hemmschwellen nicht zu hoch ansetzen. Wie hoch dabei zu hoch ist, das ist mein Argument in unserer Diskussion. Dein Argument ist, dass mein Argument nicht gelten darf, da Zugänglichkeit ein unabdingbares Muss in einem Anfägertutorial zu sein hat, egal wie sehr das die Komplexität und die Hemmschwellen erhöht, da die Anfänger sonst zu Arschlöchern werden.
Und hier werden wir uns nicht einig.
Und das ist schade.
Ja, Barrierefreiheit hat ein unabdingbares Muss in einem Anfägertutorial zu sein. Und der Punkt ist: Das erhöht die Komplexität und die Hemmschwellen gar nicht wesentlich.
Wie ich schon anderswo im Thread gesagt habe, wären in die leeren Tabellenzellen Buttons einzubauen. Wäre das Markup damit für einen Anfänger unverständlich? Nein.
Beim Anclicken wäre statt der Klasse des td die Klasse des button zu ändern und dieser auf disabled zu setzen. Wäre das JavaScript damit für einen Anfänger unverständlich? Nein.
Damit sollte das Wesentliche schon abgedeckt sein.
Nicht sagen: Barrierefreiheit mache ich nicht, weil zu kompliziert. Sondern sagen: Klar mach ich Barrierefreiheit, weil menschlich – und dabei feststellen, dass das gar nicht so kompliziert ist.
LLAP 🖖
@@Gunnar Bittersmann
Nicht sagen: Barrierefreiheit mache ich nicht, weil zu kompliziert. Sondern sagen: Klar mach ich Barrierefreiheit, weil menschlich – und dabei feststellen, dass das gar nicht so kompliziert ist.
„Barrierefreiheit wird oft als zusätzliche Arbeit und schwer zu lernen beschrieben. Und überhaupt sei nur eine kleine Anzahl von Menschen betroffen. Diese Mythen haben keine logische Grundlage und sind das Ergebnis von veralteten Informationen oder Missverständnissen.“
(Eric Eggert, Accessibility im Sinn – Kleine Änderungen, große Wirkung)
Den Artikel bitte mal lesen!
LLAP 🖖
Lieber Gunnar,
Den Artikel bitte mal lesen!
nein. Du bist jetzt dran. Im Wiki! Das ist nach dieser langen Diskussion längst überfällig.
Liebe Grüße,
Felix Riesterer.
Lieber Gunnar,
Nicht sagen: Barrierefreiheit mache ich nicht, weil zu kompliziert. Sondern sagen: Klar mach ich Barrierefreiheit, weil menschlich – und dabei feststellen, dass das gar nicht so kompliziert ist.
also: Du schreibst jetzt ein Fortsetzungstutorial, welches Du im hier vorgestellten Artikel mit dem Wortlaut "etwas mehr Entwicklungsaufwand braucht" verlinkst, welche Du als allerersten Zusatz im Kapitel "Was braucht es noch?" findest, weil ich ihn dort eingetragen habe. Und wenn Du Deine Glaubwürdigkeit nicht verspielen willst, dann formst Du alles das, was Du hier schon geschrieben und auf CodePen als Beispiele bereits erstellt hast, in diesen Fortsetzungsartikel um.
Ansonsten müsste man Dir Deine Wortwahl (Stichwort "Arschloch") vielleicht anders auslegen - siehe Glaubwürdigkeit.
Liebe Grüße,
Felix Riesterer.
Hallo Gunnar Bittersmann,
Wie würdest du jemanden nennen, der sagt: Du darfst hier nicht mitspielen, denn du bist behindert? Ich würde ihn Arschloch nennen.
Und jetzt kommst du und sagst: Kommt her, Kinder, ich zeige euch, wie man ein Arschloch wird.
Dir liegt daran, dass 93 von 100 Schüler am Ende prahlen können: Ich hab in 15 Minuten ein Tic-Tac-Toe gebaut! Mir liegt daran, dass 86 von ihnen am Ende sagen können: Ich hab in 20 Minuten ein Tic-Tac-Toe gebaut und du, mein Freund, kannst auch mitspielen.
Das macht 86 Freunde glücklich. Wenn dabei noch 7 Schüler auf der Strecke bleiben, die dann eben kein JavaScript lernen, nehm ich das dafür mehr als billigend in Kauf. Das macht die Welt eher besser als schlechter, wenn diese 7 ein anderes Betätigungsfeld für sich entdecken.
Aber vielleicht kriegt man ja auch diese 7 noch dazu, Freude daran zu haben, mit ihren Freunden zu spielen und diese nicht auszuschließen? Versuchen sollte man’s.
So:
Bis demnächst
Matthias
Hallo Gunnar Bittersmann,
Danke für deinen Beitrag. Nun muss er, falls er darf, noch den Weg ins Wiki finden, und zwar nicht anstelle des Tutorials sondern als Bonbon oben drauf. Als als eigenständiger Beitrag also. Denn ich sehe es ähnlich wie dedlfix und so ziemlich alle anderen, die sich an diesem Thread beteiligt haben, dass das Tutorial in keiner Weise schädlich ist, wenn man JavaScript erlernen möchte.
Dein Artikel deckt so einiges mehr ab, unter anderem die wichtige Zugänglichkeit.
OT: Interessant auch codepens Permalink: XXRExX ;-)
Bis demnächst
Matthias
Hallo Matthias Apsel,
Nun muss er, falls er darf, noch den Weg ins Wiki finden,
auch das Blog könnte ich mir als Heimatort vorstellen.
Bis demnächst
Matthias
Tach!
Nun muss er, falls er darf, noch den Weg ins Wiki finden,
auch das Blog könnte ich mir als Heimatort vorstellen.
Ich nicht, denn das zerstückelt unser Angebot. Eher kann ich mir vorstellen, dass im Blog eine Ankündigung (für die jungen Leute: Teaser) auch schon für den ursprünglichen Artikel erscheint, wenn er den Beta-Status verlassen hat[1].
dedlfix.
vielleicht hat er das auch schon, bin da grad nicht auf dem laufenden. ↩︎
@@Matthias Apsel
dass das Tutorial in keiner Weise schädlich ist, wenn man JavaScript erlernen möchte.
Das Schädliche daran ist, dass viele dann eben nur JavaScript erlernen.
Und dann Artikel oder Bücher schreiben, aus denen die nächsten wieder nur JavaScript lernen.
LLAP 🖖
Lieber Gunnar,
Das Schädliche daran ist, dass viele dann eben nur JavaScript erlernen.
können wir versuchen, dass wir zuerst einmal ein kleines(!) Grundlagen-Tutorial erstellen, welches nicht gleich die Welt verbessern soll, sondern Einsteigern(!) einen ersten(!) Kontakt mit der Verknüpfung von JavaScript als Programmiersprache bietet und ihre Wechselwirkung mit HTML, welches als DOM im Browser zur Verfügung steht, illustriert?
Wenn Du die Welt verbessern willst, dann solltest Du in die Politik gehen! Oder vielleicht in diverse religiöse Einrichtungen und dort Dein Evangelium predigen. Solltest Du aber die Programmierer verbessern wollen, dann müsstest Du vielleicht in das HR-Management von IT-Firmen gehen und dort die verderbten Programmierer auf den Pfad des Lichtes führen...
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
Das Schädliche daran ist, dass viele dann eben nur JavaScript erlernen.
können wir versuchen, dass wir zuerst einmal ein kleines(!) Grundlagen-Tutorial erstellen, welches nicht gleich die Welt verbessern soll, sondern Einsteigern(!) einen ersten(!) Kontakt mit der Verknüpfung von JavaScript als Programmiersprache bietet und ihre Wechselwirkung mit HTML, welches als DOM im Browser zur Verfügung steht, illustriert?
Wechselwirkung mit HTML, aha. Wie Heydon sagte: „If you're using HTML anyway, it might as well be good HTML.“
Das angeführte Beispiel aus dem AngularJS-Buch zeigt noch einmal sehr deutlich, dass der Ansatz immer wieder scheitert, Anfängern nur JavaScript beizubringen zu wollen und zu glauben, dass sie sich die nötigen HTML-Kenntnisse selbst anderswo aneignen.
So haben die Autoren wohl auch angefangen. Und haben sich die nötigen HTML-Kenntnisse eben nicht anderswo angeeignet. Und geben nun ihr Halbwissen an Anfänger weiter …
Wenn Du die Welt verbessern willst [Polemik gelöscht] Solltest Du aber die Programmierer verbessern wollen, dann müsstest Du vielleicht in das HR-Management von IT-Firmen gehen und dort die verderbten Programmierer auf den Pfad des Lichtes führen...
Ich wüsste nicht, wie HR dabei helfen sollte.
Man kann aber Entwickler auf ihre Fehler aufmerksam machen. Immer wieder. Auch Hobby-Entwickler.
LLAP 🖖
Aloha ;)
Das angeführte Beispiel aus dem AngularJS-Buch zeigt noch einmal sehr deutlich, dass der Ansatz immer wieder scheitert, Anfängern nur JavaScript beizubringen zu wollen und zu glauben, dass sie sich die nötigen HTML-Kenntnisse selbst anderswo aneignen.
Als ich das letzte Mal nachgesehen hatte, war in unserer Doku nicht nur ein bestimmtes JavaScript-Tutorial zu finden, sondern auch sehr ausführliche, breit gefächerte Inhalte zu HTML.
Unsere Definition von "anderswo" scheint sich also deutlich zu unterscheiden.
Grüße,
RIDER
@@Camping_RIDER
Als ich das letzte Mal nachgesehen hatte, war in unserer Doku nicht nur ein bestimmtes JavaScript-Tutorial zu finden, sondern auch sehr ausführliche, breit gefächerte Inhalte zu HTML.
Unsere Definition von "anderswo" scheint sich also deutlich zu unterscheiden.
Offensichtlich.
Ein anderer Artikel ist anderswo.
Du bist dem Irrglauben verfallen, jemand würde das Wiki von vorne bis hinten durchlesen?
LLAP 🖖
Lieber Gunnar,
Offensichtlich.
Ein anderer Artikel ist anderswo.
und wo ist Deiner?
Du bist dem Irrglauben verfallen, jemand würde das Wiki von vorne bis hinten durchlesen?
Nein, Du schließt im Grunde aus, dass ein Anfänger sich in HTML doch weiterbildet, obwohl ein JavaScript-Tutorial sehr stark (in Deinen Augen vielleicht zu stark) vereinfachte DOM-Strukturen für ein didaktisch reduziertes Beispiel verwendet.
Wenn Du nicht bald Deinen Artikel vorweisen kannst, dann kann man Deine Mecker-Postings über egal was leider auch in der Sache nicht mehr ernst nehmen, denn Du bist dann der, der ausschließlich meckert, anstatt mit gutem Beispiel voran zu gehen. Solche Leute helfen einer Community nicht zu gedeihen. Und dann ist ihr Wert für die Community nicht mehr positiv, denn Du nutzt Dein Wissen nicht, um zu helfen, sondern um Dich über andere zu ereifern. Diese Wahrnehmung erzwingst Du geradezu bei mir (unbd anderen!) und diese macht Dich letzten Endes unglaubwürdig. Egal wie sehr Du in der Sache vielleicht Recht gehabt hättest.
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
Ein anderer Artikel ist anderswo.
und wo ist Deiner?
Na da isser doch: https://forum.selfhtml.org/meta/2016/jan/2/neues-anfaenger-tutorial-fuer-javascript-tic-tac-toe/1658806#m1658806
Bevor jetzt Nachfragen kommen: Ist ein Beitrag im Forum der beste Platz für solch einen Artikel? Nein, wohl nicht. Aber ist denn ein Wiki der beste Platz für solch einen Artikel? Ich denke: auch nicht.
Du bist dem Irrglauben verfallen, jemand würde das Wiki von vorne bis hinten durchlesen?
Nein, Du schließt im Grunde aus, dass ein Anfänger sich in HTML doch weiterbildet
Du missverstehst. Ich schließe nicht aus, dass sich ein (lies: manche) Anfänger weiterbildet. Ich schließe aus, dass dies alle tun – obwohl das notwendig wäre.
Und diejenigen, die das nicht tun (die nach meiner Erfahrung nach die Mehrheit bilden), machen dann das erwähnte Schädliche aus.
Eben deshalb gehören bestimmte Kenntnisse mit vermittelt, damit sie bei allen ankommen.
LLAP 🖖
Lieber Gunnar,
dieser Dein Beitrag war leider nicht hilfreich. Es ist aber sehr auffällig, wie Du Dich zum x.ten Mal windest, das einzig sinvolle zu tun: Deinen Artikel da hinein zu klopfen, wo er hingehört, nämlich ins Wiki. Ob Du findest, dass er da vielleicht nicht hingehört, ist deswegen längst irrelevant, da es inzwischen fast nur noch um Deine Glaubwürdigkeit geht. Aber demontiere sie nur fleißig weiter...
Liebe Grüße,
Felix Riesterer.
Lieber Gunnar,
Wechselwirkung mit HTML, aha. Wie Heydon sagte: „If you're using HTML anyway, it might as well be good HTML.“
es tut mir leid, aber Du bist als Diskussionspartner für mich (und anscheinend nicht nur für mich) in dieser Sache inzwischen erwiesenermaßen ungeeignet, da Du meinen Standpunkt überhaupt nicht nachvollziehen kannst. Du lehnst ihn aus Gründen von Dogmen ab, da Du die Praxis nicht kennst. Gehe doch mal an eine Schule und unterrichte Schüler(!) in JavaScript inclusive "gutem HTML"! Dann darfst Du wieder Deinen Standpunkt verteidigen. So spreche ich Dir das Verständnis für die Fallstricke des Lehrens ab.
Das angeführte Beispiel aus dem AngularJS-Buch zeigt noch einmal sehr deutlich, dass der Ansatz immer wieder scheitert, Anfängern nur JavaScript beizubringen zu wollen und zu glauben, dass sie sich die nötigen HTML-Kenntnisse selbst anderswo aneignen.
Was interessiert mich hier das Buch, an dem Du Dich gerade aufgeilst? Wo ist eigentlich Dein Buch, in dem Du es besser machst? Und was insteressieren mich die Zitate, die Du aus anderen Kontexten hier anführst? Ist Heydon eine erfahrener Lehrkraft im Umgang mit Lernenden, die sich mit den Basics HTML und JavaScript gerade sehr schwer tun? HTML ist auch in Version 5 nicht "einfacher", sondern komplexer geworden. Mehr Elemente, mehr Glaubenskriege, mehr Dogmen. Da pfeife ich doch auf Apologeten wie Heydon und Dich und widme mich wieder der Praxis!
So haben die Autoren wohl auch angefangen. Und haben sich die nötigen HTML-Kenntnisse eben nicht anderswo angeeignet. Und geben nun ihr Halbwissen an Anfänger weiter …
Und das hat mit dem hier diskutierten Tutorial genau was zu tun? Richtig, überhaupt gar nichts. Nada. Du lenkst wieder von anderen Dingen ab, die der Diskussion wesentlich zuträglicher sein könnten. Ahnst Du schon, was ich meine?
Man kann aber Entwickler auf ihre Fehler aufmerksam machen. Immer wieder. Auch Hobby-Entwickler.
Dazu musst Du erst einmal ein Hobby-Entwickler sein. Die Vokabel "Entwickler" suggeriert ja schon, dass da jemand etwas entwickelt, also bereits erworbenes Wissen in die Tat umsetzt. Ein Anfänger, der dieses Tutorial wirklich benötigt, zählt also offensichtlich nicht dazu.
So. Und nun mal raus mit der Sprache! Was ist aus Deinem Ergänzungstutorial geworden? Mein OP ist vom zweiten Januar. Wir schreiben seit ein paar Minuten den 28. Februar! Code-Beispiele auf CodePen hast Du vor Wochen ja nun schon ein paar verlinkt, aber was ist mit dem zugehörigen Artikel für das hiesige Wiki geworden? Auch im Blog habe ich keinen Beitrag von Dir gelesen! Leute, die nur meckern können, jedoch selbst nicht wirklich etwas beisteuern (und nein, Deine Meinung zählt hier nicht als "etwas", ein Artikel täte das!), mag ich nicht so gerne ernst nehmen. Das wird mit der Zeit auch nicht wirklich besser, sondern eher schlimmer.
Es wäre schön, wenn von Dir das nächste Mal die erfreuliche Nachricht käme, dass Du ins Wiki einen Ergänzungsartikel eingetragen hast, der die rudimentären Anlagen des Anfänger-Tutorials um wichtige Zugänglichkeitsaspekte ergänzt. Aber da möchte ich ja wetten, dass Du das im Grunde überhaupt nicht machen willst, Dich aber genierst, es hier in aller Öffentlichkeit zuzugeben...
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
Ich hab den Tab mit deinem Posting seit Ewigkeiten offen. Vermutlich wollte ich darauf noch antworten, weiß aber nicht mehr was. Ist vielleicht auch besser, dass ich damals darauf nicht geantwortet hatte. Dein Posting spricht ja für sich:
es tut mir leid, aber Du bist als Diskussionspartner für mich (und anscheinend nicht nur für mich) in dieser Sache inzwischen erwiesenermaßen ungeeignet,
So kann man eine Diskussion natürlich auch abwürgen.
da Du meinen Standpunkt überhaupt nicht nachvollziehen kannst.
Dass ich deinen Standpunkt nicht teile heißt für dich, dass ich ihn nicht verstehe? Ich verstehe ihn, halte ihn aber für falsch.
Du lehnst ihn aus Gründen von Dogmen ab, da Du die Praxis nicht kennst.
Zur Info: Ich bin seit etlichen Jahren beruflich mit Webentwicklung befasst, kenne die Praxis dort. Du kennst Webentwicklung aus der AG an der Schule?
Mir geht’s nicht um die Praxis in der Schule, mir geht’s um die Praxis im Web. Aus manchen Anfängern werden Webentwickler. Und die machen dann genauso weiter, wie sie es als Anfänger gelernt haben. Deshalb müssen Anfänger von Anfang an mit den richtigen Grundlagen versorgt werden. Das betrifft dann auch die, die später nicht Webentwickler werden.
Gehe doch mal an eine Schule und unterrichte Schüler(!) in JavaScript inclusive "gutem HTML"! Dann darfst Du wieder Deinen Standpunkt verteidigen. So spreche ich Dir das Verständnis für die Fallstricke des Lehrens ab.
Kannst du gerne. Ich bestreite nicht deine Kompetenz in Methodik des Lehrens.
Würdest du im Gegenzug bitte nicht meine Kompetenz bestreiten beurteilen zu können, was die Lerninhalte sein sollten?
So haben die Autoren wohl auch angefangen. Und haben sich die nötigen HTML-Kenntnisse eben nicht anderswo angeeignet. Und geben nun ihr Halbwissen an Anfänger weiter …
Und das hat mit dem hier diskutierten Tutorial genau was zu tun? Richtig, überhaupt gar nichts. Nada.
Was mangelnde HTML-Kenntnisse mit dem hier diskutierten Tutorial zu tun haben? Alles!
Dem Tutorial fehlt(e?) das grundlegende Verständnis von HTML, was aber notwendige Voraussetzung für JavaScript ist.
LLAP 🖖
sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
Lieber Gunnar,
vielen Dank für Dein Feedback!
Im Kern möchtest Du das Tutorial um den sehr wesentlichen und wichtigen Punkt der Zugänglichkeit erweitern.
Kümmern wir uns lieber um die grundsätzliche Frage: Sollte das alles in einem Tutorial für Anfänger stehen?
Ja, unbedingt!!
Da möchte ich Dir widersprechen. Insbesondere "das alles" sollte nicht hinein, sondern meiner Meinung nach nur der an passender Stelle auf ein anderes Tutorial verweisende mahnende Hinweis, dass die gerade erarbeitete Lösung keinerlei Acht darauf gibt, ob das Spiel Barrieren für die Zugänglichkeit enthält, und wie man diese entfernen könnte.
So, wie ich das Problem des typsicheren Vergleichs nur angerissen habe, könnte man das auch mit dem Problem der Barrieren/Zugänglichkeit machen. Aber eben nur das: anreißen. Die Ausführlichkeit in Deinem Posting empfinde ich als für das Tutorial völlig überdimensioniert.
Warum nimmst Du nicht Dein Posting und arbeitest es zu einem zweiten Teil für das Anfänger-Tutorial um, der sich auf das bereits erarbeitete Wissen und Können stützt, um es fortzuführen? Wenn es dann einen ausführlicheren Artikel zur Barrierefreiheit im Wiki gibt, kann zwischen diesem und Deiner Fortsetzung hin und her verlinkt werden!
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
Im Kern möchtest Du das Tutorial um den sehr wesentlichen und wichtigen Punkt der Zugänglichkeit erweitern.
Wenn du mit „Zugänglichkeit“ Barrierefreiheit meinst: Nicht nur. Die fällt dabei so ganz nebenbei mit ab.
Wenn du mit „Zugänglichkeit“ meinst, dass Inhalte im Web ohne Voraussetzungen präsentiert werden sollten – das meine ich. Grundfunktionalität für alle anbieten, progressive enhancement draufsetzen.
Da das Web von Natur aus sowohl responsiv als auch barrierefrei ist – solange man dem nicht mit CSS oder JavaScript entgegenwirkt –, ist die Grundfunktionalität (bei richtig gewähltem Markup) barrierefrei. Beim Erweitern gilt es darauf zu achten, dass man die Barrierefreiheit erhält (im Sinne von „nicht zerstört“, nicht im Sinne von „bekommt“).
Da möchte ich Dir widersprechen. Insbesondere "das alles" sollte nicht hinein, sondern meiner Meinung nach nur der an passender Stelle auf ein anderes Tutorial verweisende mahnende Hinweis, dass die gerade erarbeitete Lösung keinerlei Acht darauf gibt, ob das Spiel Barrieren für die Zugänglichkeit enthält, und wie man diese entfernen könnte.
Da möchte ich dir widersprechen. Grundsätzlich. Ein Artikel muss in sich richtig sein und nicht auf notwendige Berichtigungen verlinken müssen.
Ein JavaScript-Tutorial sollte unbedingt den Grundgedanken vermitteln, dass JavaScript als progressive enhancement anzusehen ist, weil es eben nicht immer zur Verfügung steht (und damit sind nicht nur JavaScript-Ausschalter gemeint).
Barrierefreiheit sollte man nicht erst später dazu tun. Zum einem wird eben das dann meist nicht gemacht, zum anderen ist das viel aufwändiger als Barrierefreiheit von Anfang an in die Entwicklung mit einfließen zu lassen. Deshalb gehört das zum Inhalt eines Anfängertutorials, nicht in einen anderen Artikel verbannt, der von vielen gar nicht gelesen wird.
Léonie Watson zeigt in ARIA, accessibility APIs & coding like you give a damn! (Video, Folien), wie aufwändig es ist, aus einem beliebigen Element (in der jetzigen Version des Tic-Tac-Toe wäre das td) ein UI-Element zu machen, das nicht nur mit der Maus, sondern auch per Tastatursteuerung bedienbar ist, und assistive Technologie (wie Screenreader) dem Nutzer auch mitgeteilt, dass es sich dabei um ein UI-Element mit einer bestimmten Funktion handelt. Heydon Pickering zeigt im Artikel Reinventing The Hyperlink dasselbe für Links. Fazit: Nicht machen, sondern die richtigen HTML-Elemente verwenden.
In dem Fall nicht leere Tabellenzellen <td></td> mit click-Handler, sondern Tabellenzellen mit Button darin. Die Beschriftung der Buttons wäre die Position des jeweiligen Spielfeldes:
<td>
<button id="button-top-left">Feld oben links</button>
</td>
So, wie ich das Problem des typsicheren Vergleichs nur angerissen habe, könnte man das auch mit dem Problem der Barrieren/Zugänglichkeit machen. Aber eben nur das: anreißen. Die Ausführlichkeit in Deinem Posting empfinde ich als für das Tutorial völlig überdimensioniert.
Du hast insofern recht, dass der Umfang des in meinen gezeigten Beispielen progressive enhancements nicht in ein Anfänger-Tutorial gehört. Insbesondere nicht die Animation, die sowieso nur zu sehen ist, wenn kein JavaScript ausgeführt wird. Der Grundgedanke von progressive enhancement gehört aber wie gesagt rein!
Das kann auch so aussehen, dass man die ursprünglich im HTML vorhandenen select-Felder im DOM durch die eben angesprochenen Buttons ersetzt:
if (document.querySelector)
{
document.documentElement.classList.add('js');
var ticTacToeElement = document.querySelector('#tic-tac-toe');
var tdElements = ticTacToeElement.querySelectorAll('td');
for (var i = 0, labelElement; i < tdElements.length; i++)
{
labelElement = tdElements[i].querySelector('label');
tdElements[i].innerHTML = '<button id="button-' + labelElement.getAttribute('for') + '">' + labelElement.innerHTML + '</button>';
}
}
Den Buttons wird Text- und Hintergrundfarbe und Rahmen genommen und bei :focus eine Hintergrundfarbe gegeben (könnte man auch zusätzlich auch bei :hover tun) — das sieht dann so aus (unfertig).
Im gleichen Schritt kommt natürlich noch die Eventverarbeitung und die Spiellogik hinzu. Beim Drücken auf einen Button wird dieser aus dem DOM entfernt und das Feld mit ❌ (×, x) bzw. ⭕ (○, o) markiert. Bis auf das Entfernen des Buttons hast du ja schon alles. Oh wait, diese Änderung müsste AT dem Nutzer auch bekanntgeben; da wäre wohl noch ein ARIA-Attribut fällig.
So hat man dann einen Artikel, der auf progressive enhancement und Barrierefreiheit eingeht und deren Wichtigkeit verdeutlicht, ohne dabei den Rahmen zu sprengen.
Warum nimmst Du nicht Dein Posting und arbeitest es zu einem zweiten Teil für das Anfänger-Tutorial um, der sich auf das bereits erarbeitete Wissen und Können stützt, um es fortzuführen?
Wo ich das alles schon mal aufgeschrieben habe, könnte ich das tun und zeigen, wie man anstelle des in diesem Posting dargestellten einstufigen progressive enhancements ein mehrstufiges machen kann. Aber wäre das so wichtig?
Wichtig ist mir, dass der Grundlagenartikel schon bereits progressive enhancement vemittelt.
LLAP 🖖
@@Gunnar Bittersmann
Léonie Watson zeigt in ARIA, accessibility APIs & coding like you give a damn! (Video, Folien), wie aufwändig es ist, aus einem beliebigen Element (in der jetzigen Version des Tic-Tac-Toe wäre das
td) ein UI-Element zu machen, das nicht nur mit der Maus, sondern auch per Tastatursteuerung bedienbar ist, und assistive Technologie (wie Screenreader) dem Nutzer auch mitgeteilt, dass es sich dabei um ein UI-Element mit einer bestimmten Funktion handelt.
Ich frage mich gerade, ob das mit td-Elementen überhaupt ginge. tds haben ja schon eine ARIA-Rolle: cell. Wenn man diese einfach mit role="button" überschreiben würde, dann wären das (für AT) keine Tabellenzellen mehr.
LLAP 🖖
Hallo Gunnar Bittersmann, @Felix Riesterer
Wäre es klug, den Feldern Klassenbezeichner zu verpassen?
|dia1 top left | top center | dia2 top right | |middle left | dia1 dia2 middle center | middle right | |dia2 bottom left | bottom center | dia1 bottom right |
Damit beschränkte sich die Frage nach dem Sieger auf das Zählen von Klassen.
Oder ist die Idee vollkommen abwegig?
Bis demnächst
Matthias
@@Matthias Apsel
Damit beschränkte sich die Frage nach dem Sieger auf das Zählen von Klassen.
Oder ist die Idee vollkommen abwegig?
IMHO ja.
Die Spielelogik sollte von der Ausgabe (GUI) entkoppelt werden – auch und gerade in einem Tutorial für Anfänger, das zeigen sollte, wie man es richtig macht.
Wenn man die Spieldaten in einer 3×3-Matrix hält, vereinfacht das auch die Erkennung des Spielendes. Siehe https://forum.selfhtml.org/meta/2016/jan/2/neues-anfaenger-tutorial-fuer-javascript-tic-tac-toe/1659297#m1659297 unter „Aber wäre der Code dadurch besser geworden?“
LLAP 🖖
sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
Hallo Gunnar Bittersmann,
@supports (transform: scale(1)) {Dazu fragen wir ab, der der Browser
transformdenn kann. (Andernfalls würden wir die Vergrößerung in alten Browsern nicht mehr haben.)#tic-tac-toe label::after { width: 100%; height: 100%; transform: scale(0.25); transition: transform 0.1s; }
Der Grund der feature detection liegt doch dadrin, dass ohne das Verstehen von transform beide after-Pseudo-Elemente übereinander liegen und die gesamte Tabellenzelle ausfüllen würden, also in der fehlenden initialen Verkleinerung.
Bis demnächst
Matthias
Hallo Gunnar Bittersmann,
<td> <fieldset> <legend>top left field</legend> <input type="radio" name="top-left" id="top-left-x"> <label for="top-left-x">x</label> <input type="radio" name="top-left" id="top-left-o"> <label for="top-left-o">o</label> </fieldset> </td>Wieder nicht besonders schön, aber funktioniert. Und ist blind bedienbar. ♿️
Leider nein, JAWS liest nur x bzw. o vor, die Zuordnung zum legend-Element findet nicht statt. Deshalb müssen auch die label-Inhalte z.B. „top-left-o“ heißen,
Bis demnächst
Matthias
Hallo Matthias Apsel,
Leider nein, JAWS liest nur x bzw. o vor, die Zuordnung zum legend-Element findet nicht statt. Deshalb müssen auch die label-Inhalte z.B. „top-left-o“ heißen,
alternativ könnte man auch für die legend-Elemente tabindex="0" setzen. Dann wäre das Verhalten ähnlich dem Beispiel mit select.
Bis demnächst
Matthias
Lieber Gunnar,
ich habe mir diese Antwort nocheinmal durchgesehen, um zu prüfen, was eine zugängliche Bedienung alles erfordert. Nun bin ich mir nicht mehr so sicher, ob Deine Vorschläge unbedingt die besten sind.
:-P
Nun, das Markup. Es ist so gut wie nicht vorhanden. Nur leere Tabellenzellen. Aber was sollten die auch für Inhalt haben?
Der Inhalt könnte in einem Button bestehen, der als Eingabewerkzeug dafür dient, dass der Spieler, der gerade an der Reihe ist, dieses Feld belegen möchte.
Also: Ein Button in jedes Tabellenfeld. Nur einer. Und der wird nach Betätigen durch den Inhalt ersetzt, der das Symbol des jeweiligen Spielers repräsentiert, also den Buchstaben x oder o.
Dazu fragen wir uns, was denn die Gundfunktionalität ist: Ganz einfach die Auswahl von Kreuz oder Kreis in jedem Feld.
Nein. Das ist nicht die Grundfunktionalität. Diese besteht in der Auswahl eines der noch freien Felder. Der Benutzer wählt keinesfalls zwischen Kreuz und Kreis! Das würde sich mit der Spielmechanik stören, da dann eine Mehrfacheingabe denkbar wäre, welche gegen die Spielregel verstößt, dass die Spieler im Wechsel jeweils ein Feld für sich in Anspruch nehmen.
Eine solche Auswahl müsste man aufwendig wieder kompensieren, damit der aktuelle Spieler nur "sein" Symbol benutzen kann. Daher frage ich mich wozu eine solche Wahl überhaupt einen Sinn haben soll. Dann doch gleich einen Button, der das Feld auswählt. Die Spielmechanik definiert ja das Symbol des Spielers ohnehin schon.
Jede Zelle hat initial keinen Wert und kann durch Nutzerinteraktion mit ❌ (×, x) oder ⭕ (○, o) befüllt werden.
Fast. Sie enthält einen Button. Nach Betätigen dieses Buttons wird dieser ersetzt. Siehe oben.
Aber das passende UI-Element zur Auswahl ist ein Drop-Down-Menü. Das Innere der Tabellenzellen wäre
Finde ich nicht. Siehe oben. Ein Button sollte genügen. Er ist ja "von Natur aus interaktiv". :-P
Das kann sogar ein Blinder bedienen. (Und das ist wörtlich gemeint. ♿️ Deswegen auch das
aria-label-Attribut.)
Von einem Button hätte ich jetzt auch nichts anderes erwartet. Dieser sollte ebenso zuverlässig von einem Blinden bedient werden können.
Das Aussehen können wir ja verbessern. Aussehen heißt CSS.
Also kann man die Zelle weiterhin mit der passenden Klasse versehen. Diese sorgt für ein visuelles Ersetzen des Buchstabens "x" oder "o" und macht daraus das "schönere" Symbol "❌" oder "⭕".
Hier (erst!!) kommt nun JavaScript ins Spiel.
Finde ich nicht. JavaScript sollte das Spielfeld bereits erstellen. JavaScript kann einen Button ins Dokument pflanzen, der das Erstellen des Spielfeldes verursacht. Ohne JavaScript sollte ja auch keine Tabelle zu sehen sein.
Der nächste Spieler ist am Zug.
Um die nun nicht benötigten
option-Elemente auszublenden, erhält das Stylesheet noch eine Ergänzung:
Findest Du nicht, dass mein Vorschlag mit nur einem Button hier ebenso zugänglich aber technisch simpler und von daher sinnvoller ist?
Bei Ausfall von JavaScript oder CSS funktioniert die Grundfunktionalität immer noch – und zwar auch, wenn CSS ausfällt, JavaScript aber ausgeführt wird. Dann sieht das Feld wieder ungestylt aus, das JavaScript sorgt aber schon dafür, dass in den disableten
selects nicht erneut auswählt werden kann.
Ich finde nicht, dass eine JavaScript-freie Lösung in ein JavaScript-Tutorial sollte. Meiner Meinung nach darf man für ein JavaScript-Spiel diejenigen User ausschließen, für die JavaScript nicht verfügbar ist. Deshalb auch mein Votum für den initialen Button, der das Spiel erst erstellt, sodass ohne JavaScript auch nichts vom Spielfeld angezeigt wird.
Wenn der Spieler am Zug ist, der die Kreuze macht, werden die Kreuz-Radiobuttons enablet; die Kreis-Radiobuttons disablet. Für den anderen Spieler entsprechend andersrum.
Gefällt mir nicht. Aber siehe oben.
Die Label lassen wir das gesamte Feld ausfüllen, damit die Spieler überall im Feld clicken können.
Ein Button benötigt kein Label. Das macht die Sache für mich attraktiver umzusetzen. Da hätte ich dann Lust, das Tutorial in der von mir vorgeschlagenen Weise zu überarbeiten.
Auch diese Lösung funktioniert, wenn JavaScript interpretiert wird, CSS aber nicht.
Auch mein jetziger Vorschlag passt zu dieser Aussage. Buttons werden durch die Buchstaben "x" oder "o" ersetzt. Mit CSS wird es schöner, ohne CSS bleibt es aber sinnvoll dargestellt.
An der Stelle käme dann wieder die Erkennung des Spielendes hinzu, um die wir uns in diesem Posting nicht kümmern wollen.
Nun möchte ich doch diskutieren, wie man das Spielende sinnvoll darstellt. Auf jeden Fall sollte man die betreffenden Buchstaben in strong- oder zumindest em-Elemente verlagern, damit aus semantischer Sicht klar wird, welche Felder nun zum Spielentscheid beigetragen haben. Natürlich passiert bei einem Unentschieden hier nichts.
Die Anzeige, wer nun gewonnen hat, ist momentan nur durch generierten Inhalt über eine Klasse gelöst. Wie schon erörtert wird solcher Inhalt von Screen-Readern nicht vorgelesen, also ist die momentane Lösung nicht zugänglich. Besser wäre eine Art Beschriftung. Da fällt mir spontan das caption-Element ein. Wie fändest Du das? Dieses Element könnte auch während des Spiels eine Meldung enthalten, wer gerade am Zug sei. Würde sich das blind bedienen lassen? Bei Spielende kann der Inhalt dieses caption-Elements gerne die Tabelle überlagernd dargestellt werden.
Kümmern wir uns lieber um die grundsätzliche Frage: Sollte das alles in einem Tutorial für Anfänger stehen?
Ja, unbedingt!! Wie sonst sollen Anfänger das Prinzip von progressive enhancement verinnerlichen, wenn es ihnen in Tutorials nicht so vorgemacht wird? Kein Anfänger wird nach einem solchen JavaScript-Tutorial noch ein zweites lesen, denn die Lösung „funzt“ ja. Nur dass sie eben nicht funktioniert.
In kleinen und sinnvollen Dosen sehe ich das ein. Wenn Dir meine Vorschläge als ausreichend erscheinen, würde ich den Artikel entsprechend überarbeiten. Dabei werde ich dann die Vorüberlegungen etwas ausführlicher im Hinblick auf Zugänglichkeit gestalten, um die Erkenntnisse dieses Threads zur Zufriedenheit aller im Tutorial einzubringen.
Wollen wir die nächste Generation von Entwicklern heranzüchten, die das dreiundzwölfzigste JavaScript-Framework entwickeln, ohne die geringste Ahnung von HTML zu haben? Was man dem erzeugten Code auch ansieht und das Ergebnis zu Lasten von UX und Barrierefreiheit, also zu Lasten der Nutzer geht?
Kann ich sie davon abhalten? Das Framework werden sie ohnehin entwickeln. Nur vielleicht kein unzugängliches Tic-Tac-Toe mehr. Und wenn man daran sehen und verstehen - also nachvollziehen! - kann, wie man von Anfang an die Zugänglichkeit im Blick behält, dann finden wir beide doch noch unsere Positionen bestärkt.
Was meinst Du?
Liebe Grüße,
Felix Riesterer.
Hallo Felix,
ich habe die Aktivitäten in diesem Thread zwar nur noch mit gebremstem Schaum mitverefolgt, aber ich glaube, du hast mit diesem Beitrag eine ganz wesentliche und richtige Konzeptwende eingeleitet.
Der Inhalt könnte in einem Button bestehen, der als Eingabewerkzeug dafür dient, dass der Spieler, der gerade an der Reihe ist, dieses Feld belegen möchte.
Cool. Genau das.
Dazu fragen wir uns, was denn die Gundfunktionalität ist: Ganz einfach die Auswahl von Kreuz oder Kreis in jedem Feld.
Nein. Das ist nicht die Grundfunktionalität. Diese besteht in der Auswahl eines der noch freien Felder. Der Benutzer wählt keinesfalls zwischen Kreuz und Kreis! Das würde sich mit der Spielmechanik stören, da dann eine Mehrfacheingabe denkbar wäre, welche gegen die Spielregel verstößt, dass die Spieler im Wechsel jeweils ein Feld für sich in Anspruch nehmen.
Richtig, die Auswahl der Spielfigur ergibt sich durch die Zugnummer (gerade/ungerade).
Eine solche Auswahl müsste man aufwendig wieder kompensieren, damit der aktuelle Spieler nur "sein" Symbol benutzen kann. Daher frage ich mich wozu eine solche Wahl überhaupt einen Sinn haben soll. Dann doch gleich einen Button, der das Feld auswählt. Die Spielmechanik definiert ja das Symbol des Spielers ohnehin schon.
ACK. Eine Liste mit zwei Auswahlmöglichkeiten, von denen aber immer nur eine verfügbar ist, ergibt wenig Sinn.
So long,
Martin
Lieber Martin,
aber ich glaube, du hast mit diesem Beitrag eine ganz wesentliche und richtige Konzeptwende eingeleitet.
ich habe den Artikel und seine Beispiele komplett neu gefasst und überarbeitet. Jetzt sollten alle Aspekte der Zugänglichkeit auch in @Gunnar Bittersmann-s Sinne in diesem Anfänger-Tutorial zur Zufriedenheit behandelt und an den passenden Stellen angemahnt und vorgeführt sein.
Liebe Grüße,
Felix Riesterer.
Servus!
aber ich glaube, du hast mit diesem Beitrag eine ganz wesentliche und richtige Konzeptwende eingeleitet.
ich habe den Artikel und seine Beispiele komplett neu gefasst und überarbeitet.
Vielen Dank!
Mir gefällt besonders die Kleinschrittigkeit am Anfang, die vieles noch einmal gut erklärt.
Zum Schluss wird's schwieriger, aber immer noch nachvollziehbar.
Jetzt sollten alle Aspekte der Zugänglichkeit auch in @Gunnar Bittersmann-s Sinne in diesem Anfänger-Tutorial zur Zufriedenheit behandelt und an den passenden Stellen angemahnt und vorgeführt sein.
Ich bewundere deinen Optimismus.
Herzliche Grüße
Matthias Scharwies
Lieber Matthias,
Jetzt sollten alle Aspekte der Zugänglichkeit auch in @Gunnar Bittersmann-s Sinne in diesem Anfänger-Tutorial zur Zufriedenheit behandelt und an den passenden Stellen angemahnt und vorgeführt sein.
Ich bewundere deinen Optimismus.
das hat nichts (mehr) mit Optimismus zu tun. @Gunnar Bittersmann hat sich seine Glaubwürdigkeit nun wirklich mit viel Fleiß verspielt. Seine Vorschläge zu "Anfängern gleich von Anfang an Richtiges beibringen" haben sich ja als nicht optimal herausgestellt (vergleiche seine aufwendigen HTML-Konstrukte für zugängliche Bedienung). Weiterhin weigert er sich ja hartnäckig, im Wiki inhaltlich nachhaltig beizutragen (er wurde wiederholt darauf angesprochen, nicht nur von mir) und übt sich unaufhörlich im Predigen, anstatt im Tun (lies: "Tun" = inhaltliche Wiki-Arbeit).
Dass meine Neufassung des Artikels die Notwendigkeit der Zugänglichkeit verstärkt in den Blick nimmt, und dass das Ergebnis deshalb technisch etwas komplexer geworden ist, geht unmittelbar auf seine Argumentation zurück, ja. Das ist sein Verdienst. Er hätte seine Glaubwürdigkeit in diesem Forum aber wesentlich erhalten, wenn nicht sogar steigern können, wenn die Neuauflage von ihm gekommen wäre, insbesondere mit den neuen Erkenntnissen hinsichtlich "ein Button" versus "komplexes Drop-Down-Menü"...
Irgendwie ist es bezeichnend, dass er sich z.B. in der Flaggen-Frage verausgabt, anstatt Wiki-Artikel inhaltlich zu verbessern.
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
(vergleiche seine aufwendigen HTML-Konstrukte für zugängliche Bedienung).
Das stimmt nicht. Da bringst du was durcheinander. Das hatte ich aber auch schon mal gesagt.
Weiterhin weigert er sich ja hartnäckig, im Wiki inhaltlich nachhaltig beizutragen
Das hatte ich hinlänglich begründet. Ich sehe den Sinn nicht, warum du dessen ungeachtet immer wieder mit demselben Mist ankommst. Es sei denn, dir steht der Sinn, den alten Streit immer wieder neu aufzukochen.
LLAP 🖖
sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
@@Felix Riesterer
ich habe den Artikel und seine Beispiele komplett neu gefasst und überarbeitet. Jetzt sollten alle Aspekte der Zugänglichkeit auch in @Gunnar Bittersmann-s Sinne in diesem Anfänger-Tutorial zur Zufriedenheit behandelt und an den passenden Stellen angemahnt und vorgeführt sein.
Du hast erkennbare Fortschritte gemacht. Mit „alle Aspekte“ solltest du aber vorsichtig sein.
Es ist nicht geholfen, wenn ein Screenreader „Button wählen Button wählen Button wählen Button wählen Button wählen Button wählen Button wählen Button wählen Button wählen“ vorliest. Die Buttons brauchen eine jeweils eigene Beschriftung:
<tr>
<td><button>Feld oben links wählen</button></td>
<td><button>Feld oben Mitte wählen</button></td>
<td><button>Feld oben rechts wählen</button></td>
</tr>
<tr>
<td><button>Feld Mitte links wählen</button></td>
<td><button>Feld Mitte Mitte wählen</button></td>
<td><button>Feld Mitte rechts wählen</button></td>
</tr>
<tr>
<td><button>Feld unten links wählen</button></td>
<td><button>Feld unten Mitte wählen</button></td>
<td><button>Feld unten rechts wählen</button></td>
</tr>
(„Feld Mitte Mitte“ hört sich nicht besonders an, da lässt sich Besseres finden. „Mittelfeld“?)
„Es sieht so aus, als wäre die Doppelung mit dem Tabelleninhalt „x“ und der Klasse x unnötig. […] Um die Doppelung mit gleichlautender Klasse zum Tabelleninhalt kommt man daher nicht herum.“
Das ist eine Lüge-für-Kinder. Es sollte auch mit <td aria-label="x"></td> gehen, was Screenreader zufriedenstellen dürfte und auch zum Styling verwendet werden kann.
Aber das nur nebenbei. Das soll nicht heißen, dass man das so umsetzen sollte. Gerade in einem Anfängertutorial ist Tabellenzelleninhalt und Klasse wohl eine gute Wahl. Vielleicht einfach die Aussage „um die Doppelung kommt man nicht herum“ entschärfen/weglassen?
„[…] die einem geeigneten Block-Element (in diesem Tutorial <aside>, aber es könnte auch ein fast beliebiges anderes sein) vergeben wird“
Nein, das ist fehlerhaftes HTML. aside ist hier nicht geeignet, wenn das Tic-Tac-Toe doch der Hauptinhalt der Seite ist.
Manchmal ist das geeignete HTML-Element auch ein div.
Ich bin auch nicht sicher, ob caption der beste Platz ist, um die Information unterzubringen, welcher Spieler am Zug ist.
„im gegenwärtigen Zustand kann unser Spiel nicht neu gestartet werden.“
Bei vernünftigem™ Markup mit zwei Radiobuttons (bzw. einem select) hat man die Funktion gratis. Das Ganze in ein form-Element, einen Reset-Button rein – fertig.
Irgendwann kommst du noch dahinter, dass progressive enhancement nicht kompliziert und aufwendig ist, sondern im Gegenteil viele Dinge vereinfacht.
LLAP 🖖
sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
Lieber Gunnar,
Du hast erkennbare Fortschritte gemacht. Mit „alle Aspekte“ solltest du aber vorsichtig sein.
g
Es ist nicht geholfen, wenn ein Screenreader „Button wählen Button wählen Button wählen Button wählen Button wählen Button wählen Button wählen Button wählen Button wählen“ vorliest. Die Buttons brauchen eine jeweils eigene Beschriftung:
<tr> <td><button>Feld oben links wählen</button></td> <td><button>Feld oben Mitte wählen</button></td> <td><button>Feld oben rechts wählen</button></td> </tr> <tr> <td><button>Feld Mitte links wählen</button></td> <td><button>Feld Mitte Mitte wählen</button></td> <td><button>Feld Mitte rechts wählen</button></td> </tr> <tr> <td><button>Feld unten links wählen</button></td> <td><button>Feld unten Mitte wählen</button></td> <td><button>Feld unten rechts wählen</button></td> </tr>
Sehr guter Einwand! Das habe ich umgesetzt. Warum wolltest Du das nicht gleich tun?
„Es sieht so aus, als wäre die Doppelung mit dem Tabelleninhalt „x“ und der Klasse x unnötig. […] Um die Doppelung mit gleichlautender Klasse zum Tabelleninhalt kommt man daher nicht herum.“
Das ist eine Lüge-für-Kinder. Es sollte auch mit
<td aria-label="x"></td>gehen, was Screenreader zufriedenstellen dürfte und auch zum Styling verwendet werden kann.Aber das nur nebenbei. Das soll nicht heißen, dass man das so umsetzen sollte. Gerade in einem Anfängertutorial ist Tabellenzelleninhalt und Klasse wohl eine gute Wahl. Vielleicht einfach die Aussage „um die Doppelung kommt man nicht herum“ entschärfen/weglassen?
Hehe, "Lüge-für-Kinder"... aber so richtig kontern konntest Du dann doch nicht. Deinen Gegenvorschlag mit dem aria-label-Attribut hast Du ja selbst zurück gezogen. Ist Content denn nicht mehr King? Muss man das, was als Content im Dokument steht, jetzt grundsätzlich und zusätzlich mit aria--Attributen auszeichnen?
Der letzte Satz ist jedenfalls gestrichen. Damit sollte die "Lüge-für-Kinder" entfallen.
Nein, das ist fehlerhaftes HTML.
asideist hier nicht geeignet, wenn das Tic-Tac-Toe doch der Hauptinhalt der Seite ist.
Wenn, ja wenn dem so ist, dann ja. Aber wissen wir, wie das Spiel von Anfängern eingesetzt werden wird? Vielleicht basteln die eine Seite, auf der es verschiedene Spiele geben wird?
Manchmal ist das geeignete HTML-Element auch ein
div.
Manchmal, ja. Und hier? Kommt wieder mal wie so oft darauf an...
Ich bin auch nicht sicher, ob
captionder beste Platz ist, um die Information unterzubringen, welcher Spieler am Zug ist.
Hast Du einen besseren Vorschlag? Nein? Dann bleibt es dabei.
„im gegenwärtigen Zustand kann unser Spiel nicht neu gestartet werden.“
Bei vernünftigem™ Markup mit zwei Radiobuttons (bzw. einem
select) hat man die Funktion gratis. Das Ganze in einform-Element, einen Reset-Button rein – fertig.
Das sogenannte vernünftige Markup hat leider mit der Spielmechanik und der dazu notwendigen Benutzerführung nicht das geringste gemeinsam. Das hatte ich schon besprochen. Wir benötigen exakt einen Button, um ein Spiel auszuwählen. Die Spieleridentität muss(!) das Spiel selbst entscheiden.
Deswegen: Nein, keine Banane für Dich.
Irgendwann kommst du noch dahinter, dass progressive enhancement nicht kompliziert und aufwendig ist, sondern im Gegenteil viele Dinge vereinfacht.
Dein Markup-Beispiel konnte mich in dieser Angelegenheit nicht überzeugen. Aber die Sache mit dem Neustart ist inzwischen im Tutorial enthalten. Kannst es ja mal ausprobieren!
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
Sehr guter Einwand! Das habe ich umgesetzt. Warum wolltest Du das nicht gleich tun?
Weil ich nach wie vor der Meinung bin, dass diese Art von Artikeln in der Autorenschaft einer Person bleiben sollten, Änderungen also vom Autor eingepflegt werden sollten.
Hehe, "Lüge-für-Kinder"...
aber so richtig kontern konntest Du dann doch nicht.
Das war auch gar nicht meine Absicht …
Deinen Gegenvorschlag mit dem
aria-label-Attribut hast Du ja selbst zurück gezogen.
… das war kein Gegenvorschlag. Meine Absicht war einfach nur zu zeigen, dass deine Formulierung „um die Doppelung kommt man nicht herum“ unzutreffend ist. Ich habe einen Weg gezeigt, wie man doch um die Doppelung herumkommt. Damit ist nicht gesagt, dass man den Weg gehen sollte.
Nein, das ist fehlerhaftes HTML.
asideist hier nicht geeignet, wenn das Tic-Tac-Toe doch der Hauptinhalt der Seite ist.Wenn, ja wenn dem so ist, dann ja. Aber wissen wir, wie das Spiel von Anfängern eingesetzt werden wird? Vielleicht basteln die eine Seite, auf der es verschiedene Spiele geben wird?
Dann wären alle Spiele der Hautinhalt der Seite.
aside wäre dann das passende Element, wenn es anderen Hauptinhalt auf der Seite gibt und zusätzlich daneben noch „kuck mal, du kannst hier übrigens auch Tic-Tac-Toe spielen (wenn du gern vom Hauptinhalt abgelenkt werden möchtest)“.
Manchmal ist das geeignete HTML-Element auch ein
div.Manchmal, ja. Und hier?
Ja, hier. So war das „Manchmal ist …“ zu verstehen.
Ich bin auch nicht sicher, ob
captionder beste Platz ist, um die Information unterzubringen, welcher Spieler am Zug ist.Hast Du einen besseren Vorschlag?
In einem p über der Tabelle.
„Zum Spielen bitte abwechselnd in die Spielfelder klicken/tappen!“ und „Spieler X ist am Zug“ gehört ja auch inhaltlich zusammen.
Das sogenannte vernünftige Markup hat leider mit der Spielmechanik und der dazu notwendigen Benutzerführung nicht das geringste gemeinsam. Das hatte ich schon besprochen. Wir benötigen exakt einen Button, um ein Spiel auszuwählen. Die Spieleridentität muss(!) das Spiel selbst entscheiden.
Nein, das muss es in der Grundfunktionalität eben nicht. Das hatte ich schon besprochen. Hast du wohl ignoriert.
Deswegen: Nein, keine Banane für Dich.
Schon vergessen? Ich bin Ossi, also ohne Bananen aufgewachsen (so denken die Wessis jedenfalls). Deswegen: Nein, keine Träne für dich.
Dein Markup-Beispiel konnte mich in dieser Angelegenheit nicht überzeugen.
Einfach <button type="reset"> ist nicht überzeugender als unzählige Zeilen JavaScript? …
Aber die Sache mit dem Neustart ist inzwischen im Tutorial enthalten.
… zu denen es so viel zu sagen gibt, dass dies ein Neustart eines Postings erfordert.
LLAP 🖖
sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
Lieber Gunnar,
Weil ich nach wie vor der Meinung bin, dass diese Art von Artikeln in der Autorenschaft einer Person bleiben sollten, Änderungen also vom Autor eingepflegt werden sollten.
die alte Ausrede... kenn' ich schon. Die bringt das SELFHTML-Wiki aber nicht weiter - und das ist die Grundfunktion von SELFHTML, nicht das Forum. Letzteres ist seit den Anfangstagen nur eine Ergänzung. SELFHTML hätte mehr von Dir, wenn Du im Wiki aktiver wärst. Mit Ausreden kommst Du da nicht weiter.
Hehe, "Lüge-für-Kinder"...
Achso. Das alte pädagogische Mittel, um den Einstieg in eine komplexe Materie zu erleichtern. Das gehört zum Lehren dazu. Später, nachdem der Einstieg geschafft ist, kommt dann die nächste verkraftbare Menge an Input/Wahrheit/Fachwissen ... Das halte ich für richtig.
Damit ist nicht gesagt, dass man den Weg gehen sollte.
Und welchen Wert hat dann Dein aria-Label-Vorschlag? War der nur Feuerwerk? Oder wolltest Du damit etwas substanzielles vorschlagen? Warum sollte man diesen Weg gehen, und warum gerade nicht?
Im Moment wirkt das wieder wie Rechthaben um des Rechthabens willen.
In einem
püber der Tabelle.
Hmm. Naja. Da darf man geteilter Meinung sein.
„Zum Spielen bitte abwechselnd in die Spielfelder klicken/tappen!“ und „Spieler X ist am Zug“ gehört ja auch inhaltlich zusammen.
Meiner Meinung nach gehört das aber weniger eng zusammen, als der Spielfeld-Zustand und die Anweisung "Spieler X ist am Zug". Da <caption> über einer Tabelle angezeigt wird (wie vermittelt man Anfängern sonst, wozu das Ding gut sein soll?), finde ich es durchaus passend verwendet.
Das sogenannte vernünftige Markup hat leider mit der Spielmechanik und der dazu notwendigen Benutzerführung nicht das geringste gemeinsam. Das hatte ich schon besprochen. Wir benötigen exakt einen Button, um ein Spiel auszuwählen. Die Spieleridentität muss(!) das Spiel selbst entscheiden.
Nein, das muss es in der Grundfunktionalität eben nicht. Das hatte ich schon besprochen. Hast du wohl ignoriert.
Ich zitiere aus dem verlinkten Thread:
Nein. Das ist nicht die Grundfunktionalität. Diese besteht in der Auswahl eines der noch freien Felder. Der Benutzer wählt keinesfalls zwischen Kreuz und Kreis! Das würde sich mit der Spielmechanik stören, da dann eine Mehrfacheingabe denkbar wäre, welche gegen die Spielregel verstößt, dass die Spieler im Wechsel jeweils ein Feld für sich in Anspruch nehmen.
Grundfunktionalität ist für mich, was sich mit einfachsten Mitteln umsetzen lässt. Und das ist eben ein Tic-Tac-Toe nur mit HTML – bei dem die Spieler freilich selbst aufpassen müssen, wer am Zug ist und dass derjenige seine eigene Marke in ein Feld setzt. 🐕
Warum sollten die Spieler "freilich selbst aufpassen müssen, wer am Zug ist und dass derjenige seine eigene Marke in ein Feld setzt"? Das ist in meinen Augen Rechthaberei und keinesfalls die Grundfunktionalität des Spiels. Also habe ich Deinen Einwand nicht ignoriert, sondern schlicht inhaltlich nicht anerkannt, da ich anderer Überzeugung bin.
Einfach
<button type="reset">ist nicht überzeugender als unzählige Zeilen JavaScript? …
Dieser Button ändert weder die Spielinterne Variable finished, noch entfernt er die Klasse game-over. Rechthaberei! Und was ist mit Screenreadern und Braille-Zeilen? Was stellen die dar, wenn ich mit meinem Ansatz den Zelleninhalt von <button>oben mittig wählen</button> zu o ersetzt habe? Ist das nicht viel eindringlicher, als vorhandene Markup-Wälder durch ein obskures aria-Label zu "überdecken"?
Aber die Sache mit dem Neustart ist inzwischen im Tutorial enthalten.
… zu denen es so viel zu sagen gibt, dass dies ein Neustart eines Postings erfordert.
Mal sehen. Mir wird das langsam zu ermüdend, sodass ich schon öfter darüber nachgedacht habe, diesen ganzen Thread auszublenden.
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
die alte Ausrede...
Das ist die Felixsche Kommunikation, an der wir uns ein Beispiel nehmen sollen? Wenn man die Argumente des Gegenübers nicht akzeptieren will und keine eigenen entgegenzusetzen hat, einfach die „Ausrede“-Keule schwingen. In der Beziehung könnte ich wirklich was von dir lernen. Will ich aber nicht.
Die bringt das SELFHTML-Wiki aber nicht weiter - und das ist die Grundfunktion von SELFHTML, nicht das Forum. Letzteres ist seit den Anfangstagen nur eine Ergänzung.
Für mich ist es andersrum. YMMV.
Achso. Das alte pädagogische Mittel, um den Einstieg in eine komplexe Materie zu erleichtern. Das gehört zum Lehren dazu. Später, nachdem der Einstieg geschafft ist, kommt dann die nächste verkraftbare Menge an Input/Wahrheit/Fachwissen ... Das halte ich für richtig.
Ich auch.
Und welchen Wert hat dann Dein aria-Label-Vorschlag?
Hab ich das nicht zur Genüge erklärt? Um zu zeigen, dass deine Formulierung „Um die Doppelung mit gleichlautender Klasse zum Tabelleninhalt kommt man daher nicht herum“ falsch ist.
Man kann (sollte!) Dinge vereinfacht darstellen (Lügen-für-Kinder). Aber nicht falsch darstellen (Lügen).
Da <caption> über einer Tabelle angezeigt wird (wie vermittelt man Anfängern sonst, wozu das Ding gut sein soll?), finde ich es durchaus passend verwendet.
caption ist die Tabellenüberschrift, eine Zusammenfassung/Erklärung des Tabelleninhalts. „Spieler X ist am Zug“ leistet das nicht.
Grundfunktionalität ist für mich, was sich mit einfachsten Mitteln umsetzen lässt. Und das ist eben ein Tic-Tac-Toe nur mit HTML – bei dem die Spieler freilich selbst aufpassen müssen, wer am Zug ist und dass derjenige seine eigene Marke in ein Feld setzt. 🐕
Warum sollten die Spieler "freilich selbst aufpassen müssen, wer am Zug ist und dass derjenige seine eigene Marke in ein Feld setzt"?
Weil sie das beim Spielen auf Papier auch tun müssen. Weil sie auch ohne dass ihnen der Computer sagt, wer am Zug ist, Tic-Tac-Toe spielen können. Und wenn’s auch ohne geht, gehört es eben nicht zur Grundfunktionalität.
Das heißt natürlich nicht, dass man die Logik, wer am Zug ist, nicht zu implementieren braucht. Natürlich sollte man das tun – als enhancement.
Wie Jeremy Keith sagt: „When I say ‘this is an enhancement’, don’t think I’m saying ‘this is just an enhancement’.“
Progressive enhancement heißt nicht, sich mit der Grundfunktionalität zufriedenzugeben. Im Gegenteil, es heißt, dort weiterzumachen.
Also habe ich Deinen Einwand nicht ignoriert, sondern schlicht inhaltlich nicht anerkannt, da ich anderer Überzeugung bin.
Du hast den Sinn hinter progressive enhancement nicht erkannt. Das ist bedauerlich.
Mir wird das langsam zu ermüdend, sodass ich schon öfter darüber nachgedacht habe, diesen ganzen Thread auszublenden.
Dieser ganze Thread zeigt, wie schwierig es ist, ein gutes Tutorial zu schreiben. Deins ist noch ein Stück weit davon entfernt.
LLAP 🖖
sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
Hallo Gunnar Bittersmann,
Dieser ganze Thread zeigt, wie schwierig es ist, ein gutes Tutorial zu schreiben.
Unbestritten.
Deins ist noch ein Stück weit davon entfernt.
Dies denke ich nicht.
Bis demnächst
Matthias
Aloha ;)
Sehr guter Einwand! Das habe ich umgesetzt. Warum wolltest Du das nicht gleich tun?
Weil ich nach wie vor der Meinung bin, dass diese Art von Artikeln in der Autorenschaft einer Person bleiben sollten, Änderungen also vom Autor eingepflegt werden sollten.
An der Stelle muss ich mich auch mal auf Gunnars Seite schlagen, obwohl ich sonst ja eher die Aufrufe von @Felix Riesterer, im Wiki aktiver zu sein, unterstütze.
Ich zitiere mich da einfach mal selbst:
Artikel, die unter Programmiertechnik oder Anwendung und Praxis fallen, sind anders als Artikel, die unter HTML, CSS und JavaScript liegen. Erstere haben einen roten Faden und sind im Tutorial-Stil gehalten; wollen innerhalb eines Artikels didaktische eine Botschaft übermitteln. Zweitere sind mehr im Enzyklopädie-Stil gehalten und zeigen auf, wie man einzelne Elemente benutzt, ohne einen langen roten Faden aufrechtzuerhalten. Im ersteren Fall ist es unter Umständen gut und wichtig, einen Hauptautor als Hauptansprechpartner zu haben, der den roten Faden zusammenhält.
Im Sinne des roten Fadens ist Gunnars Aussage also schon mehr als eine Ausrede, sondern eine (auch meiner Meinung nach, siehe mein obiges Statement von 2015) schlüssige Begründung für seine Zurückhaltung beim aktiven Editieren. Bei Tutorials und anderen Artikeln mit rotem Faden ist das Wiki-Prinzip einfach nicht im Vollumfang anwendbar; dafür wurde es ja auch nicht direkt ersonnen. Vielleicht sollten wir mehr darauf achten, dass das Hochhalten von Ressentiments in der aktuellen Diskussion nicht ständiger Dreh- und Angelpunkt ist :)
Ich jedenfalls sehe, dass der Artikel von Felix, den ich schon zu anfangs gut fand, durch die (wie gewohnt nicht immer einfach zu schluckenden) Kritikpunkte von Gunnar (die Felix eingearbeitet hat) inzwischen noch einmal deutlich an Qualität dazugewonnen hat. Insofern einfach mal ein Lob und ein großes Danke an euch Beide.
Grüße,
RIDER
@@Felix Riesterer
Es ist nicht geholfen, wenn ein Screenreader „Button wählen Button wählen Button wählen Button wählen Button wählen Button wählen Button wählen Button wählen Button wählen“ vorliest. Die Buttons brauchen eine jeweils eigene Beschriftung:
Sehr guter Einwand! Das habe ich umgesetzt. Warum wolltest Du das nicht gleich tun?
Andere Frage: Warum wolltest du das nicht gleich tun?
In meinem Posting hatten die Buttons bereits eine aussagekräftige Beschriftung. Warum hattest du die erst weggelassen?
LLAP 🖖
sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
@@Felix Riesterer
ich habe mir diese Antwort nocheinmal durchgesehen, um zu prüfen, was eine zugängliche Bedienung alles erfordert. Nun bin ich mir nicht mehr so sicher, ob Deine Vorschläge unbedingt die besten sind.
Du begehst erneut denselben Fehler, den du schon beim Vergleich der Komplexität unserer JavaScript-Codes begangen hattest: Du schiebst „alles“ der Zugänglichkeit zu. In Wirklichkeit ist vieles davon aber für progressive enhancement und hat nichts mit Barrierefreiheit (im engeren Sinn, s.u.) zu tun.
Der Inhalt könnte in einem Button bestehen, der als Eingabewerkzeug dafür dient, dass der Spieler, der gerade an der Reihe ist, dieses Feld belegen möchte.
Also: Ein Button in jedes Tabellenfeld. Nur einer.
„Das Mindest-Markup“, das sagte ich doch.
Dazu fragen wir uns, was denn die Gundfunktionalität ist: Ganz einfach die Auswahl von Kreuz oder Kreis in jedem Feld.
Nein. Das ist nicht die Grundfunktionalität. Diese besteht in der Auswahl eines der noch freien Felder. Der Benutzer wählt keinesfalls zwischen Kreuz und Kreis! Das würde sich mit der Spielmechanik stören, da dann eine Mehrfacheingabe denkbar wäre, welche gegen die Spielregel verstößt, dass die Spieler im Wechsel jeweils ein Feld für sich in Anspruch nehmen.
Grundfunktionalität ist für mich, was sich mit einfachsten Mitteln umsetzen lässt. Und das ist eben ein Tic-Tac-Toe nur mit HTML – bei dem die Spieler freilich selbst aufpassen müssen, wer am Zug ist und dass derjenige seine eigene Marke in ein Feld setzt. 🐕
Das müssen die Spieler beim Spielen auf Papier doch auch. Es besteht kein Zwang, dass die Grundfunktionalität beim Spiel auf dem Computer mehr bieten müsste.
Eine solche Auswahl müsste man aufwendig wieder kompensieren, damit der aktuelle Spieler nur "sein" Symbol benutzen kann.
Das wäre bei mir dann progressive enhancement – eine Erweiterung der Grundfunktionalität.
Dieselbe Logik muss bei einer nur mit JavaScript spielbaren Implementation ja auch vorhanden sein – nur fehlt dann o.g. Grundfunktionalität.
Aber das passende UI-Element zur Auswahl ist ein Drop-Down-Menü. Das Innere der Tabellenzellen wäre
Finde ich nicht.
Ja ja, schon gut. Zwei Radiobuttons sind besser. ;-)
Hier (erst!!) kommt nun JavaScript ins Spiel.
Finde ich nicht. JavaScript sollte das Spielfeld bereits erstellen. JavaScript kann einen Button ins Dokument pflanzen, der das Erstellen des Spielfeldes verursacht. Ohne JavaScript sollte ja auch keine Tabelle zu sehen sein.
Aber warum denn nicht? Die Grundfunktionalität funktioniert (bei entsprechenden UI-Elementen) doch auch ohne JavaScript.
Findest Du nicht, dass mein Vorschlag mit nur einem Button hier ebenso zugänglich
Ja, wenn du „zugänglich“ im engeren Sinn meinst, also zugänglich auch bspw. für Blinde. Siehe oben.
Nein für „zugänglich“ im erweiterten Sinn. Im erweiterten Sinn zugänglich heißt zugänglich für alle ohne spezielle Anforderungen, also zugänglich bspw. auch ohne JavaScript.
aber technisch simpler
Vielleicht etwas. Aber auch nicht wesentlich.
und von daher sinnvoller ist?
Das hängt davon ab, was man als sinnvoll erachtet. Wenn man es sinnvoll findet, Anfängern ohne Blick zur Seite JavaScript einzuflößen, mag ein Nur-JavaScript-Tic-Tac-Toe dafür passend sein.
Wenn man es sinnvoll findet, Anfängern auch auf den Weg zu geben, wozu man JavaScript verwenden kann und wofür man es nicht verwenden sollte und was alles auch ohne JavaScript geht, dann halte ich das progressively enhanced Tic-Tac-Toe für angebrachter.
Ich finde nicht, dass eine JavaScript-freie Lösung in ein JavaScript-Tutorial sollte.
Ich finde, doch! Weil ich die Erfahrung gemacht habe, dass Leute auf alles mit JavaScript drauflos ballern, weil sie außer JavaScript nichts anderes gelernt haben. Traurige Wirklichkeit.
(An der Stelle sei mir noch ein Verweis auf diesen Tweet von Heydon gestattet. Ich weiß, du stehst darauf. ;-))
Wie ich sagte: Barrierefreiheit muss im Artikel mit vermittelt werden, progressive enhancement sollte im Artikel mit vermittelt werden.
„Die Entscheidung, ob progressive enhancement in den Artikel gehört, ist eine technische. Die Entscheidung, ob Barrierefreiheit in den Artikel gehört, ist eine menschliche.“
LLAP 🖖
sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
@@Felix Riesterer
isser nun im Wiki und möchte kritisiert und verbessert werden:
Mal was ganz anderes: Nach meinem Verständnis dient das Meta-Forum für Dinge über den SELFHTML-Raum, bspw. über die CForum-Software. Wäre die Diskussion zum Inhalt eines Artikels nicht besser im SELF-Forum aufgehoben gewesen?
LLAP 🖖
Lieber Gunnar,
Mal was ganz anderes: Nach meinem Verständnis dient das Meta-Forum für Dinge über den SELFHTML-Raum, bspw. über die CForum-Software. Wäre die Diskussion zum Inhalt eines Artikels nicht besser im SELF-Forum aufgehoben gewesen?
das Wiki und seine Inhalte sind integraler Bestandteil dessen, was SELFHTML (lies: "Die Doku SELFHTML") ausmacht. Warum sollte das Meta-Forum dafür weniger gut passen, als die allgemeine Plauderplattform (lies: SELFHTML-Forum) rund um das Web-Thema im allgemeinen und gelegentlich im spezielleren?
Liebe Grüße,
Felix Riesterer.
Aloha ;)
isser nun im Wiki und möchte kritisiert und verbessert werden:
Mal was ganz anderes: Nach meinem Verständnis dient das Meta-Forum für Dinge über den SELFHTML-Raum, bspw. über die CForum-Software. Wäre die Diskussion zum Inhalt eines Artikels nicht besser im SELF-Forum aufgehoben gewesen?
Mein Verständnis des Meta-Forums ist der, dass darin alle Dinge landen, die sich direkt auf den Selfraum beziehen (also unabhängig ob Wiki, Forum, Forensoftware oder auch inhaltlich), während das SELF-Forum dem eigentlichen Zweck dieses Forums als Anlaufstelle für Fragensteller mit Fragenstellungen allgemeinerer Art dient.
Das ist, wenn man die Thread-Historie im Meta-Forum anschaut, auch die bisherige Handhabung.
Das einzige, wo man argumentieren könnte, dass es aus der Reihe tanzt, sind die Fragen, die aus dem Wiki kommen und im Self-Forum landen (obwohl sie sich ja auch auf einen Inhalt des Self-Raums beziehen), das ist aber dadurch begründbar, dass es sich zumeist dabei nicht um Diskussionen über den Wiki-Inhalt, sondern vielmehr um individuelle Verständnisfragen dreht.
Vielleicht kann man das, in Bezug auf das Wiki, so sagen: Alles, was gewöhnlich in einer Wiki-Diskussion (also dem Mediawiki-eingebauten Diskussionsforum) landen würde, gehört nach Meta (die Diskussionsseiten verlinken mit ihrem Disclaimer auch dahin). Alles, was sich direkt um ein persönliches Verständnisproblem eines Lesers handelt, gehört ins Selfforum.
Nicht zuletzt kann eine inhaltlich-fokussierte Diskussion auch eine Meta-Diskussion sein; gerade in diesem Fall ging es ja darum, wie der Artikel gestaltet ist, also definitiv "meta", und nicht um eine (Verständnis-)Frage zum Artikelinhalt. Aber klar, die Abgrenzung ist immer mehr nur dem Sinn nach und nie ganz hart möglich; gerade bei Threaddrift verschwimmen gelegentlich die Grenzen. Trotzdem ist sie sinnvoll.
Grüße,
RIDER
@@Felix Riesterer
isser nun im Wiki und möchte kritisiert und verbessert werden:
Eins hatte ich in meinen Betrachtungen bislang ausgespart: die Logik. Aber auch hier stellt sich eine Frage nach den grundsätzlichen Lernzielen. Es sollten doch sicher von Anfang an Daten und Darstellung getrennt sein; dem Anfänger das EVA-Prinzip vermittelt werden.
Ist es vor diesem Hintergrund wirklich ratsam, die Logik ans DOM zu koppeln? Also die Erkennung „3 in einer Reihe?“ anhand von Klassen der DOM-Elemente vorzunehmen?
Wäre es nicht sinnvoller, die Daten über den Spielverlauf in einer 3×3-Matrix zu halten? Intitial mit Nullen gefüllt, wenn ❌ ein Spielfeld belegt, wird eine 1 in das entsprechende Feld der Matrix eingetragen, bei ⭕ −1.
Die Erkennung „3 in einer Reihe?“ bestünde dann einfach in der Ermittlung der Zeilensummen, Spaltensummen und Summen der Elemente in den Diagonalen. Wenn eine der Summen den Absolutbetrag 3 hat, ist das Spiel zuende. Bei +3 hat ❌ gewonnen; bei −3 ⭕.
Das sollte einfacher zu implementieren sein als die Abfrage von Klassen. Einfacherer Code und Vermittlung von EVA – Win-Win, oder?
LLAP 🖖
Lieber Gunnar,
Wäre es nicht sinnvoller, die Daten über den Spielverlauf in einer 3×3-Matrix zu halten? Intitial mit Nullen gefüllt, wenn ❌ ein Spielfeld belegt, wird eine 1 in das entsprechende Feld der Matrix eingetragen, bei ⭕ −1.
dann mach doch mal (am besten ein Fiddle-/CodePen-Beispiel) und vergleiche anschließend die Komplexität des Codes. Dann können wir darüber fachsimpeln.
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
Wäre es nicht sinnvoller, die Daten über den Spielverlauf in einer 3×3-Matrix zu halten? Intitial mit Nullen gefüllt, wenn ❌ ein Spielfeld belegt, wird eine 1 in das entsprechende Feld der Matrix eingetragen, bei ⭕ −1.
dann mach doch mal (am besten ein Fiddle-/CodePen-Beispiel)
Hab ich dann mal gemacht.
und vergleiche anschließend die Komplexität des Codes.
Das überlasse ich gern jemand anderem.
Dann können wir darüber fachsimpeln.
Da bin ich dann wieder dabei. ;-)
LLAP 🖖
Lieber Gunnar,
Hab ich dann mal gemacht.
na, dann schauen wir einmal in das Beispiel, um zu sehen, inwiefern es sich als Alternative für ein Anfänger-Tutorial eignet.
und vergleiche anschließend die Komplexität des Codes.
Das überlasse ich gern jemand anderem.
Warum? Traust Du Dir das nicht zu? Oder befürchtest Du, dass Dein Code tatsächlich nicht mehr anfängergerecht ist, jetzt, da Du ihn fertiggestellt hast?
Dann können wir darüber fachsimpeln.
Da bin ich dann wieder dabei. ;-)
Ich fürchte, Deine Erwartungen sind andere, als der Kern dieser Diskussion...
Vergleichen wir einmal die Komplexität des Markups, welches im Artikel verwendet wird, und welches Du dagegen stellst:
<!-- Wiki-Artikel -->
<table class="tic-tac-toe">
<tbody>
<tr>
<td></td>
<td></td>
<td></td>
<tr>
...
</tbody>
</table>
<!-- Dein Ansatz -->
<table id="tic-tac-toe">
<tbody>
<tr>
<td>
<label for="top-left">top left field</label>
<select id="top-left">
<option></option>
<option value="x" aria-label="x">❌</option>
<option value="o" aria-label="o">⭕</option>
</select>
</td>
...
</tr>
...
</tbody>
</table>
Ein Anfänger wird sicherlich meinen Ansatz schneller begreifen, da er wesentlich(!) simpler ist. Eine rein mit CSS gestaltete leere Tabellenzelle ist zwar eine Hürde für sehbehinderte (kann eine Braille-Zeile generated content darstellen?), aber um zu verstehen, wie man mit JavaScript zumindest einmal anfangen kann, ist das Beispiel wesentlich schneller erfassbar. Die ganzen Formular-Elemente muss ein Anfänger bei Dir erst einmal lernen und ihren Sinn und Zweck außerhalb eines Formulars verstanden haben, bevor er im Bereich CSS und JavaScript den Zusammenhang zum Markup herstellen kann.
Dazu kommt noch die Verwendung von id- anstelle von class-Attributen. Mehrere Spiele auf einer Seite (warum auch immer das nützlich oder sinnvoll sein mag) ist damit nicht gegeben. Eine später stärkere Objektorientierung ist dann weniger schön dadurch demonstrierbar, dass man einfach beliebig viele solcher Spiele auf einer Seite instanziiert.
Gehen wir zum CSS-Teil:
#tic-tac-toe
{
border-collapse: collapse;
}
#tic-tac-toe td
{
padding: 1em;
}
.js #tic-tac-toe td
{
width: 30vmin;
height: 30vmin;
padding: 0;
border: 1px solid black;
color: transparent;
}
#tic-tac-toe .piece-x
{
background-image: url('data:image/svg+xml,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20viewBox%3D%220%200%201%201%22%3E%3Cline%20x1%3D%220.1%22%20y1%3D%220.1%22%20x2%3D%220.9%22%20y2%3D%220.9%22%20stroke-width%3D%220.1%22%20stroke%3D%22red%22%2F%3E%3Cline%20x1%3D%220.1%22%20y1%3D%220.9%22%20x2%3D%220.9%22%20y2%3D%220.1%22%20stroke-width%3D%220.1%22%20stroke%3D%22red%22%2F%3E%3C%2Fsvg%3E');
}
#tic-tac-toe .piece-o
{
background-image: url('data:image/svg+xml,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20viewBox%3D%220%200%201%201%22%3E%3Ccircle%20cx%3D%220.5%22%20cy%3D%220.5%22%20r%3D%220.4%22%20fill%3D%22none%22%20stroke-width%3D%220.1%22%20stroke%3D%22blue%22%2F%3E%3C%2Fsvg%3E');
}
#tic-tac-toe label,
#tic-tac-toe select,
#tic-tac-toe button
{
display: block;
}
#tic-tac-toe button
{
border: none;
width: 100%;
height: 100%;
background: transparent;
color: transparent;
cursor: pointer;
}
#tic-tac-toe button::-moz-focus-inner
{
border: none;
}
#tic-tac-toe button:focus
{
background: silver;
}
Ich habe kein Problem damit, dass Dein CSS Bilddaten als Data-URI benutzt. Wer in Sachen Gestaltung weiter ausholen möchte, darf diesen Teil gerne beliebig ausweiten. Mein Tutorial stellt Anfängern auch eine mehr oder minder knapp erklärte fertige Lösung vor, um "das GUI" schnell und wirksam umzusetzen. Selbst mit dem Selektor .js #tic-tac-toe td habe ich kein Problem, auch wenn er weit über Anfänger-Niveau liegt (was die von mir verwendeten ::before und ::after zweifellos auch sind).
Also nähern wir uns dem Kern, der JavaScript-Logik:
if (document.querySelector)
{
document.documentElement.classList.add('js');
var ticTacToeElement = document.querySelector('#tic-tac-toe');
var rowElements = ticTacToeElement.rows;
for (var i = 0, cellElements; i < rowElements.length; i++)
{
cellElements = rowElements[i].cells;
for (var j = 0, labelElement; j < cellElements.length; j++)
{
labelElement = cellElements[j].querySelector('label');
cellElements[j].innerHTML = '<button data-row="' + i + '" data-column="' + j + '">' + labelElement.innerHTML + '</button>';
}
}
var isPlayerXMoving = true;
var board = [
[0, 0, 0],
[0, 0, 0],
[0, 0, 0]
];
ticTacToeElement.addEventListener('click', ticTacToeClickHandler);
}
function ticTacToeClickHandler(event)
{
var targetElement = event.target;
var parentElement = targetElement.parentElement;
var row, column;
if (targetElement.nodeName == 'BUTTON')
{
row = parseInt(targetElement.dataset.row);
column = parseInt(targetElement.dataset.column);
board[row][column] = isPlayerXMoving ? 1 : -1;
parentElement.innerHTML = isPlayerXMoving ? 'x' : 'o';
parentElement.classList.add(isPlayerXMoving ? 'piece-x' : 'piece-o');
if (gameOver())
{
alert('Game over. ' + (isPlayerXMoving ? '❌' : '⭕') + ' wins.');
}
else
{
isPlayerXMoving = !isPlayerXMoving;
}
}
}
function gameOver()
{
var sum;
for (var i = 0; i < 3; i++)
{
sum = 0;
for (var j = 0; j < 3; j++)
{
sum += board[i][j];
}
if (Math.abs(sum) == 3)
{
return true;
}
}
for (var j = 0; j < 3; j++)
{
sum = 0;
for (var i = 0; i < 3; i++)
{
sum += board[i][j];
}
if (Math.abs(sum) == 3)
{
return true;
}
}
sum = 0;
for (var i = 0; i < 3; i++)
{
sum += board[i][i];
}
if (Math.abs(sum) == 3)
{
return true;
}
sum = 0;
for (var i = 0; i < 3; i++)
{
sum += board[i][2 - i];
}
if (Math.abs(sum) == 3)
{
return true;
}
return false;
}
Wenn man den von mir verwendeten JavaScript-Code um alle Leerzeilen und Kommentarzeilen bereinigt, bleiben 61 Zeilen übrig. Das Ganze verpackt in eine anonyme Funktion, die sofort ausgeführt wird.
Dein Code umfasst abzüglich aller Leerzeilen (Kommentare sind keine vorhanden) 91 Zeilen, also 50% mehr! Damit hast Du schon quantitativ bewiesen, dass Dein Ansatz nicht minimalistisch ist, für ein Anfänger-Tutorial also eher weniger gut geeignet. Außerdem ist er nicht in eine Funktion verpackt, sondern liegt im globalen Scope herum. Sowohl die ausschließlich zu dem Spiel gehörenden Funktionen ticTacToeClickHandler und gameOver, als auch die Variablen ticTacToeElement, rowElements, i, cellElements, isPlayerXMoving und board sind Methoden bzw. Eigenschaften von window. Das sollte man Anfängern gleich von vornherein aber abempfehlen, auch wenn man das dahinter steckende Geheimnisprinzip noch nicht offen als solches thematisiert.
Was die tatsächliche Komplexität angeht, so wird in meinem Beispiel lediglich ein spezieller Attributwert von einer Sorte HTML-Element überprüft, bei Dir dagegen muss die ganze Menge an Eingabe-Elementen (select, option und button) abgeklappert werden, z.T. auch noch die Verschachtelung der Elemente im DOM berücksichtigt werden, um dann Elementeigenschaften wie parentElement, dataset, innerHTML und Methoden wie classList.add zu nutzen, um die Spiellogik zu implementieren. Für einen Anfänger ist das eine happige Menge an Objekteigenschaften und Methoden, bzw. Unterobjektmethoden! Letztlich verstößt Du damit gegen das KISS-Prinzip, weil Du es eben nicht "simple stupid" belässt.
Der Inhalt meiner Eventhandlerfunktion beläuft sich auf sechs Zeilen. Das ist für einen Anfänger sehr übersichtlich und verständlich: Eine Variablendeklaration, eine Verzweigung mit einer AND-verknüpften Bedingung, zwei Wertezuweisungen und einem Funktionsaufruf.
Der Inhalt Deiner Eventhandlerfunktion beläuft sich auf fünfzehn Zeilen, benötigt vier verschiedene Variablen für vier verschiedene Dinge, mit dementsprechend vielen Wertezuweisungen, und hat verschachtelte Verzweigungen. Das ist definitiv wesentlich komplexer!
Die Lösung mit einem alert-Aufruf ist in meinen Augen die schlechtestmögliche Lösung eines Problems, das mein Ansatz definitiv unaufdringlicher gelöst hat. Du kennst mit Sicherheit die Probleme, die ein alert in anderen Browsertabs/-fenstern verursacht. Wozu also Anfängern diese Unsitte beibriungen?
Was Dein Beispiel in meinen Augen wesentlich weniger konsequent trennt, ist der Zusammenhang von Markup und JavaScript-Logik. Du hantierst mit Elementen, deren Vorhandensein in genau der Weise gegeben sein muss. Wenn dem nicht so ist, funktioniert Dein Code nicht mehr wie gewünscht. Du abstrahierst überhaupt nicht, auf welchen Wegen Deine Eingaben ins Spiel gelangen, denn in der Eventhandlerfunktion hangelst Du Dich durch's DOM, um an die passenden (Eltern-)Elemente zu gelangen, damit Du Werte von ihnen abfragen oder an sie zuweisen kannst. Es gibt keine Zwischenschicht, die Eingaben und Darstellung mit der Spielelogik verbindet. Aber hattest Du nicht genau das gefordert und in Deinem Beispiel umzusetzen versucht?
Mein Ansatz verlangt genau neun <td>, ist dabei aber nicht auf ihre 3x3-Anordnung festgelegt und könnte in einer Setup-Funktion das Vorhandensein sicherstellen. Den Rest des GUI macht konsequent CSS - bis hin zur Ausgabe des Spielergebnisses. Besser kann man die Trennung zwischen Applikationslogik und Darstellung bei einem so minimalistischen Beispiel kaum machen! Dass bei der Auswertung wieder die neun <td> als Datenspeicher abgefragt werden, anstatt ein abstrahiertes Modell wie Dein board-Array zu verwenden, ist zwar im Vergleich zu Deinem Ansatz wirklich weniger schön, aber eben der Einfachheit des für Anfänger konzipierten Tutorials geopfert.
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
und vergleiche anschließend die Komplexität des Codes.
Das überlasse ich gern jemand anderem.
Warum? Traust Du Dir das nicht zu?
Doch, schon. Ich hätte es eigentlich auch dir zugetraut.
Stattdessen vergleichst du hier Äpfel mit Birnen. Und lines of code allein sind auch kein geeignetes Mittel, Komplexität von Code zu vergleichen.
Das war jetzt mal nichts. Zu mehr als dieser Rückmeldung fehlt mir gerade die Zeit.
LLAP 🖖
Stattdessen vergleichst du hier Äpfel mit Birnen.
Vielleich fehlt Dir einfach jegliches Verständnis für das Spannungsfeld "Best practice" vs Didaktik.
@@Mitleser
Stattdessen vergleichst du hier Äpfel mit Birnen.
Vielleich fehlt Dir einfach jegliches Verständnis für das Spannungsfeld "Best practice" vs Didaktik.
Möglich. Aber was hätte das damit zu tun, dass Felix Äpfel mit Birnen vergleicht?
Hier ging es darum, ob die Trennung zwischen GUI und Geschäftslogik den Code komplizierter macht. Felix bezieht in den Vergleich die Umwandlung des DOMs von selects zu buttons aus meinem Code mit ein, was damit nichts zu tun hat.
LLAP 🖖
Hallo Mitleser,
Vielleich fehlt Dir einfach jegliches Verständnis für das Spannungsfeld "Best practice" vs Didaktik.
Das Verständnis ist sicherlich vorhanden, ich würde es mangelndes Einfühlungsvermögen nennen.
Bis demnächst
Matthias
@@Matthias Apsel
Vielleich fehlt Dir einfach jegliches Verständnis für das Spannungsfeld "Best practice" vs Didaktik.
Das Verständnis ist sicherlich vorhanden, ich würde es mangelndes Einfühlungsvermögen nennen.
Den Ball gebe ich gern zurück. Ich fühle mit dem Nutzer, nicht mit dem Entwickler.
“You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user, and secondly, they’re mostly make-believe, especially in the long run.”
—Stefan Tilkov in Why I hate your Single Page App
LLAP 🖖
Aloha ;)
Vielleich fehlt Dir einfach jegliches Verständnis für das Spannungsfeld "Best practice" vs Didaktik.
Das Verständnis ist sicherlich vorhanden, ich würde es mangelndes Einfühlungsvermögen nennen.
Den Ball gebe ich gern zurück. Ich fühle mit dem Nutzer, nicht mit dem Entwickler.
Der Ball fliegt an dieser Stelle dann aber auch postwendend zurück. In einem Tutorial, gerade für Anfänger, geht es nämlich vor allem um den Entwickler und noch nicht so sehr um den Nutzer. Unser Wiki muss zuerstmal die Bedürfnisse der (zukünftigen) Entwickler, die sich dort einfinden, berücksichtigen, bevor es bei genau diesen das Verständnis für die Bedürfnisse der Nutzer wecken kann. Dein Argument geht am Thema vorbei.
“You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user, and secondly, they’re mostly make-believe, especially in the long run.”
—Stefan Tilkov in Why I hate your Single Page App
Mach dir doch mal Gedanken darüber, warum wir alle dir der Sache nach inhaltlich zustimmen, sofern es um ein Projekt geht, das später so wie es ist "an den Nutzer" kommt, aber nicht, wenn es um einen Wiki-Artikel zum Lernen der Programmier-Grundlagen geht.
Wir sind ja alle deiner Meinung, was die Wichtigkeit der Konzepte angeht, die du hochhältst. Wir sind nur auch alle der Meinung, dass sie zu einem anderen Zeitpunkt vermittelt werden sollten als der, den du vorschlägst. Das liegt sicher nicht daran, dass wir gegenüber den Konzepten ignorant sind, sondern mehr daran, dass wir ein anderes Verständnis davon haben, wann und wie ein Tutorial didaktisch sinnvoll gestaltet ist.
Wenn wir da was das didaktische Konzept angeht inhaltlich nicht zusammen kommen - okay. Es bringt dann aber auch nichts, weiter die Windmühlen zu jagen, wenn schon alle Beteiligten auf die ein oder andere Art und Weise gesagt haben, dass sie anderer Meinung sind. Gerade in einem Wiki zählt eben letztlich auch die konsensfähige Mehrheitsmeinung, selbst wenn es für andere Ansichten auch gute Argumente gibt.
Ein konstruktiver Umgang damit wäre sicherlich, nicht weiter auf einer Veränderung des vorliegenden Artikels zu beharren, sondern stattdessen die schon öfters vorgeschlagene Alternative, nämlich das Schreiben eines weiteren Artikels mit anderem Fokus, zu wählen. Ich halte das für einen guten Kompromiss. Es ist auch sicher nicht verkehrt, in einem anderen Artikel mit anderem Fokus dann darauf einzugehen, warum dieser eingeschlagene Weg der letztendlich sinnvollere ist.
Grüße,
RIDER
@@Camping_RIDER
Den Ball gebe ich gern zurück. Ich fühle mit dem Nutzer, nicht mit dem Entwickler.
In einem Tutorial, gerade für Anfänger, geht es nämlich vor allem um den Entwickler und noch nicht so sehr um den Nutzer.
Ach, wann fängt es denn an, um den Nutzer zu gehen?
Unser Wiki muss zuerstmal die Bedürfnisse der (zukünftigen) Entwickler,
Schön, dass du es selbst sagst: Aus Anfängern werden zukünftig Entwickler. Die lernen an einigen Stellen dazu, an anderen nicht. Sie machen vieles so weiter, wie sie es als Anfänger gelernt haben – nicht noch mal reflektierend, ob das so richtig oder falsch ist. Wenn es ihnen als Anfänger so begebracht wurde – von Leuten, denen sie vertrauen, ihnen Richtiges beizubringen –, dann wird’s wohl richtig sein‽
Deshalb muss man Anfängern gleich von Anfang an Richtiges beibringen. Was Hänschen nicht lernt, lernt Hans nimmer mehr.
Dein Argument geht am Thema vorbei.
Ganz. Und. Gar. Nicht.
Mach dir doch mal Gedanken darüber, warum wir alle dir der Sache nach inhaltlich zustimmen, sofern es um ein Projekt geht, das später so wie es ist "an den Nutzer" kommt, aber nicht, wenn es um einen Wiki-Artikel zum Lernen der Programmier-Grundlagen geht.
Weil ihr der trügerischen Hoffnung verfallen seid, Entwickler würden später so ganz von selbst ihnen erstmal falsch Beigebrachtes korrigieren. Ein Blick in die Praxis[1] zeigt: Dem ist nicht so! Es mag vereinzelt Entwickler geben, die kopfschüttelnd sagen: Oh Mann, was habe ich damals für einen Scheiß gelernt? Aber das Gros wird das nicht tun, sondern den einmal gelernten Scheiß bis in alle Ewigkeit so weitermachen.
Deshalb muss man Anfängern gleich von Anfang an Richtiges beibringen. Oh, ich wiederhole mich. Steter Tropfen …
Wir sind ja alle deiner Meinung, was die Wichtigkeit der Konzepte angeht, die du hochhältst. Wir sind nur auch alle der Meinung, dass sie zu einem anderen Zeitpunkt vermittelt werden sollten als der, den du vorschlägst.
Man muss Anfängern gleich von Anfang an Richtiges beibringen.
Es bringt dann aber auch nichts, weiter die Windmühlen zu jagen, wenn schon alle Beteiligten auf die ein oder andere Art und Weise gesagt haben, dass sie anderer Meinung sind.
Wer alle? Alle in dieser Filterblase‽
Ich bin auch außerhalb dieser Blase unterwegs. Und da höre ich Stimmen wie @faulancr‘s:
„PE [progressive enhancement] und BF [Barrierefreiheit] gehören in _jeden_ Artikel für Anfänger. Sollten sie nicht Teil der Basis sein?“
Ja, das sollten sie! Man muss Anfängern gleich von Anfang an Richtiges beibringen.
Gerade in einem Wiki zählt eben letztlich auch die konsensfähige Mehrheitsmeinung, selbst wenn es für andere Ansichten auch gute Argumente gibt.
Die Filterblase wird zum Problem.
Ein konstruktiver Umgang damit wäre sicherlich, nicht weiter auf einer Veränderung des vorliegenden Artikels zu beharren, sondern stattdessen die schon öfters vorgeschlagene Alternative, nämlich das Schreiben eines weiteren Artikels mit anderem Fokus, zu wählen. Ich halte das für einen guten Kompromiss.
Ich nicht. Es ist unsinnig, einen Artikel über Grundlegendes für ein Wiki zu schreiben, in welchem andere Artikel ebendiese Grundlagen sträflich missachten.
Es ist auch sicher nicht verkehrt, in einem anderen Artikel mit anderem Fokus dann darauf einzugehen, warum dieser eingeschlagene Weg der letztendlich sinnvollere ist.
Und wie kriegst du die Leser des ersten Artikels dazu, zwingend auch den anderen zu lesen? Nicht. Deshalb muss man Anfängern gleich von Anfang an Richtiges beibringen.
LLAP 🖖
Im Gegensatz zu einigen anderen hier arbeite ich seit etlichen Jahren als Webentwickler und habe Erfahrung in dem, was ich sage. ↩︎
Lieber Gunnar,
Im Gegensatz zu einigen anderen hier arbeite ich seit etlichen Jahren als Webentwickler und habe Erfahrung in dem, was ich sage.
eben. Du bist Entwickler und keine Lehrkraft geworden. Warum nur bestehst Du dann so hartnäckig darauf zu wissen, wo didaktische Reduktion in welchem Ausmaß für einen Anfänger richtig ist? Im Gegensatz zu Dir arbeite ich seit etlichen Jahren als Lehrkraft und habe Erfahrung in dem, was ich sage.
Und wie kriegst du die Leser des ersten Artikels dazu, zwingend auch den anderen zu lesen? Nicht. Deshalb muss man Anfängern gleich von Anfang an Richtiges beibringen.
Das ist ein pädagogisches Problem. Da Du aber Entwickler und keine Lehrkraft geworden bist... ach was soll's. Ich hoffe nur, dass das Essen im Elfenbeinturm genau so gut ist, wie der Grad an Uneinsichtigkeit für pädagogische und didaktische Fallstricke.
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
Und wie kriegst du die Leser des ersten Artikels dazu, zwingend auch den anderen zu lesen? Nicht. Deshalb muss man Anfängern gleich von Anfang an Richtiges beibringen.
Das ist ein pädagogisches Problem.
Nein, nicht nur. Es ist auch ein Problem des Mediums. Du kannst den Unterschied zwischen Web und Schule negieren, machst damit aber einen fürs Web bestimmten Artikel nicht besser.
wie der Grad an Uneinsichtigkeit für pädagogische und didaktische Fallstricke.
Von was für Fallstricken genau redest du? Dass die Beachtung von Barrierefreiheit einen Artikel für Anfänger zu kompliziert machen würde, habe ich bereits widerlegt.
LLAP 🖖
Aloha ;)
Es ist auch ein Problem des Mediums. Du kannst den Unterschied zwischen Web und Schule negieren, machst damit aber einen fürs Web bestimmten Artikel nicht besser.
Der Unterschied ist nicht so groß wie du denkst. Gerade Anfänger werden sich nicht mehrere verschiedene Quellen suchen (oder antun), um eine Technologie zu lernen, und im Normalfall eher das, was innerhalb eines spezifischen Webangebots verfügbar ist, versuchen, so vollständig wie möglich zu erfassen. Ein Springen von Quelle zu Quelle gibt es bei denen, die schon Ahnung haben - die sind aber im vorliegenden Artikel ganz offensichtlich nicht angesprochen. Dagegen ist es gerade für lernwillige Anfänger alles andere als unwahrscheinlich, dass sie nach Lesen und Verstehen eines solchen wie dem hier vorliegenden Artikel einen verlinkten, weiterführenden Artikel lesen, der dasselbe Problem auf andere, für Produktivumgebungen besser geeignete Weise anpackt.
Warum also nicht die Chance nutzen, einen weiteren Artikel zu schreiben, mit dem dann auch die Quellen-springende Zielgruppe der Fortgeschrittenen sehr viel anfangen kann, und von dem auch die Anfänger profitieren, die, quellentreu wie sie gewöhnlich sind, dann direkte Vergleiche zu dem ziehen können, was sie davor gelernt haben.
Du sagst, Barrierefreiheit ist nicht aufwändig. Dann mach das zum Thema deines Artikels und zeig im direkten Vergleich zum UX-unerfreulicheren Artikel für blutige Anfänger, dass das tatsächlich der Fall ist und dass man sich solche wie die von dir vermittelten Grundsätze ganz einfach zu Eigen machen kann.
Grüße,
RIDER
@@Camping_RIDER
Der Unterschied ist nicht so groß wie du denkst. Gerade Anfänger werden sich nicht mehrere verschiedene Quellen suchen (oder antun), um eine Technologie zu lernen, und im Normalfall eher das, was innerhalb eines spezifischen Webangebots verfügbar ist, versuchen, so vollständig wie möglich zu erfassen.
Wenn du „Artikels“ statt „Webangebots“ gesagt hättest – genau meine Rede.
Dagegen ist es gerade für lernwillige Anfänger alles andere als unwahrscheinlich, dass sie nach Lesen und Verstehen eines solchen wie dem hier vorliegenden Artikel einen verlinkten, weiterführenden Artikel lesen, der dasselbe Problem auf andere, für Produktivumgebungen besser geeignete Weise anpackt.
Ich halte das nicht für so wahrscheinlich. YMMV. Angenommen, es wäre so wie du sagst, dann rechtfertigt das aber nicht, warum es überhaupt einen Artikel geben sollte, der das Problem auf ungeeignete Weise anpackt.
Du sagst, Barrierefreiheit ist nicht aufwändig. Dann mach das zum Thema deines Artikels und zeig im direkten Vergleich zum UX-unerfreulicheren Artikel für blutige Anfänger, dass das tatsächlich der Fall ist und dass man sich solche wie die von dir vermittelten Grundsätze ganz einfach zu Eigen machen kann.
Der Punkt ist immer noch: Es sollte gar keinen UX-unerfreulicheren Artikel geben! Auch und gerade nicht für Anfänger.
LLAP 🖖
Hallo Gunnar Bittersmann,
Ich halte das nicht für so wahrscheinlich. YMMV. Angenommen, es wäre so wie du sagst, dann rechtfertigt das aber nicht, warum es überhaupt einen Artikel geben sollte, der das Problem auf ungeeignete Weise anpackt.
Ich sehe nicht, dass dieses Tutorial ungeeignet wäre.
Der Punkt ist immer noch: Es sollte gar keinen UX-unerfreulicheren Artikel geben! Auch und gerade nicht für Anfänger.
Die Argumentation „Es reicht nicht, nur auf Mängel hinzuweisen, man sollte sie auch beseitigen“ ist nachvollziehbar und richtig. Nun fehlt dein Beitrag im Wiki.
Bis demnächst
Matthias
@@Felix Riesterer
Die Filterblase wird zum Problem.
Ich hoffe nur, dass das Essen im Elfenbeinturm genau so gut ist
Hast du schon mal drüber nachgedacht, dass das, was du „Elfenbeinturm“ nennst, vielleicht die große weite Welt sein könnte? Ich höre Stimmen, die mich in die Welt hinausrufen. Sollte ich sie erhören?
LLAP 🖖
Hallo,
Sollte ich sie erhören?
Na, vorallem das mit dem „Artikel schreiben, statt sie zu kritisieren“ wollen dir ja auch hier einige nahelegen.
Gruß
Kalk
@@Camping_RIDER
Ich halte das für einen guten Kompromiss.
Ich schlage einen anderen Kompromiss vor: Wir (Ich? Noch wer da?) Webentwickler geben die Lernziele (Inhalte) vor, ihr Pädagogen überlegt, wie ihr diese didaktisch am besten aufarbeitet – aber ohne Abstriche daran vorzunehmen. Is it a deal?
LLAP 🖖
Aloha ;)
Ich schlage einen anderen Kompromiss vor: Wir (Ich? Noch wer da?) Webentwickler geben die Lernziele (Inhalte) vor, ihr Pädagogen überlegt, wie ihr diese didaktisch am besten aufarbeitet – aber ohne Abstriche daran vorzunehmen.
Dieser Aussage wohnt schon grundsätzlich ein wesentliches Missverständnis inne. Auf mehreren Ebenen, vor allem aber in deiner Auffassung dessen, was Didaktik bedeutet.
Abgesehen davon: Wie wunderbar das funktioniert, wenn fachliche Koryphäen ohne Verständnis von Didaktik versuchen, weniger Wissenden Inhalte zu vermitteln, sehe ich tagtäglich an der Universität[1]. Ich habe davon schon einen bleibenden Eindruck und bin nicht erpicht darauf, solche Attitüden auch hier umgesetzt zu sehen.
Grüße,
RIDER
Womit ich keinen Kahlschlag über alle Dozenten machen will. Es gibt einige, die sich Didaktik und didaktische Grundsätze tatsächlich zu Herzen nehmen - mit entsprechendem Erfolg. Die meisten allerdings nicht. ↩︎
Hallo,
Ich schlage einen anderen Kompromiss vor: Wir (Ich? Noch wer da?) Webentwickler geben die Lernziele (Inhalte) vor, ihr Pädagogen überlegt, wie ihr diese didaktisch am besten aufarbeitet – aber ohne Abstriche daran vorzunehmen.
Dieser Aussage wohnt schon grundsätzlich ein wesentliches Missverständnis inne. Auf mehreren Ebenen, vor allem aber in deiner Auffassung dessen, was Didaktik bedeutet.
das mag in Details so sein, im Kern sehe ich es aber ähnlich wie Gunnar:
Über das WAS, also die praxisrelevanten und wichtigen Lehrinhalte, sollten IMO Fachleute des jeweilgen Genres entscheiden. Also Linguisten, Naturwissenschaftler, Techniker, Musiker ...
Das WIE, also die Umsetzung in einer Weise, dass Laien (Schüler) dieses Wissen auch aufnehmen und begreifen können (und wollen), ist Sache der Pädagogen.
Natürlich gibt es dann grundsätzlichen Bedarf an Dialog und Abstimmung zwischen den beiden, und das bringt es mit sich, dass die Grenzen etwas unscharf werden. Aber so wäre zumindest meine Idealvorstellung.
Abgesehen davon: Wie wunderbar das funktioniert, wenn fachliche Koryphäen ohne Verständnis von Didaktik versuchen, weniger Wissenden Inhalte zu vermitteln, sehe ich tagtäglich an der Universität[^1].
So weit muss man nicht gehen. Ich habe in meiner Schulzeit, vor allem am Gymnasium, schon einige Lehrer erlebt, bei denen ich kompromisslos anerkennen musste, dass sie ihr Fachgebiet bewundernswert beherrscht haben. Als Lehrer waren sie dennoch völlig ungeeignet.
So long,
Martin
Hallo Gunnar Bittersmann,
Ich schlage einen anderen Kompromiss vor: Wir (Ich? Noch wer da?) Webentwickler geben die Lernziele (Inhalte) vor, ihr Pädagogen überlegt, wie ihr diese didaktisch am besten aufarbeitet – aber ohne Abstriche daran vorzunehmen.
Das ist doch schon geschehen. Erst Felix, im Anschluss deine Ergänzungen/Änderungen.
Bis demnächst
Matthias
@@Felix Riesterer
Wäre es nicht sinnvoller, die Daten über den Spielverlauf in einer 3×3-Matrix zu halten? Intitial mit Nullen gefüllt, wenn ❌ ein Spielfeld belegt, wird eine 1 in das entsprechende Feld der Matrix eingetragen, bei ⭕ −1.
dann mach doch mal (am besten ein Fiddle-/CodePen-Beispiel)
Hab ich dann mal gemacht.
na, dann schauen wir einmal in das Beispiel, um zu sehen, inwiefern es sich als Alternative für ein Anfänger-Tutorial eignet.
Das ist Unsinn. Das Beispiel war niemals dafür gedacht, sich in deinem Sinne für ein Anfänger-Tutorial zu eignen.
Es war – wie aus dem Threadverlauf nachvollziebar – dazu bestimmt zu sehen, ob „es nicht sinnvoller [ist], die Daten über den Spielverlauf in einer 3×3-Matrix zu halten“. Nicht mehr und nicht weniger. Da ich schon meine Beispiele auf Codepen hatte, habe ich eins davon als Grundlage genommen und die Spiellogik hinzugefügt. Mein Fehler, ich hätte deinen Code aus dem Artikel verwenden müssen, um auch dir den direkten Vergleich zu ermöglichen.
und vergleiche anschließend die Komplexität des Codes.
Und zwar ausschließlich die Teile mit der Spiellogik.
Aber gut, beschäftigen wir uns erstmal mit was anderem:
Vergleichen wir einmal die Komplexität des Markups, welches im Artikel verwendet wird
Dabei vergleichen wir auch die Sinnhaftigkeit des Markups!
<!-- Wiki-Artikel --> <table class="tic-tac-toe"> <tbody> <tr> <td></td> <td></td> <td></td> <tr> ... </tbody> </table>
Nichts da. Keine Schaltflächen. Du willst dich jetzt nicht daran erfreuen, dass kein Markup auch keine Komplexität hat, oder?
Lass uns mal an der Stelle eins klarstellen: Die Entscheidung, ob progressive enhancement in den Artikel gehört, ist eine technische. Die Entscheidung, ob Barrierefreiheit in den Artikel gehört, ist eine menschliche.
Wenn progressive enhancement rausfällt, sage ich: „Wie dumm! Der Artikel hat eine wertvolle Chance vertan.“ Wenn Barrierefreiheit rausfällt, sage ich: „Nein, das geht gar nicht!“
Das Mindest-Markup für das Tic-Tac-Toe ist
<table class="tic-tac-toe">
<tbody>
<tr>
<td><button>Feld oben links</button></td>
<td><button>Feld oben Mitte</button></td>
<td><button>Feld oben rechts</button></td>
<tr>
...
</tbody>
</table>
Und du willst mir nicht erzählen, dass die Buttons für Anfänger unbegreiflich wären? Vor allem nicht, weil da noch ein Satz der Erklärung hinzukommt, wozu die Buttons da sind: Weil andere Elemente nicht (so ohne Weiteres) per Tastatursteuerung anwählbar sind.
Eine rein mit CSS gestaltete leere Tabellenzelle ist zwar eine Hürde für sehbehinderte (kann eine Braille-Zeile generated content darstellen?), aber […]
An die Stelle gehört kein Komma und schon gar kein Aber. An die Stelle gehört ein Punkt.
(Als AT für Sehbehinderte hätte ich eher Screenreader als Braille-Zeilen im Sinn.)
Die ganzen Formular-Elemente muss ein Anfänger bei Dir erst einmal lernen und ihren Sinn und Zweck außerhalb eines Formulars verstanden haben
Und das, wo schon nicht einmal du sie verstanden hast. Sie sind nicht wegen Barrierefreiheit da, sondern wegen progressive enhancement – Grundfunktionalität auch ohne JavaScript. Das hatte ich aber lang und breit erklärt.
Ebenso die ersten Codezeilen
if (document.querySelector) { document.documentElement.classList.add('js'); var ticTacToeElement = document.querySelector('#tic-tac-toe'); var rowElements = ticTacToeElement.rows; for (var i = 0, cellElements; i < rowElements.length; i++) { cellElements = rowElements[i].cells; for (var j = 0, labelElement; j < cellElements.length; j++) { labelElement = cellElements[j].querySelector('label'); cellElements[j].innerHTML = '<button data-row="' + i + '" data-column="' + j + '">' + labelElement.innerHTML + '</button>'; } }
Die haben mit der Spiellogik nichts zu tun, sondern ersetzen die „ganzen Formular-Elemente“ im DOM durch die Buttons.
In einem Artikel, der auf progressive enhancement schpfeift, würde man die Buttons gleich ins Markup schreiben (s.o.) und diese Codezeilen fielen weg. (Sähe dann so aus.)
Jedenfalls darfst du die Zeilen beim Vergleich, ob „es nicht sinnvoller [ist], die Daten über den Spielverlauf in einer 3×3-Matrix zu halten“, nicht mitzählen.
Dass Anzahl der Zeilen und Komplexität von Code zwei grundverschiedene Dinge sind, hatte ich schon gesagt. Aber nochmal im Einzelnen:
function ticTacToeClickHandler(event) { var targetElement = event.target; var parentElement = targetElement.parentElement; var row, column; if (targetElement.nodeName == 'BUTTON') {
Ja, ich bin Freund von Allman-Style: öffnende { in einer neuen Zeile. Wenn du LOC vergleichst, musst du das berücksichtigen.
row = parseInt(targetElement.dataset.row); column = parseInt(targetElement.dataset.column); board[row][column] = isPlayerXMoving ? 1 : -1;
Das hätte man auch in einer Zeile erledigen können:
board[parseInt(targetElement.dataset.row)][parseInt(targetElement.dataset.column)] = isPlayerXMoving ? 1 : -1;
Die Aufteilung auf mehrere Zeile dient eben gerade dazu, den Code besser lesbar und verständlich zu machen. Weniger LOC heißt eben nicht verständlicherer Code.
if (gameOver()) { alert('Game over. ' + (isPlayerXMoving ? '❌' : '⭕') + ' wins.'); } else { isPlayerXMoving = !isPlayerXMoving; }
Auch hier hätte man Zeilen sparen können:
if (gameOver()) alert('Game over. ' + (isPlayerXMoving ? '❌' : '⭕') + ' wins.');
else isPlayerXMoving = !isPlayerXMoving;
Aber es gehört zur Wartbarkeit von Code, immer {}-Blöcke bei if, else, for etc. zu verwenden, auch bei nur einer Anweisung im Block.
var sum; for (var i = 0; i < 3; i++) { sum = 0;
Das hätte auch ein Einzeiler sein können:
for (var sum = 0, i = 0; i < 3; i++)
{
Aber wäre der Code dadurch besser geworden?
for (var j = 0; j < 3; j++) { sum += board[i][j]; } if (Math.abs(sum) == 3) { return true; } } for (var j = 0; j < 3; j++) { sum = 0; for (var i = 0; i < 3; i++) { sum += board[i][j]; } if (Math.abs(sum) == 3) { return true; } } sum = 0; for (var i = 0; i < 3; i++) { sum += board[i][i]; } if (Math.abs(sum) == 3) { return true; } sum = 0; for (var i = 0; i < 3; i++) { sum += board[i][2 - i]; } if (Math.abs(sum) == 3) { return true; } return false; }
Das wäre der Kern gewesen, den du mit deinen Abfragen der Klassen im DOM hättest vergleichen sollen: Ist die Bildung der Summen und der Vergleich mit 3 einfacher als die Abfrage der Klassen mit AND verknüpt? An der Beantwortung bist du haarscharf vorbeigeschrammt.
Übrigens ist hier noch Optimierungspotential: Es muss nicht das gesamte Spielfeld geprüft werden, sondern nur die Zeile und Spalte und ggfs. Diagonale(n) des gerade ausgewählten Feldes.
Dein Code umfasst abzüglich aller Leerzeilen (Kommentare sind keine vorhanden) 91 Zeilen, also 50% mehr! Damit hast Du schon quantitativ bewiesen, dass Dein Ansatz nicht minimalistisch ist, für ein Anfänger-Tutorial also eher weniger gut geeignet.
Nein, damit hast du bewiesen, dass du 2. nicht zählen kannst und 1. nicht verstanden hast, dass das Zählen von Codezeilen kaum eine Aussage über Komplexität zulässt.
Außerdem ist er nicht in eine Funktion verpackt, sondern liegt im globalen Scope herum. Sowohl die ausschließlich zu dem Spiel gehörenden Funktionen […] als auch die Variablen […] sind Methoden bzw. Eigenschaften von
window. Das sollte man Anfängern gleich von vornherein aber abempfehlen, auch wenn man das dahinter steckende Geheimnisprinzip noch nicht offen als solches thematisiert.
Wenn du das Ganze in einen IIFE packen willst – nur zu. Der Anfänger wird das Konstrukt nicht verstehen, und ein Erklärung dazu wäre für diesen Artikel wohl auch zu viel. Aber ja, das könnte man als best practise auch ohne Erklärung in den Code aufnehmen.
Was die tatsächliche Komplexität angeht, so wird in meinem Beispiel lediglich ein spezieller Attributwert von einer Sorte HTML-Element überprüft, bei Dir dagegen muss die ganze Menge an Eingabe-Elementen (
select,optionundbutton) abgeklappert werden
Wie gesagt: Das ist Unsinn.
Die Lösung mit einem alert-Aufruf ist in meinen Augen die schlechtestmögliche Lösung eines Problems, das mein Ansatz definitiv unaufdringlicher gelöst hat. Du kennst mit Sicherheit die Probleme, die ein alert in anderen Browsertabs/-fenstern verursacht. Wozu also Anfängern diese Unsitte beibriungen?
Die Ausgabe war von mir mal eben so hingerotzt. Da sollte natürlich eine vernünftige Ausgabe erfolgen.
Den Rest des GUI macht konsequent CSS - bis hin zur Ausgabe des Spielergebnisses.
Die Ausgabe ist aber Inhalt, gehört also ins DOM, nicht ins Stylesheet.
LLAP 🖖
PS:
Dazu kommt noch die Verwendung von
id- anstelle vonclass-Attributen. Mehrere Spiele auf einer Seite (warum auch immer das nützlich oder sinnvoll sein mag) ist damit nicht gegeben.
Muss auch nicht, IMHO. Die Frage „Mehrere Spiele auf einer Seite nützlich oder sinnvoll?“ würde ich mal eben mit nein beantworten. Hier bringst du IMHO unnötige Komplexität in den Code.
Aloha ;)
Eins hatte ich in meinen Betrachtungen bislang ausgespart: die Logik. Aber auch hier stellt sich eine Frage nach den grundsätzlichen Lernzielen. Es sollten doch sicher von Anfang an Daten und Darstellung getrennt sein; dem Anfänger das EVA-Prinzip vermittelt werden.
Ist es vor diesem Hintergrund wirklich ratsam, die Logik ans DOM zu koppeln? Also die Erkennung „3 in einer Reihe?“ anhand von Klassen der DOM-Elemente vorzunehmen?
Das Argument geht an der Realität vorbei. Vergiss nicht, dass wir hier von JavaScript sprechen, und gerade in diesem Beispiel von eindeutig clientseitigem JavaScript.
Abgesehen davon ist das, was du (denke ich) meinst, nicht wirklich das EVA-Prinzip - denn EVA ist ein Prinzip, dass grundsätzlich gilt, bei jeder Verwendung von JavaScript (egal, wie man programmiert) kommt EVA zum Tragen, das ist eine Frage der Architektur und nicht der Programmierung oder des zur Programmierung herangezogenen Pattern.
Du meinst wahrscheinlich eher die Trennung zwischen GUI und Geschäftslogik (sowie nötigenfalls [persistenter] Datenhaltung), die im Software Engineering oft günstig ist. Aber auch da würde ich im Fall von JavaScript - und besonders in diesem Beispiel - widersprechen. Die Trennung erfolgt aus dem praktischen Grund, dass ein Teil des Codes wiederverwendbar sein soll, selbst wenn die GUI ausgetauscht werden muss (also wenn z.B. eine native Smartphone-App und eine Weboberfläche auf die selbe Implementierung der Geschäftslogik zugreifen sollen). Im Fall von JavaScript ist das Grundsystem der GUI aber immer gleich - der Browser (denn im Allgemeinen sind clientseitige Skripte bzw. deren Aufgaben nicht identisch mit serverseitigen Aufgaben); lediglich die konkrete Darstellung kann sich ändern. Es fallen also schon viele gewichtige Gründe weg, da mit allzu großen Veränderungen auf der GUI-Seite gar nicht zu rechnen ist. Entkopplung ist immer aufwändig und lohnt sich nur dann, wenn auch ein entsprechender Nutzen zu erwarten ist. Außerdem mutet es sowieso skurril an, wenn man im JS-Bereich eine Trennung von GUI und Geschäftslogik fordert, da JS eigentlich an sich ein integraler Bestandteil des GUI-Systems ist.
So viel allgemein zu Trennung von GUI und Geschäftslogik im JS-Bereich. Und ganz abgesehen davon gibt es in diesem Fall noch mehr spezifische Argumente, die da widersprechen, vor allem: Das vorliegende System ist nicht komplex genug, dass eine Kopplung zu Unübersichtlichkeit führen würde - selbst bei GUI-Änderung wären alle zu machenden Änderungen noch einfach nachvollziehbar; es ist also eben gerade kein Beispiel, an dem man den Sinn einer solchen Trennung erkennen kann. Im Gegenteil, es ist sogar ein Gegenbeispiel, da eine solche Entkopplung auch wieder Komplexität erzeugt, die in diesem Fall die Komplexität des Gesamtentwurfs mindestens verdoppelt - ohne, dass das nötig wäre.
Wenn der Nutzen einer Entkopplung gelernt werden soll, dann muss das (wie @Felix Riesterer im Zusammenhang mit der Barrierefreiheit schon richtig sagte) Teil eines (eigenen) Artikels sein, der auch tatsächlich genau dieses Ziel hat. Dann aber auch mit einer Diskussion, wann das zu verwenden sinnvoll ist und mit einem Beispiel, bei dem die Verwendung tatsächlich angebracht ist. Auch ein entkoppelndes Pattern ist mehr Gegenstand von best practice als tatsächlich Teil der Grundlagen oder des Anfängerwissens - und gerade hier noch viel stärker als bei der Barrierefreiheit, da letztere immer sinnvoll anzuwenden ist, ein entkoppelndes Pattern aber nur, wenn eine Verwendung auch sinnvoll ist (was hier, wie gesagt, nicht der Fall ist).
Grüße,
RIDER
@@Camping_RIDER
Abgesehen davon ist das, was du (denke ich) meinst, nicht wirklich das EVA-Prinzip […] Du meinst wahrscheinlich eher die Trennung zwischen GUI und Geschäftslogik (sowie nötigenfalls [persistenter] Datenhaltung)
Ja, das meine ich.
die im Software Engineering oft günstig ist. Aber auch da würde ich im Fall von JavaScript - und besonders in diesem Beispiel - widersprechen. Die Trennung erfolgt aus dem praktischen Grund, dass ein Teil des Codes wiederverwendbar sein soll, selbst wenn die GUI ausgetauscht werden muss
Nun ja, es könnte jemand – warum auch immer‽‽ – auf die Idee kommen, die table-/tr-/td-Elemente gegen divs austauschen zu wollen.
Außerdem mutet es sowieso skurril an, wenn man im JS-Bereich eine Trennung von GUI und Geschäftslogik fordert, da JS eigentlich an sich ein integraler Bestandteil des GUI-Systems ist.
In der heutigen Anwendung von JavaScript (im Hinblick auf Dinge wie SPAs) ist diese Trennung nicht skurril, sondern essentiell.
So viel allgemein zu Trennung von GUI und Geschäftslogik im JS-Bereich. Und ganz abgesehen davon gibt es in diesem Fall noch mehr spezifische Argumente, die da widersprechen, vor allem: Das vorliegende System ist nicht komplex genug
Sind wir uns nicht einig darüber, dass der Artikel allgemeine Praktiken vermitteln soll und das Tic-Tac-Toe-Spiel nicht mehr und nicht weniger als der Aufhänger dafür ist?
dass eine Kopplung zu Unübersichtlichkeit führen würde […] Im Gegenteil, es ist sogar ein Gegenbeispiel, da eine solche Entkopplung auch wieder Komplexität erzeugt, die in diesem Fall die Komplexität des Gesamtentwurfs mindestens verdoppelt - ohne, dass das nötig wäre.
Das glaube ich nicht. Wie gesagt würde sich der Code zur Erkennung des Spielendes sogar vereinfachen. Können wir uns am konkreten Beispiel ansehen, wenn ich (oder jemand anderes?) – wie von Felix angeregt – dazu komme, das beispielhaft zu implementieren.
Wenn der Nutzen einer Entkopplung gelernt werden soll, dann muss das (wie @Felix Riesterer im Zusammenhang mit der Barrierefreiheit schon richtig sagte) Teil eines (eigenen) Artikels sein,
Wenn es Ziel des Artikels ist, allgemeine best practices zu vermitteln, dann gehört das in den Artikel; nicht in einen anderen.
Und Barrierefreiheit gehört (wie ich schon richtig sagte) auch rein. Felix irrt an dieser Stelle grundsätzlich. (Sein Posting harrt noch der Beantwortung.)
LLAP 🖖
Aloha ;)
Außerdem mutet es sowieso skurril an, wenn man im JS-Bereich eine Trennung von GUI und Geschäftslogik fordert, da JS eigentlich an sich ein integraler Bestandteil des GUI-Systems ist.
In der heutigen Anwendung von JavaScript (im Hinblick auf Dinge wie SPAs) ist diese Trennung nicht skurril, sondern essentiell.
Bei SPAs hast du vollkommen recht, das liegt aber daran, dass SPAs einen Spezialfall darstellen, der über die notwendigen Eigenschaften verfügt, die ein entkoppelndes Pattern sehr sinnvoll machen. Das ist, sozusagen, die sprichwörtliche Ausnahme von der Regel. Und, ich denke auch da sind wir uns einig: Der Einsatz von JavaScript, wie er in manchen SPAs geschieht, ist von grenzwertiger Sinnhaftigkeit - oder zumindest mit einem kleinen "Geschmäckle" versehen, dass das keine Anwendung von JavaScript im Sinne des Erfinders ist, wenn die SPA sich zu stark auf JavaScript verlässt. (Bei wenig JavaScript-Einsatz ist auch in SPAs eine solche Trennung nicht unbedingt geboten oder essentiell, es kommt hier auf den jeweiligen Ansatz an...)
So viel allgemein zu Trennung von GUI und Geschäftslogik im JS-Bereich. Und ganz abgesehen davon gibt es in diesem Fall noch mehr spezifische Argumente, die da widersprechen, vor allem: Das vorliegende System ist nicht komplex genug
Sind wir uns nicht einig darüber, dass der Artikel allgemeine Praktiken vermitteln soll und das Tic-Tac-Toe-Spiel nicht mehr und nicht weniger als der Aufhänger dafür ist?
Nein, sind wir nicht - zumindest nicht ohne nähere Spezifizierung. Der Artikel soll grundlegende Techniken vermitteln, die in JavaScript zum Einsatz kommen können. Insbesondere, so meine Lesart, geht es darum, verschiedene Sprachelemente in einem praktischen Beispiel kennen zu lernen. Der Fokus liegt dabei ganz deutlich bei Anfängern, die bisher kaum oder gar keine Erfahrung mit JavaScript als Sprache haben (sonst wäre die Kleinschrittigkeit der Erklärung auch nicht nötig). Allgemeine Praktiken oder gar best practice ist nichts, was darunter fällt, sondern vielmehr Teil des nächsten Schritts, also fortgeschrittener Stoff - denn um best practice verstehen und effektiv anwenden zu können, muss man zunächst die Sprache selbst beherrschen.
Du hast mit vielen von den Dingen, die du im Verlauf dieser Diskussion geschrieben hast, grundsätzlich Recht. Dir fehlt allerdings - meiner Meinung nach - in fast allem was du schreibst gleichzeitig auch der Blick auf den Anfänger oder überhaupt die Unterteilung in verschiedene Stufen des Lernens. Vielleicht macht folgende Überlegung meinen Punkt deutlich: Wenn ein Artikel für Anfänger folgendes vollumfänglich abdeckt
was beleibt dann für einen Artikel für Fortgeschrittene noch übrig? Nichts. Wenn jemand all die Punkte berücksichtigt, die du gerne im Artikel sehen würdest, dann wäre er schon auf dem Level eines Profis angelangt, denn was soll noch kommen, wenn man Barrierefreiheit, progressive enhancement und die zugehörigen Metaüberlegungen verinnerlicht hat?
Die Einordnung des Artikels als Anfängerartikel macht nur dann Sinn, wenn man sich auf ein Subset der möglichen Punkte beschränkt. Die anderen Punkte sollten dann selbstverständlich erwähnt oder weiterverlinkt werden, um den individuellen Lernfluss der Wissbegierigen nicht zu behindern, aber eben nicht direkt thematisiert oder gar in der grundlegenden Architektur berücksichtigt werden - denn sie sind nicht Gegenstand des Artikels für die ausdrücklich gewählte Zielgruppe.
Ob es nun Sinn macht oder nicht, die Zielgruppe zu wählen, darüber lasse ich gerne eine Diskussion zu (auch wenn ich dazu eine klare Meinung habe, das tut aber nichts zur Sache). Fakt ist aber, dass eine solche Einschränkung von Zielgruppe und Lernzielen formulierte Grundprämisse des gesamten Artikels ist und war, es ist also nicht wirklich sinnvoll, Kritik zu formulieren, die nicht von dieser Grundprämisse ausgeht - denn ohne Beachtung der Grundprämisse ist der ganze Artikel hinfällig. Es war ja auch insbesondere Kritik am konkreten Artikel gefragt, nicht Kritik an den zugrunde liegenden Randbedingungen[1]. Letztere kann auch nicht wirklich Anlass dafür geben, den konkreten Artikel zu verändern, sondern müsste dann unter Aufstellung anderer Randbedingungen in einem anderen Artikel (gerne auch vom ersten inspiriert) beachtet werden.
dass eine Kopplung zu Unübersichtlichkeit führen würde […] Im Gegenteil, es ist sogar ein Gegenbeispiel, da eine solche Entkopplung auch wieder Komplexität erzeugt, die in diesem Fall die Komplexität des Gesamtentwurfs mindestens verdoppelt - ohne, dass das nötig wäre.
Das glaube ich nicht. Wie gesagt würde sich der Code zur Erkennung des Spielendes sogar vereinfachen.
Doch - weil du durch die Entkopplung eine eigenständige Komponente dazuerhältst, nämlich die, die die GUI anhand dessen, was die Geschäftslogik errechnet, steuert. Bisher ist dieser Teil in die Geschäftslogik integriert, was zwangsläufig im Gesamtentwurf weniger komplex ist. Es ging mir nicht darum, dass zwangsläufig der Code jeder Einzelaktion komplizierter wird - tatsächlich hast du Recht, dass die Analyse der Daten bei anderer Repräsentation eventuell (!) weniger komplex ist - sondern es ging mir um die Komplexität der Architektur der Lösung. Und die steigt, weil ein Teil dessen, was bisher geschieht, losgelöst, gekoppelt und entsprechend per Schnittstelle angeschlossen werden muss (denn gerade die Bereitstellung einer Schnittstelle, die GUI und Geschäftslogik verbindet und nötigenfalls auch die Geschäftslogik mit einer anderen GUI verbinden kann, ist ja gerade der Kern des Pudels).
Das ist doch genau der Trade-Off, den man sich mit einem entkoppelnden Pattern zunutze macht: Man erhöht die Komplexität des Entwurfs (Architektur) und erhält dafür einfachere Wartbarkeit und Austauschbarkeit von Code, denn nur um letzteres kann es bei einem solchen Pattern gehen. Und genau das ist in diesem konkreten Fall eben nicht gerechtfertigt, weil sich der Trade-Off nicht auszahlt.
Können wir uns am konkreten Beispiel ansehen, wenn ich (oder jemand anderes?) – wie von Felix angeregt – dazu komme, das beispielhaft zu implementieren.
Wie gesagt - es ging mir vor allem auch um die Komplexität des Entwurfs, nicht so sehr um die Komplexität der Implementierung. Dass der Entwurf komplexer wird, sollte offensichtlich sein, denn jede Funktionalität, die bisher die GUI wie-auch-immer-geartet verändert muss in einem entkoppelten Entwurf nach wie vor existieren (und die austauschbaren GUI-Funktionen aufrufen, Stichwort Schnittstelle) während die gesamte Verwaltung der GUI als handelnde Komponente dazukommt.
Wenn der Nutzen einer Entkopplung gelernt werden soll, dann muss das (wie @Felix Riesterer im Zusammenhang mit der Barrierefreiheit schon richtig sagte) Teil eines (eigenen) Artikels sein,
Wenn es Ziel des Artikels ist, allgemeine best practices zu vermitteln, dann gehört das in den Artikel; nicht in einen anderen.
Dass eben das nicht der Fall ist hatte ich schon ursprünglich angedeutet und oben noch einmal ausführlich begründet. Es ist zwar schon Ziel des Artikels, auf allgemeine best practices zu verweisen, wo sich das anbietet, allerdings nicht, diese direkt zu vermitteln.
Und Barrierefreiheit gehört (wie ich schon richtig sagte) auch rein. Felix irrt an dieser Stelle grundsätzlich. (Sein Posting harrt noch der Beantwortung.)
Wie gesagt - ich bin in dem Fall auch Felix Meinung. Ich glaube eher, dass du nach wie vor die Zielsetzung des Artikels nicht verstanden hast, da die von dir verfolgten Ziele (so richtig sie auch sind) nicht damit übereinstimmen. Das kann auch daran liegen, dass du den Bedarf für einen Artikel mit der Zielsetzung, die hier gewählt wurde, nicht so recht siehst. Meiner Einschätzung nach (ich kann falsch liegen) liegt das aber nicht daran, dass es den Bedarf nicht geben würde, sondern vielmehr damit, dass du eher weniger oft mit blutigen Anfängern zu tun hast, die erstmal die technischen Möglichkeiten kennenlernen müssen und durch weitergehende Überlegungen überfordert bis abgeschreckt werden. Beispiel für jemanden aus dieser Zielgruppe: Ein vierzehnjähriger Schüler, für den JavaScript die erste Programmiersprache überhaupt darstellt. Oder ein Uni-Student, der zwar schon programmiert hat, aber auf einmal was mit Webtechnologien machen soll und keine Ahnung hat, wie man (technisch) mit JavaScript eine Webseite dynamisch verändern kann. Und tatsächlich sind beide auch Teil unserer Zielgruppen als Selfhtml. Natürlich muss man auch denen irgendwann fortgechrittene Konzepte vermitteln - aber nicht von Anfang an ausführlich, weil die Lernkurve sonst viel zu steil ist. Es ist doch gerade unser Ziel, Leute für Webtechnologien zu begeistern - das funktioniert aber nur, wenn am Anfang (Stichwort "Anfänger") nicht Frustration aufkommt, weil der Berg dessen, was man auf einen Schlag vermittelt bekommt, die Kapazitäten übersteigt.
Klar, manche werden damit dennoch gut umgehen können. Andere gar nicht. Gerade deshalb ist es doch sinnvoll, Erwähnungen und weiterführende Links einzubauen, statt direkt im Artikel auf die fortgeschrittenen Konzepte einzugehen - damit jeder Lerner individuell entscheiden kann, ob er sich direkt mit fortgeschrittenen Konzepten befassen möchte oder eben erst später mit mehr Eigenerfahrung und einem Verständnis der Sprachgrundlagen.
Grüße,
RIDER
In der Sprache der Mathematik: Es war nicht gefragt, ob die zugrundegelegten Axiome sinnvoll sind, sondern ob die auf Basis der Axiome getroffenen Schlussfolgerungen Fehler oder logische Brüche aufweisen. ↩︎