I'm glad to see it disappear, it's one of those things the world doesn't need. A failed experiment. And an HTML UI for firefox makes sense in the long run.
Fun fact of the day: Did you know XUL uses DTD to store translations? That's right, if you have a string you want to translate, you just have to create a new XML element in a localized DTD file. Isn't that just a wonderful idea.
I was just going to mention that, but you beat me to it. It's just bizarre to use XML external entities for internationalization.
I worked on TomTom Home, which was implemented in xulrunner, and I developed some internationalization/localization tools that had to deal with XUL DTDs as well as several other different and incompatible file formats for storing translations. I could never for the life of me figure out why they decided to use DTDs with external entities for translations.
XUL wasn't a failed experiment. From what I understand it served as the inspiration for some of the new features found in HTML. If that's the case it was a useful experiment.
It was meant as a pro. Since it was their own language, they could do anything with it. They could make a better HTML.
But HTML caught up. Currently, I believe HTML is better than XUL, and making XUL great again is both a silly reuse of a political slogan and a waste of effort.
I for one would rather see efforts made to allow CSS styling of all input elements in HTML.
Good luck - the main advantage of XUL IMO is that it looks and feels native to the platform. This is completely lacking in any HTML based UI I've ever seen. It's been a major advantage for FF extensions and I can't help but feel like it's a major step backwards to lose it.
>
Good luck - the main advantage of XUL IMO is that it looks and feels native to the platform.
That you say that is a testament to how well the meticulous CSS styling of the XUL elements—which applies equally well to HTML (try it in a browser chrome shell!)—worked.
I don't think that has anything to do with XUL directly, you can still find its original look by furing up Seamonkey, but that Firefox developers opted to rework the UI subsystem so that it translated XUL elements into native elements as much as possible. Iirc, this was done in part to speed up the Firefox UI compared to Seamonkey.
> Being nonstandard is completely irrelevant here.
It's relevant in that much of the work has to be duplicated (documentation but also layout implementation & the like) and none of the new and improved web development tools can be used for XUL.
The problem as I understand is more about the documentation, the hidden quirks and also the barrier to bring new contributors to the source code. It's always easier when they don't have to learn a custom language first.
> Being nonstandard is completely irrelevant here.
No, it's not irrelevant. Standards are also about documentation (it's easier to document standardized things) and familiarity (people are more familiar with standardized things).
I was poking at the non-standard portion. Lowering barrier to development of plugins, patches, etc is fine, but being standard doesn't help or hinder that. Popularity and ease of introduction help that. Javascript (that is, the dialect of ECMAScript that is implemented by Firefox) itself is non-standard and Mozilla isn't throwing that one out for exclusively ES2015.
Actually, tons of nonstandard SpiderMonkey features have been removed. Sharp literals were axed, E4X was removed, "let" is being changed to the ES6 behavior, and so on.
I'm glad to see it disappear, it's one of those things the world doesn't need. A failed experiment. And an HTML UI for firefox makes sense in the long run.
Fun fact of the day: Did you know XUL uses DTD to store translations? That's right, if you have a string you want to translate, you just have to create a new XML element in a localized DTD file. Isn't that just a wonderful idea.