Closed Bug 64945 (xmlview) Opened 24 years ago Closed 22 years ago

Better Default layout for "vanilla" XML documents

Categories

(Core :: XML, enhancement, P2)

enhancement

Tracking

()

VERIFIED FIXED
mozilla1.2beta

People

(Reporter: hans_k_97, Assigned: sicking)

References

()

Details

(Whiteboard: [Hixie-P4][ADT3] see comment 113)

Attachments

(3 files, 20 obsolete files)

(deleted), text/xml
Details
(deleted), patch
sicking
: review+
sicking
: superreview+
Details | Diff | Splinter Review
(deleted), text/xml
Details
When looking at an XML document that doesn't have a stylesheet, the data output needs to be more readable than simply displaying a space-separated list of the available data elements. I spend a lot of time looking at industrial XML and the (unfortunately IE-centric) feature of being able to look at the entire document (including tags) by default, with the ability to click and expand or close tags, etc. without "view source" is very useful. However, I don't think this is necessarily correct behavior- but a similarly readable option would be invaluable.
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Default layout for "vanilla" XML documents is unreadable → [RFE] Better Default layout for "vanilla" XML documents
Targeting for mozilla0.9.1
Target Milestone: --- → mozilla0.9.1
For a real world example compare ie to moz rendering http://p.moreover.com/cgi-local/page?index_xml+xml
Because of the precedent set by IE we should show XML without stylesheet in a similar way as IE. There should be a pref that controls the behaviour, so you can turn the IEism off if you want (for example I usually would, because it makes testing easier as you do not need to write a stylesheet every time).
OS: Windows 98 → All
Priority: -- → P3
Hardware: PC → All
Ok. If we implement this we have to be careful to avoid doing it for any document that matches any of the following conditions: Has an <?xml-stylesheet?> PI Has XHTML anywhere in the document (including attributes) Has XUL anywhere in the document (including attributes) Has an HTTP Link header Has an XLink anywhere in the document Was created by script Is modified by script Contains an element or pseudo-element that has style applied to it by any rule in ua.css or related stylesheets (e.g., MathML or XBL elements) Even then, we might have missed some cases where the best behaviour is to not use the IE tree stuff. I can understand that web developers may wish to enable a view source mode by default for XML documents -- but I do not see why end users (the majority of our users) would want to view the source of XML documents. If they come across an XML document on the web, it's a bug as far as they are concerned -- the author should have used either a known language such as XHTML or MathML or as a last resort should have provided a stylesheet. If web authors want this then they can just go to "View Source". In the unfortunate case where we _do_ implement this, then it is important in my opinion to use the same layout as the View Source window. If we have two different view source mechanisms we would be both wasting resources and confusing users. cc'ing mpt for UI advice.
Keywords: qawanted
Whiteboard: (py8ieh: test cases required)
I made a sample XML file that can be used to test the features - it also shows what needs to be handled. I made a first pass at a CSS stylesheet that could be used to achieve this. I am thinking that we might want to attach a default script for these documents as well, more on below... Even though all of this must be controllable from prefs, these things should probably be turned off if one of the following is true: - the document contains an xml-stylesheet PI - the document contains elements from namespaces we support and that get styles applied to them automatically (XHTML, XLink, SVG, MathML) - there is a stylesheet attached to the document by some other means (HTTP headers) - it is arguable that we might want to remove the defaults if some process later applies styles and/or scripts to the document First time the user opens a plain XML document s/he should be presented with a dialog box that asks whether s/he would like to enable the default XML stylesheet or not, and whether the user would like to save the decision so we will not ask it again (it should be in advanced preferences as well). The prefs I am thinking about here would be: // Style on/off: true or false, default true pref("layout.xml.default.stylesheet", true); // Stylesheet URL or none, default our xml.css pref("layout.xml.default.stylesheet.url", "resource://xml.css"); // Script on/off: true or false, default true pref("layout.xml.default.js", true); // Script URL or none, default our xml.js pref("layout.xml.default.js.url", "resource://xml.js");
Keywords: qawanted
Whiteboard: (py8ieh: test cases required)
Ok, I spoke with mpt about this on IRC in #mozui, and we came up with the following spec. Note that it adds no new prefs to the UI, because that is not going to help the user. (Of course, add as many hidden prefs as you like.) If an XML document has no author stylesheet [1] no author script [2] and contains no elements or attributes in namespaces given in ua.css [3], then we should display it as if someone had asked for the document's source instead of laying it per CSS. Once the document is shown, we have to listen for mutation events to (a) update the source view and (b) switch out of the source view if any of the conditions listed above stop applying (e.g., a stylesheet PI is added to the document). Things we should avoid doing: Inventing a totally new source view. Breaking XHTML or MathML. Making it hard to add extensions to ua.css without rebuilding. Killing dead the potential for DOM-based creation of styled XML documents. Notes: [1] There are various ways to add author stylesheets: style attributes in various namespaces, style elements in various namespaces, various different link elements in various namespaces, HTTP headers, presentational attributes on elements in certain namespaces, etc. I don't know how to test for this properly. For example, one way to add styles is to dynamically bind the root element to an XBL binding that links to a CSS stylesheet. We have to be able to cope with this case correctly. [2] Similarly, scripts can be added in many different ways. The XBL case is possible here too, but that's not the only way. Adding event handlers via the DOM is another possibility. Some elements and attributes in various namespaces add script to the document, etc. [3] The contents of the ua.css file can change depending on the build options and user modifications at run time. For example, MathML is sometimes supported and sometimes not, and all links (XLink included) are styled by html.css. So again we can't hardcode this. The best solution I can think of is suboptimal and is to check the CSSOM of the UA stylesheet and its kids when displaying the XML file in question. The ideal solution would be to crawl the DOM checking getComputedStyle to find out if anything was styled, but that's just stupid from a performance point of view. Heikki: Please do not remove my markers from the status whiteboard or keywords.
Keywords: qawanted
Whiteboard: (py8ieh: test cases required)
>... > then we should display it as if someone had asked for the document's source > instead of laying it per CSS. Not quite. If I choose View Source for an XML file, it should show me the file as plain text, the whole plain text, and nothing but plain text -- just as it should for any other file type. It shouldn't show me a fancy tree; the fancy tree should only be shown in the (non-view-source) style-less circumstances you mention.
> If I choose View Source for an XML file, it should > show me the file as plain text, But with colours (syntax highlighting)?
I'm saying there should be no "fancy tree", we should use view source (with colouring) instead. If authors _really_ want the opening and closing, then we can add that to viewsource (no reason why clicking on tags in viewsource shouldn't collapse their contents). The reason we are doing this is to make people think that we support XML. Currently people view XML documents in IE then Mozilla and our rendering makes them think (incorrectly) we don't support XML.
> (no reason why clicking on tags in viewsource > shouldn't collapse their contents). How would this work? The source isn't necessarily indented, and there *should* be a way to see if an element is collapsed or not.
I am also more inclined (for the short term) to keep view source as is, and only mess with the default view of XML without style/script. I believe IE is doing this as well (view source -> Notepad still?). I believe it would be possible to choose some compromise between the foolproof extensible (namespaces etc.) solution and a straw man solution. The best solution would probably be to have several levels of view source: 1) Raw text as is, 2) Syntax coloring, 3) Indented, collapsible with syntax coloring. Note that anything else beyond raw text would most likely mean parsing the data which would lead to altered data. Today the situation is that we parse view source, and do not display it as is (even without syntax coloring). The default view source view would be 1), the default "no stylesheet XML document view" would be 3). The view source window should have buttons to switch between views. This would require so much work that I think it is outside the scope of this bug (i.e. a new one should be opened for this).
Heikki's right. View source should show just the source. Any (optional) fancier presentation of source is outside the scope of this bug.
Ok, well, since mpt doesn't think it's confusing to have several different source views, I stand corrected... although I'm still not convinced that we need a "fancy view" at all. The only reason we are doing this is to make authors think we support XML when they give us an XML document whose correct output would be one long line of text. Doesn't what view source do already satisfy this need? My other comments stand.
> mpt doesn't think it's confusing to have several different source views Where did I say that? What part of `View source should show just the source' don't you understand? :-) > Doesn't what view source do already satisfy this need? If it does, that's a bug. View source should show just the source. Sure, it can change the colors, but it shouldn't change the indentation or other whitespace.
Where did I say that changing indentation and white-space would be good? Why would "[changing] the indentation or other whitespace" "make authors think we support XML when they give us an XML document whose correct output would be one long line of text" any more than a loyal coloured view source?
Hmm... as I am now looking at the the source I am starting to lean more towards rigging in view source window to show an XML document without stylesheet (CDATA sections, processing instructions, comments, entities would cause serious problems otherwise). How about, if we do not see any style information, we present the user with a dialog: This XML file does not appear to have any style information associated with it. Would you like to open it in page source view? [x] Remember this decision for all XML files without style information. [Yes] [No] If the user answers yes, the simplest solution would be to fire the view source command which would open the file in a new view source window. It might also be easy to reuse the current window. I am not sure which I prefer, they both have their pros and cons. This would make it clear that we support XML and that we think it does not make sense to try and view the file without a stylesheet, except as source view. Then we could open new bugs to add different views to view source (raw, pretty print).
Sounds great! (See my comments dated 2001-04-20 22:50 for the difficulties in finding out if we have "style", though.) I'm slightly concerned about popping up a dialog box (I can never work out which of the dozen windows I have open is the source of the dialog when Mozilla says something like "could not contact host x.y.z", and I don't see why this case would be any different) so how about this: when we detect the conditions that make us think there is no style we display a (XUL) page like this instead: ____ | L\ This XML file does not appear to have any style information |<xml>| associated with it. | | |_____| [ View document without style ] [ View source ] Ok, so UI design is not my area. Over to mpt for better ideas...
Well, we use dialogs otherwise so it would be inconsistent to use the content area for the message (although I agree with you that sometimes it is confusing). So I do not think we can go there, unless we go and change ALL the cases were we pop up dialog boxes when content area message would be 'better' (but please note that if you have retrieved part of a document it is not nice to use the content area for a message). In any case, displaying a message in the content window is also tricky, since by the time we would be able to display the message we would already have displayed the original document...
Being paranoid I wanted to save my current work. I think I have every case covered where we do not want to ask (except for scripts 'cos I am not sure about them, but one line addition only). Putting up the dialog is easy, but right now I seem to get into a hang situation (I can not dismiss the dialog). That might be due to the debugger or the fact that I do not have a parent window for the dialog. Because this thing would will affect l10n I do not know how likely we are to get this in.
Status: NEW → ASSIGNED
You shouldn't use an alert which requires the user to make a decision, unless the user is in danger of some sort. That's clearly not the case here. And you especially shouldn't throw alerts for stuff appearing in the Navigator content area, since that will aggravate people who are trying to flick through the session history. Fortunately, in this case showing an alert is unnecessary, because the alert-less UI is already there. If the user wants to see the fancy expandable tree, they just look at the content area of the window. If, on the other hand, they want to see the raw text source, they just need to choose `View' > `Source'. Meanwhile, Hixie's suggestion of a header in the content area, giving a short explanation of why the XML is appearing as a fancy tree, is an excellent one. It is true that we don't do this for other types of errors currently, but that is what bug 28586 is about.
Localization freeze in effect, moving to next milestone where this can be fixed.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
There is a good example of a 'default' stylesheet in the apache xsl-parser. Yes it is an .xsl and is currently IE-centric. With some (minor) changes it will work with Mozilla as well. It does everything from coloring, collapsing/expanding etc. Maybe the guys (and girls?) from Apache may let us borrow it, expand it and ofcourse donate the result to back to them... If you all are interested I'll see if I can adapt it to work with Mozilla.
Interesting... Unfortunately I do not know much about XSLT. Peter, do you think using an XSLT stylesheet here could work?
Attached file default xsl like IE (obsolete) (deleted) —
Attached file first working example for Mozilla (obsolete) (deleted) —
The attachment contains an example of how the 'default' stylesheet could work. Because of two limitations in XSLT in mozilla (no css and javascript from an xsl) an example html file is included. That is generated from the .xml and .xsl file with Xalan. (sorry no standalone Transformiix here ;-) ) This example is an adapted version from the one that comes with Xalan and seems to originate from the IBM Lotus xsl project. Please add comments here.
Just my 2 cents: to be honest I think the current view-source functionality in the main window would be fine. With syntax highlighting it's obvious we support XML.... anyway, just an idea. To be honest the tree thingy in IE doesn't do much for me. I prefer having the original layout exactly.
> Just my 2 cents: to be honest I think the > current view-source functionality in > the main window would be fine. With syntax > highlighting it's obvious we support > XML.... Not exactly obvious, no. And see <URL: http://www.finetuning.com/finetuningfaq.html >: > What's the best XML Browser? > > Netscape 6, has little or no XML functionality that isn't > closely-tied to its application platform, zero XSLT support > (and apparently serious no plans for adding it), and no > default view for an XML document. So if you open a file that > isn't associated with a CSS style sheet, it just dumps the > text. > > IE5, on the other hand, *is a useful XML Browser from a > developer's perspective because it provides an easy way to > access and view XML documents when you are testing or > debugging them*. [my emphasis]
Aw, and I thought I had been working on XML for a long time. Seems like all this (that is supported by Netscape 6) is not XML, or not worth mentioning: * display XML documents, * format XML with CSS, * manipulate XML with JavaScript, * load XML as data, * do some XHTML, * do simple XLinks, * do Namespaces in XML, * build UI with XML language (XUL), * build sidebar with RDF (XML language), * etc. (And did you know that IE has crappy support for formatting XML with CSS, parses entities wrong, does not support XLink at all...) If we knew this beforehand, we should have just implemented * XSLT and * view source view of XML to make the world happy. Can we have a new component, Banish incorrect information?
Yes, that would be "Evangelism". Feel free to file a bug! :-) Heikki: Any progress on fixing this bug in one way or another? After 0.9.1 ships we should have some time before the next Netscape l10n freeze.
Haven't worked on this at all. But I just had a chat with Nisheeth. It seems that as long as we do not do incremental layout in XML (this should be fixed) we could build the content model for the page as we first load it and display a message that no style available and ask what the user wants to do instead. If the user wants to see the source, we could discard the content model and load as view source. Otherwise we'd discard the current message content and put the already built content into place (frames only need to be built). Filed bug 84546 on Evangelism to get the information on finetuning corrected ;)
I like that. So, if an XML document has no author stylesheet [1] no author script [2] and contains no elements or attributes in namespaces given in ua.css [3], then we would display the following in the content area: ____ | L\ This XML file does not appear to have any style information |<xml>| associated with it. | | |_____| [ View document without style ] [ View source ] While that is shown, we have to listen for mutation events to switch out of the source view if any of the conditions listed above stop applying (e.g., a stylesheet PI is added to the document). If the user clicks [ View source ], then we don't worry about monitoring the source. If the user clicks the first button, then again we don't need to worry, since it would Just Work (as now). Actually, we could even do that on the fly, no need really to wait for the entire content tree, is there? As I mentioned bfore, we should avoid: * Implementing a totally new source view. * Breaking XHTML or MathML. * Making it hard to add extensions to ua.css without rebuilding. * Killing dead the potential for DOM-based creation of styled XML documents. Notes copied from my comments earlier: [1] There are various ways to add author stylesheets: style attributes in various namespaces, style elements in various namespaces, various different link elements in various namespaces, HTTP headers, presentational attributes on elements in certain namespaces, etc. I don't know how to test for this properly. For example, one way to add styles is to dynamically bind the root element to an XBL binding that links to a CSS stylesheet. We have to be able to cope with this case correctly. [2] Similarly, scripts can be added in many different ways. The XBL case is possible here too, but that's not the only way. Adding event handlers via the DOM is another possibility. Some elements and attributes in various namespaces add script to the document, etc. [3] The contents of the ua.css file can change depending on the build options and user modifications at run time. For example, MathML is sometimes supported and sometimes not, and all links (XLink included) are styled by html.css. So again we can't hardcode this. The best solution I can think of is suboptimal and is to check the CSSOM of the UA stylesheet and its kids when displaying the XML file in question. The ideal solution would be to crawl the DOM checking getComputedStyle to find out if anything was styled, but that's just stupid from a performance point of view.
If the document already has no scripts attached to it, how can any script modify it then? Doesn't the security manager prevent this? Can you attach XBL/XUL/CSS whatever to a document if it does not load any stylesheets (and does not have embedded style blocks in it)? I also checked out the XSLT stylesheet, and that looks pretty neat. (I have no idea what the second attachment from Ronald is, seems like binary data to me). I edited the XSLT attached so that the style is loaded from a separate CSS stylesheet, and lowercased the generated element names, and now the transformation shows up nicely. Scripts still do not work. The XSLT approach seems nice as it would provide almost exactly the same view as IE (and others mimicing IE), somebody has done the work of creating the stylesheet already (although I am not sure if we can use this one because of potential license restrictions), and we could probably leverage the XSLT plumbing to implement this with no more difficulties than any other way. There are still some problems with scripts (and embedded style), but peterv is working on them.
Any page from the same domain can modify an XML page, AFAIK. I'll create a test case for this now.
heikki: Ok, here is a first attempt at a demo test case: http://www.hixie.ch/tests/evil/xml/001.xml This case musn't regress when we fix this bug. :-)
Here is another demo, it uses frames instead of window.open: http://www.hixie.ch/tests/evil/xml/001.xml Both of these tests are purely XML based, no text/html content is involved.
Keywords: qawantedmozilla1.0
Whiteboard: (py8ieh: test cases required) → [Hixie-P4]
Bummer! Who made JS work this way anyway, we should disable it to make poor programmers life easier ;) ... Hmm... Actually, a document observer can easily catch the modification attempts and even though the script from the other window might try to modify our message document it could forward the attempt to the real document, and then switch views. Unfortunately this is confusing to the user: first we are asking for his decision, but if the script in the first window (in your example) modifies the document in the second window while we still have the message up there we would replace the message with the real document. Or should we in such a case change the message to state that the document has been changed by a script and that it would make more sense to view normally? I am not sure if catching style changes is that easy... Nor do I have any ideas how to detect namespaces we have styles for (but I can easily detect if we have an implementation for a namespace). Could you make the first document HTML, so we could test how IE behaves?
heikki: Ok, here's the first document as HTML: http://www.hixie.ch/tests/evil/xml/001.html Unfortunately, it won't help you. IE doesn't support XML at the DOM level. They don't provide document.createProcessingInstruction and their window.open() doesn't return a window object that has a DOM that is editable in the XML case. In fact, if you look at the following test case, you'll see that their DOM actually contains the DOM for their transformed document (which is very wrong per W3C, since there is no default transformation applied and XSL has no concept of UA stylesheets): http://www.hixie.ch/tests/evil/xml/003.html Trying to dump the DOM of an XML document that starts off with a processing instruction and some XML returns you an HTML document with a <LINK> element for each XML stylesheet PI, and the XML fragment as unknown tags as children of a BODY node. See: http://www.hixie.ch/tests/evil/xml/004.html In the case you give, I don't think we should change the message to state that the document has been changed by a script, since that would break this scenario just as much as the original message. The point is the message should only ever appear if there is no reason for the document to be displayed normally. Therefore I think we should switch straight away if we detect a change. Even that is not ideal because of the flicker it causes.
Heikki: the second attachment is a zip file (or tar.gz, don't remember) where besides the layout/coloring all the scripts work so you can actually collapse and expand nodes.
Target Milestone: mozilla0.9.2 → mozilla0.9.3
*** Bug 87181 has been marked as a duplicate of this bug. ***
*** Bug 66983 has been marked as a duplicate of this bug. ***
The latest patch does the XSLT transformation with the files Ronald provided (JS still does not seem to work for me). The behaviour is controlled by a pref, there is no UI yet. I have not yet checked what happens if a script tries to work on the document from another window - in fact I do not know (yet) for sure what the script sees (the transformed document or the original).
Seems like we also loose the original document in transformation. At least Hixie's samples show that we access the transformed DOM :( Peter, is this a known problem? Is it so by design? I know the DOM WG has discussed this problem, but there are no methods/properties that could be used here (to access either the original or transformed document) that I know of.
We discussed this today at Nisheeth's staff meeting, and came up with a new idea. What if we added an item to View menu (or View > Use Stylesheet) for Tree View or some such name, which would apply the default XSLT transformation? Power users could even diddle with their default transformation to get different output! It might even work for documents that have styles and scripts in them... We could display a warning to the user that a transformation will take place etc. At the moment I don't think it would be possible to switch back to the normal view without reloading. After all, the tree view is mainly useful for developers; end users should never even see nor care unformatted XML. Peter, can this be done without the content sink and changing the original document (i.e. without inserting xml-stylesheet PI)?
Heikki, it should be possible using nsIDocumentTransformer. I know I tried this about 10 months ago, but Transformiix wasn't quite up to it then. The only tricky part might be switching the original tree with the transformed tree. I'll try to look into this tomorrow or over the weekend.
If we add a menu item to the View menu it should be done as part of bug 6782 as one of the default local user stylesheets that can be applied. This would make it totally configurable which would be a big bonus.
Heikki: Does the JS work if you run it standalone, e.g. from disk? It does for me on the 2001070421 build on linux. What is the pref to activate this or isn't it in the nightlies yet?
Heikki: Sorry for being unclear. The reason it does not work (yet) on xml files is that Mozilla does not load a .js/.css file in the result document. If you save the transformed document as html and then load it from the same location you'll see it working. There is an example html file in the attachement 36257 (05/26/01)
Small correction: Mozilla *does* load external .css in the result documents. Just no .js nor embedded scripting (see bug #59912)
> After all, the tree view is mainly useful for developers; end users should > never even see nor care unformatted XML. Sure, but then why does this bug exist in the first place? Because developers expect an unstyled XML document to be shown in a Web browser as a tree. A simple, Internet-Explorer-like, non-configurable, non-themeable, non-content-pack-able, tree. Defaulting to raw text, and making developers jump through hoops (menu items, alerts, whatever) in order to get the tree which they are expecting, will just annoy them. If they want raw XML source, that (by definition) is what View Source is for.
They only want the XML tree because that is what IE has taught them to expect. The reason this bug exists is that reviewers have loaded XML pages in Mozilla, seen them rendered exactly as per CSS, and thus concluded that our support for XML is worse than IEs. If we display the coloured view source instead of the pretty tree, that will solve that problem. The best solution, IMHO, is what I have described several times above, namely displaying a message in the content area explicitly stating that we support XML. See my 2001-06-07 22:43 comment for a detailed spec.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Often requested feature.
Keywords: nsbranch+
Heiki - This is marked as an "Enhancement" right now, so I have a couple of questions: 1) What's the ETA (i.e. Will it get in before 08.31)? 2) Is this a "stop-ship" for TM0.9.4?
I don't know the ETA yet (and I am doubtful this could make it before 8/31), and this is certainly no stop-ship. But this is often requested feature so I would like to try and work on this until the last possible moment. I have a few approaches I can still try that shouldn't be too scary. The XSLT approach still looks good to me, but there are at least two open XSLT bugs (one of which has no workarounds) that might prevent us deploying that solution for 0.9.4. peterv is still working on those, however. But I have a couple more important bugs on my list right now so work on this has been stalled.
Keywords: nsbranch+
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Sorry, I'm a foreigner here. But as a user and web developer I'd like to give my opinion. The result of all this should be a solution that is the most useful one to the most people, without crippling mozilla regarding to its standard support and correctness. As a web developer I'd like to see the XML document (and every other content-type) shown in the best posible way. If I browse a vcard content-type I'd like to see a business card (and the vcard source in view-source). If I browse to a text/xml document I want it to see it in the most useful way. A non-styled XML document is a neutral piece of infomration. A collapsable tree is better than a simple colorized tree or the current everything sticked together view, period. The argument about "mozilla styles the document using CSS" is IMO wrong. There's nothing in any standard that says that CSS should be used in case there's no http header or PI saying it. In this case, mozilla is deciding a way to format the document that will clearly yield unusable results in every case. So, please... let mozilla show a non-presentational XML document in the most rich and useful way, whatever form that is (collapsable tree of tags? tree of funny ballons? xpath tooltips when moving the mouse over the tags?). thanks and sorry for the intromission (and excuse my bad non-native English).
Target Milestone: mozilla0.9.5 → mozilla0.9.6
*** Bug 14587 has been marked as a duplicate of this bug. ***
*** Bug 104997 has been marked as a duplicate of this bug. ***
A thought. Once the DOM Inspector is on by default, it sounds like it would satisfy all the things people want in this RFE... all that would need to happen is hooking into it for certain kinds of XML (and we seem to already have code to detect when this would be necessary in attachment 36257 [details]).
Target Milestone: mozilla0.9.6 → mozilla0.9.7
DOM Inspector is now in the default builds (bug 102574). I like the proposal in comment #65. Any reasons not to go forward in this direction?
I like the idea, too. Lets do it! :)
I think the DOM Inspector is great, but not for the average user. He/she (it?) does not want to know how an xml document is decomposed in dom. R.
Yes, I think using the DOM inspector for this is a great idea! Don't worry about the average user thing - as has already been pointed out, average users should never see raw XML. Having a DOM inspector would not only be very useful, but also totally blow IE out of the water! It'd show people that Mozilla really is the premier platform for web development. It gets my vote. thanks -mike
Target Milestone: mozilla0.9.7 → mozilla0.9.9
I am again working on this. I can now display a message in the content area, and have some ideas how to put the original document through transformation from there.
Keywords: nsbeta1nsbeta1+
Would anyone be willing to create an XSLT stylesheet for the default view? I don't think we can use the one already attached here because of license issues (but if anyone can prove me wrong that would be great). Status: I currently am in a situation where I display the message to user (this is XML, what do you want to do), but for some reason I have not yet been able to get the scripts to run in this dynamically created document. Once that is cleared next step is making us go through the transformation.
I think this stylesheet mimics IE's, rather than just copying it outright. It might be best to create a new one- that IE one isn't the most useful one to use.
Any suggestions? Then I can see what I can come up with.... A Nesting kind of like XMLSPY does could be an option... Let me know
My two pence: DOMInspector: Very useful for DHTML (it's ironic Mozilla has so great tools for development of DHTML) but almost useless for work with pure XML. As someone pointed out average user should never see pure XML, but for someone working with XML very much IE way is good. People working with data in XML form are not interested in their DOM structure. (Anyone has ever parsed non-indented SOAP messages with a lot of SOAP-insignificant data? You would praise for colapsable view. And simply on Windows IE is the quickest and cheapest way.) ViewSource: Much more useful than any other ViewSource ever, but also slow and not customizable. My conclusion: When JS from XSLT can work (and Ranges are working properly and so on ^_^) we can build very powerful yet customizable XML viewer on top of Mozilla which would satisfy almost everyone needs. I'm pretty sure I can find some time to do so if we can settle on something.
I'm confused by that last comment... "DOMInspector [...] almost useless for work with pure XML" ... "You would praise for colapsable view". Which is exactly what the DOM inspector gives you.... a collapsible tree view of your XML document with the ability to see the attributes on various tags and the like. Am I missing something?
I'm creating webpages almost ten years and last two years XML (data in XML - it's important!) is my daily work. I run DOMInspector when I'm cretaing some non-trivial HTML layout and I run IE when I want to see XML files. Simply DOMInspector is by far the best thing if there is something broken with your page (your scripts) and you want to track it down, and IE is by far the best thing when you want to get "complex" view of XML data. Just my experience. Simply ViewSource with some handy addings (~ what IE does) is from "data-view" much better then DOMInspector (data separated from the markup, #text-nodes everywhere you look etc.).
Target Milestone: mozilla0.9.9 → mozilla1.0
*** Bug 127920 has been marked as a duplicate of this bug. ***
ADT3 per ADT triage.
Whiteboard: [Hixie-P4] → [Hixie-P4][ADT3]
*** Bug 132751 has been marked as a duplicate of this bug. ***
taking...
Assignee: heikki → nisheeth
Status: ASSIGNED → NEW
In what way is an XSLT-based solution better than embedding the DOM inspector into the window/tab? I noticed that the DOM inspector does not display text nodes inline in the tree view, but that is an enhancement that could be made to the DOM inspector, I believe.
I agree with Brian
Changing QA Contact
QA Contact: petersen → rakeshmishra
I was introduced to this discussion today. From my view this is all very clear: If I want XML displayed in fancy way I add some style information. If I do not want any rendering I do not include any styles. I consider it harmful to the XML standard if there would be any default view of an XML file. I could only imagine one solution: If a user uses a popular DTD or schema - maybe the developers of such DTD have a defautl stylesheet on a web-page. So Docbook-XML could be displayed nicely without a stylesheet. But there we have the same problem: We do not know what the author intended. Just imagine that he HATES blue ;-) - and Mozilla displays the elements in blue! Oohhh! ;-) he will hate Mozilla for that. The discussion here indicates one thing very clearly: That there are different viewpoints how XML SHOULD be displayes by default. I think this can only lead to the conclusion that no default display other than displaying the contents of elements should be considered. I also can not see why a web developer wants to view an XML source with a browser? Don't they have an editor or parser? Nonetheless I think it is good to provide the possibility for users to link to a default stylesheet (CSS/XSL) may via the "Apearance" preferences. Summary: If I publish an XML document without style I do not want it to be displayed with any decoration. This is something that never could be reached with any kind of default fancy output. PS: If really many people want fancy plain XML, maybe it would be good to be able to browse with the source code window (add an address bar to it) . cu, Thilo
If the author of an XML document doesn't specify a style for their XML document, it means they don't care. It means it will be displayed in whatever default way the tool being used by the user displays. I use IE to view XML because I like the default way it displays XML when there is no specified style. OTOH I would love to use Mozilla to do this, except that currently, I hate the way Mozilla displays XML by default. Please help me never use IE again. Believe it or not, Microsoft set the de facto standard for plain XML display by putting IE into 90% of the population and having it work the way it does. I'm not saying this is best way to do it, I'm just saying that this is what most people are now used to, and probably what they expect. I think creating an config option to have Mozilla behave the way it does now (just displays the text contents between each tag) and similar to the way IE does it would be a great feature.
And if you think about, Mozilla technically doesn't display XML right by default. Why? Because in XML, spaces *do* matter. Mozilla shrinks all the whitespace as if it was rendering HTML. So someone could actually use this to say that Mozilla doesn't properly support XML.
See, the reason this is an issue is because only displaying the content of the elements gives the very strong impression that Mozilla "doesn't understand XML". As an XML developer myself, I will contest that "view source" in an XML file is not convenient enough. The reason why I personally am voting for this feature is because right now there seems to be a shortage of tools that are able to conveniently "pretty-print" an XML file from HTTP, also allowing expanding/contracting, highlighting, and all that good stuff. IE does this, and it is very easy and nice (although possibly against the grain of the specs, as you say). View-source does the highlighting, but without the pretty-printing of whitespace, it is pretty useless when looking at the output of pretty much any type of automatically generated XML. View-source and the DOM-viewer also require one more click, which requires XML developers to (1) know what to click and (2) be satisfied with not being able to quickly hit "refresh" to test changes to their output. Also, the DOM-viewer, as already discussed in this bug, doesn't display text nodes inline, which might turn some people off. Why can this not be configurable, and have the best of both worlds? A simple pref, even if it is hidden (although not preferably), that lets the user set the default stylesheet for a given mime-type (default text/xml and application/xml). A stylesheet that renders similarly to the one in IE should be included with the distribution, and documented. The default setting could be to have no default stylesheet, and fall back on displaying only elements' content (although personally I think that shouldn't be an option, because in XML the element names and attributes are also very relevent to the data being displayed, and to not display that extra information is bad. But that's just me). Mozilla has the potential to be an awesome platform for XML development, especially since it does a much better job that IE with cache handling. But almost everybody I know doesn't even know that using XML in Mozilla is possible (seriously), for the simple reason that it doesn't pretty-print the XML. This is a very big failure, with a very simple fix. Why not make 90% of the XML developers in the world happy?
> I also can not see why a web developer wants to view an XML source > with a browser? Don't they have an editor or parser? Thilo, this is like saying that the HTML "view source" is is useless because you have an HTML editor. Many server-side applications nowadays generate XML on the fly, as an end product or more often as part of a processing pipeline (think Apache Cocoon for example). Being able to access such XML contents through a browser UI is invaluable for debugging such applications.
Lynx has a beautiful source-browsing feature (you can reload page while viewing source). I think Lynx is better for XML developers . I am not voting für Lynx against Mozilla on every level. But see, this is not a matter for simple users. If people call themselves developers they are surely able to install a version of Lynx. I also said, taht an enhanced source browser would be acceptable for me. But I would vote totally against any default display somehow only because IE began to make a false behaviour. Why should I use Mozilla if it behaves (wrong) like IE? I think Mozilla should be more close to the standards. Regarding white space I would say there is a need to be able to change the behaviour of the browser (see also: <http://www.oreillynet.com/pub/faqs/xml_faq_space> ). A good browser allows a user to change the default behaviour. The good thing is, if there can not be assumed any "default behaviour" is, that authors are forced to attach stylesheets,... I am sure we can easily emulate IE behaviour with a stylesheet? Why not an option "emulate IE XML display"? I fear that if authors think that the behaviour of IE is correct we will see a lot of pages depending on exactly this feature. We should not forget: XML is not HTML which had a default layout. This leads to obstruction of progress and not forcing the use of stylesheets (which are actually freeing XML authors). So there may be some arguments for other display options but I do not see any good in changing Mozillas default behaviour, except that this would be a set-back. I also can imagine that user will begin to change the default look a bit - and not starting a stylesheet from scratch - so depending on a fancy Browser to display their XML correctly. Anothere thing: There is nothing won if only Mozilla and IE display XML the same way. Only if every browser would do so, authors could depend on it. PS: I only use Mozilla and sometimes Lynx for XML development as you might have guessed ;-). cu, Thilo
We already have a UI spec for this, it in comment 37 in this bug.
Whiteboard: [Hixie-P4][ADT3] → [Hixie-P4][ADT3] see comment 37
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1-
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1+
*** Bug 145156 has been marked as a duplicate of this bug. ***
Now c'mon. It's a sad, sad day when MS's bundled remotely exploitable html rendering piece of flacid man-flesh can properly (and keenly) display XML and mozilla can't. As far as relying on lynx (a ****-filled clownshoes, .. I digress) I'd sooner telnet and issue a GET. I can offer any number of questionable barters in exchange for your attention to this matter. Thank you again, Mozilla developers, for your continued efforts. May you overthrow the dominance of IE and scatter it's entrails gleefully.
> ...properly... Just for the record, Mozilla renders XML within the specs, more so than IE. But yes, it would be nice if we could implement what's described in comment 37.
Here's why I think Mozilla needs this: In my application, we have thriod parties sending xml requests to an insurance quotes system. We generate the response message and send that back to the 3rd party. That xml is never displayed to the user, so when we send it back, it's one long string of xml, with no style sheet attached. As a developer, we have a web page that simulates the third party, in which we can type, or paste, an xml request message, submit it to our servlet and back comes the xml stream. If it is displayed with no style at all, it's just displayed as one long stream of text, not at all pretty and not at readable, wheras IE "pretty prints" it and allows me as a developer to easily examine the various nodes and their values. Yes, of course I could cut and paste this into another tool to "pretty print" it, but it's SO convenient to do it right there in the browser. I think it would be a huge help to have Mozilla fall back to a default "pretty printed" display of the xml if no style sheet is specified.
Hi all ... I've seen that this RFE was first targetted for 0.9.1. It now seems to be targetted for 1.0 . Mmmmm ..... Now that Mozilla 1.0 has been and gone, is anyone able to give even an _approximate_ ballpark release that this fix may be in? I just ask because this fix has been on the list since Jan 2001. ( I'm sorry - I'm not wanting to sound whiney :-), but it's been here for quite a while ... ) Thanks in advance for your comments! ( and **VERY many thanks** for your great work so far ....
I would like to know as well if and when we can expect 'pretty XML' in Mozilla. In our company XML is used for almost everything and lots of my colleagues were really interested in Mozilla and started using it. Until... the questions came in asking "hey, how can I get Mozilla to display my XML in any usable way?". Sad to say but very understandable from their point of view they went back to using IE again (at least for work-related stuff) because of the incredible ease-of-use to just be able to either get HTML or pretty XML from our (web)services without having to switch to another view or application. And no, adding stylesheet info to our XML is NOT an option. This bug gets my vote! :-)
An idea I had: it would be easy to improve on what IE already does with XML. In a prefect browser I would have a list of namespace->stylesheet mappings where I could tell the browser which stylesheet to use to render a certain XML document (why use the stylesheet the author has defined? I might not have access to it or I might just not like it). In that list I should be able to define which stylesheet to use (if any) if none of the others match. One might ask why it should be possible to define this for XML while something similar doesn't exist (and maybe isn't needed) for HTML? Why can't you always define a stylesheet for your XML? Well I don't know about the rest of you but we use XML in a lot of ways, many of which have no direct use as a displayable document. So many (if not most) documents just hold data and have no stylesheet defined for them (and don't need one!). Of course we could define a standard stylesheet ourselves and attach that to all our XML documents but that would mean that I can't just send an XML document to somebody else, I would always need to send the stylesheet as well (this because even if the other uses IE the XML would not display because IE will try to use the stylesheet). Besides the basic fact that that particular XML document is not for displaying so WHY am I forced to pollute it with layout information? So what do y'all think? Is the above suggestion a feasible idea?
It's almost impossible to do that while still handling the dynamic cases. We already have a proposed spec for this which handles all the cases fine, see comment 37.
Most of the comments argue that having a default stylesheet will disable nice features such as dynamic behaviour. I find it strange the general case must get out of the way for the specific case. My opinion is that if you want to do something special (i.e. ecma script in a xml file) you should indicate that somehow (with a stylesheet?). If your xml is just data, then you should not have to add a stylesheet.
Status: NEW → ASSIGNED
The general case for which behavior is completely undefined should not get in the way of the specific case for which behavior is clearly standardized. Developers should be able to rely on us implementing standard APIs correctly... I fail to see how ECMAScript in an XML file is "something special", any more so than anything in an XML file that is not in the same namespace as the main file.... In fact, I would argue that using a web browser (!) to read arbitrary XML is the really odd thing to do. I would want to use an application familiar with the XML vocabulary in question that would actually be able to display the information in a useful fashion, not just as a raw tree.
You are right about implementing only that which is clearly defined but then you will probably also admit that: a) the current way Mozilla handles unknown XML is not clearly defined and next to useless b) it would be great to be able to register other namespaces (besides the current XHTML, MathML and RDF ones) with their respective stylesheets. XHTML and MathML documents don't contain PIs either and they display correctly. I did understand that currently adding support for other namespaces is only possible by making a special Mozilla build, which is a pity. I hope that in a future version (maybe aided by discussions as this) a more dynamic system will be made possible. And when we have such a system it might not be such a big problem to assign a stylesheet to all unknown namespaces thereby enabling a default view for all XML documents. I don't mind to have to install that stylesheet as a separate option if there is so much oposition to making this a standard Mozilla feature :-) I agree that a web browser is not the best application with which to manage XML documents, but it is the best application to VIEW documents in the best way possible when served over the Internet. If it was possible to install a plug-in which would show XML the way I wanted I would not bother you anymore in this list but the fact is that that isn't an option. So I'll continue to try to get the best possible user experience (and developers are also users :-) out of Mozilla.
I would argue that sometimes it is advantageous to use a web browser to view XML. The most obvious example is when developing XML Web Services, where XML documents are returned by an HTTP server. What better application is there for viewing a document of a particular URL (HTTP GET/POST)? A web browser. I develop web services almost exclusively and I use IE constantly for debugging the output from my application, not for a lack of other applications that can perform the task, but because it offers the simplest UI for querying a URL (favorites, shortcuts, history, etc...) and provides a great representation of the result. I see no reason why mozilla can't provide this: 1) type URL 2) see XML
> In fact, I would argue that using a web browser (!) to read arbitrary > XML is the really odd thing to do. Unfortunately, as MPT pointed out in comment 56, a certain market-leading web browser has spent at least the last couple of years teaching people that it's a perfectly NORMAL thing to do. The cat's out of the bag, and we aren't going to get it back in.
Guys. We're already convinced. We want to fix this. We have a spec (comment 37). You are preaching to the choir. Adding more and more comments to this bug isn't helping anyone. Thanks.
Why are the choices in the spec limited to "[ View document without style ] [ View source ]" Why not provide a list of stylesheets that the user can pick from? I think that would be more useful. The stylesheets (or symlinks) could be stored in some folder(s) that Mozilla knows about.
> Why are the choices in the spec limited to "[ View document without style ] [ > View source ]" Why not provide a list of stylesheets that the user can pick > from? I mean, in addition to "View document without style" and "view source", provide a list of stylesheets to choose from. Also, I would like to have a choice [View with DOM Inspector].
Sorry Ian, but like we discussed in our email conversation I don't think #37 adds anything to the current situation besides a shortcut to the current two options: a) display with the current stylesheet which I can't imagine anybody really using b) display like current View Source window does which is kinda nice but doesn't do a very good job of badly layouted XML (generated XML is mostly like that). Of course b) could be fixed by improving the way View Source works, but still I feel Mozilla could be given some great features here which would set it apart from the rest and even improve upon its rival. If we have to do it, like gavin says because people expect it let's make it even better!
IMHO the proposal of comment #37 could be rewritten as: [ View document in a completely useless way ] [ View source ] Why include an option that we already know nobody will want? Just to say "we are better than you"? I think Mozilla shoould display that XML file in the best way posible that shows it's structure, namespaces, with some nice [expand all] [collapse all] buttons and things like that. This is not a thing of "purism" as there's no standard which says in which way or with which stylesheet language an XML file with an unknown namespace and with no recognized PI's should be shown. Besides, I don't agree with "why would you expect to use an web browser to view an XML?" argument. I expect a web browser to do a decent job to view each content-type and file format which belongs to the "field" of web develpment/browsing. We expect a web browser to render an image/jpeg resource even if it's specified directly in the URL-bar (not referenced from an <img> tag). XML files are a new one of those formants which are just another component to build the web. Mozilla should do its best to show it in a useful way. [ sorry for the spam =) ]
There are some good suggestions here. Adding some possibilities, like: ____ | L\ This XML file does not appear to have any style information |<xml>| associated with it. | | |_____| (( Apply the pretty printer stylesheet to this document )) ( View source ) ( View document in DOM Inspector ) ( View document without style ) ...would be good. Of course, all the mutator event stuff listed in comment 37 should still apply, so that if the page is changed, it is correctly displayed. > I don't think #37 adds anything to the current situation besides a shortcut to > the current two options Indeed it doesn't, the idea was to not encourage people to send raw XML using unknown semantics over the web, while making sure that users did not assume that we don't support XML. > This is not a thing of "purism" as there's no standard which says in which way > or with which stylesheet language an XML file with an unknown namespace and > with no recognized PI's should be shown. Actually, CSS does.
>> I don't think #37 adds anything to the current situation besides a shortcut to >> the current two options > >Indeed it doesn't, the idea was to not encourage people to send raw XML using >unknown semantics over the web, while making sure that users did not assume that >we don't support XML. But who are we to decide what "XML using unknown semantics" is? There's lots of XML out there with clearly defined semantics that are just not supported by Mozilla. On the other hand there is the default behaviour (and still supported in proposal #37 and #111) which assumes that running any unsupported XML document through some kind of default Mozilla stylesheet is actually usefull (which it might be in 0.1% percent of the cases). And who are we to discourage people from sending XML documents over the web? >> This is not a thing of "purism" as there's no standard which says in which way >> or with which stylesheet language an XML file with an unknown namespace and >> with no recognized PI's should be shown. > >Actually, CSS does. Sorry, but I don't think that the CSS standard has anything to say about this. If I want to use XSLT to display my document I can. That would be something if the CSS standard would start telling me which stylesheet language to use! If we really need to have a selection I would just go for this: | L\ This XML file does not appear to have any style information |<xml>| associated with it. | | |_____| ( Apply the pretty printer stylesheet to this document ) ( View source ) ( View document in DOM Inspector ) But knowing that I can get to the View Source and DOM Inspector directly from the menu I would want an option to apply the pretty printer stylesheet without asking me. Which would make the entire page obsolete.
ok, here's an updated spec that takes recent feedback into account. If an XML document has no author stylesheet [1] no author script [2] and contains no elements or attributes in namespaces given in ua.css [3], then we would display the following in the content area: ____ | __ L\ This XML file does not appear to have any style |<xml>| information associated with it. | \/ | |_____| The document tree is shown below. You may also see the _original_unstyled_document_. <?xml version="1.0"?> <!DOCTYPE script SYSTEM "http://example.org/script.dtd"> - <script> - <episode> <title> The Witch </title> </episode> + <act> + <act> - <act id="a3"> + <scene> - <scene> <line character="Buffy"> Twisted. </line> </scene> </act> </fun> While that is shown, we have to listen for mutation events to switch out of the source view if any of the conditions listed above stop applying (e.g., a stylesheet PI is added to the document). If the user clicks the "original unstyled document" link then we'll just switch to our of source view straight away. Viewing the source of this tree should show the original document's source, not the source of the script that generated the view. Accessing the DOM of the frame should access the real document's DOM, not the source view's DOM. The DOM inspector should see the original document, not the source view either. We should avoid: * Breaking XHTML, MathML, XUL, and SVG. * Making it hard to add extensions to ua.css without rebuilding. * Killing dead the potential for DOM-based creation of styled XML documents. Notes: [1] There are various ways to add author stylesheets: style attributes in various namespaces, style elements in various namespaces, various different link elements in various namespaces, HTTP headers, presentational attributes on elements in certain namespaces, etc. I don't know how to test for this properly. For example, one way to add styles is to dynamically bind the root element to an XBL binding that links to a CSS stylesheet. We have to be able to cope with this case correctly. [2] Similarly, scripts can be added in many different ways. The XBL case is possible here too, but that's not the only way. Adding event handlers via the DOM is another possibility. Some elements and attributes in various namespaces add script to the document, etc. [3] The contents of the ua.css file can change depending on the build options and user modifications at run time. For example, MathML is sometimes supported and sometimes not, and all links (XLink included) are styled by html.css. So again we can't hardcode this. The best solution I can think of is suboptimal and is to check the CSSOM of the UA stylesheet and its kids when displaying the XML file in question. The ideal solution would be to crawl the DOM checking getComputedStyle to find out if anything was styled, but that's just stupid from a performance point of view.
Whiteboard: [Hixie-P4][ADT3] see comment 37 → [Hixie-P4][ADT3] see comment 113
Hixie: as far as performance worries... I'll be happy so long as it renders faster than I can complete these steps: 1. try to view xml in mozilla. 2. curse that mozilla still just spits a bunch of unuseable text at me. 3. click on view source and curse some more because the xml document isn't formatted pretty and the actually source is also unuseable. 4. start up IE. 5. notice that i need to apply the latest security fixes for IE. 6. reboot. 7. start up IE. 8. try to view xml in IE. 9. curse that I had to start up IE, but at least now I can read the xml output. So if you can make it faster than the above, I will be a happy camper.
I agree with comment #113 in thay displaying the tree view by default is a much better thiing to do! But, how would the other views open? a popup? same window? Why not using a tabbed view: ___________ ______________________ _____________________________ / Tree view \ / Inspect DOM structure \/ unstyled (useless =) ) view \ +--- --------------------------------------------------------------+ | -<library> | | +<book> | +<book> I think it would be nice because these are all alternate, equally valid, ways of displaying the document. And reusing the tab metaphor will make the use of this more instantly evident (no need of buttons with explanations). Anyway, it's just an idea..
The proposal in comment #113 is sufficient. But what I would really like to see is that everything that can be rendered (such as MathML or XHTML) is rendered, and everything that can not be rendered (such as plain namespace-less XML) is shown in the collapsable tree form. The rendered stuff can be shown within the tree. If this is too much work or just not possible, I am still quite happy with #113. I also like the tab idea. To avoid confusion though, these tabs should be clearly distinct from the regular tabs.
If there is any styled content in the document (e.g. any MathML or XHTML content) then it will be rendered in the styled view, not in the tree view. As for the tabs idea: The DOM Inspector view would be in the sidebar or in its own window, as now; the view source view would be in its own window, as now; that leaves merely the unstyled view and the IE-like tree view. Since the unstyled view is "useless" as you put it, we don't really need to go to the lengths of adding tabs or anything. IMHO.
I find comment #113 sufficient and am happy with that approach. The suggestion of a special tabbed view (with its own tabset distinct from the main tabs) in comment #116 is even better IMO and if the #113 approach is taken would be a splendid RFE for the next milestone. However, I vigorously oppose the idea of rendering "islands" of MathML, XHTML, SVG and so forth that are encountered inline within an otherwise raw tree-view of XML by default. I don't think it's genuinely useful for the XML-tree's audience, who are presumably looking at XML to dissect, spot-check or debug it. Rendering a MathML or SVG or RSS or whatever *document* in some useful way would be great in cases where a default transformation would be more useful to more people than the tree view would be. Just as NS4 rendered vCards as readable business cards, rendering a raw MathML document as math would be splendid, as would rendering RSS in, say, a tabular format with hyperlinks, or rendering a standards-based feed of TV listings in a pretty grid if a good stylesheet were available for the doctype. Obviously the latter isn't something that anyone's expected to tackle now, but I think we'd do well to start thinking of this as a natural path to take. As for rendering "islands" of MathML and SVG and XHTML and such that are contained in an otherwise tree-dumped raw XML file, maybe an apporpriate behavior to aim for down the road would be to mark such "renderable" islands in the tree view and allow them to be rendered when clicked via a context menu.
Steve: but Mozilla already renders MathML and SVG "islands" when encountered in XHTML, so how should it "know" about when to render and when to display as a tree? I think that would be difficult (and questionable maybe) to implement such an asymetrical system. Up to now we had been discussing that we want to see an XML tree when other ways of displaying were not defined. But there are several XML "dialects" that have a very clear function as a display/layout language, so personally I think that XHTML, MathML and SVG should be rendered whenever possible. What you want should really be handled by View Source (if a pretty printer option would be added to the View Source it would be usefull for any kind of XML).
Okay, FWIW (which isn't much) I drop my objection to rendering islands of MathML and such as long as it's pleasant and prints nicely :) Being able to get pretty-printed XML source and the raw view of source exactly as it came from the server are both equally important and serve different purposes. Hopefully both will be readily available at all times.
The problem with rendering these "recognized XML islands" is that when that kind of mixed XML is found, you can't be sure about the senantic result. E.g. an XSLT stylesheet would have XHTML embedded, but it would be a broken XHTML (e.g. intended attributes would have been supplied through <xsl:attribute>). One solution is to style the XML document only if either: a) there is a recognized styling PI. b) we know the namespace of the *root element*. So that Mozilla would style: <html:html><html:b>Hi mom</html:b></html:html>, but won't style <x:myTag><html:html><html:b>Hi mom</html:b></html:html></x:myTag>.
Quoting from the spec (comment 113): | If an XML document has no author stylesheet [1] no author script [2] and | contains no elements or attributes in namespaces given in ua.css [3], then we | would display the following in the content area: [...]
But what would that mean for a document like this: <foo xmlns="urn:MyFirstNamespace"> <bar> <math xmlns="http://www.w3.org/1998/Math/MathML"> ... </math> </bar> </foo> Would it try to render the MathML? But what would it do with the rest? The remark made by Nicolas in #122 does seem to have some merit doesn't it? (The fact that the root element would be the deciding factor.) This could mean that MathML inside XHTML would be rendered but that MathML inside the above example would depend on the stylesheet defined for <foo>. This would also mean that a stylesheet designed to show unknown or vanilla XML as a tree would not render XHTML, MathML or SVG but would show the XML in the tree instead. But you could make a tree-stylesheet that does support XHTML, MathML and/or SVG by including the respective stylesheets, couldn't you?
An example: Suppose you have a big XML file, representing a library. Lots of <book>s with their ISBNs, prices and descriptions. This kind of custom, pure data XML file is the one being targeted with this RFE. Some developer will load this file in Mozilla in order to inspect it, in order to check it for well-formedness. Now suppose somebody adds to the <description> tag some <html:strong>words </html:strong></description>. Then, the whole file would be rendered as a useless bunch of flowed text. It doesn't sound right to me.
We're not doing this so that users have a way of viewing all XML files. There already are plenty of XML viewers out there. We're only doing this so that users don't think we don't support XML. If the page has some styling, then that's fine, it'll look like we're styling it. Keying off the root namespace is dodgy, because it's possible that everything but the root namespace will have style information, and we wouldn't want to _not_ style that. For example: <composite xmlns="urn:net.example.namespace"> <html xmlns="..."> ... <script ...> ... something which uses the SVG image below ... </script> ... </html> <svg id="image1" style="display: none"> ... </svg> </composite>
(in reply to #126) does your example have well-defined semantics for styling (I doubt it), if not it should be rendered as a tree. otoh, just halfassedly supporting some feature to prove you're not **** isn't an excuse. if you're not going to support it, say so and apollogise, but if you are, do it, and do it well.
(in reply to #126) I have to agree with the remark made by spongman in #127 which is the same point I made in #124: there is no good way to render such a composite document so the best way would probably be to look to the root namespace and make your decisions based on that. This would not break any support for existing documents (like XHTML, MathML and SVG) while having the advantage that it is probably very easy to implement. Like I said in #124 you can always make a stylesheet for the root namespace and include the ones for XHTML and SVG if you want to make your example work (another plus for making it possible to define custom namespace-stylesheet mappings =). This would maybe also fix any difficult problems related to scripting code changing all kinds of things and making life generally more difficult: if rendering of XHTML, MathML and SVG is undefined for a document whose root namespace is unknown then the "rendering" of script (read: execution of script) might be undefined as well! This means that maybe you don't have to worry about scripting in unknown document formats? Just a thought.
All these things _are_ defined. There isn't anything undefined about the example document I posted above. Even the semantics are reasonably well defined, since there is only one element in the root namespace, and it doesn't represent anything except a way to hold many different documents together.
Alias: xmlview
#129: I think we should at least agree that Mozilla is a web browser, an (X) HTML viewer if you like. All other stuff is extra. So now you're telling us that the (X)HTML standard says that you can use <composite xmlns="urn:net.example.namespace"> tags to aggregate several XML documents and that a browser should be able to understand this? Can you tell me how it should be rendered? Where are the documents that tell me how browsers should handle and render composites? And even so you could easily add "urn:net.example.namespace" as one of the root elemements that Mozilla understands and make a stylesheet that includes the support for the other sub documents that you want rendered inside these composites.
Here's an example of the kind of document I mean: http://www.hixie.ch/tests/evil/xml/011.xml This document is currently rendered exactly per the CSS spec. The way we render that Web document (or any of the others in that directory) should not change when we fix this bug. Mozilla is indeed a Web browser, specifically it is a CSS renderer, with default rules for XHTML, MathML and XUL, and some special C++-level support for MathML, XBL, SVG and XHTML form controls.
ad. #131: Ok, I understand that this would mean that Mozilla _should_ actually do the "rendering islands" stuff (especially because that's what it does already) but that still leaves the fact that for Mozilla the <composite> document namespace is an unknown quantity which it does not know how to render. If we are ever going to get XML tree viewing in Mozilla implemented as suggested in this RFE this would then mean that the <composite> document above would render as a tree with 2 leaves: one showing HTML and the other showing an SVG image. If that is the way it's going to be fine although that is exactly the way IE renders it and XHTML embedded into other documents can look pretty horrible. PS: How would any scripting included in the embedded XHTML document be handled? I would think it was bound to fail because it will never expect that the XHTML it is in is not actually the root of the document.
> the <composite> document namespace is an unknown quantity which it does not > know how to render. No, it's not -- it's an element, and CSS specifies how to render *every* element -- not just those with rules that match them. (For example, '<composite>' has 'display:inline'.) That's how we know how to render it _now_. > If we are ever going to get XML tree viewing in Mozilla implemented as > suggested in this RFE this would then mean that the <composite> document above > would render as a tree with 2 leaves: one showing HTML and the other showing > an SVG image. Only if the implementation doesn't follow what I specified in comment 113. According to the spec I am proposing, we would render that as we do now, because it contains known namespaces. That is, im my opinion, correct. > How would any scripting included in the embedded XHTML document be handled? I > would think it was bound to fail because it will never expect that the XHTML > it is in is not actually the root of the document. Any script or style or known namespace should trigger the (un)styled view (i.e. not the tree view), so there would be no problem.
Jonas is working on this.
Assignee: nisheeth → sicking
Status: ASSIGNED → NEW
Keywords: nsbeta1-nsbeta1+
Target Milestone: mozilla1.0 → mozilla1.2alpha
This is just attaching what i've got so far so that we don't loose it. Most of this is making sure not *all* processing instructions implement nsIStyleSheetLinkingElement. This will also save us some memory/cycles when using PIs other then xml-stylesheet
Attached patch Prettyprinting stage 1 (obsolete) (deleted) — Splinter Review
This is a working implementation of prettyprinting stage one. This mostly includes detecting when prettyprinting should be done. For now it displays the prettyprinting by transforming the DOM so the preference defaults to off. I'd like to get this checked into the tree as a basis for the continued work
Attachment #34133 - Attachment is obsolete: true
Attachment #40345 - Attachment is obsolete: true
Attachment #94379 - Attachment is obsolete: true
Oh, and for now I have a .bmp as image. This should of course not be the case once we check in, but i don't have any other tools on my computer
After a quick look at the new PI code I could not see the following case being covered. <?something?> changed using dom to <?xml-stylesheet ...?>
I'm not entierly sure what you mean, but the current patch does not handle the DOM being accessed after prettyprinting is done, which is why it is turned off by default. It is however the basis for continued work
What the patch does: Most changes should be very strait forward, just unsets the mPrettyPrintXML boolean in a buch of places and then call a XSLT stylesheet if the bool is still on after reading the entire document. The two real changes I had to do was to make sure that not all ProcessingInstructions implement nsIStyleSheetLinkingElement (which was a good thing to do anyway IMHO) and to implement the HasRegisteredFactory function on the nsNameSpaceManager. To implement HasRegisteredFactory I made us use one and the same element factory for all non-registered namespaces instead of creating a new default one for every namespace.
Status: NEW → ASSIGNED
Erik: ooh, now i understand what you're asking. The target of processing instruction are readonly so you can't change a <?foo?> into a <?xml-stylesheet?>
Attached patch Prettyprinting stage 1 v2 (obsolete) (deleted) — Splinter Review
forgot to diff mozilla/dom
Attachment #95231 - Attachment is obsolete: true
>+NS_IMETHODIMP >+NameSpaceManagerImpl::HasRegisteredFactory(PRInt32 aNameSpaceID, >+ PRBool* aHasFactory) >+{ >+ nsCOMPtr<nsIElementFactory> ef; >+ GetElementFactory(aNameSpaceID, getter_AddRefs(ef)); >+ *aHasFactory = ef != gDefaultElementFactory; > return NS_OK; > } You might want to check for gDefaultElementFactory != nsnull. Probably very unlikely, so up to you. >Index: content/xml/document/resources/XMLPrettyPrint.css >=================================================================== >RCS file: content/xml/document/resources/XMLPrettyPrint.css >diff -N content/xml/document/resources/XMLPrettyPrint.css >--- /dev/null 1 Jan 1970 00:00:00 -0000 >+++ content/xml/document/resources/XMLPrettyPrint.css 22 Aug 2002 09:40:57 -0000 >@@ -0,0 +1,82 @@ Need a license? >Index: content/xml/document/resources/XMLPrettyPrint.xsl >=================================================================== >RCS file: content/xml/document/resources/XMLPrettyPrint.xsl >diff -N content/xml/document/resources/XMLPrettyPrint.xsl >--- /dev/null 1 Jan 1970 00:00:00 -0000 >+++ content/xml/document/resources/XMLPrettyPrint.xsl 22 Aug 2002 09:40:57 -0000 >@@ -0,0 +1,140 @@ >+<?xml version="1.0"?> >+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> >+ >+ <xsl:template match="/"> >+ <html> Do we want this to be XHTML? If so, set the namespace, if not you should set <xsl:output method="html" /> >+PRBool >+nsXMLContentSink::ShouldPrettyPrint() >+{ >+ if (!mPrettyPrintXML || (mPrettyPrintHasFactoredElements && >+ !mPrettyPrintHasSpecialRoot)) { >+ mPrettyPrintXML = PR_FALSE; >+ >+ return PR_FALSE; >+ } >+ >+ // Check for correct load-command or if we're in a display:none iframe >+ nsString command; >+ mParser->GetCommand(command); >+ if (!command.Equals(NS_LITERAL_STRING("view")) || >+ !mDocument->GetNumberOfShells()) { >+ mPrettyPrintXML = PR_FALSE; >+ >+ return PR_FALSE; >+ } >+ >+ // check if we're in an invisible iframe >+ nsCOMPtr<nsIScriptGlobalObject> sgo; >+ mDocument->GetScriptGlobalObject(getter_AddRefs(sgo)); >+ nsCOMPtr<nsIDOMWindowInternal> internalWin = do_QueryInterface(sgo); >+ nsCOMPtr<nsIDOMElement> frameElem; >+ if (internalWin) { >+ internalWin->GetFrameElement(getter_AddRefs(frameElem)); >+ } >+ >+ if (frameElem) { >+ nsCOMPtr<nsIDOMCSSStyleDeclaration> computedStyle; >+ nsCOMPtr<nsIDOMDocument> frameOwnerDoc; >+ frameElem->GetOwnerDocument(getter_AddRefs(frameOwnerDoc)); >+ nsCOMPtr<nsIDOMDocumentView> docView = do_QueryInterface(frameOwnerDoc); >+ if (docView) { >+ nsCOMPtr<nsIDOMAbstractView> defaultView; >+ docView->GetDefaultView(getter_AddRefs(defaultView)); >+ nsCOMPtr<nsIDOMViewCSS> defaultCSSView = do_QueryInterface(defaultView); >+ if (defaultCSSView) { >+ defaultCSSView->GetComputedStyle(frameElem, NS_LITERAL_STRING(""), >+ getter_AddRefs(computedStyle)); >+ } >+ } >+ >+ if (computedStyle) { >+ nsAutoString visibility; >+ computedStyle->GetPropertyValue(NS_LITERAL_STRING("visibility"), visibility); >+ if (!visibility.Equals(NS_LITERAL_STRING("visible"))) { >+ mPrettyPrintXML = PR_FALSE; >+ >+ return PR_FALSE; >+ } >+ } >+ } >+ >+ // check the pref >+ nsCOMPtr<nsIPref> prefs = do_GetService(NS_PREF_CONTRACTID); >+ if (prefs) { >+ PRBool pref = PR_FALSE; >+ prefs->GetBoolPref("layout.xml.prettyprint", &pref); >+ if (!pref) { >+ mPrettyPrintXML = PR_FALSE; >+ >+ return PR_FALSE; >+ } >+ } Should we check the pref first before doing all these other checks? >+ >+ return PR_TRUE; >+} >+ >+ > NS_IMETHODIMP > nsXMLContentSink::DidBuildModel(PRInt32 aQualityLevel) > { >+ nsresult rv = NS_OK; >+ > // XXX this is silly; who cares? > PRInt32 i, ns = mDocument->GetNumberOfShells(); > for (i = 0; i < ns; i++) { >@@ -359,7 +445,16 @@ > > mDocument->SetRootContent(mDocElement); > >- nsresult rv = NS_OK; >+ // Check if we want to prettyprint >+ if (ShouldPrettyPrint()) { >+ NS_ASSERTION(!mXSLTransformMediator, "Prettyprinting an XSLT styled document"); >+ >+ nsCOMPtr<nsIURI> uri; >+ rv = NS_NewURI(getter_AddRefs(uri), NS_LITERAL_STRING("resource:///res/xml/XMLPrettyPrint.xsl")); Make this rv = NS_NewURI(getter_AddRefs(uri), NS_LITERAL_STRING("resource:///res/xml/XMLPrettyPrint.xsl")); >+ // If we care, find out if we just used a special factory. >+ if (!mPrettyPrintHasFactoredElements && !mPrettyPrintHasSpecialRoot && >+ mPrettyPrintXML) { >+ >+ PRBool hasFactory = PR_TRUE; >+ gNameSpaceManager->HasRegisteredFactory(aNameSpaceID, &hasFactory); >+ >+ if (hasFactory) { >+ mPrettyPrintHasFactoredElements = PR_TRUE; >+ } >+ } Can't you just do if (!mPrettyPrintHasFactoredElements && !mPrettyPrintHasSpecialRoot && mPrettyPrintXML) { gNameSpaceManager->HasRegisteredFactory(aNameSpaceID, &mPrettyPrintHasFactoredElements); } >@@ -1647,6 +1754,17 @@ > if (NS_OK == result) { > // If this is the document element > if (!mDocElement) { >+ >+ // check for root elements that needs special handling for >+ // prettyprinting >+ if ((nameSpaceID == kNameSpaceID_XBL && >+ tagAtom == nsXBLAtoms::bindings) || >+ (nameSpaceID == kNameSpaceID_XSLT && >+ (tagAtom == nsLayoutAtoms::stylesheet || >+ tagAtom == nsLayoutAtoms::transform))) { >+ mPrettyPrintHasSpecialRoot = PR_TRUE; >+ } >+ Not sure if we should think about making this extensible? >Index: build/mac/build_scripts/MozillaBuildList.pm >=================================================================== >RCS file: /cvsroot/mozilla/build/mac/build_scripts/MozillaBuildList.pm,v >retrieving revision 1.228 >diff -u -r1.228 MozillaBuildList.pm >--- build/mac/build_scripts/MozillaBuildList.pm 13 Aug 2002 11:02:29 -0000 1.228 >+++ build/mac/build_scripts/MozillaBuildList.pm 22 Aug 2002 09:40:58 -0000 >@@ -238,6 +238,9 @@ > my($html_dir) = "$resource_dir" . "html:"; > InstallResources(":mozilla:layout:html:base:src:MANIFEST_RES", "$html_dir"); > >+ my($xml_dir) = "$resource_dir" . "xml:"; >+ InstallResources(":mozilla:content:xml:document:resources:MANIFEST_RES", "$xml_dir"); Align "$xml_dir" with "$htmldir"
Attached patch Prettyprinting stage 1 v3 (obsolete) (deleted) — Splinter Review
Couldn't fully change the HasRegisteredFactory-call since mPrettyPrintHasFactoredElements isn't a PRBool, made it somewhat neater though. didn't move the pref-code up since once this bug is fully fixed we will default to the pref on and we should on most systems never fail the pref-check. So better do it after checks that might actually fail. Kept the output-method to html to avoid running into bug 158457
Attachment #96290 - Attachment is obsolete: true
Comment on attachment 97166 [details] [diff] [review] Prettyprinting stage 1 v3 +class nsXMLStylesheetPI : public nsXMLProcessingInstruction, + public nsStyleLinkElement +{ +public: + nsXMLStylesheetPI(const nsAString& aData); + ~nsXMLStylesheetPI(); This dtor must be virtual. - In nsXMLContentSink::ShouldPrettyPrint(): + // Check for correct load-command or if we're in a display:none iframe + nsString command; + mParser->GetCommand(command); + if (!command.Equals(NS_LITERAL_STRING("view")) || + !mDocument->GetNumberOfShells()) { ... |command| should be an nsAutoString here to avoid an unnecessary string copy. ... + if (internalWin) { + internalWin->GetFrameElement(getter_AddRefs(frameElem)); + } 2-space indentation here please :-) sr=jst
Attachment #97166 - Flags: superreview+
Does this patch pass (i.e. act exactly the same as on the trunk now) all the regression tests at http://www.hixie.ch/tests/evil/xml/ ?
Yes, since it's disabled by default :-) Seriously, for now it won't which is why it's disabled by default. Once stage two is done it should pass all tests and it'll be enabled by default.
Okie dokie.
Comment on attachment 97166 [details] [diff] [review] Prettyprinting stage 1 v3 this one has landed
Attachment #97166 - Attachment is obsolete: true
Comment#149 says it's landed. Does that mean it will be start appearing in nightly trunk builds, or does one need to build mozilla themself in order to see it? P.S. I'm on Mac OS X.1
sorry, i forgot to write a real comment. Stage one of this has landed. That means that it is working in the nightlies but it is disabled by default since it breaks some legal (although rare) ways of loading XML. Note that this gets us on par with IE. To enable the feature add the following line to prefs.js: user_pref("layout.xml.prettyprint", true);
And I guess this means distributors will flip the switch, with all that that entails? :-( Any ETA on the second part? Please say soon...
soon :) This should be fully done by at least moz1.2
Target Milestone: mozilla1.2alpha → mozilla1.2beta
That's encouraging. Now come on, chop chop. ;-)
So how do I see the patch in action? I added the pref (in today's nightly) and went to the URL mentioned <http://p.moreover.com/cgi-local/page?index_xml+xml> but I still didn't see a pretty print layout. What am I doing wrong?
Tried this out and it worked fine. Some urls that you might find handy for testing: http://www.w3.org/Math/characters/entities.xsl http://www.w3.org/Math/characters/characters.xsl (long...) http://www.w3.org/Math/characters/unicode.xml (long...)
BTW, it might be best to style comments with "white-space: pre", as IE does.
Blocks: majorbugs
Doesn't work for me in the latest build- the XSL/CSS/BMP weren't installed. I dumped my own XSL file in there (based on the attachment in this bug) and it worked fine with the pref on.
*** Bug 167558 has been marked as a duplicate of this bug. ***
You should not pretty print if there is an XML parsing error.
The resource files need to be added to the packaging lists for installers. This is the reason why people who download nightlies can't get this to work at the moment.
ugh, i just noticed havn't been getting bugmail for the last few days (thought it just was a slow weekend). This only works for people building on their own. I'm on it.
Comment on attachment 98666 [details] [diff] [review] packager changes. Doesn't include embedding yet jst says sr=jst
Attachment #98666 - Flags: superreview+
It would be nice if the header had a couple of buttons, "view source" and "inspect DOM" (the latter is a bit redundant but it would help people discover the DOM inspector, which IMHO is the coolest thing ever)
Suggestion: The color used for .elemname in XMLPrettyPrint.css is "red" which is fairly bright and distracting. "maroon" is easier on the eyes (good reason) and is appears closer to IE (soso reason). IE also displays the XML prologue (<?XML version...)... The .markup section in the css doesn't have a semi after color: blue This change is great! I can now use Mozilla for the xml development I do. Thanks.
I notice that namespace nodes don't appear. E.g., if I look at an XSL stylesheet, the first node appears like this: <xsl:stylesheet version="1.0"> The original document of course looks like: <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> BTW IE displays the namespaces correctly.
It doesn't seem to work on: http://www.hixie.ch/tests/evil/xml/002b.xml (Ignore for now that that file is a part of a test in which the file _shouldn't_ trigger this XML view -- the point is that on its own, the file _should_ get the interactive XML view and it isn't for some reason.)
Thanks for getting this great feature into 1.2a! There might be some issues with the colors though. The attribute names seem to be displayed using a somewhat "pink" color, and that may be a little **** the eyes. Additionally, if Mozilla's used for presentations with a projector (such as what people do with Powerpoint), the colors may not be seen too well from "the back of the room." I think we need colors that contrast better with the white background. Ideally, the user should be able to set the colors from the Preferences dialog. I don't know much about the internals about how this is currently implemented. Is this possible?
Attached patch stage 2 (obsolete) (deleted) — Splinter Review
This implements stage two, prettyprinting using a binding. The only thing missing until we're fully done is dropping the binding when needed. I've moved the .xml/.xsl/.css files to xpfe/components which is nicer since they'll get packed and it means that no changes are needed to packaging (the patch backs out attachment 98666 [details] [diff] [review])
Attachment #31658 - Attachment is obsolete: true
Attachment #36108 - Attachment is obsolete: true
Attachment #36257 - Attachment is obsolete: true
Attachment #98666 - Attachment is obsolete: true
+ * Version: NPL 1.1/GPL 2.0/LGPL 2.1 New NPL code isn't being allowed into the tree, last I checked. As this affects XBL loading, does it affect Txul or Ts? I take it this doesn't yet handle the many cases described in comment 113?
Comment on attachment 101676 [details] [diff] [review] stage 2 I don't like the move. This should work in the embedding case, and if you move them to xpfe they won't get into embedding applications, I think. Also they should logically be "close" to the source that uses them. Finally packaging them means it becomes very difficult for the users to change the stylesheets.
Attachment #101676 - Attachment is obsolete: true
Attached patch prettyprint stage 2 (obsolete) (deleted) — Splinter Review
ok, this is the same as the previous one except that i've move the xbl/xslt/css files back to content/xml/document/resources The syncloader is pretty much copied from transformiix, and then rearranged to be able to load local documents without the overhead of createing a new eventqueue. I've also created a service out of it by wrapping a class around the nsSyncLoader class.
Comment on attachment 102254 [details] [diff] [review] prettyprint stage 2 >Index: content/base/public/nsISyncLoadService.idl >+interface nsISyncLoadService : nsISupports the name for this interface is too generic. please pick something more specific to nsIDOMDocument loading. >+{ >+ /** >+ * Synchronously load the document specified in documentURI. >+ * >+ * @param documentURI The URI of the document to load. >+ * @param aLoader The document that is trying to load this document. >+ * >+ * @returns The document loaded from the URI. >+ */ >+ nsIDOMDocument loadDocument(in nsIURI documentURI, in nsIURI loaderURI, >+ in nsILoadGroup loadGroup); >+ >+ nsIDOMDocument loadLocalDocument(in nsIURI documentURI, >+ in nsIURI loaderURI, >+ in nsILoadGroup loadGroup); >+ >+ nsIDOMDocument loadLocalXBLDocument(in nsIURI uri, >+ in nsILoadGroup loadGroup); >+}; please document all of these methods completely. use "a" prefixes on all variable names. also if there are any special exception codes, you should be sure to document those as well. also, it might be good to make the input be a channel, since that would give consumers more flexibility. i.e., suppose a consumer wanted to add a special HTTP header or suppose they wanted to issue a POST request. this interface would not allow for such options. also, i think you should add a very very large warning to the top of this interface definition. something like this: /************************************************************************* * * * **** NOTICE **** * * * * nsISyncLoadService defines synchronous methods to download * * data from the network. Any delays from the server will * * appear as a hang in the mozilla UI. Therefore, this interface * * should be avoided as much as possible. * * * * Don't make me come over there!! * * * * * ************************************************************************/ >+ >+%{ C++ >+#define NS_SYNCLOADSERVICE_CID \ >+ { /* 0e4e7d00-f71a-439f-9178-1a71ff11b55f */ \ >+ 0x0e4e7d00, 0xf71a, 0x439f, \ >+ {0x91, 0x78, 0x1a, 0x71, 0xff, 0x11, 0xb5, 0x5f} } >+#define NS_SYNCLOADSERVICE_CONTRACTID \ >+"@mozilla.org/content/syncload-service;1" >+%} CIDs and ContractIDs do not belong in a IDL file. The rule is that each module file should define a header file to contain all of its component/service CIDs and ContractIDs. see for example nsNetCID.h or nsXPCOMCID.h. please follow this convention. if not now, then in the future at least. >Index: content/base/src/nsSyncLoadService.cpp >+// This is ugly, but nsXBLContentSink.h isn't exported >+extern >+nsresult >+NS_NewXBLContentSink(nsIXMLContentSink** aResult, >+ nsIDocument* aDoc, >+ nsIURI* aURL, >+ nsIWebShell* aWebShell); how about a comment in nsXBLContentSink.h mentioning this dependency. future developers will thank you ;-) >+nsSyncLoader::PushSyncStream(nsIStreamListener* aListener) ... >+ aListener->OnStartRequest(mChannel, nsnull); this recursive callback is ok/desired, right? >+ rv = aListener->OnDataAvailable(mChannel, nsnull, bufferedStream, >+ sourceOffset, readCount); >+ if (NS_FAILED(rv)) { >+ break; ... >+ } >+ aListener->OnStopRequest(mChannel, nsnull, NS_OK); why not "OnStopRequest(mChannel, nsnull, rv);" ??? >+ // Set up buffering stream >+ nsCOMPtr<nsIInputStream> bufferedStream; >+ rv = NS_NewBufferedInputStream(getter_AddRefs(bufferedStream), >+ in, 4096); >+ NS_ENSURE_SUCCESS(rv, rv); >+ >+ // Load >+ listener->OnStartRequest(channel, nsnull); >+ PRUint32 sourceOffset = 0; >+ while (1) { >+ PRUint32 readCount = 0; >+ rv = bufferedStream->Available(&readCount); >+ if (NS_FAILED(rv) || !readCount) { >+ break; >+ } >+ >+ rv = listener->OnDataAvailable(channel, nsnull, bufferedStream, >+ sourceOffset, readCount); >+ if (NS_FAILED(rv)) { >+ break; >+ } >+ >+ sourceOffset += readCount; >+ } >+ listener->OnStopRequest(channel, nsnull, NS_OK); looks like code duplication here. how about pulling this out into a static helper function at least? >+nsresult NS_NewSyncLoadService(nsISyncLoadService**); does this belong in a header file somewhere? >Index: content/xbl/src/nsXBLService.cpp >+ nsCOMPtr<nsIDOMDocument> domDoc; >+ nsCOMPtr<nsISyncLoadService> loader = >+ do_GetService("@mozilla.org/content/syncload-service;1"); >+ nsresult rv = loader->LoadLocalDocument(aURI, nsnull, nsnull, getter_AddRefs(domDoc)); >+ if (rv == NS_ERROR_FILE_NOT_FOUND) { >+ return NS_OK; would XBL benefit from caching a reference to the sync loader service? >Index: content/xml/document/src/nsXMLContentSink.cpp >+ rv = NS_NewURI(getter_AddRefs(xslUri), >+ NS_LITERAL_STRING("chrome://communicator/content/xml/xmlPrettyPrint.xsl")); use NS_LITERAL_CSTRING here instead to avoid a runtime conversion.
Comment on attachment 102254 [details] [diff] [review] prettyprint stage 2 In nsSyncLoader::LoadDocument you are losing the rv from StartDocumentLoad(). NS_ENSURE_SUCCESS(rv, rv) Would be nice to have a Load() method that took in the target document and content sink (in addition to the channel, as Darin proposed). That should handle the shared code for the XBL implementation. This is just criminal, PLEASE make a topic :) + return binding->Observe(resultDocument, "", NS_LITERAL_STRING("").get()); r=jkeiser with that though I'd like to see the SyncLoad changes if you make them (given the time constraints I personally am OK with it if you do the SyncLoad change in a separate patch but do it soon)
Attached patch prettyprint stage 2 v2 (obsolete) (deleted) — Splinter Review
addresses jkeisers and darins comments. I went with darins suggestion for how to reuse the code that pushes a stream into a listener since IMHO that gave cleanest code and resulted in pretty much no codeduplication
Attachment #102254 - Attachment is obsolete: true
Comment on attachment 102307 [details] [diff] [review] prettyprint stage 2 v2 sr=darin
Attachment #102307 - Flags: superreview+
Comment on attachment 102307 [details] [diff] [review] prettyprint stage 2 v2 r=jkeiser
Attachment #102307 - Flags: review+
Comment on attachment 102307 [details] [diff] [review] prettyprint stage 2 v2 checked in
Attachment #102307 - Attachment is obsolete: true
Comment on attachment 102307 [details] [diff] [review] prettyprint stage 2 v2 >+ if (par.parentNode.className == 'expander-closed') { >+ par.parentNode.className = ''; >+ event.originalTarget.src = 'chrome://global/skin/tree/twisty-open.gif'; >+ } >+ else { >+ par.parentNode.className = 'expander-closed'; >+ event.originalTarget.src = 'chrome://global/skin/tree/twisty-clsd.gif'; >+ } >+ <td class="expander"><img src="chrome://global/skin/tree/twisty-open.gif"/><div class="spacer"/></td> So, third-party themes will have to specify these exact images? Also, where's the white-space: pre; for CDATA like rbs requested?
CDATA has no different meaning from textnodes so I won't style them any differently. Good point about making the twisties skinnable though, i'll look into what needs to be done for that
so what's left to do here? only do the themability and the all.js change, or is there more?
before everybody yells that no all.js change is needed i'm going to say that no all.js change will occur, i'll just default the code the other way around (or remove the pref entierly) what is left is that i need to drop the binding if the document is mutated
> > Also, where's the white-space: pre; for CDATA like rbs requested? > > CDATA has no different meaning from textnodes so I won't style them any > differently. neil had a noble intention, but he misquoted me. What I said was to style comments as pre. Visit http://www.w3.org/Math/characters/entities.xsl with IE and Mozilla to see the difference. In Mozilla, comments (top of the page) are wrapped in a messy way, whereas they appear neat and tidy in IE.
Personally I think I like how they look in Mozilla better. I like the green sans-serif of mozilla better than the grey monospace of ie. They are also collapesable in mozilla. :-) Although overall the fonts used in mozilla are a bit larger in size than that used in IE. I probably would go for the bit smaller font size.
People often describe tabular data, diagrams, etc, using comments. It seems to me that retaining comments as-is is a safe bet.
on comments i agree, i'll make those sustain whitespace in the next checkin
And before everybody goes wild about how the new colorscheme is ugly. It is now using the same colors as viewsource, for the sake of consitency. Bug 173648 is filed for making viewsource (and thus xml-prettyprint) use nicer colors
> CDATA has no different meaning from textnodes In the DOM, CDATA is not the same as a text node. Therefore, unless XSLT sucks mightily, it should be trivial to do this just like IE.
Standard XSLT doesn't distinguish between CDATA and regular text nodes. It treats them all as "text".
OK, but script in XBL documents looks silly :-) Sorry for the misquote.
Ian: XSLT transforms XML documents which does not distinguish between text nodes and CDATA, it would be illegal to the standard to do so. That the current XSLT transformation engine uses DOM to do its work probably does not mean that you can go around breaking that rule. Which takes me to the remark I wanted to make (and the implementers of this patch will probably hate me for this): I have the feeling Microsoft doesn't use XSLT (anymore?) to do the transformation. Why? Two reasons: a) Output seems to be streamed. I can open a really large XML document (100+MB) and I'll get instant output, growing by the second. b) When the XML document is invalid the output will be generated up to the position of the error and the error message will appear below that. Point b) I can live without although it's cool to have but point a) is a bit more problematic. I guess Microsoft implements this using SAX and custom visualisation code? Or is the current version of their transformer capable of streaming its output while still busy transforming? Anyway, what do you all think about this?
> on comments i agree, i'll make those sustain whitespace in the next checkin Would also be nice to have a color on class="markup" so that "<", "</", etc, are colored just as you had before (doesn't have to be blue -- it might be refined in bug 173648 as well).
Looks very neat so far. But here's some fun probably unreproducable bugs for ya: 1) I clicked the w3c URL. Worked fine. Then viewed the first attachment. Saw a tree view for it, but no colors Load the w3c URL again. Also no colors. So I restart mozilla. 2) Load w3c URL. fine, with colors. View first attachment. Now it's not getting tree view! Just shows: raboof hiihaa, and the raboof is not pastable When I reload, it randomly gives me eaither tree view or "styled" (but without any styles) view Linux 2002101108.
Summary: [RFE] Better Default layout for "vanilla" XML documents → Better Default layout for "vanilla" XML documents
Attached patch remove transformiix.xpt from packager (obsolete) (deleted) — Splinter Review
since the syncloader was the only thing in transformiix.xpt there is no longer a transformiix.xpt. This patch removes it from xpinstall, embedding apparently never shipped with this.
Attachment #103122 - Flags: review+
Comment on attachment 103122 [details] [diff] [review] remove transformiix.xpt from packager r/sr=darin
Comment on attachment 103122 [details] [diff] [review] remove transformiix.xpt from packager sr=bzbarsky
Attachment #103122 - Flags: superreview+
Attached patch stage three! (obsolete) (deleted) — Splinter Review
Yes folks, this is the final, last and ultimate stage of prettyprinting in mozilla. This adds code to observe the document and then drops the binding if any (non-anonymous) content is added. The reason that it doesn't trigger on anonymous content is so that collapsing/expanding the treeview won't drop the binding. Much of this patch is refactoring the prettyprint code out to it's own class. The entire nsXMLPrettyPrinter::PrettyPrint function is just moving code from nsXMLContentSink::MaybePrettyPrint. Only exception is the last few lines below the comment // Observe the document so we know when to switch to "normal" view There is one uglyness with this patch. In order to keep the observer alive it manually addrefs itself. This since the document doesn't keep strong references to it's observers. Suggestions wellcome on a nicer way to do this. The only thing that this patch doesn't do is to fix the fact that the urls to the images are hardcoded. I'm looking in to how to fix this, but that shouldn't affect any of the coding so feel free to start reviewing.
I can't try it myself yet, as my build is still spinning, but last time I tried it formatting was lost when changed character coding through View menu. Is still addressed already?
Comment on attachment 103122 [details] [diff] [review] remove transformiix.xpt from packager a=rjesup@wgate.com
Attachment #103122 - Flags: approval+
r=hyatt on the XBL changes.
Comment on attachment 103122 [details] [diff] [review] remove transformiix.xpt from packager checked in
Attached patch stage three! v1.1 (obsolete) (deleted) — Splinter Review
fixes review comments from hyatt and fixes a crasher
Attachment #103150 - Attachment is obsolete: true
Comment on attachment 103250 [details] [diff] [review] stage three! v1.1 In MaybePrettyPrint (not shown here), comment "// Check for correct load-command or if we're in a display:none iframe" is no longer accurate--no check for display:none iframe yet. In ~nsXMLPrettyPrinter, you shouldn't have to do the document remove at all, but if you do RemoveObserver(), you should RemoveBinding to be consistent. r=jkeiser
Attachment #103250 - Flags: review+
Attached patch stage three! v1.2 (obsolete) (deleted) — Splinter Review
fixes comments from jkeiser and Hixie
Attachment #103250 - Attachment is obsolete: true
Comment on attachment 103264 [details] [diff] [review] stage three! v1.2 r=jkeiser
Attachment #103264 - Flags: review+
Attached patch stage three! v2 (obsolete) (deleted) — Splinter Review
eek, i forgot that i had changes in layout as well. This is the entire patch
Attachment #103264 - Attachment is obsolete: true
Attached patch stage three! v2.1 (obsolete) (deleted) — Splinter Review
* adds some comments requested by jkeiser * adds an explicit call to binding->MarkForDeath() * adds an extra check so that we don't prettyprint parseerror-pages * renames RecreateFramesForNode to RecreateFramesFor * switches to use good interfaces instead of nsIPref * moves the check for display:none iframes to the nsXMLPrettyPrinter object phew, that's all
Attachment #103273 - Attachment is obsolete: true
Comment on attachment 103404 [details] [diff] [review] stage three! v2.1 r=jkeiser
Attachment #103404 - Flags: review+
Attached patch switch back to +/- (obsolete) (deleted) — Splinter Review
I had a discussion with hewitt about how to do the twisties in a good way. Currently there is no place where I can put the css-rules needed for this so we decided to drop the twisities in favour of +/-. Eventually we should have skinfiles for skinning things in the content-area and when that happens it should be possible to get twisties again.
Comment on attachment 103430 [details] [diff] [review] switch back to +/- r/sr=bzbarsky
Attachment #103430 - Flags: superreview+
Attachment #103404 - Flags: superreview+
Attached patch stage three! v2.2 (deleted) — Splinter Review
fixes review comments by rpotts
Attachment #103404 - Attachment is obsolete: true
Attachment #103430 - Attachment is obsolete: true
Comment on attachment 103495 [details] [diff] [review] stage three! v2.2 moving forward reviews
Attachment #103495 - Flags: superreview+
Attachment #103495 - Flags: review+
Comment on attachment 103495 [details] [diff] [review] stage three! v2.2 a=asa for checkin to 1.2 (on behalf of drivers).
Attachment #103495 - Flags: approval+
this bug is FIXED!! Thanks to everybody that reviewed, came with constructive ideas and made testsuits (Ian, you rock!). Also want to thank netscape for paying me to implement this :) Bug 175946 has been filed for the missing parts of the prettyprint tree.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
This doesn't seem to be working for me in Mac OS X build 2002102208. I've visited http://www.w3.org/Math/characters/entities.xsl and other urls in the bug as well as other xml pages that I know that used to work in the last nightly build I tried them with before. I have user_pref("layout.xml.prettyprint", true); in my user.js file.
There is no platform specific code in there so i see no reason why Mac OS X should be broken. Has anybody else tried this on OS X? Did it work?
I know it was working back on Oct 9th when I made comment #185, although I don't remember what build I was using then. But it doesn't work now. The nightly snapshots only go back to the 15th. I tried that build and I didn't seem to work then either. :-(
Attached file RTL XML testcase (deleted) —
I tested with this XML document containing right-to-left text, in both content and markup. In some elements the < and > participate in reordering, e.g. <<EMAN Also, </NAME> is displayed as <EMAN/> which is confusing.
Reloading http://www.hixie.ch/tests/evil/xml/001b.xml over and over again causes it to sometimes be pretty printed and sometimes not. Also, there appears to be a race condition in this test: http://www.hixie.ch/tests/evil/xml/001.xml Sometimes, the page shows up blank, sometimes it shows up with the pretty printer, and sometimes it shows up with the green background and text "Hello World!". It should always do the latter. Note: enable popups before visiting this test.
>Reloading http://www.hixie.ch/tests/evil/xml/001b.xml over and over again causes >it to sometimes be pretty printed and sometimes not. I'm seeing exactly the same as this with a local XML file (although it seems to heppen with any XML doc). There seems to be no pattern in whether it is pretty printed or not. From my non-exhaustive tests, it takes between 1 and 8 reloads to change mode if in non-pretty mode and between 1 and 4 if in pretty mode (dunno if that helps at all). Gecko/20021125
Status: RESOLVED → VERIFIED
I can confirm that Prettyprinting does NOT work in Mac OS X with 1.2 Final.
The final 1.2 release doesn't work on my Mandrake 9.0 Linux either. I added the following line in the prefs.js file: user_pref("layout.xml.prettyprint", true); but it still didn't show any content of the xml files on the local disk or from the internet. Moreover, as soon as the browser is closed, the line mentioned above gets deleted automatically from prefs.js
Re: Comment #225: Edit user.js, not prefs.js. Then, after editing user.js, restart Mozilla.
Does not work on 1.2 Final on Mac OS X. ( user_pref("layout.xml.prettyprint", true); in user.js)
Maybe all the breakage is related to 182031?
Does not work under 1.2.1 on Windows 2000 either. Had worked reliably in 1.2a and 1.2b. Did the final release break something?
Where is user.js located? I don't see it anywhere under my .mozilla directory. Do I need to create it manually and just include only the following line in it: user_pref("layout.xml.prettyprint", true); ? Thanks.
chunnuan, that is not necessary. it should work by default.
anyone having problems getting this to work, please head over to bug 182031. Please ready _all_ of that bug since it contains important updates.
Thanks, Chris. It does work by default. However it doesn't seem to work consistently. Sometimes I have to reload the file more than once to see the prettyprinting, which may be related to the bug pointed out by Jonas in the previous note. One more thing I noticed is that the print preview shows only one page for the whole xml file, no matter how large it is, and the printer also prints only one page. Is this a known bug?
bug 185873 filed on the printing issue. chunnuan: PLEASE head over to bug 182031. And read ALL of that bug before posting.
Blocks: 188130
No longer blocks: majorbugs
Could anyone take a look at bug #263049, is a big prettyprint issue with 10 years ...
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: