Re:No XBL Components Left in Firefox
by vbezhenar on Saturday October 26, 2019 @03:19PM
(#21365618)
That's surprising. I wrote an extension back in the days, I think it was Firefox 1.5, I used XPCOM to use C code and it worked well. I don't remember stumbling into too many bugs. Actually I liked XUL and I thought that it has great future, because it was so much better for UI than HTML.
[ Parent
| on HN ]
Even though there are still bits of XUL in Firefox, the XUL tech itself has not been maintained along with the rest of Gecko. It was probably not in much of a better state in Firefox 56 than it was back when you were working with it.
Re:No XBL Components Left in Firefox
by The_rationalist on Saturday October 26, 2019 @06:30PM
(#21366660)
Would you care elaborating why it is better than HTML5?
"HTML5" + things like css grid and flexbox that you need to build UI in a sensible manner are pretty new inventions. XUL predates them dramatically, building UI in HTML at the time would have been an absolute nightmare. I know because I had to ship it in multiple applications
Re:No XBL Components Left in Firefox
by The_rationalist on Saturday October 26, 2019 @08:01PM
(#21367092)
I understand that it probably was a better technology at the time.
But are there any concepts/technologies in XUL that would be useful to add in the HTML standard?
Re:No XBL Components Left in Firefox
by xeeeeeeeeeeenu on Saturday October 26, 2019 @08:26PM
(#21367157)
It's a minor problem, but CSS, unlike XUL, doesn't provide a way to crop text in the middle[1][2].
[1] - https://www.w3.org/wiki/Text-overflow_middle_cropping
[2] - https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XUL...
Cropping text in the middle is extremely hard to spec and implement for general inline CSS. Cropping at the start or end can be implemented as a purely paint-time operation. Cropping in the middle means you have to change the layout, and you have to define the layout of the stuff in the middle that has been cropped away in case someone does element.getClientRects() etc. It is far from obvious how that should work.
XUL texboxes avoided this problem by only supporting a single plain text string, but applying that constraint to HTML+CSS would be incredibly ugly (and people soon be complaining about that constraint, anyway).
HTML5 (2014) and Firefox 1.5 (2005) were not contemporaneous.