Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Display pretty-printed XML even if XHTML namespace is used on inner element

RESOLVED WONTFIX

Status

()

Core
XML
--
minor
RESOLVED WONTFIX
12 years ago
7 years ago

People

(Reporter: djc, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051025 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051025 Firefox/1.5

Hope this is the right product/component.

I noticed in Firefox that the rendering engine reverts to some sort of broken HTML display as soon as it encounters the XHTML namespace anywhere in the document. I think this is wrong, as it should only be done for documents where the XHTML namespace is on the root element.

Compare:
http://manuzhai.nl/weblog/?transform=false
http://manuzhai.nl/weblog/?transform=false&xml=true

All the xml=true param does is removing the XHTML namespace from the document, and then it displays like XML. I think the same should be done for the first case.

Reproducible: Always




This is with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051025 Firefox/1.5

Comment 1

12 years ago
I can confirm the behaviour, but I'm not sure if it's a bug or not.

Comment 2

12 years ago
This behaviour was specified in bug 64945 comment 5. Don't change it, it's useful.
(Reporter)

Comment 3

12 years ago
What is it good for? I don't think it makes sense.

Comment 4

12 years ago
Confirmed.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051030 Firefox/1.5 ID:2005103003

I'm with Manuzhai on this. If you have an XML file which has embedded xHTML why does the whole document get rendered as xHTML? That makes no sense.
(Reporter)

Comment 5

12 years ago
Also, IF a developer is to look at the XML using View Source, as is suggested by Hixie in the above mentioned comment, there should be XML pretty printing for View Source.
(In reply to comment #4)
> I'm with Manuzhai on this. If you have an XML file which has embedded xHTML why
> does the whole document get rendered as xHTML? That makes no sense.

It isn't "rendered as XHTML", it is styled with CSS. The reason we want this to happen if even a single element is in the XHTML namespace (or other conditions specified in the other bug) is because that single element can contain styles that correctly style the whole document.

I suggest WONTFIX.

Comment 7

12 years ago
Many XBL files include XHTML elements, but it doesn't make sense to render them as anything other than an XML tree.

Comment 8

12 years ago
(In reply to comment #6)
> It isn't "rendered as XHTML", it is styled with CSS. The reason we want this to
> happen if even a single element is in the XHTML namespace (or other conditions
> specified in the other bug) is because that single element can contain styles
> that correctly style the whole document.
> 

alright, I see your point, but I'm not sure if this is the best way though.
The given URL doesn't include any style information, so there is no check whether the element of the xhtml namespace has styles or not? It's still not shown as XML tree?
(not sure if such a check would be too heavy (resource-wise)..)

Comment 9

11 years ago
There's no way to do such a check, really, since arbitrary script can be introduced via any HTML element.

Jesse, we make an exception for XBL, if you noticed.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WONTFIX

Comment 10

11 years ago
I just got bit by this feature on a complex xml-driven site I'm building (viewing the XML to debug it), and though several people seem to feel that this is correct behavior, I think it really should be looked at again.

XML files which contain embedded XHTML do so for a reason, and it isn't to have the rest of the XML file ignored. This isn't an XHTML document, it is an XML document that simply contains XHTML code, as it should. Rendering the XHTML while throwing out the rest of the xml file is obsessing over the trees while cutting down the forrest.

Though it is true that embedded xhtml could include scripts that style the rest of the document, that strikes me as very bad form — and it's causing problems for those of us who want to use the pretty printer with our XML files. If the code already scours the document for any of the HTML namespaces, then it's got to be possible to also look for elements or attributes that could potentially be used to restyle the enclosing document, such as <script> or onload. (That'd be ugly, yeah. But so is disabling pretty printing whenever xhtml is encoutered on the off chance that someone wants to restyle the enclosing document.)

The only reason I would load an xml file containing xhtml elements is to view the entire xml file.

Thanks

Comment 11

11 years ago
Created attachment 227208 [details]
Hacked XMLPrettyPrint.xsl file I'm using to render XHTML within the pretty-printer

A hacked version of the XMLprettyPrint.xsl file from Firefox 1.5.0.4 (from chrome://global/content/xml/XMLPrettyPrint.xsl), to render XHTML elements embedded within an XML file, while pretty-printing the enclosing file. This doesn't do anything about the case where someone might include a script in the xhtml portion to restyle the enclosing document.

The following should be added to XMLPrettyPrint.css:

.html {
  margin: 1ex 1em;
  background-color: #eee;
  border: 1px solid #888;
  padding: 1ex 1em;
}

Updated

11 years ago
Summary: Display XML if XHTML namespace is used on inner element → Display pretty-printed XML even if XHTML namespace is used on inner element

Updated

11 years ago
Duplicate of this bug: 343471
Duplicate of this bug: 456989
As a workaround for this issue, I've filed bug 623236, which calls for the pretty print feature to be used when viewing XML source.

Hopefully, that will get some traction.
You need to log in before you can comment on or make changes to this bug.