Closed Bug 162653 Opened 18 years ago Closed 18 years ago
<textarea/> doesn't work correctly (XHTML served as text/html using XML-style self-closing tags)
I have an XHTML Transitional document (don't know if that actually matters). When I put in a textarea as an empty tag (<textarea/>), I get differrent behavior than if I use <textarea></textarea>. The "different behavior" was the rest of my XHTML document text showing up IN the textarea, and not on the page. As my XHTML is generated from a server-side DOM, working around this bug is very hard.
Could you at least give us a URL or upload a page so we can see this ourselves?
You are serving your XHTML as text/html. According to the XHTML 1.0 specification, you may only do this if your XHTML follows the Appendix C compatibility guidelines. The use of <textarea /> instead of <textarea></textarea> violates section C.3 of appendix C. If you want us to parse your XHTML as XML, please give it the correct MIME type (text/xml or application/xhtml+xml).
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → WONTFIX
When I set the content type as "xml", the content is displayed, but it contains no formatteing. I've attempted to set the content-type to "xhtml+xml", but I've had some problems caused by our framework not accepting that. I'll keep working on that and see if that improves things. I'll admit to not knowing the details of the spec, but it seems to me with the XML declaration and the document DTD specified, it should be clear that it is xhtml and not html.
Comment on attachment 95252 [details] Example of xhtml document with "failure" fixing bogus MIME type
Attachment #95252 - Attachment mime type: text/xhtml+xml → application/xhtml+xml
You need to put an "xmlns" attribute whose value is the XHTML namespace on your root element... see the examples in the XHTML specification. Then formatting will happen like you want. We _could_ content-sniff the document, but that would be just like sniffing text/plain documents to see whether we think they are HTML. Instead, we follow the HTTP standard and use the content-type given by the server. text/html is parsed with the HTML parser, not the XML parser.
Status: RESOLVED → VERIFIED
*** Bug 273855 has been marked as a duplicate of this bug. ***
*** Bug 314220 has been marked as a duplicate of this bug. ***
*** Bug 322892 has been marked as a duplicate of this bug. ***
Summary: XHTML Transitional, <textarea/> doesn't work correctly → <textarea/> doesn't work correctly (XHTML served as text/html)
Summary: <textarea/> doesn't work correctly (XHTML served as text/html) → <textarea/> doesn't work correctly (XHTML served as text/html using XML-style self-closing tags)
According to the spec you should be content sniffing for the doctype/xmlns tags if it is html/plain... I have both set and my bug symptoms are still being exhibited... please see closing img tags post html-render as well as closing anchor tags with a /
According to the XHTML 1.0 spec, XHTML may be sent as text/html only if it complies with Appendix C of the XHTML specification. Any document that uses "<textarea/>" does not comply with Appendix C.
but <textarea /> is as well as <img src="blah.jpg" alt="blah blah" /> is... Appendix C specifically specifies that if you include a space before the trailing / you may minimize tags (and are forced to for img tags). Thus, firefox removing the trailing / in post-render is in violation of the entire XHTML 1.0 spec.
> but <textarea /> is No, because per appendix C you may not minimize tags that don't have an empty content model. The <img> case is indeed per appendix C, and we handle it per the spec. I'm really not sure what problem you're having with <img> and why you think it's a Gecko bug. The issue described in bug 410303 seems to be a bug in the validator...
Component: DOM: Core → DOM: Core & HTML
QA Contact: stummala → general
This bug has been here since 2002, can anyone solve it? It's not that big, but can be annoying...
The reported behavior is not a bug.
Assignee: jst → nobody
Component: DOM: Core & HTML → HTML: Parser
OS: Windows 2000 → All
QA Contact: general → parser
Hardware: x86 → All
You need to log in before you can comment on or make changes to this bug.