You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of all, xmlview is a great plugin with lots of features, but sometimes it does too much.
In the old days before the Firefox developers started removing useful features, there was a hierarchy where recognized data types like RSS and SVG would be rendered by spesial functions, and if no such function was found, the generix XML viewer kicked in. Now, with both of those having been removed from Firefox and left to plugin developers, there is no longer a hierarchy and race conditions will sometimes occur with unwanted consequences. RSS is an example of this.
At the moment I am using rsspreview to show RSS feeds. When trying to see the MET Norway weather alerts the RSS is briefly shown for half a second, then xmlview kicks in and shows an XML tree structure. Clearly this is not desirable. Nor, from what I can read from closed issues, is it expected behaviour. In issue #56 it looks like default behaviour in Chrome was to render as text and optionally as XML in the preferences. In issue #70 there is a complaint that xmlview does not render RSS as XML in Firefox. So it seems that the behaviour has changed since Aug 2019.
Twenty years ago, some people had the vision that all text on the web would be delivered as CSS styled XML. Clearly did not happen, but it is still technically possible. Also, there are a lot of XML based formats intended directly for end-user viewing, like SVG, RSS/Atom, MathML, DASH, iCalendar XML and so on. Clearly, showing the XML tree structure should be a last resort when no other application is available, just like "view source" in HTML.
I'm not sure what the official policy is on this, seeing as there seems to be a conflict between earlier statements and current behaviour. One possible solution could be to "whitelist" various content types in the preferences, although this would not solve all cases since e.g. some sites serve RSS as "text/xml" or "application/xml" instead of "application/rss+xml". Another could be to make it a feature that had to be invoked explicitly via the menu; this would enable it to be used with HTML too (duplicating the Web Developer feature in Firefox). Regardsless, some kind of workaround for this problem is urgently needed.
The text was updated successfully, but these errors were encountered:
First of all, xmlview is a great plugin with lots of features, but sometimes it does too much.
In the old days before the Firefox developers started removing useful features, there was a hierarchy where recognized data types like RSS and SVG would be rendered by spesial functions, and if no such function was found, the generix XML viewer kicked in. Now, with both of those having been removed from Firefox and left to plugin developers, there is no longer a hierarchy and race conditions will sometimes occur with unwanted consequences. RSS is an example of this.
At the moment I am using rsspreview to show RSS feeds. When trying to see the MET Norway weather alerts the RSS is briefly shown for half a second, then xmlview kicks in and shows an XML tree structure. Clearly this is not desirable. Nor, from what I can read from closed issues, is it expected behaviour. In issue #56 it looks like default behaviour in Chrome was to render as text and optionally as XML in the preferences. In issue #70 there is a complaint that xmlview does not render RSS as XML in Firefox. So it seems that the behaviour has changed since Aug 2019.
Twenty years ago, some people had the vision that all text on the web would be delivered as CSS styled XML. Clearly did not happen, but it is still technically possible. Also, there are a lot of XML based formats intended directly for end-user viewing, like SVG, RSS/Atom, MathML, DASH, iCalendar XML and so on. Clearly, showing the XML tree structure should be a last resort when no other application is available, just like "view source" in HTML.
I'm not sure what the official policy is on this, seeing as there seems to be a conflict between earlier statements and current behaviour. One possible solution could be to "whitelist" various content types in the preferences, although this would not solve all cases since e.g. some sites serve RSS as "text/xml" or "application/xml" instead of "application/rss+xml". Another could be to make it a feature that had to be invoked explicitly via the menu; this would enable it to be used with HTML too (duplicating the Web Developer feature in Firefox). Regardsless, some kind of workaround for this problem is urgently needed.
The text was updated successfully, but these errors were encountered: