Anklickbare Beispiele, HTML-Referenz und Kleinigkeiten
dedlfix
Anklickbare Beispiele, HTML-Referenz und Kleinigkeiten
dedlfix
Hi!
Einige werden es vielleicht schon entdeckt haben, weil ich auf einer Diskussionsseite zur Wiki-FAQ versteckt darauf verlinkt habe: Das SELFHTML-Wiki hat eine Spielwiese zum Testen bekommen. Darauf gibt es ein paar allgemeine Dinge.
* Test der neuen Mediawiki-Version 1.16 (immer noch beta)
* Implementierung des überarbeiteten Skins, u.a. mit etwas kräftigeren Linkfarben
* überarbeitete Vorlage Iconset (Die Übernahme in das offizielle Wiki scheiterte, weil ich Funktionen verwendete, die in der Version 1.15 nicht zur Verfügung stehen und auch nicht implementierbar sind.)
Bis das im offiziellen Wiki landen kann, muss erstmal die Version 1.16 offiziell freigegeben werden und die Extensions ordentlich damit arbeiten. Ersteres steht wohl unmittelbar bevor, Probleme bereitet derzeit noch die DPL-Extension, die für eine automatische Listengenerierung zuständig ist.
Doch nun zu den beiden wichtigsten Neuerungen:
* Anklickbare Beispiele
* HTML-Referenz
Alles Erwähnte ist übrigens von der Test-Wiki-Startseite aus verlinkt.
Für die anklickbaren Beispiele habe ich eine Lösung erarbeitet, die zumindest aus Lesersicht schon nutzbar ist. Der Leser findet einen "So sieht's aus"-Link in der Beispielbox. Der auszuführende Beispiel-Code befindet sich in einem eigenen Namensraum. Um darin schreiben zu können, gibt es ein spezielles Administratoren-Recht. Auf der To-Do-Liste steht noch, einen Mechanismus zu suchen, der halbautomatisch den Code aus der Beispiel-Box, der ja - um es nicht zu einfach zu machen :-) - mit Wiki-Syntax gespickt sein kann, zu übernehmen und die entsprechende Beispiel-Namensraum-Seite damit zu erstellen. Auch bei Änderungen wäre eine Benachrichtigung wünschenswert, damit der Beispielbox-Code nicht unbemerkt dem Ausprobier-Code davonläuft.
Derzeit ist allerdings nur clientseitiger Code berücksichtigt, also HTML, CSS, Javascript, was aber vorläufig für die meisten Fälle reichen sollte. Für beispielsweise PHP-Code, der auf dem Server laufen soll, muss noch eine Sandbox-Lösung erarbeitet werden.
Die HTML-Referenz habe ich mit einem selbstgeschriebenen Programm erstellt, das die DTDs (von derzeit HTML 4.01 und XHTML 1.0) liest, die Referenz-Seiten erstellt und per Wikibot ins Wiki befördert. Da ist sicher noch nicht alles perfekt. Und teilweise lässt sich auch nicht unbedingt ein perfektes Ergebnis erzielen, wenn sich der Programmier-Aufwand in Grenzen halten soll.
Zum Vergleich die <http://de.selfhtml.org/html/referenz/elemente.htm@title=HTML-Referenz 8.1.2>. Sie trennt Element- und Attributebeschreibung, was zwei ewig lange Seiten ergibt und auch suchtechnisch für das Wiki nicht sehr gut ist. Deswegen teilte ich das auf ein Element pro Seite auf. Das ergibt (neben einer relativ kurzen URL) auch noch recht große Seiten (die teilweise die magische 32kb-Grenze überschreiten. Die haben wohl einige Browser, wenn es darum geht, Text in einer Textarea unterzubringen - sagt zumindest die automatische Warnung der Wiki-Software. Welche Browser sollen das sein und sind die noch relevant?) Und aufgrund der teilweise minimalen Unterschiede zwischen den Varianten (Strict, Transitional und Frameset) ergeben sich mitunter erhebliche Redundanzen. Die bisherige Referenz erwähnt die Unterschiede in der Regel "nur nebenbei". Ich fand es wichtiger, jeweils einen kompletten Überblick zu haben, und nicht erst durch Zusatzinformation die Regeln der jeweiligen Variante herausfinden zu müssen.
An der nicht funktionierenden Auflistung im unteren Teil der Referenz-Einstiegsseite ist derzeit die DPL-Extension (zum automatischen Generieren von Listen) schuld, die noch nicht Mediawiki-1.16-tauglich ist.
Um Kritik und Meinungen muss ich vermutlich nicht erst lange bitten :-)
Lo!
-
Doch nun zu den beiden wichtigsten Neuerungen:
* Anklickbare Beispiele
* HTML-Referenz...
Die HTML-Referenz habe ich mit einem selbstgeschriebenen Programm erstellt, das die DTDs (von derzeit HTML 4.01 und XHTML 1.0) liest, die Referenz-Seiten erstellt und per Wikibot ins Wiki befördert. Da ist sicher noch nicht alles perfekt. Und teilweise lässt sich auch nicht unbedingt ein perfektes Ergebnis erzielen, wenn sich der Programmier-Aufwand in Grenzen halten soll.
Das scheint noch nicht vollständig zu sein. Zum Beispiel sind die Attribute nicht abfragbar. Aber das wird wohl noch kommen. Der Ansatz sieht gut aus.
Ich frage mich aber, wie die Referenz für HTML5 aufgebaut sein wird.mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
Hi!
* HTML-Referenz
Das scheint noch nicht vollständig zu sein. Zum Beispiel sind die Attribute nicht abfragbar. Aber das wird wohl noch kommen. Der Ansatz sieht gut aus.Das ist eigentlich inhaltlich alles vollständig, wenn ich da nichts übersehen habe. Was konkret vermisst du denn?
Ich frage mich aber, wie die Referenz für HTML5 aufgebaut sein wird.
Da wird es doch wohl nicht die riesigen Unterschiede geben, als dass die Referenz anders strukturiert werden muss, oder? Ich hab grad keine DTD finden können. Gibt es da schon eine? Wird es überhaupt eine geben?
Lo!
-
Das scheint noch nicht vollständig zu sein. Zum Beispiel sind die Attribute nicht abfragbar. Aber das wird wohl noch kommen. Der Ansatz sieht gut aus.
Das ist eigentlich inhaltlich alles vollständig, wenn ich da nichts übersehen habe. Was konkret vermisst du denn?
{%attlist} etc... werden verlinkt. Aber die Links führen derzeit nirgendwo hin.
Ich frage mich aber, wie die Referenz für HTML5 aufgebaut sein wird.
Da wird es doch wohl nicht die riesigen Unterschiede geben, als dass die Referenz anders strukturiert werden muss, oder? Ich hab grad keine DTD finden können. Gibt es da schon eine? Wird es überhaupt eine geben?
Es wird keine geben. Das ist ja das Problem.
Aber irgend eine Datenbank müssen auch die beim w3c in den Validator füttern.Es gibt einige semantische Unterschiede in HTML5, nebst den gelöschten / neuen Attributen / Elementen.
Aber Semantik wurde bisher ja auch nicht via DTD verdeutlicht.mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
Hi!
Das scheint noch nicht vollständig zu sein. Zum Beispiel sind die Attribute nicht abfragbar.
Das ist eigentlich inhaltlich alles vollständig, wenn ich da nichts übersehen habe. Was konkret vermisst du denn?
{%attlist} etc... werden verlinkt. Aber die Links führen derzeit nirgendwo hin.Wenn du %foo verlinkt siehst, dann hast du Javascript eingeschaltet und bekommst beim Draufklicken die zugehörige Liste (das was sich hinter dem DTD-Entity verbirgt) ausgeklappt. Wenn du Javascript deaktiviert hast, siehst du sowieso alles und %foo bleibt ein span. Ich weiß grad nicht mehr, warum ich mich bei der Verbergen-Vorlage für einen a-Element entscheiden habe. Eigentlich tut's ja auch ein onclick-Eventhandler und etwas CSS auf dem Schalter-span. Da muss ich nochmal drüber nachdenken und ein, zwei Tests machen.
Aber Semantik wurde bisher ja auch nicht via DTD verdeutlicht.
Wichtig sind ja auch die Schachtelungsregeln, die sich ja hauptsächlich aus so einer DTD herauslesen lassen. Und die sind ja bei HTML5 noch nicht abgeschafft.
Lo!
-
Wenn du %foo verlinkt siehst, dann hast du Javascript eingeschaltet und bekommst beim Draufklicken die zugehörige Liste (das was sich hinter dem DTD-Entity verbirgt) ausgeklappt.
Jetzt beim 2.versuch habe ich es verstanden.
Man kann die Attributgruppen zuschaltend einblenden.
Was mir aber in der Liste missfällt:
Es ist nicht sofort deutlich, welches Attribut zu welcher Attributgruppe gehört.
Das müsst etwas klarer werden.Beispiel onload, gehört das zu den event-Attributen, oder ist es speziell für dieses Element?
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
Hi!
Wenn du %foo verlinkt siehst, dann hast du Javascript eingeschaltet und bekommst beim Draufklicken die zugehörige Liste (das was sich hinter dem DTD-Entity verbirgt) ausgeklappt.
Jetzt beim 2.versuch habe ich es verstanden.
Man kann die Attributgruppen zuschaltend einblenden.Ist also nicht unbedingt intuitiv und besonders schön ist das mit der Notation "%foo" eigentlich auch nicht - wie gehts besser?
Was mir aber in der Liste missfällt:
Es ist nicht sofort deutlich, welches Attribut zu welcher Attributgruppe gehört.
Das müsst etwas klarer werden.Hab ich auch schon drüber nachgedacht. Aufgrund der Universalität von attr hab ich aber etwas Platz sparen wollen und das in einer Zeile zusammengefasst (jedenfalls, wenn es zugeklappt ist). Eine Alternative wäre eine Anordnung der drei attr-Gruppen wie bei beispielsweise cell(h/v)align von td. Wobei dann immer noch nicht der Übergang von gruppierten Attributen zu den Einzelgängern sichtbar wird. Vielleicht ein leicht grauer Hintergrund für die Gruppen oder eine doppelte Zellwand an ihren Enden?
Beispiel onload, gehört das zu den event-Attributen, oder ist es speziell für dieses Element?
Im Grunde sind alle Attribute eines Elements gleichwertig. Ob speziell bei body nun das onload zur %events-Gruppe zählt oder nicht, spielt letztlich keine Rolle. Die Zusammenfassung zu Gruppen gibt es ja nur, damit man sich das wiederholte Erklären der Universalattribute sparen kann und einen Wiedererkennungseffekt hat.
Lo!
-
Beispiel onload, gehört das zu den event-Attributen, oder ist es speziell für dieses Element?
Im Grunde sind alle Attribute eines Elements gleichwertig. Ob speziell bei body nun das onload zur %events-Gruppe zählt oder nicht, spielt letztlich keine Rolle. Die Zusammenfassung zu Gruppen gibt es ja nur, damit man sich das wiederholte Erklären der Universalattribute sparen kann und einen Wiedererkennungseffekt hat.
Wenn du diese Reihenfolge hast
attr (%coreattr %evtattr)Dann sollten die Attribute in dieser Reihenfolge erscheinen, was sie derzeit nicht tun.
Zwischen den Gruppen mag dann eine etwas fettere Linie genügenmfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
Hi!
Wenn du diese Reihenfolge hast
attr (%coreattr %evtattr)Dann sollten die Attribute in dieser Reihenfolge erscheinen, was sie derzeit nicht tun.
Wo ist denn das nicht der Fall?
Lo!
-
Wenn du diese Reihenfolge hast
attr (%coreattr %evtattr)Dann sollten die Attribute in dieser Reihenfolge erscheinen, was sie derzeit nicht tun.
Wo ist denn das nicht der Fall?
Das kommt darauf an, wie ich
%attr (%coreattrs, %i18n, %events)
zu verstehen habe.
Bezieht sich %attr auf die immer sichtbaren?
Deiner Meinung nach nicht.
Aber für mich ist es nicht klar. Ich assoziiere %attr mit den sichtbaren Attributen.Das ist reichlich verwirrend. Für dich ist es selbsterklärend, für mich nicht.
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
Hi!
Dann sollten die Attribute in dieser Reihenfolge erscheinen, was sie derzeit nicht tun.
Wo ist denn das nicht der Fall?
Das kommt darauf an, wie ich
%attr (%coreattrs, %i18n, %events)
zu verstehen habe.
Bezieht sich %attr auf die immer sichtbaren?
Deiner Meinung nach nicht.Dazu muss man die DTD kennen. Die drei Zusammenfassungen %coreattrs, %i18n und %events sind ihrerseits wieder in %attrs zusammengefasst. Und das %attrs steht dann in der Attributliste der meisten Elemente (einige kennen keine Universalattribute (z.B. base, script), andere nur %i18n (z.B. head, title, meta)).
<!ENTITY % coreattrs
[Attributauflistung für id, class, style, title]
><!ENTITY % i18n
[Attributauflistung für lang und dir]
><!ENTITY % events
[Attributauflistung für on... (click-, mouse- und key-Events)]
>Zusammenfassung:
<!ENTITY % attrs "%coreattrs; %i18n; %events;">
Verwendung am Beispiel von COL
<!ATTLIST COL -- column groups and properties --
%attrs; -- %coreattrs, %i18n, %events --
span NUMBER 1 -- COL attributes affect N columns --
width %MultiLength; #IMPLIED -- column width specification --
%cellhalign; -- horizontal alignment in cells --
%cellvalign; -- vertical alignment in cells --
>Da sind zu sehen %attrs, die beiden individuellen Attribute span und width sowie die auch bei weiteren Tabellen-Elementen verwendeten Gruppen %cellhalign (3 Attribute) und %cellvalign (1 Attribut).
Aber für mich ist es nicht klar. Ich assoziiere %attr mit den sichtbaren Attributen.
Ich sehe schon, hier muss noch was verändert werden.
Vielleicht so: Die Nicht-%attrs-Zusammenfassungen sind meist recht kurz, weswegen sie unklappbar und ohne Zwischenüberschrift im aufgelösten Zustand zu sehen sein sollten. Die %attrs könnten aufklappbar aber als ein Block mit dem Namen "Universalattribute" eingefügt sein.Das ist reichlich verwirrend. Für dich ist es selbsterklärend, für mich nicht.
Selbsterklärend ist es nicht, aber ich weiß das mittlerweile.
Ein vergleichbares Verwirrungspotential sehe ich bei der Auflistung der Kindelemente. Einerseits wäre eine Zusammenfassung nach %block, %inline und zusammenfassend %flow recht sinnvoll, weil es oft verwendet wird. Andererseits ist das was dann in %block und %flow enthalten ist, in weiteren Untergruppen zusammengefasst, was eine Menge Klicks erfordert, sich das anzuzeigen. Das im Seitenanfang befindliche "Alles anzeigen" kann da eine Klickerleichterung sein, aber das muss man erst einmal entdecken. Hier bietet es sich vielleicht an, bis auf %block und %inline alles sofort aufzulösen und die beiden zugeklappt als "Block-Elemente" und "Inline-Elemente" anzubieten.
Lo!
-
Die Idee, Attribut-Gruppen zusammenzufassen, finde ich generell richtig.
Aber wie diese Gruppen dargestellt werden, muss allgemeinen Konventionen (nicht jener der DTD Konvention) gehorchen.Folgender Vorschlag zur Anzeige bei Attributen.
Erlaubte Attribute:
▸ attributX
▸ attributY
▸ attributZ
[-] (AttributGruppe1)
[+] (AttributGruppe2)
▸ attributXvonGruppe2
▸ attributYvonGruppe2
▸ attributZvonGruppe2
[-] (AttributGruppe3)Für jede Gruppe brauchst du eine Tabellenzeile mit einem colspan.
Anstelle von %events sollte (da der Platz zur Verfügung steht) auch ein verstänlicheres Label geäjlt werden.
Universal-Attribute
I18n-Attribute
Event-AttributeLeider haben wir keine Unicode Punkte, die öffnen/schliessen versinnbildlichen.
Ein vergleichbares Verwirrungspotential sehe ich bei der Auflistung der Kindelemente. Einerseits wäre eine Zusammenfassung nach %block, %inline und zusammenfassend %flow recht sinnvoll, weil es oft verwendet wird. Andererseits ist das was dann in %block und %flow enthalten ist, in weiteren Untergruppen zusammengefasst, was eine Menge Klicks erfordert, sich das anzuzeigen. Das im Seitenanfang befindliche "Alles anzeigen" kann da eine Klickerleichterung sein, aber das muss man erst einmal entdecken. Hier bietet es sich vielleicht an, bis auf %block und %inline alles sofort aufzulösen und die beiden zugeklappt als "Block-Elemente" und "Inline-Elemente" anzubieten.
Da habe ich noch keine Idee dazu.
Versuche gleiche Symbole zu verwenden wie im obigen Fall. Semantisch wird es sich wohl um Listen handeln.
Ob die Listenpunkte dann gefloatet werden, ist sekundär in der Betrachtung.Auch hier würde ich auf deutschliche Label statt auf DTD-Identifier %whatthefuck setzen.
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
Hi!
Die Idee, Attribut-Gruppen zusammenzufassen, finde ich generell richtig.
Ich will es nur nicht übertreiben, weil die Gruppierung außer bei den Universalattributen (core + i18n + events) aus Anwendersicht nichts bringt. Oder anders gesagt, es ist in der Regel (außer bei den Universalattributen) nicht bekannt, dass einige Attribute gruppiert wurden. Das ist hauptsächlich ein DTD-Ding. Die Universalattribute bilden hier eine Ausnahme. Da sie fast jedes Element kennt, "langweilt" es irgendwann, wenn sie ständig aufgeführt sind und man kann schlechter die individuellen Attribute finden. Deswegen war mein Vorschlag, nur sie als eine große Gruppe klappbar zu gestalten und alles anderen Gruppen gleich aufzulösen.
Leider haben wir keine Unicode Punkte, die öffnen/schliessen versinnbildlichen.
Schon die Absenz globaler verständlicher Symbole für allgemeines Öffnen und Schließen ist hier das bremsende Element. Gegen fehlende Zeichen in Unicode kann man mit Grafiken kontern.
Ein vergleichbares Verwirrungspotential sehe ich bei der Auflistung der Kindelemente. [...]
[...] Semantisch wird es sich wohl um Listen handeln.
Ob die Listenpunkte dann gefloatet werden, ist sekundär in der Betrachtung.Nicht wirklich. Auf den ersten Blick sieht es wie eine Aufzählung aus, aber das täuscht, weil zwischen den Elementen Verknüpfungs- und Reihenfolgebedingungen eingearbeitet sind und für die Elemente oder Gruppen unterschiedliche Wiederholungen gestattet sind.
Auch hier würde ich auf deutschliche Label statt auf DTD-Identifier %whatthefuck setzen.
Ja, das bedeutet aber Arbeit, sich da zum einen verständliche Übersetzungen zu suchen (kleines Problem), die auch noch einzeln für jedes dieser Entitys zu berücksichtigen (schon aufwendiger) und dann bleibt wieder die Sinnfrage aus Anwendersicht, weil die Gruppierung mit Ausnahme von Block- und Inline-Elementen wieder nur so ein DTD-Ding ist. Deswegen sähe ich auch hier gern wieder einen Kompromiss: Alles auflösen außer Block und Inline, und denen richtige Namen geben.
Lo!
-
Hi!
Auch hier würde ich auf deutschliche Label statt auf DTD-Identifier %whatthefuck setzen.
[...] Alles auflösen außer Block und Inline, und denen richtige Namen geben.So ist es jetzt auf der Spielwiese umgesetzt. Block und Inline sind bei den Kindelementen geblieben, alles andere aufgelöst. Und bei den Attributen sind nur noch die Universalattribute als eine klappbare Gruppe vorhanden.
Lo!
-
-
-
-
-
-
-
-
-
-
-
-