nicht angemeldet
Gunnar Bittersmann
Der Martin
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
Der Martin
Hallo liebe Forumsteilnehmer,
ich stehe vor dem Problem, dass mein Firefox (Version 3.5.5) bei einem Formular (es handelt sich um eine valide xhtml 1.0 strict html Ressource), bei dem 3 Inputfelder hintereinander stehen, ein seltsames Cursorverhalten zeigt.
Klickt man nämlich _direkt_ in das erste oder zweite der 3 Inputfelder, springt der Cursor _automatisch_ in das dritte Feld und bleibt dort. Eine Eingabe in die ersten beiden Felder ist somit nicht möglich.
Nur, wenn man die Eingabefelder mit der Tab-taste ansteuert, bleibt der Cursor dort, wo er sein soll.
Ruft man die selbe Ressource mit dem IE (Version 8) auf, kann man auch ins erste oder zweite der 3 Eingabefelder klicken und der Cursor bleibt - wie es sein soll - darin stehen. Ich habe mit Google kein ähnlich beschriebenes Problem und somit auch leider keine Lösung gefunden.
Bitte besucht doch diese online gestellte Beispielseite. Dort versucht beim Geburtsdatum, in das Tag- oder Monatsfeld etwas einzugeben. Bei mir springt da der Cursor (beim Firefox!) jedes mal sofort ins Jahresfeld weiter.
Tritt bei Euch das selbe Phenomen auf? Woran kann das liegen? Was kann man dagegen tun?
Ich bedanke mich für jeden Hinweis!
Mit lieben Grüßen
CharlyH
@@CharlyH:
nuqneH
Bitte besucht doch diese online gestellte Beispielseite. Dort versucht beim Geburtsdatum, in das Tag- oder Monatsfeld etwas einzugeben. Bei mir springt da der Cursor (beim Firefox!) jedes mal sofort ins Jahresfeld weiter.
Dass es noch andere Browser außer IE und Firefox gibt, ist dir bewusst? Wenn du dein Formular in Webkits (Chrome, Safari) testest, wirst du dasselbe Verhalten wie im Firefox feststellen. Also kein Firefox-Bug.
Allerdings setzt in Webkits der Click auf "Tag (TT)" bzw. "Monat (MM)" den Cursor in die entsprechenden Eingabefelder, im Firefox ist auch dann das Feld für die Eingabe des Jahres fokussiert.
Im Opera ist dein Forumular ganz kaputt.
Schuld daran ist die Verschachtelung der 'label'- und 'input'-Elemente. Da sich 'input[@id="tag"]' innerhalb von 'label[@for="jahr"]' befindet, wird die Fokussierung des Eingabefeldes an das Label weitergereicht und von diesem auf dessen zugehöriges Eingabefeld 'input[@id="jahr"]'. Vermeide solche Verschachtelungen!
Du solltest auch getrennte Eingabefelder für Tag, Monat, Jahr vermeiden. Verwende ein Eingabefeld, am besten 'input[@type="date"]'. Das verstehen Webkits und Opera bereits und stellen entsprechende Eingabefelder dar.
Qapla'
Hallo,
Schuld daran ist die Verschachtelung der 'label'- und 'input'-Elemente.
nein, die sind nicht verschachtelt - es sind leere label-Elemente <label />.
Dass das nicht besonders schlau ist, sehe ich allerdings auch so.
Ciao,
Martin
@@Der Martin:
nuqneH
nein, die sind nicht verschachtelt - es sind leere label-Elemente <label />.
Firebug sagt was anderes. (Ich hatte auch gar nicht in den Quelltext geschaut.)
Der Tagsoup-Parser schließt natürlich das 'label'-Element nicht beim '/>'. Sie werden implizit geschlossen, bspw. durch das nächste <label>-Start-Tag. (Deshalb führen die Clicks auf die Labeltexte ja auch zur Fokussierung der Eingabefelder – mehr oder weniger.)
Dass das nicht besonders schlau ist, sehe ich allerdings auch so.
Es ist sogar ziemlich blöd. Vermutlich ist es auch das, was den Opera durcheinander bringt.
Qapla'
Firebug sagt was anderes. (Ich hatte auch gar nicht in den Quelltext geschaut.)
Das liegt vermutlich am ungültigen Quelltext und Firefox baut halt etwas anderes draus in seinem generierten DOM ;)
@@suit:
nuqneH
Das liegt vermutlich am ungültigen Quelltext und Firefox baut halt etwas anderes draus in seinem generierten DOM ;)
Wie der OP schon sagte, der Quellext ist valide: An
<label/> foo <label/> bar
findet der XHTML-Validator nichts zu meckern.
Der Tagsoup-Parser liest
<label> foo <label> bar
und macht
<label> foo </label><label> bar </label>
draus.
Qapla'
Firebug sagt was anderes. (Ich hatte auch gar nicht in den Quelltext geschaut.)
Der Tagsoup-Parser schließt natürlich das 'label'-Element nicht beim '/>'. Sie werden implizit geschlossen, bspw. durch das nächste <label>-Start-Tag. (Deshalb führen die Clicks auf die Labeltexte ja auch zur Fokussierung der Eingabefelder – mehr oder weniger.)
Warum Tagsoup-Parser?
Im Code steht:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Es wird aber der header gesendet:
Content-type:text/html
<rant>Ich weiss ich weiss, ihr seid ja alle anderer Meinung.
Aber ich behaupte ma wieder, wer die Besonderheiten von XML und XHTML nicht kennt und somit keinerlei Vorteil daraus zu ziehen weiss, der halte sich an HTML 4.01 strict.</rant>
mfg Beat
Tach,
nein, die sind nicht verschachtelt - es sind leere label-Elemente <label />.
Dass das nicht besonders schlau ist, sehe ich allerdings auch so.Es ist sogar ziemlich blöd. Vermutlich ist es auch das, was den Opera durcheinander bringt.
es ist vor allem in XHTML nicht erlaubt und das ist vermutlich der Grund warum sich die Tagsoup-Parser so verhalten: "All elements other than those declared in the DTD as EMPTY must have an end tag. Elements that are declared in the DTD as EMPTY can have an end tag or can use empty element shorthand" http://www.w3.org/TR/xhtml1/#h-4.3
Also nur als leer deklarierte Elemente dürfen die Kurzschreibweise nutzen, label gehört nicht dazu, führt auch zu sehr hübschen (na gut, leeren) Effekten, wenn man das mit einem Script-Element im Head macht.
mfg
Woodfighter
@@Jens Holzkämper:
nuqneH
es ist vor allem in XHTML nicht erlaubt und das ist vermutlich der Grund warum sich die Tagsoup-Parser so verhalten:
Nö. Wenn der Browser ein Dokument als 'text/html' erhält, wirft er seinen Tagsoup-Parser an. Der Tagsoup-Parser interessiert sich einen Sc^H^Hherzlich wenig dafür, was in XHTML erlaubt ist und was nicht.
"All elements other than those declared in the DTD as EMPTY must have an end tag. Elements that are declared in the DTD as EMPTY can have an end tag or can use empty element shorthand" http://www.w3.org/TR/xhtml1/#h-4.3
Also nur als leer deklarierte Elemente dürfen die Kurzschreibweise nutzen
Nö. Auch wenn das so in der Spec steht, ist es nicht ganz richtig. Ich darf dich an http://forum.de.selfhtml.org/archiv/2010/1/t194192/#m1298039 erinnern?
Qapla'
Tach,
Nö. Wenn der Browser ein Dokument als 'text/html' erhält, wirft er seinen Tagsoup-Parser an. Der Tagsoup-Parser interessiert sich einen Sc^H^Hherzlich wenig dafür, was in XHTML erlaubt ist und was nicht.
die Tagsoup-Parser (mindestens der von Firefox) sind aber geändert worden, so dass sie das jetzige Verhalten haben, früher haben alle außer der IE es so gemacht, wie man es aus XML erwarten würde. Mir wurde das zum ersten Mal bewußt als auch Firefox bei <script/> eine leere Seite anzeigte.
"All elements other than those declared in the DTD as EMPTY must have an end tag. Elements that are declared in the DTD as EMPTY can have an end tag or can use empty element shorthand" http://www.w3.org/TR/xhtml1/#h-4.3
Also nur als leer deklarierte Elemente dürfen die Kurzschreibweise nutzen
Nö. Auch wenn das so in der Spec steht, ist es nicht ganz richtig.
Es steht in der Spec, also ist es richtig ;-). Es mag weitere Elemente geben, bei denen es keine Probleme bereitet, trotzdem sagt die Spec eindeutig "must" (und ja ich habe "This section is informative." gesehen).
Ich darf dich an http://forum.de.selfhtml.org/archiv/2010/1/t194192/#m1298039 erinnern?
Darfst du, aber das zeigte auch woanders hin, als mein Zitat heute.
mfg
Woodfighter
@@Jens Holzkämper:
nuqneH
die Tagsoup-Parser (mindestens der von Firefox) sind aber geändert worden, so dass sie das jetzige Verhalten haben, früher haben alle außer der IE es so gemacht, wie man es aus XML erwarten würde. Mir wurde das zum ersten Mal bewußt als auch Firefox bei <script/> eine leere Seite anzeigte.
??
<script src="test.js"/>
<p>Lorem ipsum</p>
zeigt eine leere Seite, weil dem Tagsoup-Parser das </script>-End-Tag fehlt.
<script src="test.js"/></script>
<p>Lorem ipsum</p>
hingegen funktioniert. Der Tagsoup-Parser ignoriert das '/' im Start-Tag.
(In 'test'.js' steht bspw. 'document.body.style.background = "green";'.)
Es steht in der Spec, also ist es richtig ;-).
*prust* ;-)
XHTML ist eine XML-Anwendung; XML erklärt '<foo></foo>' und '<foo/>' als äquivalent.
XHTML hat keine Möglichkeit, sich darüber hinwegzusetzen und '<p></p>' und '<p/>' für nicht äquivalent zu erklären.
Ich darf dich an http://forum.de.selfhtml.org/archiv/2010/1/t194192/#m1298039 erinnern?
Darfst du, aber das zeigte auch woanders hin, als mein Zitat heute.
Andere Stelle, ja. Aber selbes Thema.
Qapla'
Tach,
<script src="test.js"/>
<p>Lorem ipsum</p>
>
> zeigt eine leere Seite, weil dem Tagsoup-Parser das </script>-End-Tag fehlt.
jup, und vor etwa zwei Jahren war dem in Firefox noch nicht so.
> XHTML ist eine XML-Anwendung; XML erklärt '`<foo></foo>`{:.language-xml}' und '`<foo/>`{:.language-xml}' als äquivalent.
Im XML-Kontext, um den es hier ja nicht geht.
> XHTML hat keine Möglichkeit, sich darüber hinwegzusetzen und '`<p></p>`{:.language-html}' und '`<p/>`{:.language-html}' für nicht äquivalent zu erklären.
Aber XHTML hat die Möglichkeit Kompatibilitätsrichtlinien für die Rückwärtskompatibilität mit HTML zu geben und die sind in diesem Falle eindeutig; dass es im Moment auch anders "funzt" ist ja kein Argument.
mfg
Woodfighter
@@Jens Holzkämper:
nuqneH
XHTML ist eine XML-Anwendung; XML erklärt '
<foo></foo>' und '<foo/>' als äquivalent.Im XML-Kontext, um den es hier ja nicht geht.
Du hattest die XHTML-Spec angeführt und was laut dieser erlaubt wäre und was nicht. Damit ist der XML-Kontext gegeben.
XHTML hat keine Möglichkeit, sich darüber hinwegzusetzen und '
<p></p>' und '<p/>' für nicht äquivalent zu erklären.Aber XHTML hat die Möglichkeit Kompatibilitätsrichtlinien für die Rückwärtskompatibilität mit HTML zu geben und die sind in diesem Falle eindeutig; dass es im Moment auch anders "funzt" ist ja kein Argument.
Und eben diese Kompatibilitätsrichtlinien sind zu restriktiv. '<p><p>foo' ist in HTML 4.01 erlaubt; für einen Tagsoup-Parser ist '<p/><p>foo</p>' dasselbe und demzufolge ist diese Schreibweise auch in XHTML möglich.
Es funzt nicht nur im Moment, sondern auch zukünftig.
Qapla'
Tach,
Und eben diese Kompatibilitätsrichtlinien sind zu restriktiv. '
<p><p>foo' ist in HTML 4.01 erlaubt; für einen Tagsoup-Parser ist '<p/><p>foo</p>' dasselbe und demzufolge ist diese Schreibweise auch in XHTML möglich.
Sie wäre möglich gewesen, aus irgendeinem Grund (vermutlich weil niemand darüber nachgedacht hat oder weil sie deutlich einfacher zu formulieren war) hat man sich aber für eine andere, restriktivere Formulierung entschieden und diese steht jetzt in der Norm drin und gilt damit; "zu restriktiv" gibt es in diesem Kontext nicht, wichtig ist nur es ist restriktiv genug.
Es funzt nicht nur im Moment, sondern auch zukünftig.
I will hold you to that ;-)
mfg
Wood*ichschreibjetztmeineneeignentagsoupparsernurumgunnarzuärgernmitblackjackundnutten*fighter
@@Jens Holzkämper:
nuqneH
weil niemand darüber nachgedacht hat oder weil sie deutlich einfacher zu formulieren war
Ja, beides wäre möglich.
diese steht jetzt in der Norm drin und gilt damit
Njein.
Seien
A = "Das XHTML-Dokument entspricht den Kompatibilitätsrichtlinien nach §C [XHTML10]."
B = "Das XHTML-Dokument wird von einem Tagsoup-Parser wie erwartet verarbeitet."
Zweifelsohne gilt A ⇒ B. Vielleicht wollten die Autoren der Spec auch das ausdrücken.
Ihre Wortwohl suggeriert aber, es gelte A ⇔ B; dies ist aber nicht der Fall. Es gilt nicht ¬A ⇒ ¬B.
Qapla'
Tach,
Und eben diese Kompatibilitätsrichtlinien sind zu restriktiv. '
<p><p>foo' ist in HTML 4.01 erlaubt; für einen Tagsoup-Parser ist '<p/><p>foo</p>' dasselbe und demzufolge ist diese Schreibweise auch in XHTML möglich.
Ich erweitere dein Beispiel mal etwas, was macht ein Tagsoup-Parser aus <p/>bar<p>foo</p>?
Weiß er von XHTML sollte er daraus <p></p>bar<p>foo</p> machen, weiß er davon nichts, wird es <p>bar</p><p>foo</p>; ein korrekt arbeitender SGML-Parser müßte sogar <p>>bar</p><p>foo</p> daraus machen, da der Slash das Tag bereits beendet.
mfg
Woodfighter
@@Jens Holzkämper:
nuqneH
Ich erweitere dein Beispiel mal etwas, was macht ein Tagsoup-Parser aus
<p/>bar<p>foo</p>?Weiß er von XHTML sollte er daraus
<p></p>bar<p>foo</p>machen
Der Tagsoup-Parser weiß nichts von XHTML.
weiß er davon nichts, wird es
<p>bar</p><p>foo</p>
Ja, genau das.
ein korrekt arbeitender SGML-Parser müßte sogar
<p>>bar</p><p>foo</p>daraus machen, da der Slash das Tag bereits beendet.
Ein Tagsoup-Parser ist kein SGML-Parser. Die wenigsten Browser haben einen SGML-Parser.
Qapla'
Tach,
Der Tagsoup-Parser weiß nichts von XHTML.
hmm, würde ich einen schreiben, würde ich vermutlich in diese Falle tappen und XHTML anders behandeln als HTML.
Ein Tagsoup-Parser ist kein SGML-Parser. Die wenigsten Browser haben einen SGML-Parser.
Ein Gegenbeispiel reicht ja ;-) (Ein SGML-Parser wäre leider keins, da der mit HTML-kompatiblem XHTML eh nicht wie gewünscht umgehen könnte).
mfg
Woodfighter
Hallo,
ich stehe vor dem Problem, dass mein Firefox (Version 3.5.5) bei einem Formular (es handelt sich um eine valide xhtml 1.0 strict html Ressource), bei dem 3 Inputfelder hintereinander stehen, ein seltsames Cursorverhalten zeigt.
dein Beispieldokument mag valide sein; aber es ist sinnlos, das label-Element als leeres Element zu notieren, z.B. <label for="anrede" />. Der Inhalt des Label-Elements soll ja schließlich die Beschriftung des Formularelements sein (wahlweise zusätzlich das Formularelement selbst) und bildet dann die klickbare Fläche zum Focussieren des Formularelements.
Bitte besucht doch diese online gestellte Beispielseite. Dort versucht beim Geburtsdatum, in das Tag- oder Monatsfeld etwas einzugeben. Bei mir springt da der Cursor (beim Firefox!) jedes mal sofort ins Jahresfeld weiter.
Tritt bei Euch das selbe Phenomen auf? Woran kann das liegen? Was kann man dagegen tun?
Ja, auch schon mit einem älteren Firefox 3.0. Versuch mal, die label-Elemente "richtig" zu verwenden. Da du das Dokument ja auch als text/html auslieferst, wird der Tagsoup-Parser für HTML verwendet, der mit dem leeren label-Element möglicherweise in Straucheln kommt.
Ciao,
Martin
ich stehe vor dem Problem, dass mein Firefox (Version 3.5.5) bei einem Formular (es handelt sich um eine valide xhtml 1.0 strict html Ressource), bei dem 3 Inputfelder hintereinander stehen, ein seltsames Cursorverhalten zeigt.
dein Beispieldokument mag valide sein; aber es ist sinnlos, das label-Element als leeres Element zu notieren, z.B. <label for="anrede" />. Der Inhalt des Label-Elements soll ja schließlich die Beschriftung des Formularelements sein (wahlweise zusätzlich das Formularelement selbst) und bildet dann die klickbare Fläche zum Focussieren des Formularelements.
Ich ergänze noch:
Im Code
<p><label for="titel" /><strong>Titel:</strong><br />
Das ist hochgradiger Unsinn.
<label for="titel">Titel</label>
wäre absolut ausreichend, ohne break.
mfg Beat