Gurkenpapst
Mitglied
Registriert: 03.10.2007
Beiträge: 31
|
|
Beim Schreiben von http://www.validome.org/forum/viewtopicp-1041-1.htm habe ich überlegt, ob die Meldung bezüglich des Schachtelungsfehlers nicht möglicherweise sogar falsch ist. Nach einem Blick in die Spezifikation stellte ich fest, dass dies zumindest für das ins- und del-Element der Fall ist:
Code:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title></title>
</head>
<body>
<p>
<ins><div></div></ins>
</p>
</body>
</html> |
ist laut http://www.w3.org/TR/html4/struct/text.html#h-9.4 unzulässig, da hier das ins-Element im inline-Kontext verwendet wird, aber ein Blockelement enthält. Validome aber bemängelt diese Konstellation nicht.
Beitrag geändert von Gurkenpapst (22.04.2008 20:55:16)
|
|
| 22.04.2008 20:54:48 |
|
HTMELL
Administrator
Registriert: 11.05.2006
Beiträge: 544
|
|
Hi,
da diese Regel nicht in einer DTD abzubilden ist, muß wohl wieder einmal eine Heuristik drann ;-)
Das werde ich demnächst erledigen und hier posten.
_______________________________________
mfg
Thomas Mell
www.validome.org
|
|
| 22.04.2008 21:23:56 |
|
Chiaki
Mitglied
Ort: Confoederatio Helvetica
Registriert: 23.12.2007
Beiträge: 97
|
|
Hallo,
dazu liesse sich vielleicht anmerken, dass auch die Fehlermeldung bei verschachtelten
<p>-Elementen überarbeitet werden sollte, weil man damit nicht viel weiterkommt:
Fehler: Zeicheninhalt ist hier nicht erlaubt
Fehlerstelle:<p>Ein Absatz, der <p>noch einen Absatz</p> enthält.</p>
Fehler: Endtag P zu einem nicht vorhandenen Starttag gefunden.
Fehlerstelle: <p>Ein Absatz, der <p>noch einen Absatz</p> enthält.</p> |
Sollte da nicht besser 1 einzige Meldung mit sowas in der Art stehen wie...
Fehler: Innerhalb von P dürfen keine Blockelemente vorkommen.
Fehlerstelle:<p>Ein Absatz, der <p>noch einen Absatz</p> enthält.</p> |
...wobei das "P" als Link auf <http://www.validome.org/lang/ge/help_e/p> verweist.
Greetings, Chiaki
_______________________________________
Make sure You've read RFC 1855, before sending electronic mail,
start Chats, posting on Newsgroups or leave any Comments.
RFC 1855: Netiquette Guidelines <http://www.rfc1855.net/>
|
|
| 22.04.2008 22:13:54 |
|
HTMELL
Administrator
Registriert: 11.05.2006
Beiträge: 544
|
|
Hi,
das Problem liegt mal wieder am HTML, weil einige Elemente nicht geschlossen werden müssen. So macht der SGML-Parser aus
Code:
<p>text<p>noch ein text</p>bla</p> |
das hier
Code:
<p>text</p><p>noch ein text</p>bla</p> |
Er schließt das p-Element wenn ein neues Block-Element auftaucht. Aus diesen Grund ist das letzte "</p>" überflüssig und wird angemeckert.
Das hier ist eigentlich ein Verschachtelungsfehler, ist aber keiner ;-)
Code:
<p>text<p>noch ein text</p>bla<p>blub</p> |
In HTML kein Problem, in XHTML ein Fehler.
Mein Problem besteht nun darin, heuristisch zu erkennen, ob der SGML-Parser eingegriffen hat oder nicht, und das ist (fast) unmöglich. Ich kann leider nicht erkennen ob der User den Fehler produziert hat, oder der Parser (wobei der Fehler immer beim User liegt). Der Parser macht aus "kaputt" "richtig kaputt", woraus allerdings eine andere Fehlermeldung entsteht... ;-))
_______________________________________
mfg
Thomas Mell
www.validome.org
|
|
| 23.04.2008 17:13:36 |
|
HTMELL
Administrator
Registriert: 11.05.2006
Beiträge: 544
|
|
|
| 24.04.2008 17:20:34 |
|
Gurkenpapst
Mitglied
Registriert: 03.10.2007
Beiträge: 31
|
|
Wow, schnell wie immer ...
Ich habe allerdings das Gefühl, dass du dabei etwas über das Ziel hinausgeschossen bist. So wie ich die Spezifikation verstehe, geht es nur darum, dass das ins/del-Elements an Stellen wo nur Inline-Elemente zulässig sind eben als Inline-Element behandelt werden und sie folglich auch keine Blockelemente enthalten dürfen.
Das ist zumindest die einzige Aussage, die ich aus
| The INS and DEL elements must not contain block-level content when these elements behave as inline elements. |
entnehmen kann.
Dort wo nur Blockelemente zulässig sind, werden sie als Blockelemente behandelt und dürfen dann sowohl Block- als auch Inline-Elemente enthalten. Das sind ja zumindest die Regeln für Elemente, die %flow enthalten dürfen.
Nicht ganz sicher bin ich mir bei Elternelementen wie div, die ja selber %flow enthalten dürfen. In der Aussage
| These two elements are unusual for HTML in that they may serve as either block-level or inline elements (but not both). |
irritiert mich das "but not both" etwas. Soweit ich weiß, kann ein Element ja eh nicht beides gleichzeitig sein, in einem Szenario wie
Code:
<div>
<del><span></span></del>
</div> |
könnte aber das del-Element sowohl Block- als auch Inline-Element sein, ohne dass es falsch wäre. Ich vermute daher, dass die zitierte Aussage so zu verstehen ist, dass ein ins/del-Element sich nicht nach "außen" zu seinem Elternelement als Inline-Element geben darf und dann selbst nach "innen" zu seinen Kindelementen als Blockelement auftritt. Das würde sich dann ja auch wunderbar in die Regeln "normaler" Elemente einfügen und die Unzulässigkeit des rot umrahmten Beispiels bestätigen.
Deine Beschreibung der Testseite ist auch darüber hinaus offenbar falsch oder zumindest irgendwie unverständlich:
| Oder sie werden außerhalb von Block-Elementen notiert - dann fungieren sie selber als Block-Elemente |
Wie soll das gehen? Ist nicht das body- und das html-Element selbst schon ein Blockelement?
So wie ich das Auffasse sind die Abschnitte
Code:
10: <span>
11: <ins>
12: <span></span>
13: </ins>
14: </span> |
und
Code:
17: <div>
18: <del>
19: <p></p>
20: </del>
21: </div> |
korrekt, denn hier tritt das Element eindeutig nach "innen" und "außen" gleichzeitig als Inline-Element im ersten und als Blockelement im zweiten Fall auf.
Dagegen ist
Code:
24: <span>
25: <ins>
26: <p></p>
27: </ins>
28: </span> |
sicherlich unzulässig, in span-Elementen können (wie in p-Elementen in dem unzulässigen Beispiel) nun mal nur Inline-Elemente auftreten. Das ins-Element ist hier also nach "außen" klar ein Inline-Element, nach "innen" dagegen müsste es ein Blockelement sein, denn p-Elemente können nicht im Inline-Kontext auftreten. Das widerspricht aber klar der Aussage
| The INS and DEL elements must not contain block-level content when these elements behave as inline elements. |
Nicht ganz sicher bin ich mir im letzten Fall:
Code:
31: <div>
32: <del>
33: <span></span>
34: </del>
35: </div> |
Hier tritt ja genau der oben geschilderte Fall ein, dass das del-Element sowohl Inline- als auch Blockelement sein könnte und ggf. das "but not both" greifen könnte, obwohl ich es eben anders auffasse.
Interessant wäre eventuell noch der Fall
Code:
<body>
<ins>
<span></span>
</ins>
</body> |
Hier muss ja (in den Strict-Varianten von XHTML und HTML) das ins-Element ganz klar ein Blockelement sein und gleichzeitig Inline-Inhalt enthalten dürfen. Das ist zwar nichts ungewöhnliches (siehe das p-Element), aber möglicherweise ist die Spezifikation ja auch so zu verstehen, dass der Code auch beim Entfernen des Elements weiterhin gültig sein muss. Das wäre hier dann ja nicht mehr der Fall.
|
|
| 24.04.2008 18:24:21 |
|
HTMELL
Administrator
Registriert: 11.05.2006
Beiträge: 544
|
|
Hi,
jetzt bin ich etwas verwirrt und muss die Sache erst mal sortieren ;-)
Ich habe die Heuristik dermaßen gestaltet das ich aus der Sicht des ins/del-Elementes dessen Eltern- und Kindelemente betrachtet habe.
Abhängig davon ob es sich jeweils um ein Block- oder Inline-Element handelt, werden die Fehler generiert.
So wie ich das jetzt sehe ist bereits der Ansatz falsch.
Vielmehr müsste ich den Inhaltstyp des Elternelementes überprüfen:
Bei %flow; brauche ich gar nichts zu machen, da sich das ins/del-Element automatisch dessen Kindelement "anpasst", d.h. abhängig vom Kindelement zum Block- oder Inlineelement wird; beides ist bei %flow; erlaubt.
Beide Beispiele wären gültiges HTML:
Code:
<div>
<ins>
<p></p>
</ins>
</div>
<div>
<ins>
<span></span>
</ins>
</div> |
Beim Inhaltstyp %block; wird ins/del zum Blockelement und darf selber %block; oder %inline; enthalten.
Allerdings konnte ich (zumindest in HTML 4.01 Transitional) nur das map-Element als ein solches finden:
Code:
<!ELEMENT MAP - - ((%block;) | AREA)+ -- client-side image map --> |
Interessanterweise wirft der SGML-Parser beim folgenden Beispiel einen Fehler:
Code:
<map name="">
<ins>
<span></span>
</ins>
</map> |
Da ins/del nicht als Blockelement definiert sind, ist das auch logisch. Das hier ist dagegen gültig:
Code:
<map name="">
<p>
<ins>
<span></span>
<p></p>
</ins>
</p>
</map> |
Ich sehe das als Fehler in der DTD und müsste geändert werden:
Code:
<!ELEMENT MAP - - ((%block;) | INS | DEL | AREA)+ -- client-side image map --> |
Zurück zum eigentlichen Thema ;-)
Beim Inhaltstyp %block; muss ich also auch nichts überprüfen.
Bleibt %inline; übrig.
Nur hier muss ich überprüfen ob es sich bei dem Kindelement von ins/del NICHT um ein Blockelement handelt.
Also muss ich bei allen [X]HTML-Versionen händisch die Elemente mit den Inhaltstyp %inline; rausfischen ;-(
PS:
Mir ist noch etwas in der DTD (4.01 Transitional) aufgefallen, was ich mir (bis jetzt) nicht erklären kann.
Wie oben geschrieben wirft der SGML-Parser einen Fehler wenn ein ins/del-Element im map-Element steht.
Warum macht er das nicht bei anderen Elementen?
Code:
<!ELEMENT ADDRESS - - ((%inline;)|P)* -- information on author --> |
Schließlich sind ins/del auch nicht als Inline-Elemente definiert.
_______________________________________
mfg
Thomas Mell
www.validome.org
|
|
| 25.04.2008 13:44:11 |
|
Gurkenpapst
Mitglied
Registriert: 03.10.2007
Beiträge: 31
|
|
| Vielmehr müsste ich den Inhaltstyp des Elternelementes überprüfen |
Darauf läuft es wohl hinaus.
| Bei %flow; brauche ich gar nichts zu machen, da sich das ins/del-Element automatisch dessen Kindelement "anpasst", d.h. abhängig vom Kindelement zum Block- oder Inlineelement wird; beides ist bei %flow; erlaubt. |
Ich bin mir nicht ganz sicher, wie es sich da genau verhält, immerhin gibt es ja die geschilderten Fälle, wo sowohl Block und Inline möglich wären. Das wäre aber eigentlich nur für die Darstellung im Browser interessant, dort würde es ja unterschiedlich aussehen, wenn man dem ins/del-Element einen border geben würde.
Ich stimme dir aber zu, dass hier keine unzulässige Schachtelung auftreten kann.
| Beim Inhaltstyp %block; wird ins/del zum Blockelement und darf selber %block; oder %inline; enthalten. |
Wie schon geschrieben, ich bin mir nicht absolut sicher, ob man durch das Umschließen mit ins/del-Elementen eine sonst ungültige Schachtelung gültig machen kann. Siehe den body-ins-span-Fall in meinem letzten Beispiel. Das body-Element ist ja (in Strict) neben map ein weiterer Kandidat mit %block-Inhalt.
Bleibt %inline; übrig.
Nur hier muss ich überprüfen ob es sich bei dem Kindelement von ins/del NICHT um ein Blockelement handelt. |
Genau, so sehe ich das auch.
Mir ist noch etwas in der DTD (4.01 Transitional) aufgefallen, was ich mir (bis jetzt) nicht erklären kann.
Wie oben geschrieben wirft der SGML-Parser einen Fehler wenn ein ins/del-Element im map-Element steht.
Warum macht er das nicht bei anderen Elementen?
...
Schließlich sind ins/del auch nicht als Inline-Elemente definiert. |
Wenn ich das richtig interpretiere, liegt das daran, dass das map-Element mindestens ein %block- oder area-Element benötigt. Das ist in deinem ersten Beispiel nicht erfüllt.
Das address-Element dagegen kommt auch ohne %inline- und p-Elemente aus. ins und del dürften ja offenbar wegen dem
Code:
<!ELEMENT BODY O O (%flow;)* +(INS|DEL) -- document body --> |
prinzipiell in jedem Element innerhalb des body-Elements auftauchen. Siehe auch den Kommentar:
Code:
<!-- INS/DEL are handled by inclusion on BODY --> |
Ergänzung:
Mein Beispiel mit
Code:
<body>
<ins>
<span></span>
</ins>
</body> |
wird in XHTML 1.0 Strict von Validome und auch dem Schema-Validator von Christoph Schneegans nicht bemängelt, dagegen aber vom W3C-Validator und in HTML 4.01 Strict auch von Validome. Die DTD scheint also solch eine von mir schon angezweifelte Schachtelung tatsächlich nicht zu mögen, während das Schema sie zulässt. Gestern hatte ich das nur in Validome und als XHTML getestet, daher war mir das nicht aufgefallen. Ist das ein weiterer Fehler im Schema?
Beitrag geändert von Gurkenpapst (25.04.2008 14:57:39)
|
|
| 25.04.2008 14:47:36 |
|
HTMELL
Administrator
Registriert: 11.05.2006
Beiträge: 544
|
|
Hi,
ich verstehe bei dem body-Beispiel das Problem nicht.
Im body sind nur Blockelemente erlaubt, demnach wird das ins-Element zum Blockelement und darf Block- und Inlineelemente enthalten (zumal sein Inhaltstyp %flow; ist).
Im Grunde verhält es sich an dieser Stelle wie ein div-Element, gibt sich nach aussen als Blockelement und erlaubt nach innen Block- und Inlineelemente.
Weitergedacht: del/ins verhält sich IMMER als Blockelement mit dem Inhaltstyp %flow; (quasi wie div).
Nur wenn das Elternelement von del/ins den Inhaltstype %inline; besitzt, dürfen in del/ins keine Blockelemente vorkommen.
Das ist doch alles und das %block;-Problem existiert gar nicht?! (wenn ich nicht mächtig auf der Leitung sitze)
_______________________________________
mfg
Thomas Mell
www.validome.org
|
|
| 25.04.2008 18:00:50 |
|
Gurkenpapst
Mitglied
Registriert: 03.10.2007
Beiträge: 31
|
|
Das Problem ist, dass laut Validome und W3C-Validator diese Schachtelung in HTML, also bei Validierung nach DTD nicht gültig ist.
| Im body sind nur Blockelemente erlaubt, demnach wird das ins-Element zum Blockelement und darf Block- und Inlineelemente enthalten |
Fall das so sein sollte, dann ist es per DTD nicht abbildbar. Das würde dann aber bedeuten, dass ein valides Dokument nicht der DTD entspricht. Ich bin mir aber eben nicht mal sicher, ob ein ins/del-Element dann zu einem Block- oder eben Inline-Element wird. So wie ich es mittlerweile nach einigem Nachdenken verstehe, sind es eben spezielle Elemente, die sofern nicht explizit verboten beliebig irgendwo im body vorkommen dürfen, dabei aber aus den normalen Schachtelungsregeln herausfallen (vgl. die Zulässigkeit der Elemente, obwohl sie in der DTD außer für body - dort mit der +(...)-Syntax - für kein Element erwähnt werden), sodass man die Schachtelung so gestalten muss, als wenn diese Elemente nicht vorhanden wären. Bei dieser Interpretation wäre das verbal formulierte Verbot von Inlinelement->ins/del->Blockelement abgedeckt, ebenso wird die DTD in meinem body-Fall eingehalten. Lediglich bei der Schema-Validierung von XHTML wird dann dieses Regel nicht beachtet.
|
|
| 25.04.2008 19:55:11 |
|
HTMELL
Administrator
Registriert: 11.05.2006
Beiträge: 544
|
|
Hi,
meiner Ansicht nach ist die DTD für 4.01 Strict nicht korrekt.
Code:
<!ELEMENT BODY O O (%block;|SCRIPT)+ +(INS|DEL) -- document body --> |
Logisch das die ins/del im body einen Fehler werfen.
Wenn ich mir aber die DTD von XHTML 1.0 Strict ansehe
Code:
<!ELEMENT body %Block;>
---------------^^^^^^^
.
.
<!ENTITY % Block "(%block; | form | %misc;)*">
-----------^^^^^--------------------^^^^^^
.
.
<!ENTITY % misc "noscript | %misc.inline;">
-----------^^^^-------------^^^^^^^^^^^^^
.
.
<!ENTITY % misc.inline "ins | del | script">
-----------^^^^^^^^^^^--^^^---^^^ |
Da auch das Schema bei XHTML1.0 keinen Fehler wirft und ich in der XHTML-Spec. keinen Hinweis gefunden habe das die del/ins-Elemente anders verarbeitet werden sollten als in HTML 4.01 Strict, gehe ich von einen Fehler in der DTD für 4.01 Strict aus.
Dies hier wäre richtig
Code:
<!ELEMENT BODY O O (%block;|SCRIPT|INS|DEL)+ +(INS|DEL) -- document body --> |
Hier noch ein Paar Testdokumente:
HTML 4.01 Transitional
http://www.validome.org/check/misc/ins_ ... ional.html
HTML 4.01 Strict
http://www.validome.org/check/misc/ins_ ... trict.html
XHTML 1.0 Transitional
http://www.validome.org/check/misc/ins_ ... ional.html
XHTML 1.0 Strict
http://www.validome.org/check/misc/ins_ ... trict.html
XHTML 1.1
http://www.validome.org/check/misc/ins_del_xhtml11.html
_______________________________________
mfg
Thomas Mell
www.validome.org
|
|
| 28.04.2008 15:05:22 |
|
Gurkenpapst
Mitglied
Registriert: 03.10.2007
Beiträge: 31
|
|
| Logisch das die ins/del im body einen Fehler werfen. |
So logisch finde ich das nicht. Denn wenn die ins/del-Elemente wiederum ein Blockelement enthalten, passt ja offenbar alles wieder.
Eine konkrete Aussage kann man wohl nur treffen, wenn man wüsste, wie die außerhalb der DTD definierte Schachtelungseinschränkung nun genau zu verstehen ist.
Dass die DTDs von HTML und XHTML (jeweils Strict) dort voneinander abweichen ist offensichtlich, aber möglicherweise spricht ja in XHTML einfach nur irgendwas gegen die +()-Syntax, zumindest taucht sie in der dortigen DTD nirgends auf. Daraus kann man aber meiner Minung nach nicht ableiten, dass eine der DTDs falsch ist, da die Einschränkung ja eh verbal vorgenommen wurde. Auch dass der W3C-Validator in XHTML 1.0 Strict den oben genannten Ausschnitt
Code:
<body>
<ins>
<span></span>
</ins>
</body> |
nicht mag, lässt sich dadurch nicht erklären. Das kann ich mir übrigens auch sonst nicht erklären, die DTD erlaubt dies doch offenbar? Welche DTD-Regel wird dort verletzt?
|
|
| 28.04.2008 15:35:32 |
|
HTMELL
Administrator
Registriert: 11.05.2006
Beiträge: 544
|
|
| Denn wenn die ins/del-Elemente wiederum ein Blockelement enthalten, passt ja offenbar alles wieder. |
Nein, tut es nicht, siehe http://www.validome.org/check/misc/ins_ ... trict.html
| ...wenn man wüsste, wie die außerhalb der DTD definierte Schachtelungseinschränkung nun genau zu verstehen ist. |
Das ist für mich inzwischen Glasklar:
Diese beiden Elemente sind außergewöhnlich für HTML, können entweder als Block-Level- oder inzeilige Elemente dienen (jedoch nicht beides).
Das INS- und das DEL-Element dürfen keinen Block-Level-Inhalt haben, wenn diese Elemente als inzeilige Elemente fungieren. |
Und die Frage, wann del/ins als Inlineelement fungiert, ist geklärt - wenn das Elternelement NUR inline zulässt.
In allen anderen Fällen (block, flow oder alle anderen Elemente (sofern erlaubt)) fungieren sie als Block-Elemente.
| Dass die DTDs von HTML und XHTML (jeweils Strict) dort voneinander abweichen ist offensichtlich, aber möglicherweise spricht ja in XHTML einfach nur irgendwas gegen die +()-Syntax |
Die DTD ist dort nur anders geschrieben:
Code:
Beispiel p-Element
<!ELEMENT p %Inline;>
<!ATTLIST p
%attrs;
>
Beachte das gross geschrieben "Inline"
Diese kapselt "normale" inline-Elemente und "%misc.inline;"
<!ENTITY % Inline "(#PCDATA | %inline; | %misc.inline;)*">
"%misc.inline;" sind u.a. unsere ins/del-Elemente
<!-- these can occur at block or inline level -->
<!ENTITY % misc.inline "ins | del | script"> |
Es wird also nicht global gesagt das in allen Unterlementen von body ins/del erlaubt ist (wie in der HTML-DTD), sondern jedes betroffene Element bekommt explizit die ins/del zugewiesen (übrigens auch body, siehe mein letztes Posting).
| Daraus kann man aber meiner Minung nach nicht ableiten, dass eine der DTDs falsch ist |
Daraus leite ich es doch gar nicht ab, sondern die fehlende Deklaration, das ins/del im body erlaubt ist (4.01 Strict) wegen dem "+" im "<!ELEMENT BODY O O (%block;|SCRIPT)+ +(INS|DEL)" - es MUß ein %block; oder SCRIPT vorkommen, kein Wort von ins/del (das ist der gleiche Effekt wie mit dem map-Element, s.o.).
In HTML 4.01 Strict ist ein del/ins im body erlaubt wegen dem "*" im "<!ELEMENT BODY O O (%flow;)* +(INS|DEL)".
Da, was die del/ins-Elemente angeht, keine Unterschiede zwischen der HTML und XHTML-Version existieren, muss eine der beiden DTD's einen Fehler haben - logisch ist nur der Fehler in HTML 4.01 Strict.
| Auch dass der W3C-Validator in XHTML 1.0 Strict den oben genannten Ausschnitt nicht mag... |
Mag er doch -> http://validator.w3.org/check?uri=http% ... 0&ss=1
_______________________________________
mfg
Thomas Mell
www.validome.org
|
|
| 28.04.2008 16:22:09 |
|
Gurkenpapst
Mitglied
Registriert: 03.10.2007
Beiträge: 31
|
|
Ok, nun habe ich es verstanden, die Argumentation erscheint mir schlüsig. Ich habe mich da offenbar beim Validieren auch vertan, ich kann deine Beobachtungen bestätigen.
| In HTML 4.01 Strict ist ein del/ins im body erlaubt wegen dem "*" im "<!ELEMENT BODY O O (%flow;)* +(INS|DEL)". |
Hier war ich erst verwirrt, aber du meinst offenbar Transitional, nicht Strict. Ich stimme dir zu, dass die besagten Unterschiede in den DTDs von HTML Strict und XHTML Strickt nicht schlüssig sind.
Eine Frage habe ich dann aber doch noch zu
Und die Frage, wann del/ins als Inlineelement fungiert, ist geklärt - wenn das Elternelement NUR inline zulässt.
In allen anderen Fällen (block, flow oder alle anderen Elemente (sofern erlaubt)) fungieren sie als Block-Elemente. |
Wo/wie wurde die Frage geklärt? Für mich sind da immer noch zwei weitere Varianten denkbar. Einmal, dass die Elemente weder Block- noch Inline-Elemente werden, sondern ihre Sonderrolle behalten (sie gehören immerhin nicht zu %block oder %inline und in dem Sample-Stylesheet unter http://www.w3.org/TR/CSS21/sample.html wird auch in keinem Fall diesen Elementen ein Block-Status zugewiesen, obwohl das problemlos möglich wäre) und zum anderen die umgedrehte Variante zu deiner Aussage, nämlich, dass sie immer als Inline-Elemente auftreten, sofern sie in dem Kontext nicht ein Blockelement sein müssten.
Deine Variante wäre allerdings sicherlich am einfachsten Umzusetzen, das könnte ein Hinweis darauf sein, dass dies tatsächlich so ist.
Beitrag geändert von Gurkenpapst (28.04.2008 17:07:04)
|
|
| 28.04.2008 17:05:58 |
|
HTMELL
Administrator
Registriert: 11.05.2006
Beiträge: 544
|
|
| Hier war ich erst verwirrt, aber du meinst offenbar Transitional, nicht Strict |
Oh je, hast recht - sorry ;-)
| ...Einmal, dass die Elemente weder Block- noch Inline-Elemente werden, sondern ihre Sonderrolle behalten... |
Dieser Fall ist ausgeschlossen, da sie IMMER zu Inline- oder Blockelemente werden.
| These two elements are unusual for HTML in that they may serve as either block-level or inline elements (but not both). |
Das wäre sogar mit großen Problemen verbunden wenn das Element als Inlineelement fungiert. Damit müssen sich die Browser rumärgern, nicht der Validator.
| ...und zum anderen die umgedrehte Variante zu deiner Aussage, nämlich, dass sie immer als Inline-Elemente auftreten, sofern sie in dem Kontext nicht ein Blockelement sein müssten. |
Dieser Kontext existiert aber nur beim map-Element und bei Strict im body-Element.
Bei allen anderen Elementen wären dann Blockelemente als Kindelemente ausgeschlossen, was ganz bestimmt nicht Sinn der Sache ist ;-)
Sind wir uns aber einig das die HTML 4.01 Strict - DTD fehlerhaft ist? Ich würde dann mal ne Meldung (auch wenn sie Sinnlos ist) beim W3C ablassen.
Bis die kapieren worum es geht, gehen 10 Postings ins Land. Und wenn sie es kappiert haben (Betonung liegt auf "wenn"), dann wird es Schöngeredet und so lange gedreht und gebogen bis es "passt". Nur die DTD wird niemals geändert, dann müssten die Meister aller Klassen zugeben das sie einen Fehler gemacht haben - vergiss es.
Wir haben alleine in den Schemata ca. 15 Fehler gefunden, bis heute ist bei denen nicht einer gefixt.
_______________________________________
mfg
Thomas Mell
www.validome.org
|
|
| 28.04.2008 17:31:33 |
|
Gurkenpapst
Mitglied
Registriert: 03.10.2007
Beiträge: 31
|
|
| Dieser Fall ist ausgeschlossen, da sie IMMER zu Inline- oder Blockelemente werden. |
Ok, stimmt, dem Wortlaut nach verhalten sie sich *immer* wie ein Block- *oder* Inline-Element.
| Das wäre sogar mit großen Problemen verbunden wenn das Element als Inlineelement fungiert. |
Wieso? Man könnte doch mit body>ins, body>del, ... diese Fälle gezielt berücksichtigen. Das gehört aber dann tatsächlich nicht hierher. Ich wollte das nur als Beispiel heranziehen, dass da eben doch noch eine andere Variante denkbar wäre, auch wenn deine Interpretation sicherlich die sinnvollste ist.
| Bei allen anderen Elementen wären dann Blockelemente als Kindelemente ausgeschlossen, was ganz bestimmt nicht Sinn der Sache ist ;-) |
Nein, diesen Fall behandelt ja der Teil ab "sofern".
| Sind wir uns aber einig das die HTML 4.01 Strict - DTD fehlerhaft ist? |
Nein, ganz so weit würde ich nicht gehen. Ja, sie ist inkonsequent, da es eigentlich keinen Grund für diese Einschränkung geben sollte und sie außerdem nicht identisch zu der XHTML-Variante ist. Aber wo steht, dass diese Einschränkung nicht doch aus irgendeinem Grund existiert? Ein Fehler würde es imo nur dann sein, wenn es in einem Widerspruch zu einer anderen Definition stehen würde. Dies sehe ich innerhalb von HTML nicht gegeben. Bei dem Unterschied zur XHTML-DTD könnte ebenso davon ausgehen, dass die XHTML-DTD fehlerhaft ist, da sie sich unnötigerweise(?) von der HTML-DTD entfernt, obwohl XHTML von HTML abgeleitet wurde.
| Nur die DTD wird niemals geändert, dann müssten die Meister aller Klassen zugeben das sie einen Fehler gemacht haben |
Das Problem ist doch aber vor allem dass man damit einen Kernpunkt der Spezifikation verändern würde. Dazu müsste es dann auch eine neue Version geben und da das Problem ja nun doch nicht sonderlich praxisnah ist, dürfte der Aufwand tatsächlich nicht gerechtfertigt sein.
| Wir haben alleine in den Schemata ca. 15 Fehler gefunden, bis heute ist bei denen nicht einer gefixt. |
Das ist in der Tat bedauerlich, denn die die ich mitbekommen habe, standen eben tatsächlich im Widerspruch zur Spezifikation. Aber auch hier gilt prinzipiell die Aussage, dass man an solchen Sachen nicht ständig dran rumbasteln kann, auch wenn das Schema nur als "Note" ausgezeichnet ist.
|
|
| 28.04.2008 18:21:26 |
|
HTMELL
Administrator
Registriert: 11.05.2006
Beiträge: 544
|
|
| Nein, diesen Fall behandelt ja der Teil ab "sofern". |
Bahnhof
| Aber wo steht, dass diese Einschränkung nicht doch aus irgendeinem Grund existiert? |
Eben, wo steht es? Ich habe jedenfalls nichts gefunden.
Solche Sätze kenne ich vom W3C, Du kommst nicht zufällig daher? ;-))
Die Fragen auch immer "wo" etwas "nicht" steht.
So könnte ich mir die Spezifikationen als leeres Blatt vorstellen und immer fragen "wo" etwas "nicht" steht - ganz sicher auf dem Blatt ;-)
In allen [X]HTML-Versionen ist ein ins/del im body erlaubt, nur die 4.01 Strict meckert rum - ist schon klar das es sich dabei um keinen Fehler handelt, steht ja nirgendwo...
Ich pinsel jetzt mal ein html-Element in eine Tabelle, wer will es mir verbieten? Wo steht das dies nicht evt. doch erlaubt ist?
| Ein Fehler würde es imo nur dann sein, wenn es in einem Widerspruch zu einer anderen Definition stehen würde |
Was meinst du hier mit "Definition" eine DTD oder die Specs?
| Bei dem Unterschied zur XHTML-DTD könnte ebenso davon ausgehen, dass die XHTML-DTD fehlerhaft ist, da sie sich unnötigerweise(?) von der HTML-DTD entfernt, |
Es geht hier nicht um "entfernen", es ist *sorry* |UnWort| wie eine DTD geschrieben ist, von mir aus alles in einer Zeile Text in Türkischer Kodierung und Chinesischen Kommentaren.
Sie muß schlicht und einfach den Spezifikationen genügen - die DTD hat den Specs zu gehorchen, nicht umgekehrt, und das tut die 4.01 Strict nicht.
| Das Problem ist doch aber vor allem dass man damit einen Kernpunkt der Spezifikation verändern würde. |
An der Spezifikation muß gar nichts geändert werden die hat an andern Stellen Fehler, nur die DTD muß geändert werden (da muß nur ein Klitzekleines "|DEL|INS" rein ;-))
| Dazu müsste es dann auch eine neue Version geben und da das Problem ja nun doch nicht sonderlich praxisnah ist, dürfte der Aufwand tatsächlich nicht gerechtfertigt sein. |
Dies Sätze kenn ich doch *amKopfKratz*... Genau mit solchen Aussagen drückt sich das W3C seit fast 10 Jahren ihre korrupten Specs zu überarbeiten. Wir reden hier nicht von einen Fehler sondern von mittlerer 2-Stelliger Fehlerzahl.
Aber egal, ich werde bei uns die DTD ändern, genau so wie wir es bei den Schemata gemacht haben.
_______________________________________
mfg
Thomas Mell
www.validome.org
|
|
| 28.04.2008 19:22:26 |
|
Gurkenpapst
Mitglied
Registriert: 03.10.2007
Beiträge: 31
|
|
Mit "sofern" war dieser Teil gemeint:
| sofern sie in dem Kontext nicht ein Blockelement sein müssten. |
Ich hatte diesen Fall also durchaus bedacht.
| Eben, wo steht es? Ich habe jedenfalls nichts gefunden. |
Ich schätze mal, dass es viele Restriktionen gibt, die ausschließlich in der DTD zu finden sind. Das ist sicherlich alles andere als ideal, aber dadurch noch nicht gleich falsch. Natürlich kann man auch über den Sinn oder Unsinn einer Spezifikation diskutieren, aber in einer Spezifikation wird nun mal etwas definiert, und da gibt es halt viele Möglichkeiten, aus der dann eine ausgewählt wird. Dies muss nicht immer die beste sein. Eventuell, weil man die bessere Variante nicht bedacht hat, eventuell weil man bei der Festlegung von falschen Annahmen ausging.
| Ich pinsel jetzt mal ein html-Element in eine Tabelle, wer will es mir verbieten? Wo steht das dies nicht evt. doch erlaubt ist? |
In der DTD, die ist soweit ich weiß normativ ... :)
| Was meinst du hier mit "Definition" eine DTD oder die Specs? |
In diesem Fall den Wortlaut in der Spezifikation, die DTD in sich ist ja nicht widersprüchlich. So wie ich das verstehe ich die DTD aber eben auch ein Teil der Spezifikation.
| Aber egal, ich werde bei uns die DTD ändern, genau so wie wir es bei den Schemata gemacht haben. |
Halte ich für vorschnell. Schließlich basiert die Validierung ja gerade auf der DTD. Wenn du die nun änderst, erhält man Ergebnisse, die nicht der definierten(!) DTD entsprechen. Dazu sollte es irrelvant sein, ob die DTD an sich unlogisch ist, solange sie keine Widersprüche aufwirft.
Bei dem Schema sieht das anders aus, da erscheinen mir die Korrekturen gerechtfertigt, denn es wurde außerhalb der Spezifikation als Note veröffentlicht und es gab Widersprüche zu der DTD und dem Wortlaut der Spezifikation.
Meine Auffassung/Meinung zusammengefasst:
Eine Spezifikation setzt Dinge fest, dazu bedarf es nicht zwingend einer Begründung,
Ggf. erscheinen solche Festsetzungen unsinnig, das macht sie aber noch nicht falsch.
Die DTD ist als Teil der Spezifikation normativ.
Die DTD steht in keinem Widerspruch zu sonstigen Teilen der Spezifikation.
Sie sollte keinesfalls (zumindest nicht ohne ausdrücklichen Hinweis) modifiziert werden, denn dadurch würde man die Spezifikation selbst verfälschen.
In diesem konkreten Fall würde Validome dadurch Fehler übersehen!
Beitrag geändert von Gurkenpapst (28.04.2008 20:34:24)
|
|
| 28.04.2008 20:32:08 |
|
Wechsel zu
Die letzten Beiträge aus diesen Forum
|
|
