The default bug view has changed. See this FAQ.

<textarea/> doesn't work correctly (XHTML served as text/html using XML-style self-closing tags)

VERIFIED INVALID

Status

()

Core
HTML: Parser
--
major
VERIFIED INVALID
15 years ago
6 years ago

People

(Reporter: David Corbin, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
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
Last Resolved: 15 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 3

15 years ago
Created attachment 95252 [details]
Example of xhtml document with "failure"
(Reporter)

Comment 4

15 years ago
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.

Comment 7

15 years ago
v.
Status: RESOLVED → VERIFIED

Comment 8

13 years ago
*** Bug 273855 has been marked as a duplicate of this bug. ***

Comment 9

12 years ago
*** Bug 314220 has been marked as a duplicate of this bug. ***

Comment 10

11 years ago
*** Bug 322892 has been marked as a duplicate of this bug. ***

Updated

10 years ago
Summary: XHTML Transitional, <textarea/> doesn't work correctly → <textarea/> doesn't work correctly (XHTML served as text/html)

Updated

10 years ago
Duplicate of this bug: 369609

Updated

10 years ago
Duplicate of this bug: 203398

Updated

10 years ago
Duplicate of this bug: 181996

Updated

10 years ago
Duplicate of this bug: 268477

Updated

10 years ago
Duplicate of this bug: 281074

Updated

10 years ago
Duplicate of this bug: 193634

Updated

10 years ago
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)

Updated

10 years ago
Duplicate of this bug: 339787

Updated

10 years ago
Duplicate of this bug: 374758
Duplicate of this bug: 381390
Duplicate of this bug: 387349

Updated

10 years ago
Duplicate of this bug: 397346

Updated

10 years ago
Duplicate of this bug: 400280

Updated

10 years ago
Duplicate of this bug: 404954

Updated

9 years ago
Duplicate of this bug: 408528
Duplicate of this bug: 409218

Updated

9 years ago
Duplicate of this bug: 410303

Comment 27

9 years ago
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.

Comment 29

9 years ago
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...

Updated

9 years ago
Duplicate of this bug: 415153

Updated

9 years ago
Resolution: WONTFIX → INVALID

Updated

9 years ago
Duplicate of this bug: 416176

Updated

9 years ago
Duplicate of this bug: 419838

Updated

9 years ago
Duplicate of this bug: 419833

Updated

9 years ago
Duplicate of this bug: 420728

Updated

9 years ago
Duplicate of this bug: 441144

Updated

9 years ago
Component: DOM: Core → DOM: Core & HTML
QA Contact: stummala → general

Updated

9 years ago
Duplicate of this bug: 455831

Updated

9 years ago
Duplicate of this bug: 458596

Updated

8 years ago
Duplicate of this bug: 434651

Updated

8 years ago
Duplicate of this bug: 486695

Updated

8 years ago
Duplicate of this bug: 495054

Updated

8 years ago
Duplicate of this bug: 499246

Updated

8 years ago
Duplicate of this bug: 502581

Updated

8 years ago
Duplicate of this bug: 504391

Updated

8 years ago
Duplicate of this bug: 504799

Comment 46

8 years ago
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.
Duplicate of this bug: 507944

Updated

7 years ago
Duplicate of this bug: 532058

Updated

6 years ago
Assignee: jst → nobody
Component: DOM: Core & HTML → HTML: Parser
OS: Windows 2000 → All
QA Contact: general → parser
Hardware: x86 → All

Updated

6 years ago
Duplicate of this bug: 637033

Updated

6 years ago
Duplicate of this bug: 660108

Updated

6 years ago
Duplicate of this bug: 681395
You need to log in before you can comment on or make changes to this bug.