selfhtml-wiki: letter-spacing - nur für bestimmte werte empfänglich??!!
BerlinerTourGuide
0 
Matthias Apsel
3 
Matthias Scharwies
selfhtml-wiki: letter-spacing - nur für bestimmte werte empfänglich??!!
BerlinerTourGuide
MudGuard
Gunnar Bittersmann
Tabellenkalk
Camping_RIDERbedauerlicherweise ist die diskussionsseite zum artikel "letter-spacing" für mich zur bearbeitung gesperrt worden. ich gebe also hier die bisher dort stattgefundene diskussion wieder, und füge neueres hinzu, da ich auch leider dort nicht mal einen link auf den hiesigen thread setzen kann... (was das ganze soll??? wozu sind denn diskussionsseiten da, wenn man sie nicht, wie in anderen wikis, nutzen soll...?)💯
ich habe festgestellt, dass mein IE auf werte von 0.01 - 0.03 em nicht reagiert, auf 0.04 und 0.05 identisch, dann wieder bis 0.1 em garnicht, während 0.1 em dann eine 'explosion' bewirkt... kann jemand dies auch beoabachten, erklären, kommentieren...? bei "px"-werten wird anscheinend nur auf ganzzahlige angaben reagiert... ferner wäre gut, anzugeben, welche einheiten nach dem zahlenwert zulässig sind. es wird gesagt, dass "%" nicht geht... "em" kommt im bsp. vor. "px" wird bei w3schools verwendet... danke! --Hahawe (Diskussion) 09:05, 18. Mär. 2017 (CET) @HaHawe Bitte benutz das Forum. 0.01em sind bei 16px Standardgröße 0.16px - bei 12px sogar nur 0.12px, wie soll ein Browser das darstellen?
ferner wäre gut, anzugeben, welche einheiten nach dem zahlenwert zulässig sind.
Numerische Angabe ist blau unterlegt, wenn Du daraufklickst, öffnet sich eine andere Seite, die wieder einmal das Wort Längenmaße und mögliche Einheiten erklärt. --Matthias Scharwies (Diskussion) 10:15, 18. Mär. 2017 (CET) hallo Matthias Scharwies! danke für deine antwort. fällt aber nicht sehr hilfreich aus (das thema "länge" spare ich hier aus; dazu hinweis an alter stelle...)... (ich benutze nicht die dikussion, weil es um den artikel geht, der m.e. ergänzt werden sollte...) der link auf "numerische angabe" ist nicht sehr hilfreich, weil dort alle üblichen maßeinheiten aufgeführt werden, mit denen numerische angaben (1,2, ... 0.3 ... 0,3 etc.) spezifiziert werden können. soll mensch also schließen: alle maßeinheiten (außer %) können verwendet werden?! wenn ja, sollte dies deutlich so gesagt werden. 0.01em ist zugegebenermaßen winzig, aber 0.04em oder 0.05em sind bereits deutlich zu sehen. woran liegt das? was sind die ursachen für die sprünge? mir scheint, nach genauerer analyse, dass das problem der diskontinuitäten daher rührt, dass der browser die numerischen em-angaben in ganzzahlige pixelwerte umsetzen muss (außer bei einer dpr > 1 !). dabei rundet er offensichtlich auf. 0.04 em sind bei einer basisgröße von 15px 0,6 px; daraus wird eine vergrößerung des buchstabenabstands von 1 px. immer noch dasselbe bei 0.05em. 0.1 em sind dagegen schon 1,5px. daraus macht der browser 2px (die erwähnte "explosion" hatte mit anderem zu tun). 0.2em sind glatt 3px, und werden auch so dargestellt. s. tabellarische übersicht hier: <img src="http://www.textandmedia.com/pic/em-zu-pixel-01.jpg"></img> Datei:Http://www.textandmedia.com/pic/em-zu-pixel-01.jpg (kann man hier kein bild darstellen...??) man sollte also (bei screens mit dpr = 1) nur mit zahlenwerten arbeiten, die vielfache von 1/pixel-wert der basisschrift sind (bei 15px also 0,066667); oder besser gleich mit ganzzahligen px-werten?! andernfalls hat man mit 'unverständlichen' aufrundungssprüngen zu tun... dies erklärt wohl auch, dass in ausgabemedien mit einer dpr > 1 (z.b. 3 bei sony xperia-händi) die buchstaben-abstände differenzierter berechnet werden können, also nicht so groß ausfallen, wie an einem screen mit dpr = 1). wer dies ausnutzen will, kann mit feiner unterteilten werten arbeiten. hinweise auf diese problematik sollten in den artikel eingepflegt werden, damit der user die problematik bei der anwendung von letter-spacing in verbindung mit diversen maßeinheiten versteht! schönen gruß! hhw bzw. BTG (leider will das system nicht zulassen, dass ich mir als BerlinerTourGuide anmelde...) --Hahawe (Diskussion) 12:35, 18. Mär. 2017 (CET)
Was verstehst du an „Deshalb sollten Diskussionen über den Artikel zum Thema „letter-spacing“ besser im SELFHTML-Forum geführt werden.“ und an der folgenden Aufforderung „Bitte benutz das Forum.“ nicht? Wir haben dich auch an anderer Stelle darauf hingewiesen. -- Matthias (Diskussion) 12:47, 18. Mär. 2017 (CET) --
:ich habe begründet, warum ich die diskussionsseite und nicht das forum benutze: "ich benutze nicht die dikussion, weil es um den artikel geht, der m.e. ergänzt werden sollte..."; entsprechend: "Eine Diskussionsseite dient dazu, Änderungen am Artikel zu besprechen." mehr dazu (und polemisches!) hier:https://wiki.selfhtml.org/wiki/Benutzer_Diskussion:Apsel#diskussion_zu_.22letter-spacing.22_-_und_selfhtml-wiki_allgemeiner...
::i.d.t. zeigen versuche, dass ein wert von 0.05em, der bei 15px basisgröße 0,75px entspricht (also bei einem dpr=1-screen vom browser auf ein px aufgerundet wird), bei einem dpr=3-bildschirm nur zu einem spacing von 7px führt; gibt man 1px ein, werden 8-9 px eingebaut (je nachdem, wie man die hellgrauen anti-alias-bereiche ansetzt). diese unterschiede machen sich schon über zeilen mit ca. 40 buchstaben und leerstellen sichtbar bemerkbar... btg
-
Hallo BerlinerTourGuide,
entsprechend: "Eine Diskussionsseite dient dazu, Änderungen am Artikel zu besprechen."
Du musst auch schon zuende lesen.
Eine Diskussionsseite dient dazu, Änderungen am Artikel zu besprechen. Allerdings werden diese Seiten in unserem Wiki erfahrungsgemäß nur von sehr wenigen Leuten besucht.
- Deshalb sollten Diskussionen über den Artikel zum Thema „Name der Seite“ besser im SELFHTML-Forum geführt werden.
- Unter https://forum.selfhtml.org/meta/new kannst du einen entsprechenden Beitrag erstellen.
- Bitte hinterlasse einen entsprechenden Link auf dieser Diskussionsseite, wenn du einen Thread im Forum eröffnet hast.
Bis demnächst
Matthias--
Rosen sind rot. -
Servus!
bedauerlicherweise ist die diskussionsseite zum artikel "letter-spacing" für mich zur bearbeitung gesperrt worden. ich gebe also hier die bisher dort stattgefundene diskussion wieder, und füge neueres hinzu, da ich auch leider dort nicht mal einen link auf den hiesigen thread setzen kann... (was das ganze soll??? wozu sind denn diskussionsseiten da, wenn man sie nicht, wie in anderen wikis, nutzen soll...?)
Du wurdest im Laufe der letzten Wochen mehrmals darauf hingewiesen, dass Diskussionen im Forum mehr Reichweite haben. Da gibt's einen großen grünen Hinweiskasten. Bist du ein Troll?????
ich habe festgestellt, dass mein IE auf werte von 0.01 - 0.03 em nicht reagiert, auf 0.04 und 0.05 identisch, dann wieder bis 0.1 em garnicht, während 0.1 em dann eine 'explosion' bewirkt... kann jemand dies auch beoabachten, erklären, kommentieren...? bei "px"-werten wird anscheinend nur auf ganzzahlige angaben reagiert...
Meine Antwort auf dieser Seite ist immer noch gültig:
0.01em sind bei 16px Standardgröße 0.16px - bei 12px sogar nur 0.12px, wie soll ein Browser das darstellen?
''ferner wäre gut, anzugeben, welche einheiten nach dem zahlenwert zulässig sind.'' es wird gesagt, dass "%" nicht geht... "em" kommt im bsp. vor. "px" wird bei w3schools verwendet... danke! --Hahawe (Diskussion) 09:05, 18. Mär. 2017 (CET)
Meine Antwort auf dieser Seite ist immer noch gültig:
Numerische Angabe ist blau unterlegt, wenn Du daraufklickst, öffnet sich eine andere Seite, die wieder einmal das Wort '''Längenmaße''' und mögliche Einheiten erklärt.
hallo Matthias Scharwies! danke für deine antwort. fällt aber nicht sehr hilfreich aus (das thema "länge" spare ich hier aus; dazu hinweis an alter stelle...)... (ich benutze nicht die dikussion, weil es um den artikel geht, der m.e. ergänzt werden sollte...)
der link auf "numerische angabe" ist nicht sehr hilfreich, weil dort alle üblichen maßeinheiten aufgeführt werden, mit denen numerische angaben (1,2, ... 0.3 ... 0,3 etc.) spezifiziert werden können. soll mensch also schließen: alle maßeinheiten (außer %) können verwendet werden?! wenn ja, sollte dies deutlich so gesagt werden.
Ja, das ist bei allen Längen so.
Allerdings macht es nicht viel Sinn, eine Schriftgröße auf Webseiten in inch oder cm anzugeben. Möglich wäre das aber.
0.01em ist zugegebenermaßen winzig, aber 0.04em oder 0.05em sind bereits deutlich zu sehen. woran liegt das?
Weil das 4x so groß ist? Bist du ein Troll?
was sind die ursachen für die sprünge? mir scheint, nach genauerer analyse, dass das problem der diskontinuitäten daher rührt, dass der browser die numerischen em-angaben in ganzzahlige pixelwerte umsetzen muss (außer bei einer dpr > 1 !). dabei rundet er offensichtlich auf. 0.04 em sind bei einer basisgröße von 15px 0,6 px; daraus wird eine vergrößerung des buchstabenabstands von 1 px. immer noch dasselbe bei 0.05em. 0.1 em sind dagegen schon 1,5px. daraus macht der browser 2px (die erwähnte "explosion" hatte mit anderem zu tun). 0.2em sind glatt 3px, und werden auch so dargestellt. s. tabellarische übersicht hier: <img src="http://www.textandmedia.com/pic/em-zu-pixel-01.jpg"></img> Datei:Http://www.textandmedia.com/pic/em-zu-pixel-01.jpg (kann man hier kein bild darstellen...??) man sollte also (bei screens mit dpr = 1) nur mit zahlenwerten arbeiten, die vielfache von 1/pixel-wert der basisschrift sind (bei 15px also 0,066667); oder besser gleich mit ganzzahligen px-werten?! andernfalls hat man mit 'unverständlichen' aufrundungssprüngen zu tun... dies erklärt wohl auch, dass in ausgabemedien mit einer dpr > 1 (z.b. 3 bei sony xperia-händi) die buchstaben-abstände differenzierter berechnet werden können, also nicht so groß ausfallen, wie an einem screen mit dpr = 1). wer dies ausnutzen will, kann mit feiner unterteilten werten arbeiten. hinweise auf diese problematik sollten in den artikel eingepflegt werden, damit der user die problematik bei der anwendung von letter-spacing in verbindung mit diversen maßeinheiten versteht!
Man könnte einen kurzen Hinweis einfügen, dass das Setzen sehr kleiner Werte wie 0.1px oder 0.01em nicht dargestellt wird, sonst ist das m.E. nach klar.
Ansonsten sind wir wieder beim Thema, dass du immer wieder hörst, dass es heute Konvention ist, auf pixelgenaue Layouts zu verzichten, weil sie eben nur auf einem Bildschirm pixelgenau sind. Das willst du aber nicht wahrhaben.
Herzliche Grüße
Matthias Scharwies
--
Es gibt viel zu tun: ToDo-Liste-
Hallo Matthias Scharwies,
Man könnte einen kurzen Hinweis einfügen, dass das Setzen sehr kleiner Werte wie 0.1px oder 0.01em nicht dargestellt wird, sonst ist das m.E. nach klar.
Das sollten wir aber nicht tun.
Bis demnächst
Matthias--
Rosen sind rot. -
Hi,
kann es sein, daß es schlicht und einfach daran liegt, daß der bei letter-spacing angegebene Wert zusätzlich zum ohnehin vorhandenen Zeichenabstand genutzt wird?
Siehe letter-spacing
This value indicates inter-character space in addition to the default space between characters. [Hervorhebung durch mich]
letter-spacing: 0;bewirkt also nicht, daß die Zeichen aneinanderkleben, sondern daß sie sich so verhalten wie beiletter-spacing: normal.
letter-spacing:1px;bewirkt analog nicht, daß zwischen den Zeichen genau 1px Platz ist, sondern daß zum normalen (letter-spacing: normal;) Zeichenabstand noch 1px draufaddiert wird.cu,
Andreas a/k/a MudGuard-
Hallo MudGuard,
der bei letter-spacing angegebene Wert zusätzlich zum ohnehin vorhandenen Zeichenabstand genutzt wird?
Siehe letter-spacing
This value indicates inter-character space in addition to the default space between characters. [Hervorhebung durch mich]
letter-spacing: 0;bewirkt also nicht, daß die Zeichen aneinanderkleben, sondern daß sie sich so verhalten wie beiletter-spacing: normal.
letter-spacing:1px;bewirkt analog nicht, daß zwischen den Zeichen genau 1px Platz ist, sondern daß zum normalen (letter-spacing: normal;) Zeichenabstand noch 1px draufaddiert wird.guter Hinweis. Kann und sollte imho beinahe unverändert ins Wiki.
Bis demnächst
Matthias--
Rosen sind rot.-
Servus!
Hallo MudGuard,
der bei letter-spacing angegebene Wert zusätzlich zum ohnehin vorhandenen Zeichenabstand genutzt wird?
Siehe letter-spacing
This value indicates inter-character space in addition to the default space between characters. [Hervorhebung durch mich]
letter-spacing: 0;bewirkt also nicht, daß die Zeichen aneinanderkleben, sondern daß sie sich so verhalten wie beiletter-spacing: normal.
letter-spacing:1px;bewirkt analog nicht, daß zwischen den Zeichen genau 1px Platz ist, sondern daß zum normalen (letter-spacing: normal;) Zeichenabstand noch 1px draufaddiert wird.guter Hinweis. Kann und sollte imho beinahe unverändert ins Wiki.
Mach ich grad!
Bis demnächst
MatthiasHerzliche Grüße
Matthias Scharwies
--
Es gibt viel zu tun: ToDo-Liste -
Hi,
der bei letter-spacing angegebene Wert zusätzlich zum ohnehin vorhandenen Zeichenabstand genutzt wird?
Siehe letter-spacing
This value indicates inter-character space in addition to the default space between characters. [Hervorhebung durch mich]
letter-spacing: 0;bewirkt also nicht, daß die Zeichen aneinanderkleben, sondern daß sie sich so verhalten wie beiletter-spacing: normal.
letter-spacing:1px;bewirkt analog nicht, daß zwischen den Zeichen genau 1px Platz ist, sondern daß zum normalen (letter-spacing: normal;) Zeichenabstand noch 1px draufaddiert wird.guter Hinweis. Kann und sollte imho beinahe unverändert ins Wiki.
Die Schöpfungshöhe dieser paar Zeilen dürfte niedrig genug sein, daß ich daran kein Urheberrecht habe. Also ab damit ins Wiki (ich leg jetzt aber keinen Wiki-Account dafür an)
cu,
Andreas a/k/a MudGuard -
@@Matthias Apsel
letter-spacing:1px;bewirkt analog nicht, daß zwischen den Zeichen genau 1px Platz ist, sondern daß zum normalen (letter-spacing: normal;) Zeichenabstand noch 1px draufaddiert wird.guter Hinweis. Kann und sollte imho beinahe unverändert ins Wiki.
Nein. Das sollte verändert ins Wiki.
Die Angabe von letter-spacing sollte sich immer auf die Schriftgröße beziehen, also in
emerfolgen.pxmachen an der Stelle überhaupt keinen Sinn.LLAP 🖖
--
“When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory-
Hallo,
Die Angabe von letter-spacing sollte sich immer auf die Schriftgröße beziehen, also in
emerfolgen.pxmachen an der Stelle überhaupt keinen Sinn.Können sie auch nicht. Denn im Deutschen heißt es:
pxhaben an der Stelle überhaupt keinen Sinn.:-D
RR
-
@@RR
Da sind wir wieder bei der Frage, ob „macht Sinn“ aus dem Englischen ins Deutsche rübergeschwappt ist. IMHO nicht; und wenn, dann schon vor längerer Zeit. Ich glaube, ich habe schon „macht Sinn“ gesagt, bevor Denglisch populär wurde.
LLAP 🖖
--
“When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory-
Hallo,
Ich glaube, ich habe schon „macht Sinn“ gesagt, bevor Denglisch populär wurde.
Ich glaube, Denglish gab's schon, als es dich noch gar nicht gab.
Gruß
Kalk
-
-
-
@@Gunnar Bittersmann
Nein. Das sollte verändert ins Wiki.
Die Angabe von letter-spacing sollte sich immer auf die Schriftgröße beziehen, also in
emerfolgen.pxmachen an der Stelle überhaupt keinen Sinn.Hab ich denn mal verändert.
LLAP 🖖
--
“When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
-
-
@@Matthias Apsel
der bei letter-spacing angegebene Wert zusätzlich zum ohnehin vorhandenen Zeichenabstand genutzt wird? guter Hinweis. Kann und sollte imho beinahe unverändert ins Wiki.
Das sollte auch im Beispiel eindeutig werden. Ich wollte da „zusätzlichen“ einfügen:
Die Zeichen dieses Textabsatzes haben einen <span>zusätzlichen Abstand von 0.25em</span>.Ist mir auf der Seite auch gelungen; das wurde aber nicht ins Beispiel übernommen – so sieht’s nicht aus.
Wie kann man den die Code-Beispiele bearbeiten?
Hab die Änderung wegen der Konsistenz erstmal wieder zurückgenommen.
LLAP 🖖
--
“When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory-
Hallo,
Wie kann man den die Code-Beispiele bearbeiten?
Ich glaube, wegen Vandalismusprävention benötigt man dafür spezielle Scharwies- bzw. Apsel-Rechte.
Gruß
Kalk-
@@Tabellenkalk
Wie kann man den die Code-Beispiele bearbeiten?
Ich glaube, wegen Vandalismusprävention benötigt man dafür spezielle Scharwies- bzw. Apsel-Rechte.
Was absurd wäre.
Vielleicht sollte man das mit dem selbstgefrickelten Frickler sein lassen und Beispiele von CodePen einbetten?
LLAP 🖖
--
“When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory-
Hallo,
Vielleicht sollte man das mit dem selbstgefrickelten Frickler sein lassen und Beispiele von CodePen einbetten?
Wenn das Einbetten nicht die CI sabotiert, spräche wohl nichts dagegen, das als zusätzliche Option zu ermöglichen. Du könntest natürlich auch einfach anfragen, ob die Matthiasse dir was von ihren Rechten abgeben würden…
Gruß
Kalk-
@@Tabellenkalk
Du könntest natürlich auch einfach anfragen, ob die Matthiasse dir was von ihren Rechten abgeben würden…
Das würde das Problem, dass nicht jeder im Wiki Änderungen/Ergänzungen vornehmen kann, nicht allgemein lösen.
LLAP 🖖
--
“When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory-
Hallo Gunnar Bittersmann,
Das würde das Problem, dass nicht jeder im Wiki Änderungen/Ergänzungen vornehmen kann, nicht allgemein lösen.
Ich sehe da kein Problem. Jeder kann im Wiki Änderungen/Ergänzungen vornehmen. Nur wenige können die Beispiele oder sonstige geschützte Seiten verändern.
Bis demnächst
Matthias--
Rosen sind rot.-
@@Matthias Apsel
Ich sehe da kein Problem. Jeder kann im Wiki Änderungen/Ergänzungen vornehmen. Nur wenige können die Beispiele oder sonstige geschützte Seiten verändern.
Die Code-Beispiele gehören zu den Artikeln im Wiki dazu. Auch Code-Beispiele sollte jeder ändern/ergänzen können.
LLAP 🖖
--
“When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory-
Hallo Gunnar Bittersmann,
Auch Code-Beispiele sollte jeder ändern/ergänzen können.
Nein. Dann könnte jeder etwa
<meta http-equiv="refresh" content="0; URL=https://example.org">schreiben. Und das möchten wir nicht. Und wir möchten auch keine Zeit investieren, um solche Sachen serverseitig zu unterbinden. Die jetzige Lösung hat sich bewährt.
Bis demnächst
Matthias--
Rosen sind rot.-
@@Matthias Apsel
Auch Code-Beispiele sollte jeder ändern/ergänzen können.
Nein. Dann könnte jeder etwa
<meta http-equiv="refresh" content="0; URL=https://example.org">schreiben. Und das möchten wir nicht.
Das Problem heißt: Es soll nicht jeder irgendwelchen groben Unfug ins Wiki schreiben können.
Eine Lösung wäre: Es darf gar nicht jeder ins Wiki schreiben. Keine besonders gute, IMHO.
Natürlich muss Quellcode, den Nutzer einstellen wollen, geprüft werden.
Und wir möchten auch keine Zeit investieren, um solche Sachen serverseitig zu unterbinden.
Und natürlich müsste man da etwas Zeit investieren und darüber nachdenken, wenn man denn eine eigene Lösung anstatt CodePen o.ä. haben will.
Die jetzige Lösung hat sich bewährt.
Dass Nutzer fehlerhafte Beispiele nicht korrigieren können oder ihren Artikeln keine Beispiele hinzufügen können, würde ich nicht „bewährt“ nennen.
LLAP 🖖
--
“When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory-
Dass Nutzer fehlerhafte Beispiele nicht korrigieren können oder ihren Artikeln keine Beispiele hinzufügen können, würde ich nicht „bewährt“ nennen.
Es gibt im Wiki kein Konzept von "mein Artikel". "Meine Artikel" werden gehostet auf "meinem Server". Man muss das Wiki hier akzeptieren als ein kollaboratves Instrument.
-
@@beatovich
Dass Nutzer fehlerhafte Beispiele nicht korrigieren können oder ihren Artikeln keine Beispiele hinzufügen können, würde ich nicht „bewährt“ nennen.
Es gibt im Wiki kein Konzept von "mein Artikel". "Meine Artikel" werden gehostet auf "meinem Server".
Du hast „in ihren Artikeln“ nicht so verstanden wie von mir beabsichtigt. Gemeint ist: in den Artikeln, die sie erstellen/bearbeiten.
Man muss das Wiki hier akzeptieren als ein kollaboratves Instrument.
Eben.
Code-Beispiele gehören zu den Artikeln dazu, sollten also erstellbar/bearbeitbar sein.
LLAP 🖖
--
“When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory-
hallo
Code-Beispiele gehören zu den Artikeln dazu, sollten also erstellbar/bearbeitbar sein.
Grundsätzlich ja. Aber im Hinblick auf Sicherheit muss man doch vorsehen, dass nicht irgendwelches Javascript auf irgendwelchen Clients ausgeführt wird.
Stell dir einfach vor, das wäre eine Plattform für Open-Source Code. Solcher Code muss durch einen Review-Prozess gehen, bis er in ein Build übernommen wird.
-
-
-
-
-
-
-
Hallo,
Das würde das Problem, dass nicht jeder im Wiki Änderungen/Ergänzungen vornehmen kann, nicht allgemein lösen.
Das ist eine Problemlösung, für ein Problem, das jedes Wiki hat: Jeder kann Änderungen vornehmen.
Gruß
Kalk
-
-
-
Aloha ;)
@@Tabellenkalk
Wie kann man den die Code-Beispiele bearbeiten?
Ich glaube, wegen Vandalismusprävention benötigt man dafür spezielle Scharwies- bzw. Apsel-Rechte.
Was absurd wäre.
Naja, so speziell sind die Rechte nicht - bei Nachfrage werden sie ja auch im Normalfall erteilt. Gründe dafür, das nicht noch offener zu handhaben hat @Matthias Apsel schon genannt.
Andererseits ist es so, dass gewisse fleißige Heinzelmännchen sowieso ein Auge auf die Änderungshistorie der Artikel haben und im Zweifel (oder spätestens dann, wenn man ihnen eine Notiz hinterlässt) die Änderungen im Beispiel-Code auch ins statische Beispiel übertragen. Gerade bei gelegentlichen Änderungen durch Einmal-Bearbeiter ist das ein gut funktionierender Mechanismus.
Vielleicht sollte man das mit dem selbstgefrickelten Frickler sein lassen und Beispiele von CodePen einbetten?
Das löst die Vandalismus-Problematik auch nicht, genauso wenig wie ein Sichtungs-Mechanismus.
Bei einem Sichtungs-Mechanismus muss ein Admin drüberschauen und die Änderungen akeptieren oder entsprechend den Richtlinien anpassen - das ist in etwa der gleiche Aufwand wie die Änderung im Beispiel-Code zu registrieren und mit dem statischen Beispiel zu synchronisieren. Und manche bekannte Autoren würden eben ein automatisches-Sichtungsrecht bekommen, was im Moment dem Beispiel-Admin-Status gleichkommt.
Bei CodePen-Einbettungen muss die manuelle Überprüfung genauso stattfinden. Gleichzeitig setzen wir dabei auf einen externen Dienst, dem sowohl unsere Nutzer (externer Seitenzugriff) als auch wir (keine Kontrolle über Verfügbarkeit) als auch unsere Autoren (Rechteabtretung nicht nur an uns, sondern auch an Codepen) vertrauen müssen und können nur dann Vandalismus verhindern wenn ein zusätzlicher Sichtungs-Mechanismus greift, der wieder wie gesagt keinen Vorteil zur bisherigen Lösung bietet.
Wenn man das mit CodePen vs. Frickle mal außen vor lässt (und ich glaube zu spüren, dass es dabei vor allem darum ging, einen Nebenkriegsschauplatz zu eröffnen - nix für ungut) reduziert sich die Frage also auf Sichtungsmechanismus vs. bisherige Lösung und da gibt es aus meiner Sicht keinerlei Blumentöpfe zu gewinnen.
Grüße,
RIDER
-
@@Camping_RIDER
Gründe dafür, das nicht noch offener zu handhaben hat @Matthias Apsel schon genannt.
Und dass das allerhöchstens die zweitbeste Lösung ist, hatte ich schon gesagt.
Andererseits ist es so, dass gewisse fleißige Heinzelmännchen sowieso ein Auge auf die Änderungshistorie der Artikel haben und im Zweifel (oder spätestens dann, wenn man ihnen eine Notiz hinterlässt) die Änderungen im Beispiel-Code auch ins statische Beispiel übertragen. Gerade bei gelegentlichen Änderungen durch Einmal-Bearbeiter ist das ein gut funktionierender Mechanismus.
Von „gut funktionierend“ ist der Mechanismus weit entfernt (zumal es kein „Mechanismus“ ist), denn das wird einem so nicht vermittelt. Das heißt, ich hätte meine Änderung einfach machen und darauf vertrauen sollen, dass ein Berechtigter die Änderung zeitnah(!!) ins Beispiel übernimmt‽ Woher soll man’s wissen?
Vielleicht sollte man das mit dem selbstgefrickelten Frickler sein lassen und Beispiele von CodePen einbetten?
Das löst die Vandalismus-Problematik auch nicht, genauso wenig wie ein Sichtungs-Mechanismus.
?? Was hat das speziell mit den Beispielcodes zu tun? Die Problematik besteht auch allgemein für die Texte im Wiki.
Bei CodePen-Einbettungen muss die manuelle Überprüfung genauso stattfinden. Gleichzeitig setzen wir dabei auf einen externen Dienst, dem sowohl unsere Nutzer (externer Seitenzugriff) als auch wir (keine Kontrolle über Verfügbarkeit) als auch unsere Autoren (Rechteabtretung nicht nur an uns, sondern auch an Codepen) vertrauen müssen
Ja, man begibt sich in eine Abhängigkeit. Was, wenn CodePen morgen ankündigt, übermorgen dicht zu machen?
Vorteil wäre: fremder Code läuft in einer Sandbox, CodePen hat sich darum schon gekümmert.
und ich glaube zu spüren, dass es dabei vor allem darum ging, einen Nebenkriegsschauplatz zu eröffnen - nix für ungut
Bullshit.
LLAP 🖖
--
“When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory-
Aloha ;)
Andererseits ist es so, dass gewisse fleißige Heinzelmännchen sowieso ein Auge auf die Änderungshistorie der Artikel haben und im Zweifel (oder spätestens dann, wenn man ihnen eine Notiz hinterlässt) die Änderungen im Beispiel-Code auch ins statische Beispiel übertragen. Gerade bei gelegentlichen Änderungen durch Einmal-Bearbeiter ist das ein gut funktionierender Mechanismus.
Von „gut funktionierend“ ist der Mechanismus weit entfernt (zumal es kein „Mechanismus“ ist), denn das wird einem so nicht vermittelt. Das heißt, ich hätte meine Änderung einfach machen und darauf vertrauen sollen, dass ein Berechtigter die Änderung zeitnah(!!) ins Beispiel übernimmt‽ Woher soll man’s wissen?
Da hast du Recht; das sollte besser kommuniziert werden, um Autoren mehr Sicherheit zu geben. Vielleicht kann auf die Editierungs-Seite ein entsprechender Hinweis?
Vielleicht sollte man das mit dem selbstgefrickelten Frickler sein lassen und Beispiele von CodePen einbetten?
Das löst die Vandalismus-Problematik auch nicht, genauso wenig wie ein Sichtungs-Mechanismus.
?? Was hat das mit den Beispielcodes zu tun? Die Problematik besteht auch für die Texte im Wiki.
Nein. Die Problematik besteht für die Texte im Wiki weniger, da Vandalismus auf statischen Beispiel-Seiten größere Auswirkungen hat als auf Wiki-Seiten, die durch die Wiki-Software gehen. Für die Texte im Wiki (und das, was im BeispielCode steht) hat ein Vandalismus so wenig schlimme Folgen, dass es (beim aktuellen Umfang an Änderungen) ausreicht, Vandalismus zu reparieren statt präventiv dagegen vorzugehen. Für die statischen Beispielseiten gilt das nicht im gleichen Maße.
Bei CodePen-Einbettungen muss die manuelle Überprüfung genauso stattfinden. Gleichzeitig setzen wir dabei auf einen externen Dienst, dem sowohl unsere Nutzer (externer Seitenzugriff) als auch wir (keine Kontrolle über Verfügbarkeit) als auch unsere Autoren (Rechteabtretung nicht nur an uns, sondern auch an Codepen) vertrauen müssen
Ja, man begibt sich in eine Abhängigkeit. Was wenn CodePen morgen ankündigt, übermorgen dicht zu machen?
Ich halte die anderen beiden Argumente, die ich beispielhaft gebracht habe, für stärker, aber ja.
Vorteil wäre: fremder Code läuft in einer Sandbox, CodePen hat sich darum schon gekümmert.
Auch wenn du Recht hast - inwiefern ist das ein Vorteil gegenüber der bisherigen Lösung, die durch manuelle Kontrolle durch ausgewählte Benutzer auch verhindert, dass schädliche Inhalte ausgeführt werden?
und ich glaube zu spüren, dass es dabei vor allem darum ging, einen Nebenkriegsschauplatz zu eröffnen - nix für ungut
Bullshit.
Naja. Ich sehe die Eigenschaften, die CodePen (einfach so) als Alternative zum bisherigen Mechanismus auszeichnet, nicht. CodePen lässt sich vielleicht als Alternative zu frickle handeln, aber eine Verwendung von CodePen löst die Probleme, die dazu führen, dass statische Beispielseiten im Moment nur eingeschränkt bearbeitbar sind, nicht, und ist demnach dazu auch keine echte Alternative - wenn-dann müsste man hier über einen Sichtungsmechanismus als Alternative nachdenken, gerne auch zusätzlich zum CodePen-Vorschlag, aber CodePen alleine löst gar nichts. Deshalb meine Vermutung eines Nebenkriegsschauplatz von frickle vs. CodePen. Selbst wenn die Unterstellung vielleicht nicht zutrifft bleibt trotzdem das Problem, dass CodePen alleine keine ausreichende Alternative darstellt.
Grüße,
RIDER
-
Tach!
Vielleicht sollte man das mit dem selbstgefrickelten Frickler sein lassen und Beispiele von CodePen einbetten?
Das löst die Vandalismus-Problematik auch nicht, genauso wenig wie ein Sichtungs-Mechanismus.
?? Was hat das speziell mit den Beispielcodes zu tun? Die Problematik besteht auch allgemein für die Texte im Wiki.
Wie ist das denn bei CodePen mit Änderungen? Wie bekommt man davon Wind, wenn dort jemand Änderungen vornimmt?
dedlfix.
-
Hallo dedlfix,
Wie ist das denn bei CodePen mit Änderungen? Wie bekommt man davon Wind, wenn dort jemand Änderungen vornimmt?
Man kann dort keine fremden Pens ändern, soweit ich weiß. Man kann sie forken.
Bis demnächst
Matthias--
Rosen sind rot.-
Tach!
Wie ist das denn bei CodePen mit Änderungen? Wie bekommt man davon Wind, wenn dort jemand Änderungen vornimmt?
Man kann dort keine fremden Pens ändern, soweit ich weiß. Man kann sie forken.
Und wie gehts dann weiter? Der Autor muss dann im Wiki den Link ändern?
Wie kann man sicherstellen, dass dort derselbe Inhalt zu sehen ist, wie im Wiki erklärt wird?
dedlfix.
-
Aloha ;)
Man kann dort keine fremden Pens ändern, soweit ich weiß. Man kann sie forken.
Und wie gehts dann weiter? Der Autor muss dann im Wiki den Link ändern?
Ja. Siehe auch meine Antwort.
Wie kann man sicherstellen, dass dort derselbe Inhalt zu sehen ist, wie im Wiki erklärt wird?
Sicher-sicherstellen? Gar nicht. Das ist ja mit mein Problem.
Grüße,
RIDER
-
-
Aloha ;)
Wie ist das denn bei CodePen mit Änderungen? Wie bekommt man davon Wind, wenn dort jemand Änderungen vornimmt?
Man kann dort keine fremden Pens ändern, soweit ich weiß. Man kann sie forken.
Was dann in der Folge bedeutet, dass man den Link eines veränderten Beispiels auf den Fork umbiegen muss, wobei dann ein Admin, der vorbeikommt, um die Änderung zu prüfen…
- den alten Pen aus der Versionshistorie im Wiki herauslesen und öffnen muss
- den neuen Pen öffnen muss
- manuell prüfen muss ob ausschließlich das geändert wurde, was auch im BeispielCode geändert wurde
und bei Pens, die von angemeldeten Usern erstellt wurden, ist die Sache aus Wiki-Sicht noch schlimmer, weil der Pen afaik ohne Veränderung der URL verändert werden kann, es kann also (durch den Autor, der ja wiederum jeder sein kann) unbemerkbar Vandalismus betrieben werden oder unerwünschte Änderungen am Beispiel vorgenommen werden.
Grüße,
RIDER
-
Hallo Camping_RIDER,
Wir hatten die Diskussion über CodePen vor einiger Zeit geführt. Ich möchte sie ruhen lassen.
Bis demnächst
Matthias--
Rosen sind rot.-
Aloha ;)
Wir hatten die Diskussion über CodePen vor einiger Zeit geführt. Ich möchte sie ruhen lassen.
Full ACK.
Grüße,
RIDER
-
-
-
@@dedlfix
Wie ist das denn bei CodePen mit Änderungen? Wie bekommt man davon Wind, wenn dort jemand Änderungen vornimmt?
Nicht. Man müsste darauf vertrauen, dass der Autor des Pens den Inhalt passend zum Wiki-Artikel belässt.
Oder einen Nutzer SELFHTML anlegen, unter diesem den Pen forken und diesen Fork im Wiki einbinden.
Jemand, der am Artikel arbeitet und das Beispiel bearbeiten will, forkt das Beispiel und ändert den Link im Wiki. Davon bekommt man Wind. Wenn die Änderungen sinnvoll sind, kann der Nutzer „SELFHTML“ diese Variante forken wieder und im Wiki einbetten.
Ich will nicht sagen, dass das eine optimale Lösung wäre …
Aber Plattformen wie CodePen haben einige Probleme halt schon gelöst (Behandlung von fremden JavaScript-Code; Darstellung der HTML-, CSS- und JavaScript-Editoren und der Ausgabe, Einbindung von HTML- und CSS-Prozessoren sowie JavaScript-Bibliotheken, …)
LLAP 🖖
--
“When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
-
-
-
-
-
-
Hallo Gunnar Bittersmann,
Wie kann man den die Code-Beispiele bearbeiten?
Dazu muss man Beispiele-Administrator sein.
Bis demnächst
Matthias--
Rosen sind rot.
-
-
-
-
@@Matthias Scharwies
Man könnte einen kurzen Hinweis einfügen, dass das Setzen sehr kleiner Werte wie 0.1px oder 0.01em nicht dargestellt wird
Das ist falsch.
Auch bei kleinen Werten werden die Buchstaben auseinandergezogen, siehe Pen.
Bei 0.1px kommen bei „This type is set with letter-spacing“ (36 Zeichen) gegenüber keinem letter-spacing nur 3.6px Unterschied bis zum Doppelpunkt zustande; aber der Unterschied ist zu erkennen.
LLAP 🖖
--
“When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
-