Re: Deprecating XUL in new UI

On 1/16/2017 12:43 PM, Dave Townsend wrote: One of the things I've been investigating since moving back to the desktop team is how we can remove XUL from the application as much as possible. Would you be open to a team of volunteers working on this issue? I've been pursing an effort in the sta

Re: Deprecating XUL in new UI

Certainly given that there are already several projects that use HTML to build desktop and mobile app UIs, standardizing ways to use HTML to represent any missing parts of a desktop UI would be a worthwhile endeavor. Eric Shepherd Senior Technical Writer Mozilla https://developer.mozilla.org/

Re: Deprecating XUL in new UI

On Monday, January 23, 2017 at 12:03:35 PM UTC-8, Eric Shepherd wrote: > It seems to me, anyway, that the ideal solution would be to enhance HTML > (ideally in the spec) with the features needed to build a full-fledged > desktop UI. That would be fabulous not just for Firefox making the transitio

Re: Deprecating XUL in new UI

It seems to me that the XUL to HTML transition is a big job that needs to be done with care. Would it make sense to try to work toward additions to HTML and/or additions of prefixed attributes and the like to add the needed behaviors to HTML wherever possible before trying to hack out a transiti

Re: Deprecating XUL in new UI

On 1/23/17 10:31 AM, David Bolter wrote: Should (can) it die in the Quantum development timeframe? In my opinion, no. What does that do to shipping risk? Makes it super-high. I realize churn creates risk, but I seem to recall XBL is getting in the way for Quantum styling? Not as much as

Re: Deprecating XUL in new UI

On Tue, Jan 17, 2017 at 12:55 PM, Bobby Holley wrote: > On Tue, Jan 17, 2017 at 8:56 AM, Boris Zbarsky wrote: > > > On 1/16/17 4:28 PM, Matthew N. wrote: > > > >> Does it just work from XHTML documents? > >> > > > > Yes, as far as I know. > > > > Is our implementation of Web Components ready to

Re: Deprecating XUL in new UI

Hi all, so as not to leave this hanging: On Tue, Jan 17, 2017 at 9:24 AM, Axel Hecht wrote: > Am 16/01/2017 um 21:43 schrieb Dave Townsend: > >> >> What other features do we depend on in XUL that I haven't listed? >> >> > Accessibility? Not sure how big the difference is there between XUL and >

Re: Deprecating XUL in new UI

On Mon, Jan 16, 2017 at 1:28 PM, Matthew N. wrote: > Trees are the big thing that come to mind. I've heard about three non-XUL > re-implementations (IIRC mostly in devtools) which sounds like a > maintainability issue and potentially redundancy. I would rather keep using > XUL trees than have eve

Re: Deprecating XUL in new UI

Regarding choice of framework for HTML-backed UIs. My initial suggestion is to try not to go into a fully-opinionated stack like React. My opinion has nothing to do with React itself, it's quality or suitability, but with a generic approach of using an opinionated stack that diverges from vani

Re: Deprecating XUL in new UI

On 01/18/2017 08:11 PM, J. Ryan Stinnett wrote: Thanks for checking it out! I guess the reading from / writing to disk is only for speeding up initial load of the first window then? reading is for speeding up the initial load, and once prototype has been loaded, no new loads are needed, since

Re: Deprecating XUL in new UI

On 01/18/2017 08:28 AM, smaug wrote: On 01/17/2017 10:51 PM, J. Ryan Stinnett wrote: On Mon, Jan 16, 2017 at 3:08 PM, smaug wrote: On 01/16/2017 10:43 PM, Dave Townsend wrote: One of the things I've been investigating since moving back to the desktop team is how we can remove XUL from the ap

Re: Deprecating XUL in new UI

On 01/17/2017 10:51 PM, J. Ryan Stinnett wrote: On Mon, Jan 16, 2017 at 3:08 PM, smaug wrote: On 01/16/2017 10:43 PM, Dave Townsend wrote: One of the things I've been investigating since moving back to the desktop team is how we can remove XUL from the application as much as possible. The ben

Re: Deprecating XUL in new UI

On 01/17/2017 12:05 AM, Dave Townsend wrote: Trees! I knew I was forgetting something, thank you. Yeah those are things we're going to need some sane replacements for. AS far as XBL goes, while I suspect it works from HTML documents I think we want to be phasing out use of XBL too for pretty muc

Re: Deprecating XUL in new UI

On 17/01/2017 17:55, Bobby Holley wrote: On Tue, Jan 17, 2017 at 8:56 AM, Boris Zbarsky wrote: On 1/16/17 4:28 PM, Matthew N. wrote: Does it just work from XHTML documents? Yes, as far as I know. Is our implementation of Web Components ready to replace it and riding the trains? No.

Re: Deprecating XUL in new UI

A few things we had to handle when going through this process for the devtools UI: 1) Already mentioned to but for panels we added a new module that falls back to XUL panels for now 2) For context menu handling we we added a new module similar to the Menu API from Electron that falls back to an

Re: Deprecating XUL in new UI

On Tue, Jan 17, 2017 at 02:51:47PM -0600, J. Ryan Stinnett wrote: I am not very familiar with the details of XUL prototype cache, but my understanding of bug 1286082[1] is that currently the XUL prototype cache is not actually working correctly (and possibly has been broken since bug 592943[2] la

Re: Deprecating XUL in new UI

On Mon, Jan 16, 2017 at 3:08 PM, smaug wrote: > On 01/16/2017 10:43 PM, Dave Townsend wrote: >> >> One of the things I've been investigating since moving back to the desktop >> team is how we can remove XUL from the application as much as possible. >> The >> benefits for doing this are varied, som

Re: Deprecating XUL in new UI

On Mon, Jan 16, 2017 at 2:43 PM, Dave Townsend wrote: > * iframe elements don't have the same capabilities that the XUL browser > element does and we use that in some UI. We do have available to chrome pages on desktop now (bug 1238160[1], landed in Firefox 47), which should get you a large part

Re: Deprecating XUL in new UI

Hello Boris, you're right - it's not XUL/HTML difference, but a chrome/content one. The issue with React and privileged iframes was investigated here: https://bugzilla.mozilla.org/show_bug.cgi?id=1245921#c55 see comments 55 and on. Jarda On Tue, Jan 17, 2017 at 6:05 PM, Boris Zbarsky wrote:

Re: Deprecating XUL in new UI

On Tue, Jan 17, 2017 at 8:56 AM, Boris Zbarsky wrote: > On 1/16/17 4:28 PM, Matthew N. wrote: > >> Does it just work from XHTML documents? >> > > Yes, as far as I know. > > Is our implementation of Web Components ready to replace it and riding the >> trains? >> > > No. > >From the perspective o

Re: Deprecating XUL in new UI

On 1/16/17 4:31 PM, Jaroslav Šnajdr wrote: - there is a difference in how events are dispatched in HTML vs XUL iframes. In HTML, the capture/bubble phases are isolated inside the iframe window, but in XUL, the target chain crosses the iframe boundaries. I'm not aware of this behavior for XUL, n

Re: Deprecating XUL in new UI

On 1/16/17 4:28 PM, Matthew N. wrote: Does it just work from XHTML documents? Yes, as far as I know. Is our implementation of Web Components ready to replace it and riding the trains? No. -Boris ___ dev-platform mailing list dev-platform@lists.m

Re: Deprecating XUL in new UI

You can still use dtd files in XHTML as long as it’s chrome-privileged. A lot of the about pages are doing this (aboutNetError.xhtml and others: https://dxr.mozilla.org/mozilla-central/search?q=path%3Axhtml+dtd). Brian > On Jan 17, 2017, at 3:34 AM, zbranie...@mozilla.com wrote: > > One more

Re: Deprecating XUL in new UI

Am 16/01/2017 um 21:43 schrieb Dave Townsend: One of the things I've been investigating since moving back to the desktop team is how we can remove XUL from the application as much as possible. The benefits for doing this are varied, some obvious examples: * XUL is a proprietary standard and we b

Re: Deprecating XUL in new UI

On 17/01/2017 12:34, zbranie...@mozilla.com wrote: > Our plan was to target post-quantum release to refactor the XUL code to > switch from DTD to L20n, but we could also just introduce the new approach > and use it for new code already, while waiting for post-quantum to transition > the old code

Re: Deprecating XUL in new UI

One more thing that XUL gives us is L10n. With HTML, we can use .properties to load localization resources and inject them into HTML, but I believe this to be a very inelegant solution with a surprisingly high risk of bugs. We do have an l10n framework called L20n that is supposed to replace DT

Re: Deprecating XUL in new UI

Hi Dave, I am glad that we are having this conversation. To be honest, two of features spinning in Taipei are already partly implemented in HTML, out of the expectations that, dealing with familiar tech means faster development and less regressions. They are - Desktop video control UI within htt

Re: Deprecating XUL in new UI

On Tue, Jan 17, 2017 at 11:41 AM, Sebastian Zartner < sebastianzart...@gmail.com> wrote: > https://bugzilla.mozilla.org/show_bug.cgi?id=740910 My comments in that bug still apply. Ellipsizing in the centre when the line contains more than just a single text node is really hard. Rob -- lbir ye,

Re: Deprecating XUL in new UI

On 1/16/2017 2:43 PM, Dave Townsend wrote: One of the things I've been investigating since moving back to the desktop team is how we can remove XUL from the application as much as possible. The benefits for doing this are varied, some obvious examples: * XUL is a proprietary standard and we bare

Re: Deprecating XUL in new UI

On 16 January 2017 at 23:08, Dave Townsend wrote: > Thanks for your feedback Jaroslav, it's really helpful. The issue around > mixing XUL and HTML is one in particular where I think we may end up having > to make some platform fixes to at least make the transition away from XUL > possible. > > On

Re: Deprecating XUL in new UI

Trees! I knew I was forgetting something, thank you. Yeah those are things we're going to need some sane replacements for. AS far as XBL goes, while I suspect it works from HTML documents I think we want to be phasing out use of XBL too for pretty much the same reasons as XUL. Web components seem

Re: Deprecating XUL in new UI

Thanks for your feedback Jaroslav, it's really helpful. The issue around mixing XUL and HTML is one in particular where I think we may end up having to make some platform fixes to at least make the transition away from XUL possible. On Mon, Jan 16, 2017 at 1:31 PM, Jaroslav Šnajdr wrote: > Hello

Re: Deprecating XUL in new UI

On Mon, Jan 16, 2017 at 1:33 PM, Mike Connor wrote: > I think the rule is fine, subject to the reality that the scope of totally > new doc-level UX is fairly limited. I think you'll want to be a little > more aggressive up front if you want to shift the overall codebase in > finite time. > > To

Re: Deprecating XUL in new UI

I think the rule is fine, subject to the reality that the scope of totally new doc-level UX is fairly limited. I think you'll want to be a little more aggressive up front if you want to shift the overall codebase in finite time. To that end, I'd propose an additional requirement that any major re

Re: Deprecating XUL in new UI

Hello Dave, while contributing to some of the devtools.html refactoring projects, I noticed the following further issues: - the XUL label element has attribute crop=start|center|end, which can be used to truncate the label text and insert an ellipsis character at the place of your choice. HTML do

Re: Deprecating XUL in new UI

On 1/16/17 9:43 PM, Dave Townsend wrote: > One of the things I've been investigating since moving back to the > desktop team is how we can remove XUL from the application as much as > possible. The necessary first step of reducing XUL use is to stop > adding any more UI that uses XUL and here I'm t

Re: Deprecating XUL in new UI

Trees are the big thing that come to mind. I've heard about three non-XUL re-implementations (IIRC mostly in devtools) which sounds like a maintainability issue and potentially redundancy. I would rather keep using XUL trees than have even more different tree implementations (though I'd be fine wit

Re: Deprecating XUL in new UI

On 01/16/2017 10:43 PM, Dave Townsend wrote: One of the things I've been investigating since moving back to the desktop team is how we can remove XUL from the application as much as possible. The benefits for doing this are varied, some obvious examples: * XUL is a proprietary standard and we ba

Deprecating XUL in new UI

One of the things I've been investigating since moving back to the desktop team is how we can remove XUL from the application as much as possible. The benefits for doing this are varied, some obvious examples: * XUL is a proprietary standard and we barely maintain it. * Shallower learning curve fo