nicht angemeldet Robert B.
Auge
Robert B.
marctrix
Matthias Apsel
Rolf B
Matthias Apsel
Matthias Apsel
Rolf B
Matthias Apsel
Rolf B
Rolf B
Matthias Apsel
Rolf B
Hallo Forum,
in der HTML-Referenz zum fieldset-Element steht:
Darf vorkommen in:
allen Fluss-Elementen
Elemente: … p …
Dementsprechend sollte folgender HTML-Code so, wie er ist, behandelt werden:
<fieldset><legend>Author</legend>
<p>
<label><input type="radio" name="author" value="-"/>None</label>
<fieldset><legend>Me</legend>
<label><input type="radio" name="author" value="uid"/>User-ID</label>
<label><input type="radio" name="author" value="name"/>Name</label>
</fieldset>
<label><input type="radio" name="author" value="m"/>Manager</label>
</p>
</fieldset>
Im DOM-Inspector sowohl von Firefox als auch Chrome sehe ich hingegen:
<fieldset>
<legend>Author</legend>
<p>
<label><input type="radio" name="author" value="-"/>None</label>
</p>
<fieldset>
<legend>Me</legend>
<label><input type="radio" name="author" value="uid"/>User-ID</label>
<label><input type="radio" name="author" value="name"/>Name</label>
</fieldset>
<label><input type="radio" name="author" value="m"/>Manager</label>
<p></p>
</fieldset>
Das fieldset ist also tatsächlich nicht im p enthalten. Ist das ein Fehler im Wiki, in der Spec oder in den Browsern?
Viele Grüße
Robert
Matthias Apsel
Hallo
[
fieldset] Darf vorkommen in:allen Fluss-Elementen
Elemente: … p …
Im DOM-Inspector sowohl von Firefox als auch Chrome sehe ich
<fieldset> <legend>Author</legend> <p> <label><input type="radio" name="author" value="-"/>None</label> </p> <fieldset> <legend>Me</legend> <label><input type="radio" name="author" value="uid"/>User-ID</label> <label><input type="radio" name="author" value="name"/>Name</label> </fieldset> <label><input type="radio" name="author" value="m"/>Manager</label> <p></p> </fieldset>Das fieldset ist also tatsächlich nicht im p enthalten. Ist das ein Fehler im Wiki, in der Spec oder in den Browsern?
Ich vermute mal, dass das daran liegt, dass p selbst nur Phrasing content (da isser wieder) enthalten darf (nach alter Definition: keine Blockelemente). Dein p wird also vor dem fieldset implizit geschlossen. Auch das leere Element p vor dem das fieldset schließenden Tag weist darauf hin.
Tschö, Auge
Hallo @Auge,
Das fieldset ist also tatsächlich nicht im p enthalten. Ist das ein Fehler im Wiki, in der Spec oder in den Browsern?
Ich vermute mal, dass das daran liegt, dass
pselbst nur Phrasing content (da isser wieder) enthalten darf (nach alter Definition: keine Blockelemente). Deinpwird also vor demfieldsetimplizit geschlossen. Auch das leere Elementpvor dem dasfieldsetschließenden Tag weist darauf hin.
Das wäre dann ein Fehler im Wiki, oder? Denn wenn p fieldset enthalten dürfte, wäre mein geschriebener Code ja richtig.
Viele Grüße
Robert
hallo
in p darf nur phrasing content vorkommen. fieldset ist aber erlaubt wo flow content erwartet wird.
hallo
Hallo @beatovich,
also stimmt die Information im Wiki nicht.
Die Aussage
Darf vorkommen in:allen Fluss-Elementen
Info: Fluss-Elemente (flow content)
ist verschieden von der w3c Formulierung:
fieldset ist erlaubt wo flow-content erwartet wird.
Ja die Aussage ist falsch.
Hej beatovich,
fieldset ist erlaubt wo flow-content erwartet wird.
Ja die Aussage ist falsch.
Wer kann es korrigieren. Ich habe da keinen bearbeiten-Button?!?
Marc
Hallo marctrix,
Wer kann es korrigieren. Ich habe da keinen bearbeiten-Button?!?
Die Seite ist nicht geschützt. In der oberen Leiste sollte es neben „Referenz“ auch „Bearbeiten“ geben.
Bis demnächst
Matthias
Hallo beatovich,
Die Aussage
Darf vorkommen in:allen Fluss-Elementen Info: Fluss-Elemente (flow content)ist verschieden von der w3c Formulierung:
fieldset ist erlaubt wo flow-content erwartet wird.
Ja die Aussage ist falsch.
Ja. Allerdings ist die Aussage fieldset ist erlaubt wo flow-content erwartet wird völlig unbrauchbar (Rote Autos sind erlaubt, wo Autos erlaubt sind), wenn man die Frage beantworten möchte, innerhalb welcher Elemente fieldsets erlaubt sind.
Bis demnächst
Matthias
Hallo Matthias,
nein, das ist genau richtig so und ich habe das jetzt auch eingepflegt.
Edit: Ich dachte ich hätte. Ist wieder weg. Und kein Revert in der History. Hä???
Die Spec formuliert das konsequent so. <fieldset> darf da vorkommen, wo Flow-Elemente erlaubt ist. D.h. da, wo nur eine Teilmenge von Flow-Elementen erlaubt ist (wie Phrasing Content in <p>, da ist <fieldset> nicht erlaubt, weil es nämlich in keiner Teilmenge von Flow enthalten ist.
Die Aussage "ein rotes Auto ist da erlaubt, wo Kraftfahrzeuge erlaubt sind", würde z.B. Orte ausschließen, die nur Motorräder erlauben.
Bei Flow-Elementen ist es etwas schwierig, Gegenbeispiele zu machen, weil die fast alles umfassen. Nehmen wir <output>. Das ist Phrasing Content, aber nicht Embedded oder Interactive. Deswegen darf ich <output> in Elementen verwenden, die Phrasing erlauben. In Elementen, die nur Interactive Content erlauben, ist <output> verboten.
Rolf
Hallo Rolf B,
Die Spec formuliert das konsequent so. <fieldset> darf da vorkommen, wo Flow-Elemente erlaubt ist. D.h. da, wo nur eine Teilmenge von Flow-Elementen erlaubt ist (wie Phrasing Content in <p>, da ist <fieldset> nicht erlaubt.
Ja. Hilfreich ist es trotzdem nicht. Weil ich eben ohne umfangreiches zusätzliches Wissen nicht erkennen kann, dass fieldset in p nicht erlaubt ist.
Wahrscheinlich sind noch viele weitere Referenz-Seiten genauso falsch, wie fieldset war.
Bis demnächst
Matthias
Hallo Matthias Apsel,
Ja. Hilfreich ist es trotzdem nicht. Weil ich eben ohne umfangreiches zusätzliches Wissen nicht erkennen kann, dass fieldset in p nicht erlaubt ist.
Um das noch deutlicher zu formulieren: Ich bin dagegen, dass das so im Wiki erscheint (so falsch wie es war, darf es natürlich auch nicht bleiben). Eine Aufzählung aller möglichen Elternelemente halte ich für deutlich hilfreicher.
Bis demnächst
Matthias
hallo
Hallo Matthias Apsel,
Ja. Hilfreich ist es trotzdem nicht. Weil ich eben ohne umfangreiches zusätzliches Wissen nicht erkennen kann, dass fieldset in p nicht erlaubt ist.
Um das noch deutlicher zu formulieren: Ich bin dagegen, dass das so im Wiki erscheint (so falsch wie es war, darf es natürlich auch nicht bleiben). Eine Aufzählung aller möglichen Elternelemente halte ich für deutlich hilfreicher.
Wir haben es hier mit Klassen und Kontexten zu tun. Es gibt Klassen von Elementen die in einem Kontext erscheinen dürfen, die aber eventuell einen anderen Kontext hervorbringen.
fieldset darf in allen flow-context-erzeugenden Elementen vorkommen. und dazu passt dann der Link zu flow-context-erzeugenden Elementen.
fieldset ist selbst ein flow-context-erzeugendes Element.
Hallo Matthias,
einverstanden. Aber das ist natürlich eine Menge Arbeit, weil man es auf jeder Referenzseite tun muss.
An den Eltern-Elementen befindet sich jeweils ein Popup. Wenn in der Referenz steht "Element darf da stehen wo Flow-Content erwartet wird", dann ist da aktuell ein Popup drunter das alle Elemente aufzählt die Flow-Content SIND. Das ist dann Unfug, man bräuchte analog zu Referenz:HTML/Fluss-Elemente auch eine Übersicht Referenz:HTML/Elemente-mit-Fluss-Inhalt, oder so (weiß nicht ob das ein passender Namen ist) die man dann in der Elementreferenz aufklappen kann.
Haben wir da schon was?
Brauchen wir als Arbeitsgrundlage eine spec-validierte Liste aller HTML Elemente mit ihrer eigenen Kategorie und der Kategorie des erwarteten Inhalts? Ich würde das <i> dazu mitnehmen und eine Excel-Tabelle oder so als Arbeitsgrundlage produzieren, es wird nur ein paar Tage dauern. Diese Tabelle könnte man dann auch ins Wiki übernehmen.
Rolf
Hallo Rolf B,
Wenn in der Referenz steht "Element darf da stehen wo Flow-Content erwartet wird", dann ist da aktuell ein Popup drunter das alle Elemente aufzählt die Flow-Content SIND. Das ist dann Unfug,
Ja, das habe ich inzwischen verstanden.
man bräuchte analog zu
Referenz:HTML/Fluss-Elementeauch eine ÜbersichtReferenz:HTML/Elemente-mit-Fluss-Inhalt, oder so (weiß nicht ob das ein passender Namen ist) die man dann in der Elementreferenz aufklappen kann.
Genau das habe ich mir auf dem Heimweg auch überlegt.
Haben wir da schon was?
Nein, aber das bedeutet nur geringen Arbeitsaufwand, wenn …
Brauchen wir als Arbeitsgrundlage eine spec-validierte Liste aller HTML Elemente mit ihrer eigenen Kategorie und der Kategorie des erwarteten Inhalts? Ich würde das <i> dazu mitnehmen und eine Excel-Tabelle oder so als Arbeitsgrundlage produzieren, es wird nur ein paar Tage dauern. Diese Tabelle könnte man dann auch ins Wiki übernehmen.
… es die inhaltliche Zuarbeit gäbe. Ich bin übrigens recht sicher, dass die bereits vorhandenen Gruppen korrekt sind.
Bis demnächst
Matthias
Hallo Matthias,
Ich bin übrigens recht sicher, dass die bereits vorhandenen Gruppen korrekt sind.
Ich nicht, oder ich habe Dich falsch verstanden. Bei vielen Form-Elementen steht z.B. dass sie erlaubt sind wo flow content erlaubt ist. Das ist aber falsch; sie sind erlaubt wo phrasing content erlaubt ist. Wenn ich also bei <select> lese, dass es in Elementen mit Flow-Inhalt erlaubt ist, dann müsste ich daraus schließen, dass ein <select> nicht in einem <label> stehen darf. Weil <label> ja nur phrasing content erlaubt.
Rolf
Hallo Rolf B,
Ich bin übrigens recht sicher, dass die bereits vorhandenen Gruppen korrekt sind.
Ich nicht, oder ich habe Dich falsch verstanden.
Letzteres. Ich meine, dass die aufgezählten Elemente korrekt zugeordnet sind. (https://wiki.selfhtml.org/wiki/HTML/Kategorien_von_Elementen#Kategorien_von_HTML-Elementen)
Bis demnächst
Matthias
Hallo Rolf B,
nein, das ist genau richtig so und ich habe das jetzt auch eingepflegt.
Übrigens hast du die form-Seite bearbeitet, nicht die fieldset-Seite.
Bis demnächst
Matthias
Hallo Matthias,
macht nichts, für Form gilt das gleiche 😀. Verdammt 😕
Wie machen wir das jetzt mit phrasing content? Die Referenz schreibt da ständig Stil-Elemente; das wurde diskutiert und hier umformuliert. Ist das jetzt die neue Sprachregelung oder eine Eintagsfliege?
Grund: Bei <label> steht, dass es in Elementen erlaubt ist die <flow> erwarten. Nicht falsch, aber auch nicht präzise. <label> darf da verwendet werden wo phrasing content erwartet wird. Und weil phrasing eine Teilmenge von flow ist, kann ich <label> auch überall nutzen wo flow erwartet wird. Nur - wenn ich schreibe: <label> geht da wo flow erwartet wird, dann verbietet das den Gebrauch da wo nur phrasing erwartet wird. Das muss also geändert werden, und eventuell muss man einen Text verfassen der diese Sprachregelung der Spec erläutert.
Rolf
Hallo Matthias,
scheitere gerade bei <legend>.
Grund: {{Referenz:HTML/Fluss-Elemente}} ist kaputt, da stimmt die erzeugte HTML Schachtelung am Ende nicht und deswegen kann man keine zwei Referenz-Verweise hintereinander setzen. Das wäre aber nötig, weil legend sowohl phrasing als auch heading content haben darf.
Konkretes Problem: die beiden letzten </div> müssten hinter das letzte </li></ul>.
<div class="note-box note-box-info">
<p class="note-box-title">Information: Fluss-Elemente</p>
<div class="note-box-text">
<ul>
<li>
<b>Elemente:</b>
<a href="/wiki/Referenz:HTML/a" title="Referenz:HTML/a">a</a>
...
, <a href="/wiki/Referenz:HTML/wbr" title="Referenz:HTML/wbr">wbr</a>
</li>
</ul>
<ul>
<li>
<b>Siehe auch:</b>
<a href="/wiki/HTML/Kategorien_von_Elementen" title="HTML/Kategorien von Elementen">Kategorien von HTML-Elementen</a>
</div>
</div>
</li>
</ul>
Da ich es nicht schaffe, die Vorlage:Referenz:HTML zu bearbeiten (weil das im Wiki nur eine Redirektion auf Vorlage:HTML-Referenz ist), muss ich an dieser Stelle aufgeben. Keine Ahnung, wo diese Vorlage steht, das scheint ein Spezial-Hack zu sein.
Rolf
Hallo Rolf B,
scheitere gerade bei <legend>.
Grund:
{{Referenz:HTML/Fluss-Elemente}}ist kaputt, da stimmt die erzeugte HTML Schachtelung am Ende nicht und deswegen kann man keine zwei Referenz-Verweise hintereinander setzen.
Nein, mMn. ist nicht die Vorlage kaputt, sondern Mediawiki verhält sich nicht erwartungsgemäß (Ich möchte eigentlich die Arbeit anderer nicht als kaputt bezeichnen).
Das wäre aber nötig, weil legend sowohl phrasing als auch heading content haben darf.
Da muss getrickst werden, wie auch an anderen Stellen (z.B. https://wiki.selfhtml.org/wiki/Referenz:HTML/a).
Bis demnächst
Matthias
Hallo Matthias,
(Ich möchte eigentlich die Arbeit anderer nicht als kaputt bezeichnen).
Warum nicht? Das erzeugte HTML ist definitiv falsch geschachtelt.
Wenn generierter Output nicht in Ordnung ist, ist der Generator nicht in Ordnung oder der Input des Generators. Oder defekt. Oder kaputt. Synonyme. Ob das aus Mediawiki kommt, aus der Vorlage oder aus Steuertabellen der Vorlange, kann ich nicht beurteilen, ich kenne die Mechanismen nicht die an dieser Stelle ablaufen. Im Referenz-Artikel sieht es so aus, als würde eine Vorlage eingebunden. Und was die produziert, passt nicht.
Wenn mir jemand sagt: Dein Programm XY ist kaputt - ok, dann repariere ich's halt. Bugs kommen vor, das würde ich jetzt nicht persönlich nehmen. Anders wäre es mit "Was Du baust ist eh kaputt" - DAS ist persönlich.
Da muss getrickst werden
Echt jetzt? Eine div Klammer ist natürlich ein Workaround, aber befindet sich das Problem außerhalb dessen, was für SelfHTML an Eigenvorlagen erstellt wurde?
Nachtrag: Habe gerade nochmal die Doku der Verbergen-Vorlage studiert: der Parameter typ=block verdeckt das Problem auch. Offenbar generiert dann die Verbergen-Vorlage das workaround-div. Das HTML der Referenz-Vorlage ist aber immer noch falsch geschachtelt.
Rolf
Hallo Rolf B,
Warum nicht? Das erzeugte HTML ist definitiv falsch geschachtelt.
Nun ja, die Vorlage ist von mir und die enthält kein falsch geschachteltes HTML. Es entsteht erst durch die Interpretation der Mediawiki-Syntax innerhalb von Tabellen.
Das HTML der Referenz-Vorlage ist aber immer noch falsch geschachtelt.
Nein, die Vorlage ist lediglich eine Tabelle.
Bis demnächst
Matthias
Hallo Matthias,
ok, man kann mit {{Referenz:blabla}} also einfach einen Referenz-Artikel inkludieren?
Jetzt komme ich der Sache näher; denn auch das HTML der Referenz:HTML/fließender Inhalt Seite ist kaputt. Eine Liste übrigens, keine Tabelle.
Da ist eine Info-Vorlage mit einer geschachtelten Liste drin, und offenbar poppt der Mediawiki-Renderer den Listenstack nicht, wenn die Info-Vorlage endet, sondern erst am Ende der Datei. Und da hat die INfo-Vorlage bereits ihr </div></div> ausgegeben.
Ein Workaround, der das Problem auf die Info-Seite reduziert, wäre:
{{Info|titel=Elemente, die fließenden Inhalt erlauben|
* '''Elemente:''' [[Referenz:HTML/article|article]]<br>Außerdem gehören mit Einschränkungen folgende Elemente dieser Kategorie an:<br>
** bla
** bla
** bla
* '''Siehe auch:''' dings
<nowiki></nowiki>}}
Die <nowiki></nowiki> Gruppe am Ende terminiert die Liste und produziert keinen Output. Leerzeilen haben nicht geholfen.
Ob man das Problem der nicht beendeten Liste innerhalb der Info-Vorlage lösen kann weiß ich nicht, dafür müsste ich an dieser Vorlage rumbasteln und DAS will ich nicht. Ich weiß auch nicht, ob man damit mehr Probleme schafft als man löst.
Rolf
Hallo Rolf B,
Die <nowiki></nowiki> Gruppe am Ende terminiert die Liste und produziert keinen Output. Leerzeilen haben nicht geholfen.
Gute Idee.
Ob man das Problem der nicht beendeten Liste innerhalb der Info-Vorlage lösen kann weiß ich nicht, dafür müsste ich an dieser Vorlage rumbasteln und DAS will ich nicht. Ich weiß auch nicht, ob man damit mehr Probleme schafft als man löst.
Das Problem müsste man überall da lösen, wo Listen in Vorlagen übernommen werden, und das ist quasi überall. Es fällt eben nur selten auf.
Bis demnächst
Matthias