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-Kenntnis