My favorites | Sign in
Project Home Wiki Issues
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 3030: Mark XHTML documents served with the wrong MIME type
1 person starred this issue and may be notified of changes. Back to list
Project Member Reported by sroussey, Apr 22, 2010
1. Need to change isXHTML utility function to seek information from doctype, 
not from the browser DOM.

2. This will automatically change the edit/copy html to xhtml as well as how 
the tags are closed, etc. in these cases.

3. It will also change item 3 from  Issue 2548  automatically, though that code 
should change also.

4. This will reverse some other issues #s, which should get a comment when 
Apr 22, 2010

Unfortunately, the situation is more complicated than that.  The reason for the
tooltip warning in the email mentioned above would also apply to HTML5.  Except that
mathml and svg are allowed in HTML5, and work is progressing to make such markup work
in Firefox even when served as text/html.  And once that code lands, the ability to
include mathml and svg would also apply to documents which include an XHTML1 DOCType.

My recommendation is that you don't flag potential problems that affect few people
(how many people currently include mathml or svg in html documents today), but if you
are interested in flagging something, flag actual problems when they occur.  If you
see a math or svg element anything other than the mathml or svg namespaces, then you
have hit an actual problem, where the solutions may be to either upgrade your browser
or change the MIME type under which the content is served.
Apr 22, 2010
Project Member #3 sroussey
Agreed to not flag. I had no idea that mathml and svg would some day work in XHTML1 served as 
text/html. That is not what I got out of:

"In particular, 'text/html' is NOT suitable for XHTML Family document types that adds elements and 
attributes from foreign namespaces, such as XHTML+MathML [XHTML+MathML]."

I suppose if the namespace is defined at the top and not in the svg element itself, it would be 
alright? I guess that makes the inside of the document work a lot like (x)html5.

On the note about flagging unknown xml namespaces, it was something I planned to work on.

BTW: I think more people try to include mathml or svg in html documents than you think, it's just 
that they don't get it to work and abandon the effort.
Apr 22, 2010
Project Member #4 sroussey
For reference:
Apr 22, 2010
Project Member #5 sroussey
Reverted r6496 in r6616.
Apr 22, 2010
The intent of HTML5 is to document how HTML actually works today.  HTML as
implemented in browsers is essentially unversioned.  In essence, HTML5 supersedes all
prior HTML specifications.  As an example, you can use <canvas> elements in pages
with the HTML4 doctype, and such will work in Firefox today.

When parsed as text/html, the xmlns attributes are essentially ignored for namespace
processing purposes (the are merely put into the DOM as attributes).  The DOM
namespace is inferred from the element itself (this part isn't fully implemented in
firefox yet, but can be enabled in firefox nightly builds, and can be seen in IE9's
preview).  To see what I mean, search for svg and math in the following:

Apr 23, 2010
#8 is a
non-normative document published outside the W3C REC track by the WG now known as the
XHTML2 WG. It's probably not a particularly good idea to treat that document as

Instead, I suggest treating HTML5 as normative.

SVG and MathML support in text/html in Gecko is pretty close:
Apr 29, 2010
Project Member #9 sroussey
At this point in time we are not showing an error in the alpha anymore.

I think I will do one other thing instead: 

1. If the doctype is clearly XHTML 1 or 1.1 and served as text/html, I will put some 
text after the doctype that says "Served as text/html" (or less likely, "Served as 
text/html, activating Gecko HTML mode")

2. If the document was served without a content-type, "Served without content-type".

3. All other cases, no additional note.

This might also be good for things like image tags (like the case where an image was 
served as text/html -- I just saw such a thing this week).

I don't want Firebug to be a validation tool (an extension to Firebug could do that), 
though it could bubble up decisions that Firefox is making on the user's behalf, and 
that developers should know when debugging on this specific platform.

I could also put these notice type things into an extension to firebug for further 
Jul 8, 2010
Project Member #10
I changed the status from Accepted -> Started. I don't understand what Accepted means, "we're thinking this is something we ought to get around to do"? Well that's all bugs really ;-)

If the Owner really is not working on this bug, Triaged would be better, so we don't hold a release for your result.
Status: Started
Oct 21, 2013
Project Member #11
The summary was unclear, so I tried to interpret what this issue asks for and changed the summary. So as I understand XHTML documents served as text/html instead of application/xhtml+xml should have an indication that they use the wrong MIME type, right?

Steven, I assume you won't work on this, right? Also do you still think it's relevant to have this info in Firebug?

Summary: Mark XHTML documents served with the wrong MIME type (was: XHTML documents can be served as text/html)
Status: NeedInfo
Labels: -Type-Defect Type-Enhancement 1.12.3 Test-case-needed
Jan 12, 2014
Project Member #12
Steven isn't answering again, so I'm asking the others. Do we want to have that feature?

Status: Triaged
Owner: ---
Cc: simon.lindholm10
Jan 13, 2014
Project Member #13 simon.lindholm10
> Do we want to have that feature?
Probably not - XHTML is dead. In any case it's not worth spending time on.
Jan 13, 2014
Project Member #14
With XHTML I agree, but it's not just about that but also embedded files like images incorrectly served as "text/html" for example. See comment 9.

Sign in to add a comment

Powered by Google Project Hosting