Rest Operator und Spread Operator
Orlok
- javascript
- selfhtml-wiki
Hallo
Ich habe in der vergangenen Woche einen ziemlich umfangreichen Artikel zum Rest- beziehungsweise Spread Operator geschrieben, der in ECMAScript 2015 eingeführt wurde und zu dem es bislang im Wiki noch keinen Artikel gab. Da sich die Semantik des Operators ...
abhängig vom Kontext in dem er verwendet wird stark unterscheidet, sind es also eigentlich zwei verschiedene Artikel. Aber es erschien mir nicht sinnvoll, das auf zwei Seiten zu verteilen, zumal die Syntax dieselbe ist.
function name (parameter, ...rest) {
console.log(rest);
return rest;
}
const values = name(25, 50, 75); // [50, 75]
console.log(Array.isArray(values)); // true
Der Operator kann zum Beispiel dazu verwendet werden um Restparameter zu erstellen. Dabei wird ein (anders als das Objekt arguments
) echtes Array mit den beim Aufruf an die Funktion übergebenen Werten erzeugt, die nicht zuvor an formale Parameter gebunden wurden.
const numbers = [15, 30, 45, 60];
let [first, second, ...rest] = numbers;
console.log(rest); // [45, 60]
Bei der Destrukturierung iterierbarer Objekte wie zum Beispiel Arrays erfüllt der Operator denselben Zweck, das heißt, auch hier wird ein Array mit den zuvor nicht gebundenen Werten erzeugt.
const part1 = [10, 15],
part2 = [25, 30];
const list = [5, ...part1, 20, ...part2, 35];
console.log(list.length); // 7
Als Spread Operator kann der Operator dazu verwendet werden, die Werte eines iterierbaren Objektes in ein Array einzufügen. Wird er also wie hier in einem Arrayliteral notiert und ihm Objekt übergeben, welches ein Iterable Interface implementiert hat, dann iteriert er über dieses Objekt und fügt die Werte an der Stelle in das Array ein, an der er notiert wurde.
const numbers = new Set([3, 17, 5, 11, 31]);
let max = Math.max(...numbers);
console.log(max); // 31
Genauso verhält er sich, wenn er bei der Übergabe von Argumenten notiert wird. Erwartet die Funktion, so wie zum Beispiel Math.max
die zu übergebenden Werte als einzelne Argumente, liegen diese aber in einem iterierbaren Objekt vor, dann kann der Operator dazu verwendet werden, die Werte aus dem referenzierten Objekt zu lesen und sie in Argumente umzuwandeln.
Also, wer mag, kann ja mal einen Blick auf Artikel zum Rest- oder Spread-Operator werfen.
Gruß,
Orlok
hi,
Also, wer mag, kann ja mal einen Blick auf Artikel zum Rest- oder Spread-Operator werfen.
Interessant. Warum nur kommt mir das alles so bekannt vor!? Achja, Perl..
Hallo pl
Also, wer mag, kann ja mal einen Blick auf Artikel zum Rest- oder Spread-Operator werfen.
Interessant. Warum nur kommt mir das alles so bekannt vor!? Achja, Perl..
Gleich vorweg, das Minus für deinen Beitrag ist nicht von mir. Allerdings muss ich doch eingestehen, dass mir nicht so recht klar ist, was du mit deiner Antwort eigentlich sagen wolltest, es sei denn, du meintest mit das alles lediglich die aus drei Punkten bestehende Syntax. Denn soweit ich das erkennen kann, besitzt der Operator ...
in ECMAScript und in Perl eine völlig unterschiedliche Semantik.
Wozu er in ECMAScript verwendet werden kann, habe ich ja nun lang und breit beschrieben, aber das ist wohl etwas anderes als das, was der Operator in Perl bewirkt.
print(1 ... 10); # 12345678910
Dort fügt er in einer Liste als Bereichsoperator (Range Operator) Werte zwischen einem definierten Start- und Endwert ein, was nicht zwingend numerische Werte sein müssen wie in dem Beispiel oben. Dabei werden die Werte aber wohl in jedem Fall automatisch generiert und nicht einer Datenstruktur beziehungsweise der internen Liste der an eine Funktion übergebenen Argumente entnommen.
Entsprechend sind die Operatoren kaum miteinander zu vergleichen, es sei denn, ich hätte hier etwas wesentliches übersehen. – In diesem Fall könntest du mich vielleicht aufklären.
Gruß,
Orlok
Hallo,
Dort fügt er in einer Liste als Bereichsoperator (Range Operator) Werte zwischen einem definierten Start- und Endwert ein, was nicht zwingend numerische Werte sein müssen wie in dem Beispiel oben.
Laut Wiki wäre das aber "..", also nur zwei.
In den Perl-Operatoren kann ich die zwei Punkte auch nur bei der Operatoren-Rangfolge finden.
Gruß
Kalk
Hallo Tabellenkalk,
Laut Wiki wäre das aber "..", also nur zwei.
Perl hat zwei Range-Operatoren, ..
und ...
. Den Unterschied sieht man aber erst, wenn man die Range in einem Skalar-Kontext betrachtet: dort wird sie zu einem boolschen Wert.
Die Semantik einer Range in Perl in einem Skalar-Kontext ist ziemlich kompliziert. Im wesentlichen handelt es sich um ein Flipflop. Betrachten wir einmal diesen Ausdruck:
if($left .. $right) {
#...
}
Die Bedingung evaluiert solange false
bis der linke Operand wahr wird. Dann wird der linke Operand ignoriert und evaluiert solange zu true
, bis der rechte Operand zu true
evaluiert: dann wird der Ausdruck false
. So kann man den Wert dieses Ausdrucks hin- und herschalten, wie bei einem Flipflop. Mal ein Beispiel, wo man so etwas einsetzen könnte: ich möchte in einem Text alles zwischen den Zeilen foo
und bar
haben:
while (<DATA>) {
print if /foo/ .. /bar/;
}
__DATA__
blub
foo
Zeile 1
Zeile 2
Zeile 3
bar
blub
blub
foo
Zeile 4
Zeile 5
bar
blub
blub
Die Ausgabe dieses Programms ist:
foo
Zeile 1
Zeile 2
Zeile 3
bar
foo
Zeile 4
Zeile 5
bar
Setzen wir jetzt den Operator ...
ein, dann wird der rechte Operand nicht mehr geprüft wenn der linke wahr ist. Das führt in unserem Beispiel dazu, dass Zeilen, bei denen sowohl foo
als auch bar
vorkommen nicht als beendet markiert werden:
while (<DATA>) {
print if /foo/ ... /bar/;
}
__DATA__
blub
foo
Zeile 1
Zeile 2
Zeile 3
bar
blub
blub
foo
Zeile 4
Zeile 5
bar
foo bar
blub
blub
Als Ausgabe gibt das:
foo
Zeile 1
Zeile 2
Zeile 3
bar
foo
Zeile 4
Zeile 5
bar
foo bar
blub
blub
Beachte die beiden blub
am Ende.
Diese komplizierte Semantik ist sicher noch ein Grund, warum Perl als Write-Only Language veschriehen wird ;-)
LG,
CK
@@Christian Kruse
Perl hat zwei Range-Operatoren,
..
und...
. Den Unterschied sieht man aber erst …
Den Unterschied zwischen ...
und . sieht man aber kaum.
Ich hab da mal ' um die Operatoren gesetzt.
War immer noch nicht besonders gut lesbar. Deshalb den Punkt am Satzende – obwohl formal durchaus korrekt – noch entfernt.
LLAP 🖖
sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
Hallo Gunnar,
Den Unterschied zwischen
...
und . sieht man aber kaum.Ich hab da mal ' um die Operatoren gesetzt.
War immer noch nicht besonders gut lesbar. Deshalb den Punkt am Satzende – obwohl formal durchaus korrekt – noch entfernt.
Argh! Und dass das Absicht war ist dir nicht in den Sinn gekommen? ;)
LG,
CK
Hallo,
Ich hab da mal ...
Argh! ...
Wäre es möglich und sinnvoll, in der Versionsansicht den Text auf die geänderten Zeilen, plus jeweils ein paar Zeilen Kontext, zu kürzen?
Gruß
Kalk
Hallo Tabellenkalk,
Wäre es möglich und sinnvoll, in der Versionsansicht den Text auf die geänderten Zeilen, plus jeweils ein paar Zeilen Kontext, zu kürzen?
Ist jetzt als Benutzer-Konfiguration eingebaut.
LG,
CK
@@Christian Kruse
Argh! Und dass das Absicht war ist dir nicht in den Sinn gekommen? ;)
Wenn alle verstanden haben, was mit ....
gemeint ist, kannste meine Änderungen ja wieder rückgängig machen. ;-)
LLAP 🖖
sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
Hallo Gunnar,
Wenn alle verstanden haben, was mit
....
gemeint ist, kannste meine Änderungen ja wieder rückgängig machen. ;-)
Wie gesagt, das war durchaus Absicht, ein kleiner Scherz am Rande ;)
Wie auch immer, ich habe das Styling von Inline-Code mal angepasst, so dass es jetzt dem von Code-Blöcken gleicht.
LG,
CK
Hallo Christian
Wie auch immer, ich habe das Styling von Inline-Code mal angepasst, so dass es jetzt dem von Code-Blöcken gleicht.
An den neuen Look des Inline-Codes
könnte ich mich wahrscheinlich gewöhnen, aber irgendwie hat sich auch das Styling der Code-Blöcke verändert, und das nicht unbedingt zum Besseren, wie ich finde.
// das ist ein Kommentar function dasIstEinBezeichner ( ) { // das ist noch ein Kommentar }
Bislang war es ja so, dass der Code in den Blöcken im Original wie im Zitat identisch dargestellt wurde, wenn ich mich nicht völlig irre, und das fand ich im Prinzip auch gut so, denn es reicht meiner Ansicht nach, wenn links neben dem Block ein Balken angezeigt wird, um das Zitat zu erkennen.
// das ist ein Kommentar
function dasIstEinBezeichner ( ) {
// das ist noch ein Kommentar
}
Aber jetzt wird der normale Quelltext (zumindest in JavaScript) in Code-Blöcken die Teil eines Zitats sind anders dargestellt als in nicht-zitierten Blöcken und zwar so, dass Kommentare von Bezeichnern und Syntaxelementen wie Klammern zumindest farblich kaum mehr zu unterscheiden sind.
Also, keine Ahnung ob die Änderung Absicht war oder nicht, aber ich denke vorher war es besser.
Viele Grüße,
Orlok
Hallo Orlok,
Also, keine Ahnung ob die Änderung Absicht war oder nicht, aber ich denke vorher war es besser.
Nö, das war ein Bug, ich hatte aus Versehen die Vordergrundfarbe für code
entfernt.
LG,
CK
@@Christian Kruse
Hallo Gunnar,
Wenn alle verstanden haben, was mit
....
gemeint ist, kannste meine Änderungen ja wieder rückgängig machen. ;-)Wie gesagt, das war durchaus Absicht, ein kleiner Scherz am Rande ;)
Wie auch immer, ich habe das Styling von Inline-Code mal angepasst, so dass es jetzt dem von Code-Blöcken gleicht.
Das nervt mich auch auf anderen Seiten.
Was dagegen spricht:
Es stört den Lesefluss. (Beispiel 1, Beispiel 2)
Links sind kaum noch als solche zu erkennen. (Beispiel 3, Beispiel 4)
Kannst du das bitte wieder rückgängig machen?
LLAP 🖖
sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
Hallo Gunnar Bittersmann,
Wie auch immer, ich habe das Styling von Inline-Code mal angepasst, so dass es jetzt dem von Code-Blöcken gleicht.
Was dagegen spricht:
- Es stört den Lesefluss. (Beispiel 1, Beispiel 2)
Ich habe schon lange in meinem User-Stylesheet:
code {
font-size: .85em;
}
Ohne das wirken die inline-codes tatsächlich etwas zu wuchtig. Das ist mir bisher gar nicht aufgefallen.
- Links sind kaum noch als solche zu erkennen. (Beispiel 3, Beispiel 4)
Hier stimme ich zu.
Kannst du das bitte wieder rückgängig machen?
Ein Kompromiss wäre mir lieber.
Bis demnächst
Matthias
Tach,
- Es stört den Lesefluss. (Beispiel 1, Beispiel 2)
das ist doch der Sinn der Auszeichnung in diesem Fall; Code soll als solcher erkennbar sein.
- Links sind kaum noch als solche zu erkennen. (Beispiel 3, Beispiel 4)
Ist bei mir eindeutig unterstrichen und deshalb als Link erkennbar.
Kannst du das bitte wieder rückgängig machen?
Da wäre ich deutlich dagegen; bei der Variante vorher waren code und Text quasi nicht zu unterscheiden. Vielleicht gibt es etwas dezenteres als die aktuelle Variante, aber es sollte meiner Meinung nach deutlich sein.
mfg
Woodfighter
Hallo woodfighter,
- Links sind kaum noch als solche zu erkennen. (Beispiel 3, Beispiel 4)
Ist bei mir eindeutig unterstrichen und deshalb als Link erkennbar.
Naja, der Unterstrich fällt beinahe mit dem border-bottom zusammen.
Da wäre ich deutlich dagegen; bei der Variante vorher waren code und Text quasi nicht zu unterscheiden.
Nur wegen der standardmäßig verwendeten Monospace-Schriftart ;-)
Vielleicht gibt es etwas dezenteres als die aktuelle Variante, aber es sollte meiner Meinung nach deutlich sein.
Eine kleinere Schriftgröße trägt schon viel dazu bei, kann aber auch sein, dass das nur an Windows-Rechnern wirkt, weil die Unterschiede zwischen den verwendeten Proportional- und Monospaceschriften an anderen Rechnern kleiner sind.
Bis demnächst
Matthias
@@woodfighter
Code soll als solcher erkennbar sein.
Das ist er doch bereits an der Schriftart: Proportionalschrift für Fließtext, dicktengleiche für Code.
Oh, ganz vergessen, dass das ja nicht der Default fürs Forum ist und bei euch wohl auch Fließtext in dicktengleicher Schrift gesetzt ist. Dieses Übel wäre auch zu beseitigen.
Ist bei mir eindeutig unterstrichen und deshalb als Link erkennbar.
Nein. In Beispiel 4 ist das unten eine doppelte Rahmenlinie, keine Unterstreichung. Und auch in Beispiel 3 ist der Unterschied zwischen velinktem und nicht verlinktem Code wohl zu subtil, als das er von unbedarften Lesern (für die man hier oft Antworten schreibt und weiterführende Links setzt) als solcher wahrgenommen wird.
Da wäre ich deutlich dagegen; bei der Variante vorher waren code und Text quasi nicht zu unterscheiden.
S.o. Der Stil des Fließtexts wäre zu ändern.
LLAP 🖖
sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
Tach,
Das ist er doch bereits an der Schriftart: Proportionalschrift für Fließtext, dicktengleiche für Code.
Oh, ganz vergessen, dass das ja nicht der Default fürs Forum ist und bei euch wohl auch Fließtext in dicktengleicher Schrift gesetzt ist. Dieses Übel wäre auch zu beseitigen.
und du beschwerst dich dann wieder mal, dass das Archiv kaputt geht?
Ist bei mir eindeutig unterstrichen und deshalb als Link erkennbar.
Nein.
Das kannst du nicht entscheiden.
In Beispiel 4 ist das unten eine doppelte Rahmenlinie, keine Unterstreichung.
Ich weiß nicht, was du in deinem Browser siehst, aber so würde ich das Aussehen nicht beschreiben.
Und auch in Beispiel 3 ist der Unterschied zwischen velinktem und nicht verlinktem Code wohl zu subtil, als das er von unbedarften Lesern (für die man hier oft Antworten schreibt und weiterführende Links setzt) als solcher wahrgenommen wird.
Ich glaube nicht, dass du es als Code auszeichnen und gleichzeitig so eindeutig als Link darstellen kannst, dass ein unbedarfter es immer erkennt (dafür ist die Darstellung des Codes zu verschieden); vermutlich wäre es besser auf das Feature (Code in Linktext) zu verzichten.
mfg
Woodfighter
Hallo
Das ist er doch bereits an der Schriftart: Proportionalschrift für Fließtext, dicktengleiche für Code.
Oh, ganz vergessen, dass das ja nicht der Default fürs Forum ist und bei euch wohl auch Fließtext in dicktengleicher Schrift gesetzt ist. Dieses Übel wäre auch zu beseitigen.
und du beschwerst dich dann wieder mal, dass das Archiv kaputt geht?
Ich wüsste zwar nicht, was, außer nicht mehr als solcher zu erkennender Inlinecode, deswegen im Archiv kaputtgehen sollte, aber …
Ist bei mir eindeutig unterstrichen und deshalb als Link erkennbar.
Nein.
Das kannst du nicht entscheiden.
… ja, zum Glück hat er das nicht zu entscheiden.
Tschö, Auge
Tach,
Oh, ganz vergessen, dass das ja nicht der Default fürs Forum ist und bei euch wohl auch Fließtext in dicktengleicher Schrift gesetzt ist. Dieses Übel wäre auch zu beseitigen.
und du beschwerst dich dann wieder mal, dass das Archiv kaputt geht?
Ich wüsste zwar nicht, was, außer nicht mehr als solcher zu erkennender Inlinecode, deswegen im Archiv kaputtgehen sollte, aber …
könnte da nicht noch funktionierende ASCII-Art lauern?
-------------------------------------^
---------------------------------------------^
Und falls sie nicht mehr funktioniert, wartet sie ja nur darauf, dass der Parser verbessert/das Posting konvertiert wird.
mfg
Woodfighter
Hallo
… Fließtext in dicktengleicher Schrift … Dieses Übel wäre auch zu beseitigen.
und du beschwerst dich dann wieder mal, dass das Archiv kaputt geht?
Ich wüsste zwar nicht, was, außer nicht mehr als solcher zu erkennender Inlinecode, deswegen im Archiv kaputtgehen sollte, aber …
könnte da nicht noch funktionierende ASCII-Art lauern?
-------------------------------------^
---------------------------------------------^
Aber sicher doch. Das habe ich mal ganz generös und frech unter Inlinecode subsumiert. ;-)
Und falls sie nicht mehr funktioniert, wartet sie ja nur darauf, dass der Parser verbessert/das Posting konvertiert wird.
Das kannst du mMn vergessen. Da ASCII-Art typischerweise nicht in Tags eigefasst ist, geht die Chance, diese Stellen zu identifizieren, gen – Achtung: Inlinecode! – 0
.
Tschö, Auge
Tach,
Und falls sie nicht mehr funktioniert, wartet sie ja nur darauf, dass der Parser verbessert/das Posting konvertiert wird.
Das kannst du mMn vergessen. Da ASCII-Art typischerweise nicht in Tags eigefasst ist, geht die Chance, diese Stellen zu identifizieren, gen – Achtung: Inlinecode! –
0
.
möglich wäre es schon, wenn man komplett getrennte Parser für die verschiedenen Perioden verwenden würde (und bereits angepasste Postings als solche markiert sind) (soweit ich das mitbekommen habe). Ob das den Aufwand wert ist, ist eine andere Frage.
mfg
Woodfighter
Hallo woodfighter,
möglich wäre es schon, wenn man komplett getrennte Parser für die verschiedenen Perioden verwenden würde (und bereits angepasste Postings als solche markiert sind) (soweit ich das mitbekommen habe).
Es werden bereits komplett verschiedene Parser verwendet ;-) anders war das nicht sinnvoll lösbar. Und konvertierte Postings werden auch markiert (muss ja).
LG,
CK
Tach,
möglich wäre es schon, wenn man komplett getrennte Parser für die verschiedenen Perioden verwenden würde (und bereits angepasste Postings als solche markiert sind) (soweit ich das mitbekommen habe).
Es werden bereits komplett verschiedene Parser verwendet ;-) anders war das nicht sinnvoll lösbar.
oh ich dachte die alten Postings werden aufbereitet und dann auch durch Markdown geschickt (und ich habe das Gefühl, wir hatten diese Unterhaltung schonmal).
mfg
Woodfighter
Hallo woodfighter,
oh ich dachte die alten Postings werden aufbereitet und dann auch durch Markdown geschickt (und ich habe das Gefühl, wir hatten diese Unterhaltung schonmal).
Ach das meinst du. Ja, das ist richtig, die alten Postings gehen durch einen Parser, der sie nach MD konvertiert.
LG,
CK
@@woodfighter
und du beschwerst dich dann wieder mal, dass das Archiv kaputt geht?
Das Archiv ist bereits an unzähligen Stellen kaputtgegangen.
Ich wäge ab: eine Handvoll ASCII-Arts aus der Vergangenheit erhalten oder die Lesbarkeit für alle Zeit verbessern. Für mich ist die Entscheidung klar.
Ist bei mir eindeutig unterstrichen und deshalb als Link erkennbar.
Nein.
Das kannst du nicht entscheiden.
Das nicht. Was ich sagen wollte: Es ist irrelevant, ob du den Link erkennen kannst. Ich kann ihn auch erkennen. Ich weiß ja, dass er da ist ‒ hab ihn ja selbst gesetzt. Es geht darum, ob andere das als Link erkennen, besonders Neulinge im Forum, auf deren Fragen man hier antwortet und für die man die Links setzt.
Ich weiß nicht, was du in deinem Browser siehst, aber so würde ich das Aussehen nicht beschreiben.
Du nicht, andere womöglich schon, s.o.
Ich glaube nicht, dass du es als Code auszeichnen und gleichzeitig so eindeutig als Link darstellen kannst, dass ein unbedarfter es immer erkennt (dafür ist die Darstellung des Codes zu verschieden);
Unterschiedliche Schriftarten für Fließtext und Code sollten das Problem schon deutlich mildern.
vermutlich wäre es besser auf das Feature (Code in Linktext) zu verzichten.
Äh, was jetzt genau? Code nicht als solchen auszeichnen? Nicht für den Link relevanten Text als Linktitel verwenden (das kann auch functionName
sein), sondern „click hier“ als Linktitel verwenden? Und das wegen einer unzweckmäßigen Grundeinstellung im Forum-Stylesheet? Ernsthaft?
LLAP 🖖
sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
Tach,
und du beschwerst dich dann wieder mal, dass das Archiv kaputt geht?
Das Archiv ist bereits an unzähligen Stellen kaputtgegangen.
im Moment ist es allerdings nur so, dass die falsch dargestellten Postings gefixt werden können; die Schriftart zu ändern, würde die mit Monospace im Hinterkopf gedachten Postings vorsätzlich kaputt machen.
Ich wäge ab: eine Handvoll ASCII-Arts aus der Vergangenheit erhalten oder die Lesbarkeit für alle Zeit verbessern. Für mich ist die Entscheidung klar.
Ob Monospace tatsächlich schlechter lesbar ist, weiß ich nicht; gibt es da neuere Untersuchung zu? Ich habe nur eine vom Anfang der 80er gefunden, die eine 6% Verbesserung bei der Darstellung auf damaligen Fernsehern gefunden hatte und wenn ich mir die Bilder darin anschaue, ist das mit aktuellen Monospace-Fonts eher nicht vergleichbar. Ah, da ist noch eine The Effect of Font Type on Screen Readability by People with Dyslexia (vermutlich hinter einer Paywall):
„The fonts designed specifically for dyslexia, OpenDys and OpenDys It., did not lead to better or worse readability.“
„Although Arial had the shortest reading time for both groups and is highly recom- mended in literature for dyslexia [British Dyslexia Association 2012; Evett and Brown 2005; Lockley 2002], we cannot conclude that this font type leads to better readability because we only found significant differences with respect to OpenDys It. and Arial It in participants with dyslexia. However, for people with and without dyslexia, Arial It. did lead to significantly longer reading times than Helvetica, Arial, and CMU. It also led to significantly longer fixation durations than most of the fonts. Hence, we recommend avoiding Arial It.“
„Among the tested fonts, the two fonts that led to shorter fixation durations were Courier and Helvetica. Hence, the use of these fonts might help people with dyslexia to read faster on screen. This is consistent with the recommendation of Ability Net [2013] to use Courier and with Lockley [2002] to use sans serif fonts in the case of Helvetica. Also, Helvetica was the second most significantly preferred font by our participants after Verdana.“
„Regarding reading time, more significant differences were found for participants without dyslexia, whereas, regarding fixation duration, more effects were found within the participant with dyslexia. Similar to participants with dyslexia, Arial It. had longer reading times, Arial and CMU presented shorter reading times, and shorter fixation durations were found using Courier. The discordant font was Verdana. While Verdana did not lead to shorter reading times for people with dyslexia and even presented shorter fixation durations than Arial It., it seems to have the opposite effect for people without dyslexia.“
„Among the tested fonts, good on-screen fonts for people with dyslexia are Helvetica, Courier, Arial, Verdana, and CMU, taking into consideration both reading performance and subjective preferences. Also, for the tested fonts, sans serif , monospaced, and roman font types increased reading performance significantly, whereas italic fonts decreased reading performance.“
Leider vergleicehn sie den einzigen getesteten Monospace-Font nicht mit den serifenlosen sondern nur mit den Serifenschriftarten direkt. Courier verliert gegenüber den anderen hier genannten bei der subjektiven Präferenz.
vermutlich wäre es besser auf das Feature (Code in Linktext) zu verzichten.
Äh, was jetzt genau? Code nicht als solchen auszeichnen? Nicht für den Link relevanten Text als Linktitel verwenden (das kann auch
functionName
sein), sondern „click hier“ als Linktitel verwenden? Und das wegen einer unzweckmäßigen Grundeinstellung im Forum-Stylesheet? Ernsthaft?
Wie ich schrieb, glaube ich nicht, dass Inline-Code, der ein Link ist, immer sinnvoll zu erkennen sein wird. Damit meine ich, dass Schrift- und Hintergrundfarbe sowie die Schriftformatierung nicht einfach vorhersehbar/zu komplex sind. Ohne den Rahmen finde ich code nicht unterscheidbar genug und mir fällt dann nix mehr ein, was man tun könnte (Link-Symbol einblenden?). Und ich habe nirgendswo von click here geschrieben, aber ich hätte die von dir geschriebenen Texte anders formuliert und ausgezeichnet.
mfg
Woodfighter
Hallo woodfighter,
Wie ich schrieb, glaube ich nicht, dass Inline-Code, der ein Link ist, immer sinnvoll zu erkennen sein wird. Damit meine ich, dass Schrift- und Hintergrundfarbe sowie die Schriftformatierung nicht einfach vorhersehbar/zu komplex sind. Ohne den Rahmen finde ich code nicht unterscheidbar genug und mir fällt dann nix mehr ein, was man tun könnte (Link-Symbol einblenden?).
Ich fühle mich ignoriert ;-)
Bis demnächst
Matthias
@@woodfighter
Wie ich schrieb, glaube ich nicht, dass Inline-Code, der ein Link ist, immer sinnvoll zu erkennen sein wird. Damit meine ich, dass Schrift- und Hintergrundfarbe sowie die Schriftformatierung nicht einfach vorhersehbar/zu komplex sind.
Als Autor eines Postings wird man Code als solchen auszeichnen wollen. Außerdem wird man für Links sinnvolle Linktitel verwenden wollen. Das sind zwei Dinge, die unabhängig voneinander sind.
Als Betreiber dieses Forums muss man nun Sorge dafür tragen, dass auch beides zusammen funktioniert. Eben weil beides von Autoren unabhängig voneinander verwendet werden kann; also auch beides gleichzeitig. Es ist nicht Aufgabe des Autors, sich darüber Gedanken zu machen.
LLAP 🖖
sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
Tach,
Als Betreiber dieses Forums muss man nun Sorge dafür tragen, dass auch beides zusammen funktioniert.
dann solltest du als Moderator dieses Forums und Usability-Experte vielleicht mal mithelfen eine Kompromisslösung zu finden.
Es ist nicht Aufgabe des Autors, sich darüber Gedanken zu machen.
Das sehe ich anders.
mfg
Woodfighter
Hallo woodfighter,
Ich glaube nicht, dass du es als Code auszeichnen und gleichzeitig so eindeutig als Link darstellen kannst, dass ein unbedarfter es immer erkennt (dafür ist die Darstellung des Codes zu verschieden); vermutlich wäre es besser auf das Feature (Code in Linktext) zu verzichten.
imho geht ja nur a code
. Was wäre mit
a code {
border-color: /* Linkfarbe */
border-bottom-width: 2px;
}
a! > code {
text-decoration: none;
/* demnächst auch in Ihrem Browser */
}
Bis demnächst
Matthias
Tach,
imho geht ja nur
a code
. Was wäre mita code { border-color: /* Linkfarbe */ border-bottom-width: 2px; } a! > code { text-decoration: none; /* demnächst auch in Ihrem Browser */ }
das wäre, wenn man es auf einer Seite mit einem nicht verlinkten Code-Block hätte im Vergleich vielleicht erkennbar, aber ich befürchte alleine stehend würde ich das nicht als Link erkennen (vorallem, wenn die Unterstreichung noch wegfiele).
Dann eher das Symbol aus dem „Link hinzufügen“-Button davor oder dahinter stellen.
mfg
Woodfighter
Hallo woodfighter,
Dann eher das Symbol aus dem „Link hinzufügen“-Button davor oder dahinter stellen.
$(document).ready(function(){
$('a > code').parent().addClass('code-link');
})
.thread-message .posting-content a.code-link {
text-decoration: none;
}
.thread-message .posting-content a.code-link::after {
font-family: FontAwesome;
content: "";
padding-left: 0.2em;
}
Sieht gar nicht so schlecht aus.
Bis demnächst
Matthias
Tach,
Dann eher das Symbol aus dem „Link hinzufügen“-Button davor oder dahinter stellen.
Sieht gar nicht so schlecht aus.
das ist zwar ein anderes Symbol, aber vermutlich verbreiteter. Ich würde vermutlich die Unterstreichung drin lassen, aber mich nach Designvorschlägen zu fragen, ist allgemein schon keine gute Idee.
mfg
Woodfighter
Hallo,
Also, wer mag, kann ja mal einen Blick auf Artikel zum Rest- oder Spread-Operator werfen.
Hab mal ein paar überflüssige Leerzeichen durch Bindestriche ersetzt.
Gruß
Kalk