Re: Moratorium on new XUL features
On 16/10/2014 13:56, Robert O'Callahan wrote: On Fri, Oct 17, 2014 at 9:45 AM, Gijs Kruitbosch wrote: There are also "interesting" height computation issues that I'm pretty sure HTML (flexbox) doesn't have, e.g. bug 451997. I'm not sure that's a function of the box model, considering it's not an issue with flexbox... Yeah. XUL layout (all layouts, not just flexbox) compute intrinsic width *and* height bottom up before doing actual layout. This is incompatible with CSS and really just broken, and the friction between that model and CSS is painful. Rob This is an interesting point in terms of wanting to switch to HTML here. We use quite a lot of popups and panels in the Firefox front-end code. Those size to content (and windows/dialogs have a .sizeToContent method). How would/could that work in the HTML/CSS model? (asking particularly because I'd love to have an alternative for the broken XUL layout we get now which leads to stupid bugs and wasted time and frustration - so far I've not been able to work around just by using lots of display: flex; and friends...) ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
在 2014年10月17日星期五UTC+8下午2时39分54秒，Yonggang Luo写道： > There is a lost of falt in XUL, but still have something good, such as tree > and the XBL binding, besides, the window elements is also important, because > we need it to implement chromeless window, and titlebar, there is no > equivalent in HTML/JS, that's must be considerate when propose the removal of > XUL. There is also the command liner parser is also needed. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
There is a lost of falt in XUL, but still have something good, such as tree and the XBL binding, besides, the window elements is also important, because we need it to implement chromeless window, and titlebar, there is no equivalent in HTML/JS, that's must be considerate when propose the removal of XUL. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
On Fri, Oct 17, 2014 at 9:45 AM, Gijs Kruitbosch wrote: There are also "interesting" height computation issues that I'm pretty sure > HTML (flexbox) doesn't have, e.g. bug 451997. I'm not sure that's a > function of the box model, considering it's not an issue with flexbox... > Yeah. XUL layout (all layouts, not just flexbox) compute intrinsic width *and* height bottom up before doing actual layout. This is incompatible with CSS and really just broken, and the friction between that model and CSS is painful. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
On 16/10/2014 06:15, Boris Zbarsky wrote: On 10/16/14, 5:30 AM, Neil wrote: Out of interest, what does it do that complicates layout? You mentioned the box model of course, but what else is there? There's a bunch of listbox-related frame constructor complexity (and for a while it was a quite lively source of security bugs, too). But for the most part the layout complications come from the box model, yes. -Boris There are also "interesting" height computation issues that I'm pretty sure HTML (flexbox) doesn't have, e.g. bug 451997. I'm not sure that's a function of the box model, considering it's not an issue with flexbox... ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTMLOverlays (was Re: Moratorium on new XUL features)
On 2014-10-16, 1:44 PM, David Rajchenbach-Teller wrote: On 16/10/14 12:54, Ehsan Akhgari wrote: It can be implemented in JS, right? Indeed. I meant, as a JS library by web developers who feel like it's needed, not by us. :-) FWIW I think that XUL overlays are a terrible way of extending the UI so I'm not in a rush for something like that to happen for HTML. Their biggest issue is that they completely ignore the problem of how to handle two different overlays being applied to the same element. They also effectively make your DOM structure a public API which is barely maintainable, as we have learned the hard way. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTMLOverlays (was Re: Moratorium on new XUL features)
On 16/10/14 12:54, Ehsan Akhgari wrote: > It can be implemented in JS, right? Indeed. -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTMLOverlays (was Re: Moratorium on new XUL features)
On 2014-10-16, 7:02 AM, David Rajchenbach-Teller wrote: Which actually looks pretty good to me and should perhaps be (re)discussed. It can be implemented in JS, right? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
On 10/16/14, 5:30 AM, Neil wrote: Out of interest, what does it do that complicates layout? You mentioned the box model of course, but what else is there? There's a bunch of listbox-related frame constructor complexity (and for a while it was a quite lively source of security bugs, too). But for the most part the layout complications come from the box model, yes. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
HTMLOverlays (was Re: Moratorium on new XUL features)
Which actually looks pretty good to me and should perhaps be (re)discussed. I wonder if something like HTMLoverlays (certainly extended with a mechanism to help with unloading) could be made part of the Add-on SDK. Cheers, David On 16/10/14 04:53, Gervase Markham wrote: > Although glazou did propose one a decade ago: > http://disruptive-innovations.com/zoo/20040830/HTMLoverlays.html > > Gerv > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
Boris Zbarsky wrote: The situation is that we have a bunch of unmaintained code that complicates layout. Out of interest, what does it do that complicates layout? You mentioned the box model of course, but what else is there? -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
On 15/10/14 14:24, Boris Zbarsky wrote: > I haven't thought much about #3; it's somewhat in its own little world > and has no web tech equivalent. Although glazou did propose one a decade ago: http://disruptive-innovations.com/zoo/20040830/HTMLoverlays.html Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
On Wednesday 2014-10-15 09:24 -0400, Boris Zbarsky wrote: > "XUL" covers a variety of somewhat-unrelated features, including at least: > > 1) The XUL box model. > 2) The built-in XUL elements (with C++ implementations). for > example. > 3) The overlay system. > 4) XBL and the bindings provided by default. > 5) Localization via DTDs > > I probably missed some; please tell me what they are. > > I would dearly like #1 to go away in favor of flexbox. This might > be possible to do without changing anything else, maybe, albeit with > some UI layout breakage in some consumers because the models are not > quite identical. If that's not possible, it might be a good idea to > migrate away from flexbox manually (by using those display types > instead of -moz-box and company in your stylesheets for XUL > hbox/vbox/etc elements). flexbox is all done, pretty much, so there > is a viable path forward here that just needs resources. This would > clearly not affect scripts, except to the extent that the slightly > different layout model forces changes to the DOM used. > > I'm slightly less concerned about #2, though it would be good to > replace those with web components if/when possible. > > I haven't thought much about #3; it's somewhat in its own little > world and has no web tech equivalent. We should also distinguish between doing the work to make things go away, and putting effort into improving them. For the former, we have to compare the amount of overhead (over time) these features add to the amount of work (once) it would take them to go away. But what started this thread was the latter -- adding new features to XUL. Part of the problem with adding features to XUL is that there is not an effective community around this technology. We don't have code reviewers who are domain experts in it, and thus code reviews end up falling to people with general knowledge of all of layout, who are already overloaded with other work that contributes much more to Mozilla's mission. Don't, however, take that as a suggestion that we're looking for volunteers. I think at this point it's too late; we've had 11 years since Netscape stopped improving this technology for volunteers to show up to lead its development. Yes, we have occasional contributors show up to add a feature that they want. But we don't have anyone who's leading its development or who has a good reason to do so. The Web has beaten XUL, and it's part of our mission to make the Web beat XUL, and other things like it; the Web is open, standardized, and cross-vendor. XUL isn't going away anytime soon because we have too many dependencies on it. Getting rid of it is a long-term goal, not a short-term one. What we're saying now is that we're not going to invest effort into mentoring and reviewing additions of features to XUL -- effort that we could otherwise spend improving the Web. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
On 10/15/14, 9:03 AM, Boris Zbarsky wrote: The situation is that we have a bunch of unmaintained code that complicates layout. I feel like I should expand on this. "XUL" covers a variety of somewhat-unrelated features, including at least: 1) The XUL box model. 2) The built-in XUL elements (with C++ implementations). for example. 3) The overlay system. 4) XBL and the bindings provided by default. 5) Localization via DTDs I probably missed some; please tell me what they are. I would dearly like #1 to go away in favor of flexbox. This might be possible to do without changing anything else, maybe, albeit with some UI layout breakage in some consumers because the models are not quite identical. If that's not possible, it might be a good idea to migrate away from flexbox manually (by using those display types instead of -moz-box and company in your stylesheets for XUL hbox/vbox/etc elements). flexbox is all done, pretty much, so there is a viable path forward here that just needs resources. This would clearly not affect scripts, except to the extent that the slightly different layout model forces changes to the DOM used. I'm slightly less concerned about #2, though it would be good to replace those with web components if/when possible. I haven't thought much about #3; it's somewhat in its own little world and has no web tech equivalent. For #4 a viable path forward is piecemeal conversion to web components once those are stable and shipping. Since they aren't, there's nothing to think about here yet. For #5, I'm not an expert. l20n or something seems like a possible replacement, but in any case a replacement would need to exist to talk about moving away from the current localization mechanism. Again, except for maybe #1 these are all off in "who knows when this will be possible?" territory. I'm sorry if you got the impression that there are short-term plans to remove anything here. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
This is one of the reasons I started to breathe new life in the Chromeless project[1], but with a grander scope this time around. I’d like to facilitate a pragmatic migration route to building desktop apps with XULRunner using only the latest Web technologies, including asm.js and WebGL+WebVR. Due to my work on Australis, Loop/ Hello and the move to a new house eating away my spare time too, this project got stalled quite a bit as I can/ could only work on it then. I hope to be able to pick up this work again soon! Perhaps this project offers a likeable middle-ground solution to still allow for a Mozilla SDK to exist, while not needing to maintain the entire XUL stack. Mike. [1] https://github.com/mikedeboer/chromeless2 On 15 Oct 2014, at 15:03, Boris Zbarsky wrote: > On 10/15/14, 5:01 AM, glazou wrote: >> w/o even trying to discuss with >> them the situation, the possibilities, the alternatives, the ETA, >> the transition plan. > > The situation is that we have a bunch of unmaintained code that complicates > layout. And layout needs no extra complications; it has enough as it is. So > again, on a purely technical level we would like to get rid of this code. > > I'm happy to discuss possibilities and alternatives, of course. Any ideas? > > There is no ETA, and no concrete transition plan past the one Bobby and I > outlined upthread. > >> That will require an enormous investment that most embedders won't be >> able to cope with. > > I don't think that long-term (think decades, not years) Mozilla can cope with > the investment of having the XUL support we have in the rendering engine > right now > > -Boris > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
On 10/15/14, 5:01 AM, glazou wrote: w/o even trying to discuss with them the situation, the possibilities, the alternatives, the ETA, the transition plan. The situation is that we have a bunch of unmaintained code that complicates layout. And layout needs no extra complications; it has enough as it is. So again, on a purely technical level we would like to get rid of this code. I'm happy to discuss possibilities and alternatives, of course. Any ideas? There is no ETA, and no concrete transition plan past the one Bobby and I outlined upthread. That will require an enormous investment that most embedders won't be able to cope with. I don't think that long-term (think decades, not years) Mozilla can cope with the investment of having the XUL support we have in the rendering engine right now -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
On 10/15/14, 3:40 AM, glazou wrote: Guys, you understand there is an ecosystem - even if it is a small one - of companies relying on XUL for their businesses? Yes, including Mozilla, via Firefox. 1. does Mozilla still care about us? I can't answer this question. On a personal level, I care about you, but not enough to leave XUL in the tree if you're the only remaining consumer. Which you're not. 2. since it's out of question to rebuild something as big as the UI of BlueGriffon or Postbox in html (and that will imply rewriting most of the js around) for the time being, what do you suggest? The Firefox UI has the same issue. The only viable plan I can think of for either case is to move the UI to HTML piecemeal (e.g. move the preferences dialog into HTML, etc) until the remaining work is small enough to be done in a flag day. I'm not saying this is an easy project, or high priority at the moment, so it's not likely to happen anytime soon, but I believe it _is_ desirable and should be the end goal. At least for Firefox and Gecko. Whether this happens before Gecko is perhaps replaced by Servo or something is anyone's guess. Servo doesn't support XUL and has no plans to, of course. I would like to have a response from - or some direct interaction with - Chris Beard please. This is probably the wrong forum for that; I doubt he reads this newsgroup. Long-time partners heavily relying on XUL deserve a bit more than the current ultralight information we have. There isn't any more information to be had. On the technical level, we would like to get rid of the complexity XUL support introduces to the rendering engine. There are no _concrete_ plans or timescales for doing that, it would be blocked on a whole bunch of other changes at the very least to Firefox desktop builds, and it's not clear when or whether it will actually happen. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
Le mercredi 15 octobre 2014 10:18:19 UTC+2, Bobby Holley a écrit : > I agree that the current state of affairs sucks for XUL embedders, and you > have our sympathy. But if we translate that sympathy into strategy, we will > lose much bigger battles. I have the feeling "sucks" is a bit far from reality... This is going to kill long-time partners of Mozilla w/o even trying to discuss with them the situation, the possibilities, the alternatives, the ETA, the transition plan. Ahem, to say the least. > Firefox is much bigger than BlueGriffon, and is still mostly written in > XUL. I'd suggest following the same strategy as the Firefox team - slowly > transition to web technology, and file bugs when stuff doesn't work. If you > want to go whole-hog and ride the technologies that Mozilla is investing > in, I'd suggest creating an OpenWebApp that you can put in the Mozilla > Marketplace. If you do that, you will find orders of magnitude more > responsiveness and interest from Mozilla's side than you will as a > XULRunner developer. That will require an enormous investment that most embedders won't be able to cope with. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
On Wed, Oct 15, 2014 at 9:40 AM, glazou wrote: > 1. does Mozilla still care about us? In terms of the goals of the organization, I think it's pretty clear that XUL embeddings are not a priority - they're pretty orthogonal to the Mozilla Mission (which is about the Internet and the Web - not desktop SDKs). Lots of Mozilla developers have positive feelings and personal relationships with embedders like yourself, and so we do our best to make things smooth when we can. But fundamentally, we would be doing a disservice to our mission if we spent significant resources on non-web technologies like XUL. Gecko is large and often unwieldy, so any transition takes time. But I think it's pretty clear that our _ideal_ direction would be to migrate all frontend code to standardized non-dead-end technologies like HTML and WebComponents. This lets us focus our efforts, eat our own dogfood, and make it easier for web developers to contribute to Firefox. > I have endlessly tried to discuss the fate of XUL and XULRunner with a > previous Mozilla CEO, Gary Kovacs. He _never_ accepted to have a chat about > it. This isn't really something that a C-level exec would have anything useful to say about. Bob Moss is the VP of Gecko, but even he would probably defer to the judgement of the people you're talking to (bz, roc, dbaron, bsmedberg, myself, etc). And I think our opinions are pretty clear in this thread. > I have the feeling we are left outside alone in a « too bad for you » move > and I find it depressing. > I agree that the current state of affairs sucks for XUL embedders, and you have our sympathy. But if we translate that sympathy into strategy, we will lose much bigger battles. > 2. since it's out of question to rebuild something as big as the UI of > BlueGriffon or Postbox in html (and that will imply rewriting most of the > js around) for the time being, what do you suggest? > Firefox is much bigger than BlueGriffon, and is still mostly written in XUL. I'd suggest following the same strategy as the Firefox team - slowly transition to web technology, and file bugs when stuff doesn't work. If you want to go whole-hog and ride the technologies that Mozilla is investing in, I'd suggest creating an OpenWebApp that you can put in the Mozilla Marketplace. If you do that, you will find orders of magnitude more responsiveness and interest from Mozilla's side than you will as a XULRunner developer. > I would like to have a response from - or some direct interaction with - > Chris Beard please. I don't set his schedule, but per above I doubt he'd have much to say on this topic. bholley ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
Le mardi 14 octobre 2014 14:29:04 UTC+2, Boris Zbarsky a écrit : > On 10/13/14, 11:28 PM, Yonggang Luo wrote: > > > If the XUL is truly dead, then mozilla community should consider to remove > > it totally from the codebase > > > > Working on it. It's a big project. ;) Seriously ?!? Guys, you understand there is an ecosystem - even if it is a small one - of companies relying on XUL for their businesses? BlueGriffon, Postbox and more rely on XUL and XULRunner. So I have two questions: 1. does Mozilla still care about us? I have endlessly tried to discuss the fate of XUL and XULRunner with a previous Mozilla CEO, Gary Kovacs. He _never_ accepted to have a chat about it. I have the feeling we are left outside alone in a « too bad for you » move and I find it depressing. 2. since it's out of question to rebuild something as big as the UI of BlueGriffon or Postbox in html (and that will imply rewriting most of the js around) for the time being, what do you suggest? I would like to have a response from - or some direct interaction with - Chris Beard please. Putting XUL to rest would be a death knell on a critically-large part of my business - among others - and I think it deserves a bit more than a technical discussion or one-liners with a smiley. In short, it would kill my company. Long-time partners heavily relying on XUL deserve a bit more than the current ultralight information we have. Thanks. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
在 2014年10月14日星期二UTC+8下午8时29分04秒，Boris Zbarsky写道： > On 10/13/14, 11:28 PM, Yonggang Luo wrote: > > > If the XUL is truly dead, then mozilla community should consider to remove > > it totally from the codebase > > > > Working on it. It's a big project. ;) Well, indeed, i've seen so much simulated tree in HTML, it's totally slow and not performance good, and do not support for big data(1000,000+) indeed. So if mozilla community are working on it, there should be some equivalent for tree in HTML. > > > > -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
On 10/14/2014 5:12 PM, Robert O'Callahan wrote: On Tue, Oct 14, 2014 at 4:56 PM, Joshua Cranmer 🐧 wrote: From another point of view: Mozilla, for over a decade, provided a relatively featureful toolkit for building UIs known as XUL. If the argument is that we should be using HTML instead of XUL, then wouldn't it make sense to provide an at-least-as-featureful HTML toolkit to make migration easy and relatively painless? I already said I'm not proposing a wholesale migration here. Please stop misconstruing me. Nor am I proposing a wholesale migration. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
On Tue, Oct 14, 2014 at 4:56 PM, Joshua Cranmer 🐧 wrote: > From another point of view: Mozilla, for over a decade, provided a > relatively featureful toolkit for building UIs known as XUL. If the > argument is that we should be using HTML instead of XUL, then wouldn't it > make sense to provide an at-least-as-featureful HTML toolkit to make > migration easy and relatively painless? I already said I'm not proposing a wholesale migration here. Please stop misconstruing me. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
On Tue, Oct 14, 2014 at 2:29 PM, Boris Zbarsky wrote: > Working on it. It's a big project. ;) Is there a tracker for this? Cheers, Dirkjan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
On 10/13/14, 11:28 PM, Yonggang Luo wrote: If the XUL is truly dead, then mozilla community should consider to remove it totally from the codebase Working on it. It's a big project. ;) -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
On Mon, Oct 13, 2014 at 8:56 PM, Joshua Cranmer 🐧 wrote: > From another point of view: Mozilla, for over a decade, provided a > relatively featureful toolkit for building UIs known as XUL. If the argument > is that we should be using HTML instead of XUL, then wouldn't it make sense > to provide an at-least-as-featureful HTML toolkit to make migration easy and > relatively painless? I would love to make it easier for people to create long scrollable lists for HTML. However it's a quite hard problem to solve. We're doing some experimenting on this front in FirefoxOS. There's no reason we couldn't do the same in Firefox Desktop UI as well. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
On 10/13/2014 10:10 PM, Andrew Sutherland wrote: On 10/13/2014 07:06 PM, Joshua Cranmer 🐧 wrote: I nominally agree with this sentiment, but there are a few caveats: 1. nsITreeView and exist and are usable in Mozilla code today. No HTML-based alternative to these are so easily usable. There are many lazy-rendering infinite tree/table/infinite list implementations out there: I found far fewer when searching, but I suppose I'm just bad at coming up with search terms. e) already existed and were generally maintained in toolkit/ This is a weird, NIH-ish requirement. Why should Mozilla create and maintain an HTML tree widget when there are so many open source implementations that already exist? I suppose the requirement I really meant was "does not require a massive toolkit to work properly." Taken to the extreme, we'd end up with a half a dozen large JS toolkits being installed when we install Firefox--see the current thread about Firefox installer size pondering. Also, I feel that a Mozilla-maintained (or at least Mozilla-blessed) toolkit is far more likely to solve issues that aren't normally in the thoughts of web developers, e.g., accessibility. From another point of view: Mozilla, for over a decade, provided a relatively featureful toolkit for building UIs known as XUL. If the argument is that we should be using HTML instead of XUL, then wouldn't it make sense to provide an at-least-as-featureful HTML toolkit to make migration easy and relatively painless? -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
I know there is so much alternative for tree in HTML/JS, but the simplest way is to improve tree directly when you have already use it. If the XUL is truly dead, then mozilla community should consider to remove it totally from the codebase, but not reject to improve it. 在 2014年10月14日星期二UTC+8上午11时11分39秒，somb...@gmail.com写道： > On 10/13/2014 07:06 PM, Joshua Cranmer 🐧 wrote: > > > I nominally agree with this sentiment, but there are a few caveats: > > > 1. nsITreeView and exist and are usable in Mozilla code > > > today. No HTML-based alternative to these are so easily usable. > > > > There are many lazy-rendering infinite tree/table/infinite list > > implementations out there: > > > > For example: > > - Dojo: TreeGrind/LazyTreeGrid > > http://dojotoolkit.org/reference-guide/1.10/dojox/grid/TreeGrid.html > > - dgrid (Dojo related): http://dojofoundation.org/packages/dgrid/ > >- tree examples > >- column hider extension: > > https://github.com/SitePen/dgrid/blob/v0.3.15/doc/components/extensions/ColumnHider.md > > - the things that the dgrid website provides in its comparison table > > - Sencha (which is GPLv3 but has a weird library style exception it > > seems): http://dev.sencha.com/ext/5.0.1/examples/tree/locking-treegrid.html > > - React (just a list, but an example of how easy such a component is in > > React): https://github.com/orgsync/react-list > > > > > 2. The main rationale for this feature (bug 213945, although I doubt > > > the approach currently taken in bug 441414 is actually usable for that > > > anyways) involves a tree view that is currently performance-sensitive > > > and comprises 13,446 lines of C++ code, so it can't easily move to JS. > > > Which means some sort of XPIDL API is going to be necessary anyways, > > > and that API would probably look vaguely similar to nsITreeView. > > > > The performance-sensitive parts of the XUL tree view widget is that it > > paints synchronously and does not do any smart caching on its own. > > These are deficiencies of the C++ XUL tree implementation that an HTML > > implementation need not share. (In fact, I've never seen any that would > > have the same performance problems; you'd have to write your own widget > > from the ground up in Canvas to reproduce them.) > > > > For the bug 213945 Thunderbird use-case, the existing C++ nsITreeView > > interface implemented by the mailnews DBView could easily be used by a > > Dojo Store adapter/etc. Any calls made by C++ code to update the tree > > view can (and already do) call JS code to cause proper invalidation of > > the JS/HTML-exposed data-model. I say this as someone with expensive > > experience working with that area of the Thunderbird codebase and who > > considered our options and decided that an HTML-based widget was the way > > to go. > > > > > 3. I've never done a lot of UI coding myself, so I don't know if my > > > recollection is correct anymore or even if it ever was, but I recall > > > hearing that XUL and HTML didn't get together terribly well. > > > > > > So if we had an HTML tree implementation that: > > > a) supported lazy generation of row data > > > b) supported column pickers, rearrangeable columns, etc. > > > c) supported CSS queries similar to what does already, > > > > The examples I give above I believe all support these features. > > > > > d) could be used or made usable from C++ without too much effort > > > > As noted above, I don't think Thunderbird's use-case actually requires > > C++ code to meaningfully interact with the tree widget in a way that > > can't be compensated for in JS. > > > > > e) already existed and were generally maintained in toolkit/ > > > > This is a weird, NIH-ish requirement. Why should Mozilla create and > > maintain an HTML tree widget when there are so many open source > > implementations that already exist? > > > > > f) were properly accessible > > > > A good concern and something that should be used for evaluation of any > > library options. Since the widgets above all use the HTML DOM, it's a > > question of making sure they are using the appropriate HTML and ARIA > > attributes (ex: aria-posinset). > > > > Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
On 10/13/2014 07:06 PM, Joshua Cranmer 🐧 wrote: I nominally agree with this sentiment, but there are a few caveats: 1. nsITreeView and exist and are usable in Mozilla code today. No HTML-based alternative to these are so easily usable. There are many lazy-rendering infinite tree/table/infinite list implementations out there: For example: - Dojo: TreeGrind/LazyTreeGrid http://dojotoolkit.org/reference-guide/1.10/dojox/grid/TreeGrid.html - dgrid (Dojo related): http://dojofoundation.org/packages/dgrid/ - tree examples - column hider extension: https://github.com/SitePen/dgrid/blob/v0.3.15/doc/components/extensions/ColumnHider.md - the things that the dgrid website provides in its comparison table - Sencha (which is GPLv3 but has a weird library style exception it seems): http://dev.sencha.com/ext/5.0.1/examples/tree/locking-treegrid.html - React (just a list, but an example of how easy such a component is in React): https://github.com/orgsync/react-list 2. The main rationale for this feature (bug 213945, although I doubt the approach currently taken in bug 441414 is actually usable for that anyways) involves a tree view that is currently performance-sensitive and comprises 13,446 lines of C++ code, so it can't easily move to JS. Which means some sort of XPIDL API is going to be necessary anyways, and that API would probably look vaguely similar to nsITreeView. The performance-sensitive parts of the XUL tree view widget is that it paints synchronously and does not do any smart caching on its own. These are deficiencies of the C++ XUL tree implementation that an HTML implementation need not share. (In fact, I've never seen any that would have the same performance problems; you'd have to write your own widget from the ground up in Canvas to reproduce them.) For the bug 213945 Thunderbird use-case, the existing C++ nsITreeView interface implemented by the mailnews DBView could easily be used by a Dojo Store adapter/etc. Any calls made by C++ code to update the tree view can (and already do) call JS code to cause proper invalidation of the JS/HTML-exposed data-model. I say this as someone with expensive experience working with that area of the Thunderbird codebase and who considered our options and decided that an HTML-based widget was the way to go. 3. I've never done a lot of UI coding myself, so I don't know if my recollection is correct anymore or even if it ever was, but I recall hearing that XUL and HTML didn't get together terribly well. So if we had an HTML tree implementation that: a) supported lazy generation of row data b) supported column pickers, rearrangeable columns, etc. c) supported CSS queries similar to what does already, The examples I give above I believe all support these features. d) could be used or made usable from C++ without too much effort As noted above, I don't think Thunderbird's use-case actually requires C++ code to meaningfully interact with the tree widget in a way that can't be compensated for in JS. e) already existed and were generally maintained in toolkit/ This is a weird, NIH-ish requirement. Why should Mozilla create and maintain an HTML tree widget when there are so many open source implementations that already exist? f) were properly accessible A good concern and something that should be used for evaluation of any library options. Since the widgets above all use the HTML DOM, it's a question of making sure they are using the appropriate HTML and ARIA attributes (ex: aria-posinset). Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
On Tue, Oct 14, 2014 at 12:06 PM, Joshua Cranmer 🐧 wrote: I nominally agree with this sentiment, but there are a few caveats: > 1. nsITreeView and exist and are usable in Mozilla code today. > No HTML-based alternative to these are so easily usable. > 2. The main rationale for this feature (bug 213945, although I doubt the > approach currently taken in bug 441414 is actually usable for that anyways) > involves a tree view that is currently performance-sensitive and comprises > 13,446 lines of C++ code, so it can't easily move to JS. Which means some > sort of XPIDL API is going to be necessary anyways, and that API would > probably look vaguely similar to nsITreeView. > I'm not proposing migrating the current tree code to HTML+JS. > 3. I've never done a lot of UI coding myself, so I don't know if my > recollection is correct anymore or even if it ever was, but I recall > hearing that XUL and HTML didn't get together terribly well. > > So if we had an HTML tree implementation that: > a) supported lazy generation of row data > b) supported column pickers, rearrangeable columns, etc. > c) supported CSS queries similar to what does already, > d) could be used or made usable from C++ without too much effort > e) already existed and were generally maintained in toolkit/ > f) were properly accessible > g) had any other compatibility features I've neglected > > I would happily agree with you. But without those, it does feel a little > bit like you're holding hostage real improvements on the basis that a > better solution theoretically exists. > Nope. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
On 10/13/2014 5:28 PM, Robert O'Callahan wrote: Bug 441414 has patches adding features to XUL trees. I'm sympathetic to the desire for these features, but I do not think we should take these patches, nor any other patches adding features to XUL. XUL is a dead-end technology and investment in XUL provides minimal returns --- this includes effort spent reviewing and maintaining XUL. Some amount of XUL maintenance is necessary to support Firefox, Thunderbird and the Firefox addons ecosystem, but we should keep it to a minimum. In most cases our apps and addons can use standard Web platform technology instead, which continues to evolve rapidly. There may be some cases where small extensions to XUL provide great benefits to the Mozilla project that we can't easily get any other way, in which case we should allow it. I don't think bug 441414 is one of those cases. With some effort you can build arbitrarily rich XUL-tree-like functionality using HTML, and that's the way to go. I nominally agree with this sentiment, but there are a few caveats: 1. nsITreeView and exist and are usable in Mozilla code today. No HTML-based alternative to these are so easily usable. 2. The main rationale for this feature (bug 213945, although I doubt the approach currently taken in bug 441414 is actually usable for that anyways) involves a tree view that is currently performance-sensitive and comprises 13,446 lines of C++ code, so it can't easily move to JS. Which means some sort of XPIDL API is going to be necessary anyways, and that API would probably look vaguely similar to nsITreeView. 3. I've never done a lot of UI coding myself, so I don't know if my recollection is correct anymore or even if it ever was, but I recall hearing that XUL and HTML didn't get together terribly well. So if we had an HTML tree implementation that: a) supported lazy generation of row data b) supported column pickers, rearrangeable columns, etc. c) supported CSS queries similar to what does already, d) could be used or made usable from C++ without too much effort e) already existed and were generally maintained in toolkit/ f) were properly accessible g) had any other compatibility features I've neglected I would happily agree with you. But without those, it does feel a little bit like you're holding hostage real improvements on the basis that a better solution theoretically exists. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
On Tuesday 2014-10-14 11:28 +1300, Robert O'Callahan wrote: > Bug 441414 has patches adding features to XUL trees. I'm sympathetic to the > desire for these features, but I do not think we should take these patches, > nor any other patches adding features to XUL. XUL is a dead-end technology > and investment in XUL provides minimal returns --- this includes effort > spent reviewing and maintaining XUL. Some amount of XUL maintenance is > necessary to support Firefox, Thunderbird and the Firefox addons ecosystem, > but we should keep it to a minimum. In most cases our apps and addons can > use standard Web platform technology instead, which continues to evolve > rapidly. > > There may be some cases where small extensions to XUL provide great > benefits to the Mozilla project that we can't easily get any other way, in > which case we should allow it. I don't think bug 441414 is one of those > cases. With some effort you can build arbitrarily rich XUL-tree-like > functionality using HTML, and that's the way to go. Agreed. (And, really, I should have sent something like the above message two weeks ago, but roc beat me to it.) -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Moratorium on new XUL features
Bug 441414 has patches adding features to XUL trees. I'm sympathetic to the desire for these features, but I do not think we should take these patches, nor any other patches adding features to XUL. XUL is a dead-end technology and investment in XUL provides minimal returns --- this includes effort spent reviewing and maintaining XUL. Some amount of XUL maintenance is necessary to support Firefox, Thunderbird and the Firefox addons ecosystem, but we should keep it to a minimum. In most cases our apps and addons can use standard Web platform technology instead, which continues to evolve rapidly. There may be some cases where small extensions to XUL provide great benefits to the Mozilla project that we can't easily get any other way, in which case we should allow it. I don't think bug 441414 is one of those cases. With some effort you can build arbitrarily rich XUL-tree-like functionality using HTML, and that's the way to go. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
