Hilfe Diskussion:Tags

Extensionen?

Ist der eingedeutschte Begriff „Extensionen“ in der WP- bzw. allgemein der EDV-Welt üblich? Ich hätte dazu immer „Erweiterung“ gesagt, wenn ich schon nicht das englische Wort benutze … Gruß --Schniggendiller Diskussion 13:04, 22. Dez. 2012 (CET)

Ich hatte auch eine Weile gegrübelt, was ich hier damit mache.

• Der übliche Begriff und mw-amtliche Begriff ist ausschließlich extension – weil diese ausschließlich in englischer Sprache geschrieben.
• Eine freie Übersetzung als „Erweiterung“ wäre insoweit TF und würde den Transfer erschweren, wenn man dort auf mw:Manual:Extension gelangen soll.
• Es gibt in der IT-Welt eine ziemliche Ausdifferenzierung und Bedeutungsunterschiede je nach Produkt; ähnlich aber nicht unbedingt gleich sind „Add-On“ und „Plug-In“. Eine Einheitsübersetzung mit „Erweiterung“ wäre unscharf.
• Von „Extension“ im Singular kann ich guten Gewissens behaupten, dass das englisch sei. Nur beim Plural kommt es raus; steht wenigstens im Duden, obwohl da wohl eher an Haarteile gedacht wurde.

In jedem Fall setze ich gleich mal die deutsche Übersetzung dahinter.

Schönen Advent --PerfektesChaos 13:25, 22. Dez. 2012 (CET)

Okay, also kein Flüchtigkeitsfehler ;-) Guten Rutsch wünscht --Schniggendiller Diskussion 02:02, 25. Dez. 2012 (CET)

categorytree

Wie kann ich den langen durch categorytree angezeigten Baum bei mir verbergen? thx--Wheeke (Diskussion) 18:33, 27. Jan. 2013 (CET)

Eine eigene Hilfeseite „Kategorienbaum“ haben wir offenbar noch nicht. Ich kann also nichts anderes machen als dem angegebenen Link zu folgen.

Demnach gibt es etliche Parameter; depth="0" sieht nach einem passenden Startwert für dich aus. Da müsstest du mal selbst mit rumspielen; ich hoffe, dass du dann trotz depth="0" noch aufblättern kannst.

VG --PerfektesChaos 19:28, 27. Jan. 2013 (CET)

&­shy; Empfehlung geändert/aktualisiert.

Hallo,

ich habe die bisherige Empfehlung zu &­shy;

• ­ für ein weiches Trennzeichen ist im Allgemeinen unerwünscht; es verhindert Suchvorgänge und irritiert im Quelltext; nur wenige Autoren sind damit vertraut.
  • Ausnahmsweise kann es angewendet werden, wenn bei begrenztem Raum (Bildlegende, Tabellenzelle) einzelne lange Wörter unangemessen über die Grenzen ragen.

geändert in:

• ­ für ein weiches Trennzeichen. Es sollte sparsam im Fließtext eingesetzt werden.
  • Ausnahmsweise kann es angewendet werden, wenn einzelne lange Wörter nicht automatisch umgebrochen werden, sie z. B. bei begrenztem Raum (Bildlegende, Tabellenzelle) unangemessen über die Grenzen ragen.
  • Um Unklarheiten bei der Verlinkung von Wortteilen zu vermeiden, sollte ­ als unsichtbarer Trenner eingefügt werden.

Grund: Die Aussage war zum einen unbelegt ("irritiert", tut   oder jedes andere html oder wiki Tag das denn weniger?), und zum anderen veraltet (stört Suchfunktion, obsolet bei aktuellen Browsern).

LG --Richard (Diskussion) 12:14, 31. Mär. 2014 (CEST)

Es stört unsere hauseigenen Suchfunktionen im Wikitext auf dem Server; das hat nichts mit irgendwelchen Browsern zu tun. Unsere eigene Suche findet das zusammenhängende Wort nicht; und der Wikiautor, der im Quelltext mit der Suchfunktion nach einem markierten Wort sucht, findet es ebenfalls nicht mehr.

Es gab auch 2006 schon mal Editwars um nbsp, und es gibt bis heute Autoren, die konsequent alle nbsp aus ihren Artikeln entfernen.

Es hat schon seinen Grund, warum hier davon abgeraten wird.

VG --PerfektesChaos 12:23, 31. Mär. 2014 (CEST)

Dann bitte

* entweder die hauseigene Suchfunktion anpassen (Einzeiler, btw. ich bin Informatiker). Nachtrag: das ist sogar Pflicht, weil sie auch nach der alten Regelung in allen Infoboxen mit knappen Raum und langen Worten scheitern wird.

* der MediaWiki-Software ordentliche Worttrennungen beibringen. Sobald dies geschehen sein sollte, ist es wiederum mit einem kleinen Skript möglich, alle dann offenkundig überflüssigen shy Tags zu entfernen (d.h. nicht alle). LG --Richard (Diskussion) 12:29, 31. Mär. 2014 (CEST)

Fein; dann darf ich dich auf Wikipedia:Verbesserungsvorschläge/Feature-Requests bitten; bis das umgesetzt ist, bliebe es so, wie es bisher war.

Mit den Autoren, die Entities im Quelltext nicht haben wollen, müsstest du dich separat auseinandersetzen. Nur weil du als IT-Profi kein Problem mit ­ hast, kannst du ihnen das nicht vorschreiben. Ich hätte auch kein Problem damit und lese seit 1995 HTML als Queltext, noch bevor es Editoren gab; wir beide sind aber hier nicht der Maßstab für alle Autoren.

Infoboxen bilden Tabellenzellen; diese waren wie auch Bildlegenden bereits ausdrücklich im Bedarfsfall freigegeben.

Nicht verstanden hast du offenbar: Wenn man ein seltenes Wort in der Seitenvorschau markiert und dann (im FF etwa nur ein Klick) das seltene Wort oder die einmalige Wortgruppe im Bearbeitungsmodus sucht, findet man sie im Bearbeitungsfeld an der richtigen Stelle im Quelltext. Wenn dort jedoch ein Entity wie ­ im Wort steht, scheitert dies.

VG --PerfektesChaos 12:40, 31. Mär. 2014 (CEST)

Die alte Empfehlung ist sowieso widersinnig, da sie das shy tag auch bei einigen Trennungen (z. B. Amphetamin­missbrauch Amphetamin&­shy;missbrauch) nötig ist. Die Alternative Amphetamin<­nowiki />missbrauch zu schreiben macht es auch nicht schöner, und ist auch nicht die gängige Praxis.

Setze es gerne auf Wikipedia:Verbesserungsvorschläge/Feature-Requests, aber es wird wie gesagt bereits verwendet, und bringt auch nicht mehr Probleme als &­nbsp; mit sich. Daher kein Grund den alten Stand wieder in Kraft zu setzen. LG --Richard (Diskussion) 12:50, 31. Mär. 2014 (CEST)

• Du vergisst, dass der Wikitext nicht nur von Software und IT-Profis gelesen und verstanden werden muss, sondern auch noch von Laienautoren.
• Es steht dir schlicht und ergreifend nicht zu, einen über ein Jahrzehnt gewachsenen Konsens hier eigenmächtig nach deinen Vorstellungen als IT-Profi umzuwerfen und als Richtlinie für alle Artikel Modernität zu oktroyieren, und alle anderen haben das jetzt gefälligst auch noch zu verstehen.
• In der Vorlagenprogrammierung wenden wir HTML-Konstrukte und viel wildere Sachen an; in Artikeln beschränken wir uns in der Syntaxkomplexität und in der Zahl verschiedener Elemente auf das unbedingt Nötige – zumindest was den allgemeinen inhaltlichen Textfluss angeht.
• Im vorliegenden Einzelfall hätte ich nichts dagegen, eine besondere Umbruchsituation einstweilen mal so zu lösen, und wenn sich niemand darüber beschwert (hatte aber wohl doch), dann mag das so sein. Mit deinen umseitigen Änderungen hier erklärst du aber alle und alles für veraltet und deine Sichtweise als IT-Profi zum Maßstab für die Artikel und alle anderen Autoren.
• Diese Seite hat in gewissem Sinn auch eine Art Richtliniencharakter; du hast da vielleicht nicht so ganz den Überblick, was in der Community der Autoren so eingeschätzt wird.
• Es ist auch völlig belanglos, dass du alles auf irgendeine so nicht implementierte Software schiebst; wenn die MediaWiki-Software anders programmiert wäre, und wenn die Suchalgorithmen anders programmiert wären, und wenn man alles nochmal von vorne beginnen würde, und wenn die Menschen andere Menschen wären. Wenn überhaupt, dann ist es die Unfähigkeit (Zitat: „Dysfunktionalität“) der Browser, dass sie bei dem Konstrukt …zit-/Hyp… nicht nach dem Schrägstrich von sich aus einen Zeilenumbruch machen, oder überhaupt von sich aus Worttrennung vornehmen; und zwar auf allen Webseiten. Geh hin und schreib bessere Browser.

VG --PerfektesChaos 19:59, 9. Apr. 2014 (CEST)

PerfektesChaos passt gut zu Dir, denn offenbar bringst Du das was ich geändert habe durcheinander. Ich habe nicht meine ursprüngliche weitergehende Änderung wiederhergestellt, und nichts ergänzt, was nicht schon vorher Richtliniencharakter hatte. Wie wäre es, wenn Du zunächst durch schlichtes Ausprobieren feststellst, dass wbr nicht in jedem Fall durch shy ersetzt werden kann (- und dann shy verglichen mit - und dann wbr), ich also schlicht einen Fakt eingefügt habe, Du dann erst einmal die Seite WP:VL#Verlinkung_von_Teilwörtern besuchst, und feststellst, dass es längstens Konsens ist, shy für selten aber manchmal benötigte Wort­trennungen (vgl. Worttrennungen und Worttrennungen) einzusetzen, und Du mir bitte nicht vorwirfst einen edit-war zu führen, nur weil Du im perfekten Chaos lebst. Es steht Dir schlicht nicht zu, Deine Meinung über Fakten zu stellen. VG --Richard (Diskussion) 21:39, 9. Apr. 2014 (CEST)

Aktuell findet eine Diskussion zur Verlinkung von Teilwörtern mit ­ statt, diese bitte abwarten. LG --Richard (Diskussion) 23:59, 9. Apr. 2014 (CEST)

wbr Tag

Hallo,

das wbr Tag unter Unerwünschtes HTML zu führen ist bei derzeitigem Stand der MediaWiki-Software zu radikal. Wie bitte soll man das elend-lange Wort Aufmerksamkeitsdefizit-/Hyperaktivitätsstörung nach der sich anbietenden Stelle "-/" umbrechen? Auch die automatische Trennung nach "defizit-" klappt üblicherweise nicht. Die genannte Alternative shy ist unbrauchbar, weil sie einen zweiten Bindestrich einführt.

LG --Richard (Diskussion) 12:42, 31. Mär. 2014 (CEST)

Siehe eins drüber. Weil unsere Autoren auch gerne noch verstehen möchten, was für ein IT-technisches Kuddelmuddel in die Wikitexte eingeschmuggelt wird; und von <wbr /> hat bislang weniger als jeder 1000. Wiki-Autor irgendwas gehört oder könnte es zuordnen.

Wenn du schon so scharf und stolz auf fortgeschrittene Browser-Technologie bist: Warum macht der Webbrowser sich die Worttrennung nicht gleich selber, wenn er sich an langen Wörtern stört? Das kann er ja gleich auf allen Webseiten so darstellen.

Und wie wäre es mal mit einem sprachlichen Feinschliff statt IT-Kryptik? Aufmerksamkeitsdefizit- und Hyperaktivitätsstörung wäre ein sprachlich eleganteres Lemma; als Weiterleitung allemal geeignet und ist längst eine. Sollte man glatt mit dem Lemma tauschen.

Und der Einbau von Trennzeichen füht zum Syntaxbruch:

• [[Aufmerksamkeitsdefizit-/<wbr />Hyperaktivitätsstörung]] → [[Aufmerksamkeitsdefizit-/Hyperaktivitätsstörung]]
• [[Aufmerksamkeitsdefizit-/­Hyperaktivitätsstörung]] → Aufmerksamkeitsdefizit-/­Hyperaktivitätsstörung

VG --PerfektesChaos 12:52, 31. Mär. 2014 (CEST)

Das und statt -/ wäre vor allem falsch, weder ist es die Fachbezeichnung, noch gäbe es die Bedeutung "und bzw. oder" wieder. Der Einbau von Trennzeichen führt nie zu Problemen, wenn man es auf die übliche Weise tut <code>[[Aufmerksamkeitsdefizit-/Hyperaktivitätsstörung|Aufmerksamkeitsdefizit-/<wbr />Hyperaktivitätsstörung]]</code>.

Die Wikitexte strotzen vor html und anderen Anfängerhürden (das könnte einfacher sein, wenn man alles nochmal von neuem startet, sprich die komplette Software austauscht...), das ist ein grundsätzliches Problem. Wer sich davon nicht abschrecken lässt, kommt auch mit dem wbr Tag klar (Suchmaschinen sind ein Freund).

Was Browser könnten und was sie dürfen um im Standard zu bleiben sind zwei verschiedene Aspekte. LG --Richard (Diskussion) 13:04, 31. Mär. 2014 (CEST)

Vielleicht bin ich schon übermüdet, aber ich kann die Sinnhaftigkeit des wbr-Tag innerhalb von wikitext echt nicht erkennen. Frohes Schaffen — Boshomi ☕⌨☺  23:32, 9. Apr. 2014 (CEST)

Ist wohl Übermüdung, Du hast bei Deinem revert ja nichts an der Platzierung unter Unerwünschtes HTML geändert, und dafür Kollateralschaden angerichtet. Zur Sinnhaftigkeit siehe oben. --Richard (Diskussion) 23:52, 9. Apr. 2014 (CEST)

Das wbr-Tag als Standard zu erwähnen ist Unfug. Wikitext != html. Dass die Eingabe nullbreiter Zeichen und Softhyphen kompliziert ist, ist eigentlich auch ganz gut so, denn wirklich erwünscht sind diese Zeichen auch nicht. Das Übersetzen von wikitext nach HTML überlassen wir der Mediawiki-Software. HTML5-Syntax ist für Mediawiki nicht ganz irrelevant, aber doch recht unwichtig.  Frohes Schaffen — Boshomi ☕⌨☺  12:32, 10. Apr. 2014 (CEST)

Hi, ist mir letztlich auch egal, ob in den wenigen Spezialfällen ein nullbreites Leerzeichen oder das wbr-Tag eingesetzt wird, solange nicht alle Lösungen verbaut sind. Das Ausgangsproblem war, dass das Beispielwort auch in (je nach Gerät) mehr oder minder schmalen Tabellenspalten o. ä. vorkommt. Dann ist es ziemlich doof, wenn alle Lösungen verbaut sind. Ich hatte lediglich vorgeschlagen, es nicht radikal als unerwünschtes html zu bezeichnen, aber zu keiner Zeit diesen Zustand geändert. Warum dennoch die Änderungen, dass es nicht immer durch shy ersetzt werden kann, sowie dass es nicht deprecated ist, mehrfach revertiert wurden, bleibt mir ein Rätsel. Diese Punkte waren völlig unabhängig von der Frage unerwünscht ja/nein, und schlicht kleine Fehlerkorrekturen.

Beim gleichzeitigen Löschen der Empfehlung zu Teilwortverlinkung verstehe ich auch die Motivation nicht, welcher vernünftige Grund rechtfertigt es, andere Empfehlungen zur shy Verwendung zu verschweigen? Inkonsistenzen führen zu unnötigen Problemen, weil nicht jeder jede Hilfe und WP Seite kennt. Ich habe umgekehrt auch kein Problem damit, den Verweis auf V unter Hilfe:Tags wieder zu streichen, falls die Empfehlung auf V geändert wird.

Es war mein Fehler, dass ich bei Version 129373684 das nullbreite Leerzeichen nicht ergänzt habe. Den Fehler hätte ich sicher nicht begangen, wenn die Vorversion nicht alle Fehlerkorrekturen sowie den Verweis auf den status quo zur Teilwortverlinkung beseitigt hätte.

Ich wünsche uns allen mehr Bedenkzeit vor reverts, und ebenso frohes Schaffen! LG --Richard (Diskussion) 23:09, 10. Apr. 2014 (CEST)

PS: Da Du während ich dies schrieb genau die gleichen Fehler wiederholt hast, denke bitte darüber nach und nimm Deinen revert zurück. Dem fehlt schlicht die Sachgrundlage. --Richard (Diskussion) 23:09, 10. Apr. 2014 (CEST)

Ein "Siehe auch „[[WP:V#Verlinkung von Teilwörtern|Verlinkung von Teilwörtern]]”." würde als Ergänzung bei shy auch reichen. Ändere gerne Version 129381238 dementsprechend ab. --Richard (Diskussion) 23:26, 10. Apr. 2014 (CEST)

Mit dem wbr-Tag wird ein Problem gelöst, dass hier nicht existiert. Für die Kennzeichnung von Umbrüchen innerhalb langer Worte existiert das Softhyphenzeichen, für Umbrüche an Wortgrenzen ohne Sonderzeichen das nullbreite Leerzeichen (für ganz wenige Fällen wo man kein Trennzeichen bei Zeilenumbruch sehen will). Bleibt als Hauptanwendungsgebiet des wbr-Tags die Aushebelung normaler Wikitextsyntax. Das Softhyphenzeichen macht gelegentlich innerhalb von Tabellen Sinn, das nullbreite Leerzeichen bei langen Zeichenketten, die der Browser nicht von alleine umbrechen kann. Für Zweiteres gibt es nur sehr wenige Anwendungsfälle innerhalb von Wikipedia. Für das wbr-Tag fällt mir beim besten Willen keine einzige Seite ein, wo das eine Verbesserung bringen würde. Frohes Schaffen — Boshomi ☕⌨☺  22:14, 11. Apr. 2014 (CEST)

Nur mal so zur Info über die Geschichte des wbr-Tags: Dieses Tag wurde 1995 mit dem Netscape Navigator 1.1 als proprietäre Erweiterung zu HTML 2.0 eingeführt, und zwar zusammen mit dem nobr-Tag (Dokumentation). Es war so gedacht, dass man mit nobr einen Bereich umschließt, in dem keine automatischen Zeilenumbrüche stattfinden sollen und innerhalb dieses Bereichs mit wbr Stellen markiert, an denen doch Zeilenumbrüche stattfinden können.

Beispiel:

<nobr>bla bla bla<wbr>blubb blubb blubb</nobr>

Um mit dem damals marktführenden Netscape-Browser kompatibel zu sein, haben die anderen Browser diese Tags ebenfalls implementiert, obwohl sie beide nicht standardisiert wurden, weil man recht schnell erkannt hat, dass solche Darstellungsfragen besser nicht durch Tags, sondern durch CSS (white-space:nowrap) und spezielle Unicode-Zeichen (​) kodiert werden.

Ca. 15 Jahre später hat Microsoft erkannt, dass Webstandards wichtig sind und deshalb dem Internet Explorer 8 eine völlig neue Rendering-Engine spendiert, in der das wbr-Tag nicht mehr unterstützt wird, weil es ja nicht standardkonform ist. Ungefähr zur gleichen Zeit (oder vielleicht ganz kurz davor, müsste man recherchieren) wurde das Tag in HTML5 aus mir unerfindlichen Gründen erstmals standardisiert, weil es ja in allen Browsern funktioniert (den IE 8 hat man dabei wohl übersehen, oder es gab ihn noch nicht).

Festzuhalten bleibt jedenfalls, dass das wbr-Tag im Internet Explorer seit Version 8 nicht mehr funktioniert und dass das Unicode-Zeichen ​ im Wesentlichen dasselbe leistet und in allen Browsern funktioniert. Meiner Meinung nach hätte wbr deshalb in MediaWiki nicht freigegeben werden sollen; jedenfalls sehe ich keinen Grund, es zu benutzen. Gruß --Entlinkt (Diskussion) 22:39, 11. Apr. 2014 (CEST)

+1 (Anmerkung zur Allgemeinverständlichkeit: Das spezielle Unicode-Zeichen (​) heißt „ZERO WIDTH SPACE“ auf deutsch „Breitenloses Leerzeichen“ ) Frohes Schaffen — Boshomi ☕⌨☺  23:30, 11. Apr. 2014 (CEST)

Unter Gerrit:132750 gibt es einen CSS-Fix, der noch nicht live ist, aber sehr bald live gehen sollte und dazu führt, dass das <wbr>-Element auch in aktuellen Internet-Explorer-Versionen (also dann in allen Browsern) funktioniert.

Unter diesen Voraussetzungen sehe ich ehrlich gesagt keinen Grund mehr, <wbr> als unerwünscht anzusehen. Es ist gleichwertig zu ​, aber im Quelltext tendenziell einprägsamer und leichter verständlich.

In jedem Fall muss die Darstellung auf der Vorderseite korrigiert werden, denn dort steht, ­ wäre ein Ersatz für <wbr>, was nicht stimmt. ­ erzeugt an der Umbruchstelle einen Bindestrich, aber ​ und <wbr> tun dies nicht. --Entlinkt (Diskussion) 03:23, 11. Mai 2014 (CEST)

HTML5 zweierlei Maß

(Auch wenn ich schon sehr müde bin.) Nach der letzten Änderung verstehe ich die Seite nicht mehr ganz. „HTML5 schnurzpiepegal…; in der Wiki-Welt wird das noch zehn Jahre leben…“ Zum einen werden tags, die in HTML5 deprecated aber auch tags die empfohlen sind, hier als unerwünscht deklariert. Zum anderen wird ein Hinweis zum sehr naheliegendem WP:HTML5 enfternt. So benutzt z.B. die "Standardwerkzeugleiste" ein tag (big) dass hier unerwünscht ist (entgegen tt).
@center: Auch hier habe ich schon mal meinen Umnut darüber geäußert. Wenn man so argumentiert ist die Verbannung des center-tags ebenfalls absurd, denn es ist seit mehr als 15 Jahren deprecated und erfreut sich trotzdem (wie font) noch ungetrügter Beliebtheit (entgegen allen Widerstands, das nenne ich durchgesetzt). Die Vorlage:Center (welche es hier seit rund einer Woche gibt) verdeutlicht noch einmal die Absurdität, denn diese soll angeblich das tag ersetzen, nur kennt diese keiner und die Verwendung ist wesentlich problematischer (vor allem für den Wikiparser, z.B. verträgt der Parameter kein Pipe-Zeichen).

Daher frage ich mich woher die Grundlage bzw. Kenntniss für diese Sichtweise kommt? Ungeachtet dessen habe ich vor der Leistung von PerfektesChaos hier generell natürlich größten Respekt. ↔ User: Perhelion 01:55, 10. Nov. 2014 (CET)

• Ob in HTML5 irgendwas deprecated sei oder nicht, ist erstmal völlig egal.
  • Browser werden trotz HML5 auch weiterhin Dokumente aus 1995 in HTML2 korrekt darstellen.
  • Die durch deprecated implizierte Aufforderung zielt an Programmierer, die dokumentengenerierende Software zukünftig so zu schreiben, dass sie die überholten tags vermeiden. Das wirkt sich aber allenfalls auf zukünftig generierte Dokumente aus. Vorhandene Dokumente sind überhaupt nicht betroffen.
  • Unsere Wikitexte werden jedoch nicht von Software geschrieben, sondern von Menschen mit begrenzter Lernkapazität für technische Finessen.
• Die Autoren haben kein Interesse an diesem Zeug.
  • Sie wollen ihre Artikel so schreiben, wie sie das 2005 mal mühsam gelernt hatten, und das für immer.
  • Wenn tags bequem und intuitiv sind, dann werden sie auch gnadenlos eingesetzt; wurscht was auf dieser Hilfeseite steht.
  • Wir können nur über viele Jahre hinweg mittels Verbreitung der vorbildlichen aktuellen Lösungen und unter der nachwachsenden Autorengeneration eine allmähliche Abkehr von alter Syntax bewirken, die immer seltener in den Artikeln vorkommt.
• Ziel ist es, ohne überflüssige und unbekannte tags auszukommen und sich auf eine überschaubare Anzahl tatsächlich benötigter tags zu beschränken, die man sich dann auch gut merken kann und die die Mit-Autoren wiedererkennen. Soweit möglich, sollten die dann auch per HTML5 zukunftssicher sein.
• Zu den tags im einzelnen:
  • <tt> ist zurzeit nicht ersetzbar, da <code> einen weißen Hintergrund und Rahmen hat und bei Verlinkungen verbirgt, dass es sich um ein Link handelt.
    • Sollten irgendwann die Browser <tt> tatsächlich nicht mehr verstehen, kann die MediaWiki-Software jedes <tt> nach außen in ein <span> umwandeln und für monospace sorgen. Das Element <pre> wurde schon längst in gleicher Weise gekapert und ist nicht mehr HTML-Element, sondern MW-Tag. Desgleichen <source> (was allerdings von vornherein eine Eselei war).
    • Wenn HTML5 das <tt> nicht mehr gefällt, sie aber keinen menschenzumutbaren Ersatz anbieten, dann bleiben wir eben dabei. Bzw. der HTML5-Ersatz wäre <code> und ist hier international dauerhaft anders belegt.
    • Kurzum: <tt> bleibt.
  • <font> ist eine der ekligsten Altlasten, weil das auch noch eine spezielle Parameter-Syntax hat, die inkompatibel mit CSS ist. Bloß weg damit. Meist ist es nur size=+/-1, was soviel meint wie big oder small. Wie genau SIZE= in % umzurechnen ist, weiß der Geier. Es gibt wohl noch 4000 Artikel, werden aber allmählich weniger. Ein vermeidbarer Exot, mit dem keiner der Nachkommen mehr etwas anfangen kann.
  • <big> und <center> sind intuitiv und haben keine Parameter. <big> ist im Quelltext von Artikeln vermeidbar; Vorlagenprogrammierern ist <span> zuzumuten. Kommt in rund 2000 Artikeln vor. <center> kommt wahrscheinlich in 100.000 Artikeln vor und wird da noch lange Zeit bleiben, obwohl mit class günstiger Ersatz geschaffen wurde. Das dauert eben etliche Jahre, bis sich das durchsetzt. Wir können nur den Neuzugang etwas eindämmen.
  • Zu <samp> gibt es keinerlei Spezifikation, wie das gerendert werden soll, lediglich eine semantische Feststellung, dass es sich bei dem, was es einschließt, um ein Beispiel handelt.
• Wir haben auch noch 38.497 prettytable im ANR. Die drücken unsere Performance viel mehr, weil wir dafür auch noch gesonderten style in jeder Seite einbinden müssen.
• Die Vorlage:Center halte ich aufgrund der Pipe-Problematik auch für bedenklich. Ich habe ihr jedoch zur Ersten Hilfe gegen Gleichheitszeichen die Kopiervorlage verbessert. Tabellen damit einzuschließen, wie das suggeriert wurde, ist hingegen völliger Quatsch, und gerade bei Tabellen tut es ein class= in der ersten Zeile.
• Mit der Standardwerkzeugleiste müsstest du dich selbst auseinandersetzen und <big> dort rauskegeln.

Schöne Woche --PerfektesChaos 10:01, 10. Nov. 2014 (CET)

Ok, danke Dir der Erklärung. Du könntest ja noch das hier verlinken.

@Center: Ich habe mir die Verwendung kurz angesehen, so gut wie alle sind in einer weiteren Vorlage (über das deutsche Synonym). (Leider steht mit dem Ersteller Aka ein massiver Script-Benutzer dahinter. Ich jedenfalls werde entgegen die Vorlage überall entfernen wo ein class reicht)

@centered: Seltsamer Weise gibt es diese in En so nicht. Sollte man da ein Request stellen!?

Projekt HTML5: Wir sollten da nicht unterschiedliche Ansichten propagieren. Wie siehst du den Nutzen bzw. die Zukunft von diesem? Eigtl. macht es so oder so keinen wirklichen Sinn mehr wenn HTML5 egal ist.

Das gleiche wünsche ich auch ↔ User: Perhelion 11:18, 10. Nov. 2014 (CET) ↔ User: Perhelion 11:28, 10. Nov. 2014 (CET)

• Wie du den Bug voranbringst, musst du selbst wissen. Schnark hatte auf Komplettentfernung des Buttons gedrungen; abgewürgt wurde eine hässliche Realisierung, die span mit Attribut in den Quelltext gedrückt hätte.
  • Ich stimme 100 % mit Schnark überein, dass dieses tag im Quelltext völlig überflüssig ist; entweder man macht innerhalb der Vorlage arabische Schrift usw. grundsätzlich einen Hauch größer, oder man verwendet richtige Überschriften im Artikel, oder man kommt in der Vorlagenprogrammierung sowieso mit span und style aus.
• Zu dem Projekt sehe ich positiv, dass man sich mal Gedanken gemacht hatte.
  • Seinerzeit hatten bereits Schnark und ich heftig gegen das Arbeitsprogramm protestiert.
  • Insbesondere geht es von der völlig falschen Voraussetzung aus, wegen amtlicher Einführung von HTML5 müsse jetzt sofort jedes Wikiprojekt umgestellt werden.
  • Weiterhin sind völlig untaugliche Konvertierungsvorschläge 1:1 gemacht worden, der jeden alten Unsinn pixelgenau bewahrt hätte, statt schlicht zu sagen: Eine Schrift ist normal groß, oder kleiner, oder größer, fertig. Mehr braucht ein enzyklopädischer Artikel nicht, und noch nicht einmal größere Schrift.
  • Richtig ist an der Geschichte, dass perspektivisch alte tags und alte Attribute ausgedünnt und durch immer mehr positive Vorbilder und zukunftsfähige Konstrukte ersetzt werden sollen. Genau darauf wirkt die umseitige Hilfeseite hin. HTML5 ist also nicht „egal“, sondern beschreibt ein Fernziel.
  • Gaga ist wiederum die Vorstellung, man solle nun durch Botläufe alle Artikel umbauen.
  • Da dieses Projekt einem Hilfesuchenden keinen Nutzen bringt, sondern höchstens verwirren kann, möchte ich auch keine Verlinkung von der Hilfeseite aus.

LG --PerfektesChaos 12:20, 10. Nov. 2014 (CET)

Ich hatte die Vorlage nur 1:1 aus der englischen Wikipedia übernommen (en:Template:Center), da mich jemand im Zuge einer das-"center"-Tag-ist-böse-Diskussion darauf hingewiesen hatte, dass es diese dort und in vielen anderen Sprachversionen gibt. -- Gruß, aka 11:40, 10. Nov. 2014 (CET)

@aka: Das ist eine allgemeine Marotte der enWP, der ich kritisch gegenüberstehe. Die haben für sämtliche Tags auch Vorlagen drumrum, weshalb sie die Wikisyntax zweimal zum Auswendiglernen fordern: Einmal in der Grundversion und einmal hinter teilweise kryptischen Kurzbezeichnungen der Vorlagen verborgen.

• Hier bei center geht es so halbwegs, wobei sie in der fortgeschrittenen Vorlagenprogrammierung nichts zu suchen hat. In Artikeln würde ich sie überall bei zufälliger Gelegenheit eliminieren, wo ich einen kurzen Ersatz fände; etwa wenn um eine <gallery> gewickelt, in die ich genauso eine class="centered" schreiben kann.

LG --PerfektesChaos 12:02, 10. Nov. 2014 (CET)

br

Also bei allem Respekt das führt hier zu nichts, wer ist denn bitte für die Syntax der deutschen Wikipedia verantwortlich?[1] Falls man hier nichts darlegen kann, ist das alles offensichtlich eine persönliche Ansicht. (Ich kann hier nur vermuten, dass sich SyntaxTidy-Skriptbauer/nutzer eher etwas in ihrer Sinnhaftigkeit ihrer Tätigkeit im Bezug HTML4 zurück HTML5 in Frage gestellt fühlen). Also halten wir kurz fest, in deWP wird weiterhin das tot-gesagte XHTML propagiert. ↔ User: Perhelion 12:55, 12. Nov. 2014 (CET)

1. Es gibt eine seit zehn Jahren gefestigte und weitaus überwiegend umgesetzte Praxis, wie wir dieses Element notieren, und genau das ist auf der Hilfeseite beschrieben, und das haben auch Tausende von Leuten mühsam erlernt.
2. Dort wird sich auch große Mühe gegeben, den Unterschied zwischen einem Start-Tag (ohne einen Schrägstrich) und einem unary (Schrägstrich am Ende) zu erklären.
   • Und wenn man das nicht kapiert, ist man mit references aufgeschmissen.
   • Also muss auf ein öffnendes <br> immer ein schließendes </br> folgen.
3. Wikitext ist nicht HTML5.
   • Wikitext ist XML.
   • Merkt man übrigens schnell bei <source>, und auch <pre> ist in Wirklichkeit ein <nowiki> mit dem style analog zu einem pre.
4. Die Definitionen von HTML5 sind nicht direkt verbindlich für Wikitext; wo es angebracht ist, reichen wir sie gern durch.
5. Weil HTML5 irgendwas anders macht, müssen wir nicht Tausende von Autoren umerziehen zu einer komplizierten Ausnahmeregelung, die in diesem Projekt gerade mal ein Dutzend Techies begreifen.
6. Die Systematik war auch in HTML hoch umstritten; HTML5 beschreitet einen kuriosen Sonderweg und brät unnötig verkomplizierende Extrawürste. Es kann leicht passieren, dass HTML6 dann wieder zu 100 % XML zurückkehrt. Dann erziehen wir Tausende von Autoren zurück um?

VG --PerfektesChaos 13:22, 12. Nov. 2014 (CET)

Das hört sich nachvollziehbar und vernünftig an, entschuldige mein voreiliges Vorpreschen. Ein bisschen mehr Transparenz würde hier jedoch wirklich nicht schaden. Ich werde mit Sicherheit nicht der letzte sein der sich wundert. Eigentlich kann es mir ja egal sein, ich finde es persönlich nur befremdlich gegen das aktuelle HTML zu arbeiten/empfehlen (also explizit mit Scripten ausgetauscht wird gegen XHTML), daher sollte man da deutlicher werden, diesen vermeintlichen Widerspruch benennen. FG ↔ User: Perhelion 20:37, 13. Nov. 2014 (CET)

Das umseitig auseinanderzufieseln, würde die Hilfeseite sprengen, und die Nerds schaffen es auf die Disku.

HTML5 habe ich schon seit Jahren eingepreist, lange bevor die sich über das letzte Komma im Abschlussdokument einigen konnten. So arbeite ich dieser Tage mal wieder gegen <font> an, das vor allem mit dem unverständlichen Parameter face= wie auch der unvorhersagbaren Nicht-Prozent-size ein elender Restmüll ist. face= habe ich vermutlich aus den Artikeltexten eliminiert.

Ziel der Übung ist es, den Autoren für den ANR eine klare und logische Tag-Struktur anzubieten, die mit mögichst wenig Tag-Namen auskommt und trotzdem alle häufigen Fälle abdeckt; auf exotische unverständliche Tags jedoch verzichtet. Seitens HTML genügen für den ANR zwei Attribute; class style. Vorlagenprogrammierer brauchen noch id lang. Die restlichen Attribute sind Altlasten aus den 1990ern oder kommen aus MediaWiki. Entities halten wir auch knapp.

LG --PerfektesChaos 21:47, 13. Nov. 2014 (CET)

Als einfacher Bearbeiter möchte ich hier nochmal nachfragen, was denn jetzt die bevorzugte Variante ist. <br>, <br/> oder <br />? Alle Varianten begegnen mir regelmäßig und bunt gemischt in Artikeln. Ich frage auch, weil wenn man den Tag über den Button im Editor hinzufügt <br> eingefügt wird.--L.xschlag (Diskussion) 15:18, 15. Jul. 2022 (CEST)

Du wirst bei uns seit zwei Jahrzehnten weitaus überwiegend <br /> finden, und das ist auch die Zielvariante.

Unsere hiesige Sonderzeichenleiste fügt das auch in dieser Form ein.

Globale Werkzeuge mögen andere Notationen verwenden.

Alle Varianten und sogar syntaktisch falsche funktionieren erstmal; wir konvergieren aber recht einheitlich zu <br /> (was keinen besonderen Edit rechtfertigt, sondern nebenbei miterledigt werden mag).

VG --PerfektesChaos 15:37, 15. Jul. 2022 (CEST)

Zentriert

Unter Berufung auf diese Seite hat Benutzer:MitigationMeasure in diesem Artikelabschnitt den Tag „center“ in einer Kartenerläuterung herausgenommen. Da die Karte zentriert eingebunden ist, halte ich in diesem Fall auch die Zentrierung des Karten(Bild)textes nach wie vor für sinnvoll. Mit dem umseitig vorgeschlagenen Alternativtag class="centered" komme ich nicht klar. Ist bitte jemand so freundlich, das entsprechend einzubinden, sodass der Kartentext wieder zentriert erscheint? Danke und Gruß --Lienhard Schulz Post 10:05, 16. Nov. 2014 (CET)

Wenn du meinst, dass es ein ästhetischer Gewinn wäre, so habe ich das nunmehr umgesetzt.

Die Zentrierung des Gesamtbildes wurde durch den Bildparameter bewirkt; somit musste hier die Legende extra zentriert werden.

Persönlich würde ich das eher ncht zentrieren; vielleicht mal bei Gedichten oder Inschriften, aber weniger bei einem beschreibenden Sachtext. Das hat auch nichts damit zu tun, ob das Bild innerhalb der Seite links, rechts oder mittig steht.

VG --PerfektesChaos 12:59, 16. Nov. 2014 (CET)

Vielen Dank. Ja, in diesem (Ausnahme-)Fall finde ich die Zentrierung auch der Legende sehr passend. --Lienhard Schulz Post 13:29, 16. Nov. 2014 (CET)

Allerdings frage ich mich warum PC nicht sein universelles eigenes WSTM zur Anwendung gebracht hat?⁈ (z.B die Commons-Links kann man entfernen bzw. anders formatieren) ↔ User: Perhelion 16:41, 16. Nov. 2014 (CET)

Weil ich bewusst nur den angegebenen Abschnitt bearbeitet hatte, damit Lienhard für das „Alternativtag class="centered"“ ein überschaubares Beispiel-Diff bekommt. LG --PerfektesChaos 16:56, 16. Nov. 2014 (CET)

Trotzdem kurz die Frage, ob nicht dieses generell auf die Hilfeseite könnte: Es erleichtert die Arbeit und gerade bei den jetzt laufenden Aktionen kann das eigentlich nur hilfreich auch für andere sein (ich hatte es in dem Beispiel nämlich nicht hinbekommen und dann doch die Finger weggelassen). Grüße,--MitigationMeasure (Diskussion) 17:03, 16. Nov. 2014 (CET)

Was genau ist „dieses“?

Diese Hilfeseite ist eigentlich schon viel zu lang und behandelt 92 tags; dazu noch Entities. Es gibt unendlich viele Möglichkeiten, all das zusammen mit Attributen zu allem Möglichen zu kombinieren. Jetzt auch noch umfassende Code-Beispiele zur Wikitext-Formatierung anzubringen, würde sie völlig sprengen.

Probier es doch mal bei Hilfe:Textgestaltung – dort ist allerdings genau solch ein Beispiel in Hilfe:Textgestaltung #Formatierungen, die nicht in Wikipedia-Artikeln verwendet werden sollten aufgelistet und als unerwünscht deklariert.

Ganz allgemein wird in die Artikel viel zu viel optischer und nicht bedeutungstragender und nicht bedeutungsunterstützender Schnickschnack hineingepfriemelt, nur dem persönlichen Geschmack von Einzelpersonen folgend und das dann auch noch in einer nicht begriffenen Syntax.

LG --PerfektesChaos 17:19, 16. Nov. 2014 (CET)

┌─────────────────────┘
In diesem Bezug würde ich gerne wieder etwas ergänzen wollen, bzw. klarstellen (was ich zugegeben teilweise entfernt/ersetzt hatte). Die Sache ist wie unter WP:HTML5 beschrieben, (leider) etwas komplexer bzw. differenzierter zu sehen. Daher würde ich unter dem Bewusstsein, dass hier alles eher sehr knapp gehalten werden soll und wir dennoch bemüht sein sollten akkurat zu bleiben, hier einen Hinweis setzen (von mir aus auch in Klammern und auf Hilfe:CSS). In bestimmten (seltenen?) Fällen ist nämlich ein style="text-align:center;" (bzw. ein gleichbedeutendes class="center" style="width:auto;" mit explizierter Breitenangabe) doch angebracht. Nämlich wenn keine Breite von 100% (also auch kein class="centered") gewünscht ist und es sich um ein Block-Element (Tabelle, Galerie, div) handelt, was nämlich class center leider (u.a.) tut. ↔ User: Perhelion 14:01, 21. Nov. 2014 (CET)

Ich schau es mir an. Einen allgemeinen Hinweis darauf, dass es verschiedene Techniken und Syntaxelemente gibt, und diese zu erwähnen, ist okay; aber eine ausführliche Erörterung mit Anzeigebeispielen ist hier fehl am Platz.

Eher irgendwas wie eine Unterseite /Zentrieren von irgendwas wie Hilfe:Textgestaltung zur vergleichenden Übersicht über die verschiedenen Syntaxkonstruktionen und ihrer Wirkung; unter einleitender Beachtung des Hinweises bei Hilfe:Textgestaltung #Formatierungen, die nicht in Wikipedia-Artikeln verwendet werden sollten.

class="center" style="width:auto;" liegt allerdings oberhalb der Anforderungen, die wir an das technische Verständnis von Autoren stellen.

OT: Der Haken ┌─────────────────────┘ ist schick.

Ich habe allerdings den Eindruck, dass du auf dieser Diskussionsseite ein quelltextveränderndes Skript zu laufen hast.

LG --PerfektesChaos 14:20, 21. Nov. 2014 (CET)

Ja das stimmt. @OT: Richtig du Schelm, es ist Deins. (@für „Verbesserungen“ bin ich auch immer offen) Ich muss schon etwas schmunzeln das von dir zu hören (auch wegen dem od, auf die Gefahr hin nicht auf eine Ironie aufgesessen zu sein) @Od: Vorlage:Outdent wurde anscheinend nach deutscher Regelhuperei gelöscht (wie so einige englische Vorlagen die sich dann später doch durchgesetzt haben wie z.B. Vorlage:Vorlage um spontan nur ein Bsp. zu nennen) Der Löschkommentar spricht für sich, daher ist es jedem freigestellt diese Vorlage neu zu erstellen. LG ↔ User: Perhelion 14:56, 21. Nov. 2014 (CET)

• @WSTM: Ja, aber erstens verwahrt sich das gegen Diskussionsseiten, und zweitens wird in der Werkseinstellung auch nicht aus „!?“ ein kryptisches „⁈“ gemacht, von dem ich grad nur Mojibake und Hexcode sehe und zu faul bin, den nachzuschlagen.
• @Outdent: erledigt sich in ein paar Jahren durch Flow.
• Vorlage:Vorlage ist ja okay; fies ist dieses kryptische „Tlx“ und „Tl“, das man uns aufzuschwatzen versuchte. Ich blicke in der enWP durch den ganzen Dschungel an T-dingsda-Vorlagen nie durch, und es ist auch eine Schrott-Idee, alles auf zwei oder drei Buchstaben runterzukürzen, bis niemand mehr lesen kann, was da eigentlich steht; nebst über 17.000 Shortcuts auf irgendwelche Seiten zum Auswendiglernen.
• „Regelhuperei“ ist süß; habe ich mir grad in meinen Duden dazugeschrieben.
• Über eine neue Hilfeseite mache ich mir im Lauf des Wochenendes Gedannken; über sowas möchte ich gern ein- bis zweimal schlafen.

LG --PerfektesChaos 15:27, 21. Nov. 2014 (CET)

Altenglische Literatur

Hallo, Ihr wißt, dass da eine große Runde der Bereinigung von Tag-Fehlern läuft. Im o.g. Artikel werden Tag-Fehler durch akas Skript ausgeworfen:

Zitat: <div class="toccolours spoilercontents"> oder <div class="notice spoilerbox">

Kann man das nicht einfacher gestalten? Im Endeffekt läuft es auf eine Rahmung verschiedener altenglischer Texte mit einer leicht grauen Hintergrundfarbe hinaus. Aber offenbar fasst hier niemand die Bereinigung an wegen völlig unbekannter Klassen. Danke schon im voraus und Grüße, --MitigationMeasure (Diskussion) 16:36, 1. Dez. 2014 (CET)

notice spoilerbox spoilercontents kannst du m. E. vergessen und rauslöschen. Dürften aus der enWP geklaut sein, hier nicht definiert.

• div ohne Attribute kann in aller Regel weg.

toccolours ist die weltweite Definition des Rahmens um ein Inhaltsverzeichnis.

Für zukünftige Anfragen dieser Art empfehle ich die WP:VWS.

VG --PerfektesChaos 17:23, 1. Dez. 2014 (CET)

Danke trotzdem für die Hilfe, habe es erledigt, hat alles so funktioniert. Du hast ja schon mehrfach geholfen, ich scheue mich aber, mit solchen technischen Dingen eine Benutzerdiskussionsseite zu füllen. Grüße zurück,--MitigationMeasure (Diskussion) 20:55, 1. Dez. 2014 (CET)

Geschützter Bindestrich

Hallo! Wäre jemand so nett und könnte im Artikel noch die Verwendung des geschützten Bindestriches ‑ im Fließtext (also nicht in Überschriften denke ich) aufnehmen, wenn die automatische Trennung an dieser Stelle verhindert werden soll? Danke! --Ökologix (Diskussion) 11:39, 22. Mär. 2015 (CET)

Wir sind sehr, sehr reserviert gegenüber der Verwendung numerischer Entities, da sie den Quelltext schwer lesbar machen, für Newbies völlig undurchschaubar sind, und erfahrungsgemäß diese Entities in aller Regel auch absolut überflüssig und für die Wiedergabequalität des Wikitextes in Browsern nicht sinnvoll eingesetzt werden – das ist hier kein Kunstdruck.

Einer der seltenen Fälle wäre ein α-Teilchen, aber selbst bei dem geht die Welt nicht unter, wenn es nach dem Alpha einen Zeilenumbruch gäbe.

VG --PerfektesChaos 11:57, 22. Mär. 2015 (CET)

ein <nobr>-Tag könnte eigentlich ganz nützlich für Wikitext sein. Das würde dann auch die vielen &nbsp;-Zeichen ersetzbar machen, und damit für bessere Lesbarkeit des Quelltextes sorgen. Frohes Schaffen — Boshomi ☕⌨☺  21:22, 22. Mär. 2015 (CET)

"Hilfe:Tags #big" vs. Wiki-Editor

Warum bietet der Wiki-Editor ganz selbstverständlich die Formatmöglichkeit "Groß" an und schreibt dazu big-Tags in den Text ("Großer Text"), wenn gleichzeitig unter der Überschrift "Ungebräuchliches HTML" geboten wird: „big: Dieses Element soll nicht verwendet werden.“? Und warum wird "big" nicht einfach in der CSS entsprechend abgefangen und deklariert? Damit ließen sich spätere Austauschaktionen des "verfluchten" Tags verhindern…
Gruß -- Chiananda (Disk | Edits | Portal:Ethnologie) 17:17, 13. Mai 2018 (CEST)

Das Phänomen wurde bereits 2012 von unserem Schnark als phab:T40487 berichtet.

Die fragliche Werkzeugleiste ist aus 2009/10, die HTML5-Geschichte kam ab etwa 2011 auf.

Unserer ältesten Werkzeugleiste von um 2005 ist bereits angekündigt wrden, dass sie mittelfristig nicht mehr zur Verfügung gestellt werden wird; diese hier wird wohl langfristig auch wegfallen.

Hintergrund ist, dass die VE-Quelltext-Werkzeugleiste von 2017 alle Vorgänger einheitlich ersetzen soll und es dann nur noch eine Struktur und Programmierung dafür geben wird. Da wird an dem Dings von 2010 wohl auch keiner mehr was machen.

LG --PerfektesChaos 13:47, 14. Mai 2018 (CEST)

small als Klasse

Da es mir jetzt gehäuft in den Linterlisten auftaucht mal eine Frage, gibt es hier bei uns im Wiki eine funktionierende Klasse small? Ich zumindest kann in meinem Browser (noch immer Firefox) nicht wirklich eine Wirkung sehen. Aber scheinbar sorgt es doch für eine winzige Verkleinerung auf 94 %? Ich bin nicht so gut im Konsolenlesen. Daher mal hier ein Beispiel in etwas größerer Schrift.TTT Was mir auch neu ist, ist dass es auch feste Werte (x- xx-) gibt, die scheinbar von der Umgebung unabhängig reagieren.

Textbeispiel normal	Textbeispiel normal
Textbeispiel style="font-size:large"	Textbeispiel style="font-size:small" (minimal kleiner als normal?)
Textbeispiel style="font-size:larger" (larger < large = big-Tag ???)	Textbeispiel style="font-size:smaller" (= small-Tag ???)
Textbeispiel style="font-size:x-large"	Textbeispiel style="font-size:x-small"
Textbeispiel style="font-size:xx-large"	Textbeispiel style="font-size:xx-small"

Diese Tabelle komplett heruntergesetzt auf 50 %

Textbeispiel normal	Textbeispiel normal
Textbeispiel style="font-size:large"	Textbeispiel style="font-size:small"
Textbeispiel style="font-size:larger"	Textbeispiel style="font-size:smaller"
Textbeispiel style="font-size:x-large"	Textbeispiel style="font-size:x-small"
Textbeispiel style="font-size:xx-large"	Textbeispiel style="font-size:xx-small"

Das war mir bisher überhaupt gar nicht bewusst. Maximal doppel-x, oder?

Aber zurück zu der Frage, weil für mich class="small" eigentlich optisch kaum sichtbar ist, sollte man dann nicht all die marginalen Textgrößeneinstellungen, die diese Klasse enthalten ersetzen oder eliminieren? Oder liegt es an meinen Browser und bei anderen ist da mehr zu sehen? Ich frage, weil ich mir dann doch unsicher bin, ob meine Zusammenfassungskommentare wirklich passend sind, oder anders, was wäre die korrekte Ersetzung für diese Angaben? Ich schrieb nämlich es hat keine Wirkung. Weil ich sie nicht sehen konnte. Da es zumeist Tabellen betrifft würde ich nicht gern auf das small-Tag wechseln, da das wieder zu den selben Umbruchproblemen führen könnte. Was also tun? --Liebe Grüße, Lómelinde Diskussion 15:25, 14. Aug. 2018 (CEST)

Die class="small" ist wirksam und kommt irgendwoher aus MediaWiki.

Woher genau, ob auf jeder Seite, wie lange noch, ob garantiert ist die Frage. Ich benutze es nicht.

94% stimmen.

Wenn keine Prozente angegeben sind, ist es Sache des Browsers, sinnvolle Werte zu verwenden für small, smaller, x-small, <small> usw.

Die Klasse ist wohl, weil die Autoren wollen, dass es kleiner wird, aber die Leser es dann nicht mehr lesen können, wenn es verkleinert wird, und da macht man halt nur ein Fitzelchen kleiner, dann bekommen die Autoren ihren Willen und die Leser merken nix.

Beachte, dass smaller larger Prozent em relativ ist, also kleiner/größer als im Elternelement. Alle anderen und rem sind absolut zur Dokumenten/BODY-Schriftgröße.

LG --PerfektesChaos 15:45, 14. Aug. 2018 (CEST)

Elternelement, ja genau das dachte ich immer, wenn etwas schon im Tabellenkopf auf 90 % verkleinert wurde, dann würde eine nochmalige Verkleinerung von diesem Wert (90 % von 90 % und nicht 90 % von Normalgröße sein). Dann muss ich meinen Kommentar ändern, ich habe echt Null Veränderung (T<span class="small">T</span>T) → (TTT) gesehen, daher dachte ich für mich, das ist „komplett wirkungslos“, da es aber so oft vorkommt, dachte ich, ne das macht doch niemand wenn es nichts bewirkt, oder?

Manche Dinge sind sehr verwirrend. Dankeschön für die Info.

Ich versuche es mal so, wenn ich 10px Höhe habe und soll davon 94 % darstellen, und wenn das immer aufgerundet wird, dann kann es nur 10px ausgeben, solange der Wert nicht unter 90 % liegt. So denke ich wird wohl die Wirkung (T<span style="font-size:90%;">T</span>T) → (TTT) sein. --Liebe Grüße, Lómelinde Diskussion 16:06, 14. Aug. 2018 (CEST)

Ja, die Idee bei 94% kann sowas sein, dass es vielleicht kleiner wird, aber nur manchmal, und meistens nicht. Wobei moderne Font-Pixel nicht mehr ganzzahlig sein müssen. Alles das wissen die meisten Leute, die mit sowas um sich schmeißen, jedoch üblicherweise nicht.

<small> ist vermutlich das Gleiche wie <span style="font-size:smaller"> – was aber unmittelbar oder indirekt aufeinander folgende <small> oder <big> ergeben soll, ist nirgendwo definiert. Alles dem Browser überlassen.

LG --PerfektesChaos 16:34, 14. Aug. 2018 (CEST)

Aha, wie kann man denn ein Pixel teilen? So wie das hier ?

Mein Atari hatte Sprites, die 16 × 16 Pixel groß sein konnten, da ging nicht viel. :-) aber ich verstehe schon was du meinst, wenn ich ein Pixel als 2 × 2 Punkte Quadrat definiere kann ich es variieren und wenn mein Pixel nun 16 × 16 Punkte hätte dann hätte ich ein zigfaches an Möglichkeiten gehabt. So aber musste ich vier Sprites verschmelzen, um wenigstens 32 × 32 Felder oder Bildschirmpunkte mit unterschiedlichen Farbzuweisungen zu erhalten. Schade nur, dass meine Daten für immer verloren gingen.

Wichtiger ist aber, denke ich, dass ich jetzt verstanden habe, dass es feste (absolute) und veränderliche, dynamische Anweisungen für die Größe gibt. --Liebe Grüße, Lómelinde Diskussion 17:09, 14. Aug. 2018 (CEST)

2½ × 2½ schwarze Pixel auf weißem Grund sind 2×2 schwarze Pixel und fünf mittelgraue drumrum; oder vier mittelgraue und ein etwas helleres. Geht auch mit Buchstaben. LG --PerfektesChaos 17:22, 14. Aug. 2018 (CEST)

Meta-Tags

War das so richtig <meta name="robots" content="noindex"> oder hätte ich dafür NOINDEX einfügen sollen? Aber ich finde es etwas unlogisch für Diskussionsseiten von Artikeln. Es kommt aber wohl durchaus vor , daher bin ich jetzt etwas unsicher. --Liebe Grüße, Lómelinde Diskussion 18:04, 2. Okt. 2019 (CEST)

<meta> ist verbotenes HTML, wie du richtig verlinkt hattest, siehe umseitig, und deshalb unwirksam.

Es würde außerhalb des Wikitext-Bereichs liegen, sogar außerhalb des sichtbaren Dokuments <body>, und das ist dem Wikitext grundsätzlich nicht als HTML, sondern nur über System-Wikisyntax zugänglich.

Alle Diskussionsseiten sind von alleine NOINDEX.

LG --PerfektesChaos 22:42, 2. Okt. 2019 (CEST)

Wie gesagt hatte es mich etwas verunsichert, weil ich noindex auch auf anderen Diskussionsseiten gefunden hatte. Dankeschön. --Liebe Grüße, Lómelinde Diskussion 06:41, 3. Okt. 2019 (CEST)

Wiki-Zensur

Gemeldet in Phabricator
Task T25932

Offensichtlich gibt es keine Blacklist, sondern eine Whitelist, in der vieles übersehen wurde. z.B. <figure>.. <figcaption>.. </figcaption></figure> wird brav
umgesetzt in <figure>.. <figcaption>.. </figcaption></figure>. Das ist kein Einzelfall. Einige HTML-Tags sind durchaus nützlich, werden jedoch großzügig wegzensiert, obwohl der Einsatz durchaus sinnvoll ist. Das ‚gefährliche‘ Tags entschärft werden, ist verständlich, aber nützliche Elemente?

Andererseits passieren sehr merkwürdige ‚Korrekturen‘: <br></br><br />selbst<br //////> wird dann als <br><br><br><br>in die Welt geschickt, während man lautstark von XHTML-konform predigt. Na immerhin fehlertoleranter als sonstige WP-Anwendungen.

Wer ist für die Zensur zuständig?--Klaus-Peter 12:08, 27. Dez. 2019 (CET)

Bei der Freigabe von HTML-Elementen muss immer aufmerksam geschaut werden, dass sie prinzipiell erwünscht sind, und weder Sicherheitsbedenken noch Kollisionen mit MediaWiki-Erweiterungen vorliegen. Außerdem ist es Arbeit für die Entwickler und konkurriert dabei mit vielen anderen, sinnvollen Projekten. Task 25932 fasst den aktuellen Zustand und Fortschritt hier zusammen. --MGChecker – (📞| 📝| ) 13:56, 27. Dez. 2019 (CET).

Danke für den Hinweis. Die beiden oben genannten tags finde ich da mit Vermerk enablable - semantic markup seit 2016. Also abwarten und mit den Fehlern leben, die ich damit zu umgeghen hoffte (siehe hier)--Klaus-Peter 18:47, 27. Dez. 2019 (CET)

Tidy↔RemexHTML

Auf einigen Seiten haben wir, wie beispielsweise hier auf der Vorderseite noch so etwas stehen.

„Bevor dies zum Leser ausgeliefert wird, läuft zurzeit noch das Programm HTML Tidy und versucht, das entstandene Gemenge zu interpretieren und als standardkonformes HTML zu formatieren. Mittelfristig wird das nicht mehr verwendet werden können; die Software entstand 1998 unter anderen Bedingungen.“

– Stand → 2012

Das ist ja wohl inzwischen überholt. Es wäre daher sinnvoll das mal anzupassen.

• Wikipedia:Technik/Skin/Tutorial#Entstehungsprozess einer Wiki-Seite = „Das Resultat wird durch HTML Tidy weitgehend standardkonform gemacht. Das Ergebnis wird im „Seiten-Cache“ bereitgestellt.“
• Was genau ist RemexHTML?

Ebenso finde ich die Empfehlung das tt-Tag zu verwenden nicht mehr zeitgemäß. Wie soll man HTML-Fehler beheben, wenn es an anderer Stelle als Alternative angeboten oder explizit empfohlen wird →Hilfe:Tags#code →Stand 2014 („muss noch auf <tt> ausgewichen werden“). Ich weiß, das ist nicht die dringlichste Baustelle, aber je mehr davon ersetzt wird, desto weniger neue Fehler kommen, meiner Meinung nach, durch Verschleppung (Kopieren) hinzu. Ich halte mich da schon zurück, aber irgendwann muss auch das mal ersetzt werden und in vielen Fällen ist eine Umstellung auf code sogar besser lesbar. Aber das →(tt = sinnvoll für Artikel) steht dazu im Widerspruch und erschwert die Akzeptanz einer Anpassung. --Liebe Grüße, Lómelinde Diskussion 08:37, 17. Jan. 2020 (CET)

• Die Vorderseite habe ich mir betreffend Tidy auf die ToDo-Liste zur Aktualisierung gesetzt.
• Ich schreibe ungern sofort bei derartigen Umstellungsprozessen alles um, weil es oft wieder zurück auf Anfang oder ganz woanders lang geht. Parsoid hat inzwischen auch eine Ehrenrunde gedreht und ist mit Dezember 2019 schon der zweite Wechsel im Konzept bei der Ablösung des Parsers aus den 2000er Jahren.
• RemexHTML ist möglicherweise eine Eigenentwicklung von MediaWiki, vielleicht eine Weiterentwicklung einer anderen Fremdsoftware. RemexHTML hat nichts mit Wiki zu tun und kann jedes beliebige HTML-Dokument nachpolieren, genauso wie es HTMLtidy von 1998 auch gekonnt hatte, und mit für uns ungeeigneten Resultaten in einer Weiterentwicklung bis heute macht.
• Ich möchte nicht regelmäßig mit <tt> genervt werden; niemand weiß wirklich, wie dessen Zukunft aussieht. Es kann mit ein paar Zeilen zu einem MediaWiki-Tag gemacht werden, genauso wie <pre> zwar aussieht wie HTML, aber in Wirklichkeit ein MediaWiki-Tag ist. Bloß weil irgendein Programmierer es mal auf die Liste der in HTML5 nicht mehr neu zu verbauender Elemente gesetzt hat, heißt das noch lange nicht dass <tt> nicht noch dreißig Jahre in HTML und im Wiki funktionieren würde. Es ist auch völlig wurscht, ob das irgendwelche Zahlen in der Statistik in einer vorvorletzten Spalte bewirkt. Es kann auch HTML mal wieder eine Kehrtwende machen, wie es sie bei den 1998–2010 genauso veralteten <b> und <i> schon mal gab, und in HTML6 oder HTML5a ist <tt> nicht mehr „veraltet“. Das ist schlicht und einfach kein „Fehler“. HTML wird es noch die nächsten 50 Jahre ordnungsgemäß verarbeiten.

LG --PerfektesChaos 14:40, 17. Jan. 2020 (CET)

O.k. schon gut, aber solche Widersprüche finde ich immer etwas unschön. An irgendetwas muss man sich doch orientieren. --Liebe Grüße, Lómelinde Diskussion 15:55, 17. Jan. 2020 (CET)

Auch Tidy→RemexHTML eingearbeitet. LG --PerfektesChaos 21:56, 19. Feb. 2020 (CET)

sprachliche Anpassungen und inhaltliche Kommentierung

Ich habe versucht, einige sprachliche Unklarheiten zu überarbeiten und möchte auf weitere inhaltliche Unklarheiten direkt im Quelltext hinweisen.

Die teilweise kleinteiligen Änderungen erstrecken sich über die ganze Länge der Seite, so dass ich nicht recht wußte, wie diese hier vorzustellen wären.

Ich habe mir beholfen, indem ich die Änderungen vorläufig in den Quelltext übernahm und die Bearbeitung anschließend wieder rückgängig machte.

Ich bitte um Durchsicht und Kommentierung oder entsprechend angepaßte Übernahme.

besten Dank,

Kai Kemmann (Diskussion) - Verbessern statt löschen - 04:02, 29. Mai 2020 (CEST)

• Nach erster flüchtiger Durchsicht waren hier keinerlei Verbesserungen zu erkennen, die bei gleichem Sinn und Inhalt eine Formulierung durch eine deutlich verständlichere verfeinern würden.
• Du ersetzt einen Ratschlag, eine Empfehlung durch eine unbedingte Anweisung; du machst aus vorsichtigen Einschätzungen absolute Feststellungen; du ersetzt Fachbegriffe, deren Bedeutung dir vermutlich überhaupt nicht klar ist, durch Vokabeln deiner eigenen Welt mit nicht deckungsgleichem Inhalt.
• Ich habe in der Vergangenheit bereits viele viele viele Stunden mit deinen Änderungen an Hilfe- und Projektseiten zubringen müssen, und es war praktisch alles zu revertieren.
• Du „vereinfachst“ regelmäßig komplexe Sachverhalte, differenzierte Darstellungen durch verkürzte Aussagen, die in ihrer Absolutheit dann schlicht falsch sind.
• Die vermeintlichen „Unklarheiten“ sind präzise definierte Begriffe, die durch schwammige Ausdrücke aus deiner eigenen Alltagswelt ersetzt wurden.
• Ich habe nicht die Lebenszeit, um mich wieder mal über Stunden mit der Vielzahl deiner Änderungswünsche im Detail auseinanderzusetzen; ich habe etliche offene Baustellen im Browser, denen ich die Stunden widmen möchte, die ich klar im Kopf und zu mehr als Formatierung in der Lage bin, und ich kann nicht erneut alle anderen Sachen stehen und liegen lassen, um mich spontan mit nicht zielführenden Holzwegen zu befassen.

VG --PerfektesChaos 12:42, 29. Mai 2020 (CEST)

SP beim Kommentar

Es ist unsinnig, einerseits hier die Regel aufzustellen:

• Längere Inhalte werden meist durch ein Leerzeichen an Anfang und Ende abgegrenzt:

<!-- Interne Info. -->

aber:

<!--sic!-->

und anderseits hier diese zwei Beispiele gerade umgekehrt aufzuführen:

<!-- sic! -->

<!--schweizbezogen-->

In neu angelegten schweizbezogenen Artikeln wird die Schreibweise mit SP klar bevorzugt (ca. 70 % im März 2022). --Peteremueller (Diskussion) 13:18, 2. Jun. 2022 (CEST)

Anderes Beispiel für <onlyinclude> gesucht

Hallo, umseitig wird in #Bedingtes Einbinden von Quelltextblöcken unter <onlyinclude> das Beispiel der BKS Meier (Familienname). Doch findet sich im Quelltext kein solches Tag. Ein instruktives Beispiel tut not.

(Brauche es dann für die richtige Platzierung in Hans Eberhardt; oder ist es dort gar nicht nötig?) Danke, --Wi-luc-ky (Diskussion) 19:36, 21. Dez. 2022 (CET)

Nicht im Quelltext von Meier (Familienname), sondern in etlichen dort eingebundenen Artikeln; diverse Hans Meier.

Meier (Familienname) soll die Auswirkung eingebundener Seiten in die einbindende Seite illustrieren; was aus „Hans Meier“ landet in Meier (Familienname) und was nicht?

VG --PerfektesChaos 23:07, 21. Dez. 2022 (CET)

Verstanden, PerfektesChaos. Und bei Hans Eberhardt ist es für bzw. um alle Einträge herum nötig, die dann bspw. in Eberhardt (Familienname) eingebunden werden und erscheinen. Danke und gute Tage wünscht --Wi-luc-ky (Diskussion) 16:24, 22. Dez. 2022 (CET)

Dieser Abschnitt kann archiviert werden. --Wi-luc-ky (Diskussion) 16:24, 22. Dez. 2022 (CET)

Bessere Formulierung

• englischsprachige Buchstaben - hat niemand was besseres ? ASCII eventuell ? -- A1000 (Diskussion) 11:49, 27. Feb. 2024 (CET)

Ach je, wohl der alte Konflikt zwischen allgemeinverständlicher Darstellung und einer nerdigen präzisen Bezeichnung A-S-C-I-I die niemand kennt. „7-Bit-Code“ könnte ich ja noch anbieten. Ich schau es mir die Tage mal an. VG --PerfektesChaos 12:27, 27. Feb. 2024 (CET)

Worum geht's hier? Das etwa: Bis etwa 2015 wurden nur englischsprachige Buchstaben a–z A–Z sowie Ziffern als Bestandteile eines Wortes erkannt?

Das scheint mir nicht ASCII zu entsprechen, und auch nicht 7-Bit. Das ist ein festgelegter Satz zulässiger Zeichen, der mit z.B. Uniform Resource Locator #Liste erlaubter Zeichen mehr gemeinsam hat als mit ASCII -- entspricht diesen bei URLs erlaubten Zeichen aber auch nicht zu 100% wenn nur die 26 Buchstaben des lateinischen Alphabets und Ziffern erlaubt waren/erkannt wurden. ‣Andreas•⚖ 13:32, 27. Feb. 2024 (CET)

Worum ging es?

Früher wurden als „Wort“-Bestandteile nur [A-Za-z_0-9] erkannt.

Damit wunderten sich WP-Autoren, wenn sie id=Heißluft und id=Heißwasser schrieben, dass dies keine Wirkung hatte, bzw. die gleiche wie id="Hei", jedoch eine solche Sprungmarke aber nirgendwo verwendet worden war.

Das war in den frühen Jahren nicht nur beim Wiki-Parser, sondern allgemein in Browsern und Parsern üblich gewesen.

• Alles, was nicht dieser Regel entsprach, galt als Sonderzeichen und beendete deshalb den Attributwert.
• Heutzutage werden aus Unicode die Zeichenklassifizierungen Letter und Digit ausgewertet, und damit würden vielerlei weitere echte Buchstaben erkannt; aber nicht die „Buchstaben-ähnlichen“.

Deshalb plumpe Regel: Immer alles in " einschließen und gut ist. Dann muss auch niemand darüber nachdenken und tüfteln, wann welches Zeichen vorkäme und wie das interpretiert würde.

VG --PerfektesChaos 14:35, 27. Feb. 2024 (CET)

Es geht nur um die Formulierung englischsprachige Buchstaben, ich bin kein Germanist, aber da Kringeln sich mir die Fußnägel, spricht was gegen Bis etwa 2015 wurden nur die Buchstaben a–z A–Z sowie Ziffern als Bestandteile eines Wortes erkannt ? -- A1000 (Diskussion) 12:31, 1. Mär. 2024 (CET)

+1 --Dirk Lenke (Diskussion) 12:33, 1. Mär. 2024 (CET)

+1. Das reicht völlig. Warum müssen die Buchstaben zusätzlich noch englisch sprechen? --Rodomonte (Diskussion) 13:21, 1. Mär. 2024 (CET)

Weil die Menschlein das nie kapiert hatten, x-mal wegen angeblicher Softwarefehler mit ihren Heißluft auf FZW aufschlugen, und nicht begriffen hatten, dass ß nicht zu den „Buchstaben a–z“ dazugehört. Und äöü auch nicht. VG --PerfektesChaos 13:57, 1. Mär. 2024 (CET)

Ich verstehe vollkommen PCs Begründung. Aber englischsprachig sind die Buchstaben nicht, sondern es sind die Buchstaben, die alle heutigen Sprachen, die das lateinische Alphabet benutzen, kennen. Also besser: die Grundbuchstaben a–z, A–Z des lateinischen Alphabets. --BurghardRichter (Diskussion) 15:47, 1. Mär. 2024 (CET)