Wikiup Diskussion:WikiProjekt HTML5
Vorlage:SortKey
Es sollte erstmal gut und verständlich dokumentiert werden, wie genau "data-sort-value" die genannten Vorlagen ersetzt, d. h. welche Syntaxänderungen nötig sind. 213.54.82.20 12:34, 30. Sep. 2012 (CEST)
- Das sollte wohl zweckmäßigerweise auf der Seite Vorlage:SortKey dokumentiert werden, siehe dort. --TMg 17:19, 5. Okt. 2012 (CEST)
Die Vorlage setzt den ersten der beiden Parameter in ein Span-Tag mit "display:none" und den zweiten dahinter. Bei einer Umstellung der Tabellen muss der erste Parameterwert vom Zellenwert zum Zellattribut (also vor ein "|") verschoben werden und die Vorlage dann aus der Zelle entfernt werden: Aus
| {{SortKey|Muller, Peter|Peter Müller}}
muss
| data-sort-value="Muller, Peter"|Peter Müller
werden. Das geht nur mit einem guten halbautomatisch laufenden Bot, bei dem jeder Edit einzeln bestätigt wird. Bereits ersetzte Umlaute muss man nicht erneut einbauen. ÅñŧóñŜûŝî (Ð) 17:37, 15. Okt. 2012 (CEST)
Umlaute in data-sort-value
Umlaute müssen inzwischen nicht mehr ersetzt werden:
Name | data-sort-value
|
---|---|
Fritz Müller | Müller, Fritz |
Max Mustermann | Mustermann, Max |
Franz Mayer | Mayer, Franz |
Andere akzentuierte Buchstaben könnte man in MediaWiki:Common.js aufnehmen. Dadurch ist der Sortiersclüssel in vielen Fällen überflüssig, und kann in anderen bei der Umstellung auf data-sort-value
gleich vereinfacht werden. --Schnark 09:39, 1. Okt. 2012 (CEST)
Das ist gewiss sinnvoll. Das Skript sollte alle modifizierte lat. Buchstaben berücksichtigen können. Die Arbeitsweise von "data-sort-value" in der WP-Syntax muss man schlichtweg mit einer Testseite ermitteln. ÅñŧóñŜûŝî (Ð) 17:37, 15. Okt. 2012 (CEST)
Missbilligte Elemente und Attribute
Würde zu einem HTML5-Projekt nicht auch gehören, Elemente und Attribute zu behandeln, die im HTML5-Standard offiziell nicht mehr unterstützt werden, aus Kompatibilitätsgründen aber noch von unserer MediaWiki-Software akzeptiert und ausgegeben werden? Genau das wird in Bug 40633 gefordert. Sollten wir auf diese Kategorisierung warten? Oder können wir per Botanfragen schon sinnvolle Vorarbeit leisten? Wenn das Unterstützung findet, wünsche ich mir einen abgestimmten Plan mit einer klaren Priorisierung. Beispielsweise dürfen meiner Meinung nach keinesfalls irgend welche Ersetzungen per Bot oder gar per „Magie“ in der MediaWiki-Software durchgeprügelt werden. Das wäre reine Augenwischerei, die niemandem hilft, vor allem aber wäre es verschenktes Potential. Ich fände es sehr reizvoll, die Gelegenheit zu nutzen, Vorlagen und Artikel mit missbilligtem HTML-Ramsch manuell abzuarbeiten (gestützt durch Arbeitslisten und halbautomatische Skripte), denn solche Vorlagen und Artikel haben meist noch viel mehr Probleme und Verbesserungspotential als beispielsweise nur mal fix ein <font>
-Tag durch einen entsprechenden CSS-Stil auszutauschen.
Vorschlag:
- Eine Liste aller missbilligten Elemente und Attribute erstellen (vgl. en:Help:HTML in wikitext).
- Für jedes Element und Attribut genau beschreiben, wann es welche Wirkung hat. Nur ein Benutzer, der wirklich verstanden hat, was der missbilligte Quelltext bewirkt, sollte ihn durch einen anderen Quelltext ersetzen.
- Mögliche Ersetzungen für jeden Fall dokumentieren. Manches ist simpel, aber manches kann auch unheimlich kompliziert werden.
- Prioritäten festlegen, was zuerst systematisch abgearbeitet werden sollte. Das hängt von der Verwendungshäufigkeit ab, vor allem aber davon, wie kompliziert die Ersetzung ist. Für Dinge wie
cellpadding
beispielsweise kann es durchaus zweckmäßig sein, anstelle von Dutzendenstyle="padding: …;"
lieber eine leichte Veränderung im Aussehen einer Infobox in Kauf zu nehmen, was aber zuvor kommuniziert und diskutiert werden muss. Oder anders formuliert: Eh man sich auf solche problematischen Fälle stürzt, sollte man dascellpadding
lieber vorübergehend stehen lassen und statt dessen erst einmal eindeutigere Fälle abarbeiten, von denen es sicher mehr als genug gibt.
Es stellt sich auch die Frage, in welchen Namensräumen man das macht. Artikel-, Vorlagen- und evtl. der Portal-Namensraum sollten eigentlich genügen. --TMg 17:19, 5. Okt. 2012 (CEST)
- Ich habe mal eine Tabelle angefangen wobei ich nicht genau weiß wo es mehrere Möglichkeiten zum Ersetzen gibt. Gruß Matthias (Diskussion) 14:09, 14. Okt. 2012 (CEST)
- Die Möglichkeiten sind unendlich, vor allem wenn man nicht zwingend nach einem pixelgenauen Ersatz sucht sondern sich in Ruhe anschaut, welche Bedeutung die ursprüngliche Formatierung tragen und vermitteln sollte. Man sollte immer versuchen, einen Ersatz zu finden, der diese intendierte Bedeutung trägt, selbst wenn es danach etwas anders aussieht. Viel wichtiger ist, dass das Ergebnis einerseits in sich stimmig ist (im gesamten Artikel wird die selbe Formatierung verwendet) als auch zu anderen Artikeln passt. --TMg 23:49, 14. Okt. 2012 (CEST)
- Grundsätzlich halte ich es für richtig, alte html-Tags auszubessern, aber ist es wirklich gut, einen big-Tag durch css zu ersetzen? Imho wird dadurch die lesbarkeit beim Bearbeiten stark geschwächt. Vielleicht sollte man die Änderungen teilweise nochmals überdenken. --- Bene ~ Disk ~ Bewerten --- 23:51, 14. Okt. 2012 (CEST)
- Du hast völlig Recht. Wie ich weiter oben schon andeutete, wäre es vollständig sinnfrei,
<big>
per Bot durch<span style="font-size: bigger;>
zu ersetzen. Das würde den Quelltext in keinster Weise besser machen, eher im Gegenteil. Es wäre nicht semantischer. Es wäre exakt die selbe „physische Textauszeichnung“, nur mit anderen Mitteln.<big>
wird noch viele, viele Jahre lang seinen Zweck erfüllen. Aus dem selben Grund kämpfe ich auch dafür, dass das heimlich verbotenealign
wieder zugelassen wird. Aber: Ich sehe in diesem Projekt eine Chance, problematische Altlasten aufzufinden und mit Geduld und Sachverstand aufzuarbeiten. Die Erfahrung zeigt mir, dass das Vorkommen z. B. eines<center>
nur die Spitze des Eisbergs ist und Artikel oder Vorlagen, die so etwas enthalten, auch noch viele, viele andere Probleme haben, die man in diesem Zusammenhang gleich mit beheben kann. Ein<big>
in einem Artikel würde ich als eine solche „Spitze des Eisberges“ betrachten und mich fragen, was das dort soll und was der Benutzer damit ausdrücken wollte. In anderen Namensräumen wäre ich da weniger zurückhaltend. Ob eine Vorlage mit| align="center" | <big>'''{{{Name}}}'''</big>
(gibt es immer noch sehr häufig) oder mit! style="font-size: bigger;" | {{{Name}}}
beginnt, ist den meisten Benutzern ziemlich egal. Vorlagen sind Programmierung und da würde ich gern einen zeitgemäßen Programmierstil sehen, auch wenn der auf den ersten Blick etwas komplizierter wirkt. --TMg 00:18, 15. Okt. 2012 (CEST)
- Du hast völlig Recht. Wie ich weiter oben schon andeutete, wäre es vollständig sinnfrei,
- Grundsätzlich halte ich es für richtig, alte html-Tags auszubessern, aber ist es wirklich gut, einen big-Tag durch css zu ersetzen? Imho wird dadurch die lesbarkeit beim Bearbeiten stark geschwächt. Vielleicht sollte man die Änderungen teilweise nochmals überdenken. --- Bene ~ Disk ~ Bewerten --- 23:51, 14. Okt. 2012 (CEST)
- Die Möglichkeiten sind unendlich, vor allem wenn man nicht zwingend nach einem pixelgenauen Ersatz sucht sondern sich in Ruhe anschaut, welche Bedeutung die ursprüngliche Formatierung tragen und vermitteln sollte. Man sollte immer versuchen, einen Ersatz zu finden, der diese intendierte Bedeutung trägt, selbst wenn es danach etwas anders aussieht. Viel wichtiger ist, dass das Ergebnis einerseits in sich stimmig ist (im gesamten Artikel wird die selbe Formatierung verwendet) als auch zu anderen Artikeln passt. --TMg 23:49, 14. Okt. 2012 (CEST)
Void Elemente
Nachdem sich nun XHTML nach fast 10 Jahre dürftiger Existenz als unpraktikabel (berechtigter Weise) erwiesen hat, schlage ich ebenfalls vor sich nach dem Standard zu richten und standardmäßig den überflüssigen Slash aus den Leeren Tags (Standalone-Tags wie br nach fleißiger Scriptarbeits-Umwandlung) wieder zu entfernen (auch wenn es nun zwangsweise optional geworden ist). -- ΠЄΡΉΛΙʘ
17:29, 26. Okt. 2012 (CEST)
- Funktioniert denn beispielsweise ein
<ref name="…">
ohne Schrägstrich? (Meinem Test zufolge nicht.) Ich erinnere mich an einen Bot, der erst kürzlich bei vielen<references>
den vergessenen Schrägstrich ergänzte, weil das neuerdings (wohl durch eine Softwareumstellung) dazu führt, dass der Artikel ab dieser Stelle unsichtbar wird. Ja, mir ist natürlich klar, dass das kein HTML ist. Mein Argument ist aber, dass alle Elemente mit spitzen Klammern einheitlich geschrieben werden sollten. Ich denke, dass das wesentlich weniger verwirrt als zu schreiben „in diesen Fällen bitte weglassen aber in diesen Fällen unbedingt setzen“. Dann lieber „möglichst immer setzen, vor allem in diesen Fällen“. Außerdem (untergeordnetes Argument) finde ich, dass ein potentiell unerwünschtes<br />
viel eher auffällt als die Kurzform<br>
. --TMg 19:20, 26. Okt. 2012 (CEST)
Testtabelle
Nachfolgend eine Testtabelle für die Darstellung von font size="N" bzw. span style="font-size:O":
<table style="font-family:Cumberland, 'Courier New',monospace; text-align:left; line-height:200%;" class="wikitable">
<tr><th>N</th><th style="text-align:left;">Testzeichen</th><th>%</th><th style="text-align:left;">Testzeichen</th><th>CSS-Attribut</th><th style="text-align:left;">Testzeichen</th></tr>
<tr><td>1</td><td><font size="1">XXXXXXX</font></td><td>50% </td><td><span style="font-size:50%" >XXXXXXX</span></td><td>xx-small</td><td><span style="font-size:xx-small">XXXXXXX</span></td></tr>
<tr><td>2</td><td><font size="2">XXXXXXX</font></td><td>80% </td><td><span style="font-size:80%" >XXXXXXX</span></td><td>x-small </td><td><span style="font-size:x-small" >XXXXXXX</span></td></tr>
<tr><td>3</td><td><font size="3">XXXXXXX</font></td><td>100%</td><td><span style="font-size:100%">XXXXXXX</span></td><td>small </td><td><span style="font-size:small" >XXXXXXX</span></td></tr>
<tr><td>4</td><td><font size="4">XXXXXXX</font></td><td>120%</td><td><span style="font-size:120%">XXXXXXX</span></td><td>medium </td><td><span style="font-size:medium" >XXXXXXX</span></td></tr>
<tr><td>5</td><td><font size="5">XXXXXXX</font></td><td>150%</td><td><span style="font-size:150%">XXXXXXX</span></td><td>large </td><td><span style="font-size:large" >XXXXXXX</span></td></tr>
<tr><td>6</td><td><font size="6">XXXXXXX</font></td><td>200%</td><td><span style="font-size:200%">XXXXXXX</span></td><td>x-large </td><td><span style="font-size:x-large" >XXXXXXX</span></td></tr>
<tr><td>7</td><td><font size="7">XXXXXXX</font></td><td>250%</td><td><span style="font-size:250%">XXXXXXX</span></td><td>xx-large</td><td><span style="font-size:xx-large">XXXXXXX</span></td></tr>
</table>
- ÅñŧóñŜûŝî (Ð) 11:40, 27. Okt. 2012 (CEST)
- Ich hab sie mal ergänzt --- Bene*DiskussionBewerten --- 11:47, 27. Okt. 2012 (CEST)
- Ich hab sie mal ergänzt --
ΠЄΡΉΛΙʘ 16:07, 27. Okt. 2012 (CEST)
- Ähm sorry mir fällt gerade auf dass bei mir die Größen um eine Stufe versetzt sind, kann das jemand nachvollziehen (egal welcher Browser)? --
ΠЄΡΉΛΙʘ 16:18, 27. Okt. 2012 (CEST)
Du hattest die Titelzeile nicht verlängert und eine nicht existierende HTML-Stufe 0 war aufgetaucht. Jetzt erledigt. Eine genaue Zuordnung der HTML-Stufen zu Prozent ist schwierig. Eher schon kann man die Stufen 1 bis 7 den Attributwerten xx-small bis xx-large zuordnen, was aber die Bezugsreihe "Stufe 3 -- 100% -- medium" verletzt. Was der Browser daraus konkret macht, hängt von mehreren Faktoren wie z.B. Grundeinstellung, Zoomstufe und -verhalten, Benutzer- oder Autorenmodus, ab. ÅñŧóñŜûŝî (Ð) 12:53, 28. Okt. 2012 (CET)
- Ja das war mir schon klar (daher Absicht). So ist es jedenfalls auch Quatsch, da ja offensichtlich Stufe 3 hier nicht wie 100% aussieht, das hat konkret nichts mit dem Browser zu tun, eher mit Mediawiki? Das ist die Frage (also bei mir machen die Browser da keine großen Unterschiede FF, Chrome, IE). PS: Konkret, sollte Bezeichner medium = 3 sein, also die Frage bzw. Feststellung: sieht bei euch auch Stufe 7 wesentlich größer als 250% aus!? (vermutlich wird hier <font> nachträglich beeinflusst, daher dann wohl auch eher unwesentlich) --
ΠЄΡΉΛΙʘ
14:39, 28. Okt. 2012 (CET)- An der Media-Wiki software liegts nicht. Wenn du dir den Seitenquelltext im Browser anschaust, sind die Bezeichner gleich. --- Bene*DiskussionBewerten --- 15:37, 28. Okt. 2012 (CET)
- Wie meinst Du das? Ja (bei mir?) aber außerhalb von MediaWiki!? --
ΠЄΡΉΛΙʘ
15:45, 28. Okt. 2012 (CET)- Ich mein, wenn du im Browser (Firefox) mit rechter Maustaste auf Seitenquelltext anzeigen gehst. Das ist ja dann das, was aus der MediaWiki-Software rauskommt. Und da stehen die gleichen Bezeichner; so sieht es dann auch überall aus. --- Bene*DiskussionBewerten --- 17:08, 28. Okt. 2012 (CET)
- Wie meinst Du das? Ja (bei mir?) aber außerhalb von MediaWiki!? --
- Meine Recherche zeigt: Die meisten Browser machen Stufe 7 fast dreimal so groß. Das dürfte hier in WP aber nur selten eine angemessene Skalierung sein. Besser, wir belassen es bei 250%. Eine Alternative wäre die Zuordnungen von
1 = x-small
bis6 = xx-large
und eine "Verbannung" von Stufe 7, also ebenfalls Ersatz durch "xx-large". ÅñŧóñŜûŝî (Ð) 19:48, 28. Okt. 2012 (CET)
- An der Media-Wiki software liegts nicht. Wenn du dir den Seitenquelltext im Browser anschaust, sind die Bezeichner gleich. --- Bene*DiskussionBewerten --- 15:37, 28. Okt. 2012 (CET)
- Firefox nimmt beim Fonttag und den Attributen xx-small bis xx-large Bezug auf die im Browser eingestellte Grundschriftart und ordnet folgendes zu:
<table class="wikitable" cellpadding="10px" style="font-family:Cumberland, monospace; text-align:left; font-size:20px; line-height:250%;">
<tr><th>Stufe</th><th style="text-align:left;">Testzeichen</th><th>CSS-Attribut</th><th style="text-align:left;">Testzeichen</th><th>Pro­zent zur Grund­schrift</th><th style="text-align:left;">Testzeichen</th></tr>
<tr><td colspan="2">keine Entsprechung</td><td>xx-small</td><td style="font-size:xx-small">█████</td><td> 60%</td><td style="font-size:60%" >█████</td></tr>
<tr><td>1</td><td><font size="1">█████</font></td><td>x-small </td><td style="font-size:x-small" >█████</td><td> 75%</td><td style="font-size:75%" >█████</td></tr>
<tr><td>2</td><td><font size="2">█████</font></td><td>small </td><td style="font-size:small" >█████</td><td> 90%</td><td style="font-size:90%" >█████</td></tr>
<tr><td>3</td><td><font size="3">█████</font></td><td>medium </td><td style="font-size:medium" >█████</td><td>100%</td><td style="font-size:100%">█████</td></tr>
<tr><td>4</td><td><font size="4">█████</font></td><td>large </td><td style="font-size:large" >█████</td><td>120%</td><td style="font-size:120%">█████</td></tr>
<tr><td>5</td><td><font size="5">█████</font></td><td>x-large </td><td style="font-size:x-large" >█████</td><td>150%</td><td style="font-size:150%">█████</td></tr>
<tr><td>6</td><td><font size="6">█████</font></td><td>xx-large</td><td style="font-size:xx-large">█████</td><td>200%</td><td style="font-size:200%">█████</td></tr>
<tr><td>7</td><td><font size="7">█████</font></td><td colspan="2">keine Entsprechung </td><td>300%</td><td style="font-size:300%">█████</td></tr>
</table>
- Bei 300% stimmts nicht. das ist zu groß --- Bene*DiskussionBewerten --- 20:50, 28. Okt. 2012 (CET)
- Es hängt wohl auch von der Schrift ab. Wenn du, wie ich es gemacht habe, die Monospaceschrift Cumberland nimmst und du im FF satte 72px Grundschriftgröße einstellst, dann sind 300% exakt richtig. Bei Quivira ist es etwas abweichend, aber nicht viel. Öffne den Quelltext mal offline. Die Ganze Datei sieht so aus:
<!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN' 'http://www.w3.org/TR/html4/loose.dtd'>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="background:#FFFFFF;">
<table cellpadding="10px" style="font-family:Cumberland, monospace; text-align:left; font-size:20px;">
<tr><th>Stufe</th><th style="text-align:left;">Testzeichen</th><th>CSS-Attribut</th><th style="text-align:left;">Testzeichen</th><th>Pro&shy;zent zur Grund&shy;schrift</th><th style="text-align:left;">Testzeichen</th></tr>
<tr><td colspan="2">keine Entsprechung</td><td>xx-small</td><td style="font-size:xx-small">&#x2588;&#x2588;&#x2588;&#x2588;&#x2588;</td><td> 60%</td><td style="font-size:60%" >&#x2588;&#x2588;&#x2588;&#x2588;&#x2588;</td></tr>
<tr><td>1</td><td><font size="1">&#x2588;&#x2588;&#x2588;&#x2588;&#x2588;</font></td><td>x-small </td><td style="font-size:x-small" >&#x2588;&#x2588;&#x2588;&#x2588;&#x2588;</td><td> 75%</td><td style="font-size:75%" >&#x2588;&#x2588;&#x2588;&#x2588;&#x2588;</td></tr>
<tr><td>2</td><td><font size="2">&#x2588;&#x2588;&#x2588;&#x2588;&#x2588;</font></td><td>small </td><td style="font-size:small" >&#x2588;&#x2588;&#x2588;&#x2588;&#x2588;</td><td> 90%</td><td style="font-size:90%" >&#x2588;&#x2588;&#x2588;&#x2588;&#x2588;</td></tr>
<tr><td>3</td><td><font size="3">&#x2588;&#x2588;&#x2588;&#x2588;&#x2588;</font></td><td>medium </td><td style="font-size:medium" >&#x2588;&#x2588;&#x2588;&#x2588;&#x2588;</td><td>100%</td><td style="font-size:100%">&#x2588;&#x2588;&#x2588;&#x2588;&#x2588;</td></tr>
<tr><td>4</td><td><font size="4">&#x2588;&#x2588;&#x2588;&#x2588;&#x2588;</font></td><td>large </td><td style="font-size:large" >&#x2588;&#x2588;&#x2588;&#x2588;&#x2588;</td><td>120%</td><td style="font-size:120%">&#x2588;&#x2588;&#x2588;&#x2588;&#x2588;</td></tr>
<tr><td>5</td><td><font size="5">&#x2588;&#x2588;&#x2588;&#x2588;&#x2588;</font></td><td>x-large </td><td style="font-size:x-large" >&#x2588;&#x2588;&#x2588;&#x2588;&#x2588;</td><td>150%</td><td style="font-size:150%">&#x2588;&#x2588;&#x2588;&#x2588;&#x2588;</td></tr>
<tr><td>6</td><td><font size="6">&#x2588;&#x2588;&#x2588;&#x2588;&#x2588;</font></td><td>xx-large</td><td style="font-size:xx-large">&#x2588;&#x2588;&#x2588;&#x2588;&#x2588;</td><td>200%</td><td style="font-size:200%">&#x2588;&#x2588;&#x2588;&#x2588;&#x2588;</td></tr>
<tr><td>7</td><td><font size="7">&#x2588;&#x2588;&#x2588;&#x2588;&#x2588;</font></td><td colspan="2">keine Entsprechung </td><td>300%</td><td style="font-size:300%">&#x2588;&#x2588;&#x2588;&#x2588;&#x2588;</td></tr>
</table>
</body>
</html>
Wichtig: Du musst im Table-tag hinter "font-size:" die Pixelgröße der eingestellten Grundschrift des Browsers angeben, damit die Prozentwerte vergleichbar sind. Damit kannst du beliebig testen. ÅñŧóñŜûŝî (Ð) 21:09, 28. Okt. 2012 (CET)
Ganz einfache Empfehlung
Ihr habt Sorgen. Ich würde ja einfach empfehlen, die „1“ durch font-size: smaller
zu ersetzen und alles ab „3“ und höher durch font-size: larger
. Wobei es natürlich immer auf den Einzelfall ankommt, ob das angemessen ist. Das muss so oder so immer ein Mensch entscheiden, vollautomatisch darf das keinesfalls ersetzt werden. Der Vorteil dieser schlichten Empfehlung (entweder „smaller“ oder „larger“ oder gar nichts) wäre, dass dadurch in den weitaus meisten Fällen die selben drei Schriftgrößen Verwendung finden. Das würde dabei helfen, beispielsweise die Kopfzeilen von Infoboxvorlagen einheitlicher zu machen. Meine große Sorge bei Prozentangaben ist, dass das viel zu viele Variationen erlaubt und die Stellen, an denen das Verwendung findet, in einem noch uneinheitlicherem Chaos enden als das mit <font>
der Fall war. Damit waren wenigstens nur 7 Stufen möglich, Prozentwerte erlaubt potentiell hunderte. --TMg 02:56, 30. Okt. 2012 (CET)
- Alle Angaben, welche sich auf die im Browser definierte Grundschrift beziehen, sind problematisch. Wir sollten alles so weit wie möglich nur CSS-Angaben, welche die WP-eigenen CSS-Dateien (Common.css, Skinspezifische CSS-Datei und Benutzer-CSS-Datei) als Bezug haben, verwenden. ÅñŧóñŜûŝî (Ð) 10:29, 1. Nov. 2012 (CET)
- Richtig, aber was habe ich denn anderes gesagt? Die beiden Schlüsselwörter
smaller
undlarger
beziehen sich relativ auf die vom Skin vorgegebenen Schriftgrößen, genau wie Angaben inem
und Prozent. Zu vermeiden sind absolute Angaben wie daslarge
,x-large
usw. aus den obigen Tabellen. --TMg 12:47, 1. Nov. 2012 (CET)
- Richtig, aber was habe ich denn anderes gesagt? Die beiden Schlüsselwörter
Botlauf
Wäre es sinnvoll, den Botlauf zur Ersetzung von Sortkey usw. mit dem Botlauf zusammenzufassen, der irgendwann im Lauf des nächsten Jahres die Interwikis aus den Artikeln entfernen wird? Steak 11:13, 17. Nov. 2012 (CET)
- Das wäre ideal. Die Umsetzung ist ja sowieso eine langfristige Aufgabe. ÅñŧóñŜûŝî (Ð) 22:25, 17. Nov. 2012 (CET)
- Sehr guter Gedanke, äh, ich meine +1. ;-) --TMg 16:37, 19. Nov. 2012 (CET)
- Dann sollte man sich langsam an die Details machen, denn der Botlauf wird nicht mehr lange hin sein. Zu lange kann man ja nicht warten, da die lokalen IWs veralten und Bots sonst andauernd Korrekturarbeiten auszuführen hätten. Steak 17:16, 2. Mär. 2013 (CET)
- Die meisten der umseitig gelisteten Ideen sind nicht Bot-fähig.
- Teilweise sind sie schlicht falsch;
<mark>
beispielsweise ist eine von Browser und Benutzer abhängige Hervorhebung, die vorübergehend dynamisch in das HTML-Dokument eingefügt wird. Im Quelltext von Artikeln hat sie nichts zu suchen. - Es ist auch überhaupt nicht wünschenswert, irgendwelches vorgefundenes gammliges HTML 1:1 in HTML5 zu übersetzen. So wäre ein
<font size=...
in der Regel komplett zu entfernen. Im Artikel gibt es nur zwei Schriftgrößen, Normalschrift und im begründeten Ausnahmefall<small>
. Die<big>
gehören in Vorlagenprogrammierung mittelsstyle=
, etwa asiatische Sprachen oder noch nicht in Infoboxen eingebrachte Rohformatierung: checkwiki – bis hin zu den vergeigten Überschriften in Wanderfalter. Die vorgefundenen Elemente sind nicht einfach automatisiert umstellbar, sondern es kann bei vielen eine schlankweg falsche, sinnlose, überflüssige Benutzung im Quellcode sein. Wenn schon, dann ist für Autoren ein kurzes veraltendes<big>
erstmal sinnvoller als ein Ersatz durch langatmigesspan
undstyle=
. Ein<font face="Courier">
wäre nicht wie umseitig dargestellt durch<span style="font-family: Courier, monospace;">
1:1 zu ersetzen, sondern simpel durch<code>
(falls an dieser Stelle überhaupt angemessen).
- Teilweise sind sie schlicht falsch;
- Es ist auch überhaupt nicht erwünscht, die Artikeltexte mit den Autoren unbekannten HTML-Varianten zu fluten, für die wir Vorlagen verwenden. So kommt
<kbd>
genau einmal vor, und das ist in Vorlage:Taste, und fertig.- Siehe H:Tags zu Details.
- Die Bot-Betreiber haben teils über ein Jahrzehnt HTML-Erfahrung und werden sich darauf sowieso nicht einlassen.
- Die meisten der umseitig gelisteten Ideen sind nicht Bot-fähig.
- VG --PerfektesChaos 17:59, 2. Mär. 2013 (CET)
- Verzeih, aber in der in diesem Abschnitt gestellten Bot-Frage geht es ausschließlich um den Ersatz der Vorlage:SortKey und evtl. einiger anderer durch
data-sort-value="…"
. Zumindest hatte ich es so verstanden. Dass nichts von dem, was du aufzählst, von einen Bot gemacht werden sollte, ist hier so hoffe ich jedem klar. --TMg 20:59, 2. Mär. 2013 (CET)
- Verzeih, aber in der in diesem Abschnitt gestellten Bot-Frage geht es ausschließlich um den Ersatz der Vorlage:SortKey und evtl. einiger anderer durch
- Ja? Wäre fein.
- Allerdings ist in der ersten Zeile dieses Abschnitts unpräzise von einem „Sortkey usw.“ die Rede. Wie weit das „usw.“ reichen soll, wird mir nicht ganz klar. Wikipedia:Bots/Anfragen #Großer Botlauf zur Entfernung der Interwiki-Links hat auch ein offenes „etc.“ drin. Die Vorderseite mal aufzuräumen und zu berichtigen wäre in den letzten Monaten nett gewesen. Was die beiden Experimental-Abschnitte mit der Schriftgröße hier drüber erbringen sollen, stimmt mich in Verbindung mit der Vorderseite etwas misstrauisch. Insofern wäre es an der Zeit, dies explizit klarzustellen.
- Frühlingsgefühle --PerfektesChaos 22:05, 2. Mär. 2013 (CET)
- Ich hoffe – da bin ich mal Optimist –, dass alle Beteiligten aus der
align
-Katastrophe (bugzilla:40329, bugzilla:40632) gelernt haben. Was ich über die obige Diskussion denke, hatte ich dort schon geschrieben. --TMg 22:36, 2. Mär. 2013 (CET)
- Ich hoffe – da bin ich mal Optimist –, dass alle Beteiligten aus der
$wgAllowMicrodataAttributes
Eure fachliche Kenntnisse bezüglich Usecases zu time, data, link und meta wären unter WD:NEU#$wgAllowMicrodataAttributes willkommen. Vielen Dank. Der Umherirrende 19:38, 21. Feb. 2013 (CET)
HTML Code
Hallo,
ich würde gerne zur Verbesserung eines Seitenlayouts Frames mit einbinden. Allerdings lässt mir dies die MediaWiki-Software nicht zu. Gibt es da vielleicht irgend eine andere Lösung? --Korrektor123 (Diskussion) 11:55, 25. Dez. 2013 (CET)
- Es ist Absicht, dass das nicht funktioniert (Gründe: Zugänglichkeit/Barrierefreiheit und Sicherheit).
- Was genau heißt denn „Verbesserung eines Seitenlayouts“? Falls du eine externe Webseite einbinden möchtest, dann geht das wirklich auf keinen Fall, setze stattdessen einen Link (falls die Lizenz es erlaubt, kann man evtl. auch den Inhalt übernehmen, ist aber meist aus inhaltlichen/stilistischen Gründen nicht sinnvoll). Falls du eine andere Wikiseite einbinden möchtest, kann man das evtl. durch eine Vorlageneinbindung lösen.
- In HTML5 sind Frames übrigens auch nicht mehr standardkonform, nachdem sie bereits lange Zeit verpönt waren. Gruß --Entlinkt (Diskussion) 17:14, 25. Dez. 2013 (CET)
Es ist so, dass ich derzeit an den Tennis-Bundsligen von Damen und Herren Arbeite. Da hätte ich gemeint, es wäre vom Design her ansprechender wenn man auf dem linken Bildschirmrand eine Tabelle mit den Spielergebnissen hätte und zugleich auf der rechten einen Frame mit einem Spielbericht, den man über verschiedene Links von der Tabelle aus aufrufen kann. Das wäre also alles Wikipedia-Intern. --Korrektor123 (Diskussion) 10:14, 26. Dez. 2013 (CET)
- Dafür gibt es Inhaltsverzeichnisse. Zu große Artikel (ab ca. 200 kB) teilen wir auf mehrere auf. Bei zu ausufernde Tabellen sollte es auch erlaubt sein, zu fragen, ob das überhaupt noch in eine Universalenzyklopädie gehört. In jedem Fall denke ich, dass das hier die falsche Diskussionsseite dafür ist. Vielleicht nach WP:WGAA verschieben? --TMg 15:14, 26. Dez. 2013 (CET)
- Was spricht gegen ein Design, das sich an dieses anlehnt? 213.54.156.252 20:59, 4. Jan. 2014 (CET)
Genaugenommen ist eine Umsetzung pedantisch und sinnlos
Seit HTML4 (1997) wird vom W3C versucht HTML-Elemente durch (das damals neue) CSS zu ersetzen, was dann dann in XHTML weitergeführt und schlussendlich in die Sackgasse von XHTML-2.0 geführt hat. Deshalb begann – vom W3C losgelöst – die Entwicklung von HTML5, mit Besinnung auf alte Werte (und Rehabilitierung von Elementen). Es ist doch wohl mehr als bezeichnend, dass Elemente die seit 15 Jahren als überholt gelten/galten, sich immer noch eine sehr lebendigen Verwendung erfreuen (ich selber habe diese massenhaft überall in DE.WP in deutscher Regel- u. Gründlichkeitsmanier getilgt). Daher mein Fazit: Nicht die Anwender sind die Dummen, sondern... Gerade hier in einer MediaWiki-Umgebung ist eine Ersetzung von benutzerfreundlichen Tags durch CSS vollkommen kontraproduktiv (wie man auch in der ein oder anderen Kritik zu hören bekommt). Wie auch immer, das wäre eh eine Angelegenheit bzw. Forderung von Wikimedia und nicht uns. In diesem Zusammenhang möchte ich die Ersetzung von Attributen und CSS-Klassen mal außer Acht lassen. PS: Um die Absurdität noch etwas zu verdeutlichen, hüben wie drüben sind sog. "überholte Elemente" in den Standard-Werkzeugleisten (der Wikimedia, z.B. big
von den ganzen Erweiterungen gar nicht zu reden). → User: Perhelion 23:27, 27. Jul. 2014 (CEST)
- PPS: Ums jetzt noch deutlicher zu sagen, das wäre das Selbe als wenn wir die WikiMarkup in HTML umwandeln würden, CSS geht dann schon fast in Richtung Scriptsprache (vgl. jQuery - JS) um nicht zu sagen Webprogrammierer, kurz gesagt: einfach anwenderunfreundlich. → User: Perhelion 23:58, 27. Jul. 2014 (CEST)
Begrenztes Aufgabenfeld
Laut Help:Tags ist der Wikitext weiterhin mehr XML/XHTML als HTML5 und soll dies auch bis auf Weiteres bleiben. Das sollte natürlich prominent in umseitiger Einleitung stehen um etwaige Missverständnisse klarzustellen. Auch wenn scheinbar eine klare Aussage direkt von Wikimedia fehlt.HTML5 zweierlei Maß ↔ User: Perhelion 20:53, 13. Nov. 2014 (CET)
Was mir spanisch vorkommt
Was bedeutet „<span></span>“, und kann die Kombination ohne Objekt dazwischen sinnvoll gebraucht werden? --Georg Hügler (Diskussion) 08:58, 13. Apr. 2021 (CEST)
Hinweis auf kostenlose Literatur-Zugänge für Wikipedia-Aktive
Liebe Mitarbeitende vom WikiProjekt HTML5,
ich möchte euch gerne auf das Förderprogramm der Wikimedia-Vereine aufmerksam machen.
Wer einen Artikel schreiben oder überarbeiten möchte und dazu ein bestimmtes Fachbuch gebrauchen könnte, kann von den Wikimedia-Fördervereinen kostenlose Zugängen zu Fachliteratur erhalten. Weitere Informationen zur Literaturvergabe und andere Unterstützungsmöglichkeiten, wie die Erstattung von Bibliothekskosten, sind hier zu finden.
Sonstige Formen der Unterstützung, wie E-Mail-Adressen für Freiwillige, Trainingsangebote und anderes, sind unter Wikipedia:Förderung aufgeführt.
Es wäre sinnvoll, dass auch zukünftig Aktive und Neue in diesem Themenbereich auf das leider oft nicht bekannte Förderangebot hingewiesen werden und von kostenlos zur Verfügung gestellter Literatur profitieren können. Daher würde ich mich freuen, wenn ihr einen entsprechenden Hinweis dauerhaft an geeigneter Stelle dieses WikiProjekts platzieren möchtet, beispielsweise an geeigneter Position auf der Projektseite, oder als fixierter Hinweis oberhalb der Diskussionsbeiträge auf dieser Diskussionsseite. Als Vorschlag könnte die unter meiner Signatur folgende Vorlage verwendet werden – dazu einfach nur das „XY“ mit dem entsprechenden Themenbereich ersetzen.
Solltest du weitere Fragen zur Förderung haben, kannst du dich entsprechend deines Wohnsitzes an Wikimedia Deutschland (communitywikimedia.de), Wikimedia Österreich (vereinwikimedia.at) oder WMCH (ulrich.lantermannwikimedia.ch) wenden. Da dieser Hinweis auf mehreren Projektseiten platziert wird, möchte ich euch bitten, Fragen und Rückmeldungen zu dieser Kampagne dort auf der Diskussionsseite zu stellen, damit diese an zentraler Stelle gesammelt und beantwortet werden können.
Viele Grüße --Nico (WMDE) (Diskussion) 14:36, 16. Sep. 2021 (CEST)
Vorschlag zur dauerhaften Platzierung des Förderhinweises an geeigneter Stelle:
Wenn du einen Artikel im Themenbereich XY schreiben oder überarbeiten möchtest und dazu ein bestimmtes Fachbuch gebrauchen könntest, kannst du von den Wikimedia-Fördervereinen kostenlose Zugänge zu Fachliteratur erhalten. Weitere Informationen zur Literaturvergabe und andere Unterstützungsmöglichkeiten wie die Erstattung von Bibliothekskosten sind hier zu finden. |