Re: Deprecating XUL in new UI

[R Kent James]

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 state of Washington to get teams of 
prisoners who are graduates of a computer education curriculum to 
contribute to open-source projects. I'm looking for a few projects that 
could have pedagogical value, and could be successfully pursued in an 
environment with severe restrictions such as a prison. The best projects 
have a large, well-defined backlog of similar projects that could be 
pursued after a particular skillset and set of tools is acquired. It 
seems to me like XUL to HTML conversion might fit this well.


I might be able to put together a team of around 5 people on this. Are 
you seriously interested in converting existing XUL to HTML such that 
you might have the patience to work with volunteers on this, and would 
accept patches that met your standards? I would serve as a filter so any 
issues that would be presented publicly would not be trivial hand holding.


I might start with a similar project in Thunderbird because I have 
better contacts there and it might be more approachable.


Are there any good examples of XUL to HTML conversions that have been 
done already? If not, would it be possible to get at least one official 
conversion done that could serve as an example of expected practice?


:rkent
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[Eric Shepherd]

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/ 
Blog: http://www.bitstampede.com/ 
Twitter: http://twitter.com/sheppy 

> On Jan 24, 2017, at 2:36 AM, zbranie...@mozilla.com wrote:
> 
> I can totally imagine us doing it for HTML.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[zbraniecki]

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 transition 
> to defining its UI in HTML, but could potentially be adopted by other 
> projects and platforms that use JavaScript and HTML to build apps (such as 
> Electron).

This is, by the way, what we're doing with Intl.

We're replacing all of our Intl APIs with TC39 ECMA402 backed Intl APIs (driven 
by CLDR) and when we find a limitation, we introduced a `mozIntl` chrome-only 
API which serves us as a place where we close the gap while maintaining future 
compatibility and at the same time we use it to test ideas for future ECMA402 
extensions.

This model has been received really well by TC39 so far and keeps us on a path 
with a multi-win:

1) We're aligned with the spec work
2) We're championing a lot of the spec work
3) We have a reason to believe that eventually, all of mozIntl will end up in 
ECMA402
4) Moving things from mozIntl into Intl once it gets into spec is easy

I can totally imagine us doing it for HTML.

zb.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[Eric Shepherd]

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 transition?

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 transition to 
defining its UI in HTML, but could potentially be adopted by other projects and 
platforms that use JavaScript and HTML to build apps (such as Electron).

If we can set a goal of getting a list of the features needed and spec out how 
we’d revise HTML to support those same functionalities (or at least 
functionalities that will get the job done), it would be good for everyone.

Eric Shepherd
Senior Technical Writer
Mozilla
https://developer.mozilla.org/ 
Blog: http://www.bitstampede.com/ 
Twitter: http://twitter.com/sheppy

> On Jan 23, 2017, at 11:12 AM, Boris Zbarsky  wrote:
> 
> 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 having to rewrite all our in-tree XBL in not-yet-existing 
> technologies would get in the way...
> 
> -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: Deprecating XUL in new UI

[Boris Zbarsky]

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 having to rewrite all our in-tree XBL in not-yet-existing 
technologies would get in the way...


-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[David Bolter]

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 replace it and riding
> the
> >> trains?
> >>
> >
> > No.
> >
>
>
> From the perspective of the platform, my general experience is that XBL is
> much, much more of a PITA than XUL itself. I would be very skeptical of a
> plan to start using some form of heavily-XBL-reliant HTML.
>
> I have generally ambivalent feelings towards XUL, but XBL cannot die fast
> enough.
>

Should (can) it die in the Quantum development timeframe?  What does that
do to shipping risk? I realize churn creates risk, but I seem to recall XBL
is getting in the way for Quantum styling?

Cheers,
David


>
> bholley
>
>
> >
> > -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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[David Bolter]

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
> HTML.
>

Thanks for bringing this up. There is almost no difference and we're
covered here.

Cheers,
D
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[Bryan Clark]

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 even more different tree implementations (though I'd be
> fine with a one or two simpler replacements since many uses of a xul:tree
> don't need a lot of the feature like nesting) which brings me to my next
> point:
>

I'd lean in on your point there even more.  Besides bookmarks which could
have lots of nesting I imagine most other implementations of tree views are
actually "doing it wrong" and could be using a simple list.  Some time with
UX might reveal a new way to display those things.  It might be worth
digging around to see how many trees really exist and if we could chop some
of that down.


What about XBL? Does it just work from XHTML documents? Is our
> implementation of Web Components ready to replace it and riding the trains?
> I think it would be good to implement drop-in replacements (or as close as
> possible) for some simple XBL bindings or native XUL elements to prove that
> Web Components are a replacement. Once the Web Component version is working
> we can transition to it everywhere. Perhaps something like 
> would be a good candidate.
>
> Matthew
>
> On Mon, Jan 16, 2017 at 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. The benefits for doing this are varied, some obvious examples:
>>
>> * XUL is a proprietary standard and we barely maintain it.
>> * Shallower learning curve for new contributors who may already know and
>> use HTML.
>> * HTML rendering is more optimized in the platform than XUL.
>> * Further integration of Servo code may require dropping XUL altogether.
>>
>> The necessary first step of reducing XUL use is to stop adding any more
>> UI that uses XUL and here I'm talking about wholly new UI, additions to
>> browser.xul and other existing UI are a separate concern. What do folks
>> think about making this a rule for new projects in the near future?
>>
>> Of course there are some features missing from HTML that make this
>> impossible in some cases right now. Some that I've already found:
>>
>> * HTML has no support for popup panels like XUL does. The devtools team
>> have been working around this but they are still dependent on XUL right now.
>> * iframe elements don't have the same capabilities that the XUL browser
>> element does and we use that in some UI.
>> * Top level menus on OSX are currently only able to be defined with XUL
>> elements. This only affects UI that uses top-level windows and most of our
>> new UI is in-content so may be less of an issue.
>>
>> What other features do we depend on in XUL that I haven't listed?
>>
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>>
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[zbraniecki]

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 
vanilla javascript.

Sticking as close to bare metal as possible, will allow us to solve our needs 
by improving the Web stack, instead of improving a particular framework.

Over time, if we're successful, we will not only create Firefox UI in HTML 
stack, but we'll enable others to create UI on the level of complexity of 
Firefox one's using the same stack.

If we go for an opinionated framework, we'll sort of lock ourselves in their 
technology, irrelevant how good it is. If 5 years from now, React will not be 
the best solution, we'll have a major challenge to migrate away from it, but as 
:brendan likes to say "Always bet on JS" - JS will be here and using JS will 
likely be the right choice for our high level glue code.

I'd also prefer to develop dependency-free libraries that we can contribute to 
the web world, than react plugins that we would contribute to react community 
only.

For that reason, I'd suggest we try to evaluate what needs to we really have 
that we believe react could solve - is it about data bindings? routing? 
components? and consider trying to find a minimal library that will solve those.

For example, vue seems to be much lighter and less opinionated, while polymer 
seems to be sticking closer to the vanilla web stack increasing the chance that 
we'll be able to eventually reduce our reliance on any framework as the web 
stack progresses.

zb.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[smaug]

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 the prototype can be used as such to generate document 
objects.

We don't have anything like that for html/xhtml documents, they are always 
loaded/parsed from scratch.
But, I wonder if we could use XUL documents with xhtml content. That should 
still use the prototype setup


-Olli




- Ryan


On Wed, Jan 18, 2017 at 12:50 AM, smaug  wrote:

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 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 for new contributors who may already know
and
use HTML.
* HTML rendering is more optimized in the platform than XUL.



But XUL has prototype cache which makes for parsing faster and opening
new
windows even faster
since one needs to just clone from the prototype, and not load anything.
So, be careful with the performance numbers.



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] landed as part of Firefox 7 in 2011).

So, an even more careful investigation / comparison is warranted. The
prototype cache might not currently be doing anything.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1286082
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=592943

- Ryan



those looks like about reading/writing to disk, not about the cache
itself, which should still help quite a bit with new window performance.
We did get significant performance regression when starting to use html
for...hm, was it about:newtab or about:home or what.

And https://bugzilla.mozilla.org/show_bug.cgi?id=1286082 is only about
some case, not all, as far as I see, but let me test.




Just tested and we seem to load for example
chrome://browser/content/browser.xul
chrome://global/content/editMenuOverlay.xul
chrome://browser/content/baseMenuOverlay.xul
chrome://browser/content/places/placesOverlay.xul
loaded chrome://layoutdebug/content/layoutdebug-overlay.xul
chrome://browser/content/report-phishing-overlay.xul
successfully when starting browser.
And once those are loaded, they don't need to be loaded again when opening
new windows.



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[smaug]

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 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 for new contributors who may already know and
use HTML.
* HTML rendering is more optimized in the platform than XUL.


But XUL has prototype cache which makes for parsing faster and opening new
windows even faster
since one needs to just clone from the prototype, and not load anything.
So, be careful with the performance numbers.


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] landed as part of Firefox 7 in 2011).

So, an even more careful investigation / comparison is warranted. The
prototype cache might not currently be doing anything.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1286082
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=592943

- Ryan



those looks like about reading/writing to disk, not about the cache itself, 
which should still help quite a bit with new window performance.
We did get significant performance regression when starting to use html 
for...hm, was it about:newtab or about:home or what.

And https://bugzilla.mozilla.org/show_bug.cgi?id=1286082 is only about some 
case, not all, as far as I see, but let me test.



Just tested and we seem to load for example
chrome://browser/content/browser.xul
chrome://global/content/editMenuOverlay.xul
chrome://browser/content/baseMenuOverlay.xul
chrome://browser/content/places/placesOverlay.xul
loaded chrome://layoutdebug/content/layoutdebug-overlay.xul
chrome://browser/content/report-phishing-overlay.xul
successfully when starting browser.
And once those are loaded, they don't need to be loaded again when opening new 
windows.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[smaug]

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
benefits for doing this are varied, some obvious examples:

* XUL is a proprietary standard and we barely maintain it.
* Shallower learning curve for new contributors who may already know and
use HTML.
* HTML rendering is more optimized in the platform than XUL.


But XUL has prototype cache which makes for parsing faster and opening new
windows even faster
since one needs to just clone from the prototype, and not load anything.
So, be careful with the performance numbers.


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] landed as part of Firefox 7 in 2011).

So, an even more careful investigation / comparison is warranted. The
prototype cache might not currently be doing anything.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1286082
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=592943

- Ryan



those looks like about reading/writing to disk, not about the cache itself, 
which should still help quite a bit with new window performance.
We did get significant performance regression when starting to use html 
for...hm, was it about:newtab or about:home or what.

And https://bugzilla.mozilla.org/show_bug.cgi?id=1286082 is only about some 
case, not all, as far as I see, but let me test.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[smaug]

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 much the same reasons as
XUL. Web components seem like an obvious alternative and I understand that
they are only preffed off right now. If we can have them work in chrome
documents they could be the right replacement.


The Shadow DOM implementation v0 we have in tree will be replaced with v1. 
Those aren't quite compatible in
API level. We must not pref on the current shadow DOM implementation.




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 even more different tree implementations (though I'd be
fine with a one or two simpler replacements since many uses of a xul:tree
don't need a lot of the feature like nesting) which brings me to my next
point:

What about XBL? Does it just work from XHTML documents? Is our
implementation of Web Components ready to replace it and riding the trains?
I think it would be good to implement drop-in replacements (or as close as
possible) for some simple XBL bindings or native XUL elements to prove that
Web Components are a replacement. Once the Web Component version is working
we can transition to it everywhere. Perhaps something like 
would be a good candidate.

Matthew

On Mon, Jan 16, 2017 at 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. The benefits for doing this are varied, some obvious examples:

* XUL is a proprietary standard and we barely maintain it.
* Shallower learning curve for new contributors who may already know and
use HTML.
* HTML rendering is more optimized in the platform than XUL.
* Further integration of Servo code may require dropping XUL altogether.

The necessary first step of reducing XUL use is to stop adding any more
UI that uses XUL and here I'm talking about wholly new UI, additions to
browser.xul and other existing UI are a separate concern. What do folks
think about making this a rule for new projects in the near future?

Of course there are some features missing from HTML that make this
impossible in some cases right now. Some that I've already found:

* HTML has no support for popup panels like XUL does. The devtools team
have been working around this but they are still dependent on XUL right now.
* iframe elements don't have the same capabilities that the XUL browser
element does and we use that in some UI.
* Top level menus on OSX are currently only able to be defined with XUL
elements. This only affects UI that uses top-level windows and most of our
new UI is in-content so may be less of an issue.

What other features do we depend on in XUL that I haven't listed?

___
firefox-dev mailing list
firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev






___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[Gijs Kruitbosch]

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.





From the perspective of the platform, my general experience is that XBL is

much, much more of a PITA than XUL itself. I would be very skeptical of a
plan to start using some form of heavily-XBL-reliant HTML.

I have generally ambivalent feelings towards XUL, but XBL cannot die fast
enough.


As both of you are aware, I am (very) sympathetic to this sentiment, but 
we'll need a replacement of some sort. In toplevel chrome, we can in 
theory use some kind of JS framework (like React, or something else). 
However, that doesn't really solve things like the video controls (which 
we embed into content  elements).


What can we do in this space if Web Components is not the answer? Like, 
can we (and I'm thinking out loud here) build a system where we get 
handed the native anon container element in a script (js component 
createinstance + init with a param, if we need something existing to 
piggyback on) that has its own context (and ideally, some way to load 
more script)?


If there isn't a reasonable other answer, what's the rough timeframe for 
web components to be more feasible (maybe only in chrome and/or in 
native anon content (because video controls...)) ) - weeks, months, 
years, decades ? :-)


~ Gijs
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[Brian Grinstead]

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  and  elements.  We didn't 
need to worry about top-level menus or overlays though.
3) Not impossible but needed a replacement for  /  elements for 
registering keyboard shortcuts.
4) Not impossible but agree with Jarda about mixing XUL and HTML flex - many of 
the bugs blocking the de-XUL meta 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1263741) were layout issues 
created when an individual UI component was converted, and finding workarounds 
can be time consuming and require trial and error.

For 1 and 2, in our case it was worth changing the frontend to use new modules 
even though they are ultimately still relying on XUL.  That let us provide an 
HTML shim when running the panel in a content tab, and hopefully will let us 
change the implementation if/when there are ways to do it without XUL.

Brian

> On Jan 16, 2017, at 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. The 
> benefits for doing this are varied, some obvious examples:
> 
> * XUL is a proprietary standard and we barely maintain it.
> * Shallower learning curve for new contributors who may already know and use 
> HTML.
> * HTML rendering is more optimized in the platform than XUL.
> * Further integration of Servo code may require dropping XUL altogether.
> 
> The necessary first step of reducing XUL use is to stop adding any more UI 
> that uses XUL and here I'm talking about wholly new UI, additions to 
> browser.xul and other existing UI are a separate concern. What do folks think 
> about making this a rule for new projects in the near future?
> 
> Of course there are some features missing from HTML that make this impossible 
> in some cases right now. Some that I've already found:
> 
> * HTML has no support for popup panels like XUL does. The devtools team have 
> been working around this but they are still dependent on XUL right now.
> * iframe elements don't have the same capabilities that the XUL browser 
> element does and we use that in some UI.
> * Top level menus on OSX are currently only able to be defined with XUL 
> elements. This only affects UI that uses top-level windows and most of our 
> new UI is in-content so may be less of an issue.
> 
> What other features do we depend on in XUL that I haven't listed?
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[Kris Maglione]

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] landed as part of Firefox 7 in 2011).

So, an even more careful investigation / comparison is warranted. The
prototype cache might not currently be doing anything.


I've recently run into multiple bugs (mostly timing bugs) that 
only show up after we flush the prototype cache and have to do a 
fresh load, so I can say with fair certainty that it is doing 
something.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[J. Ryan Stinnett]

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, some obvious examples:
>>
>> * XUL is a proprietary standard and we barely maintain it.
>> * Shallower learning curve for new contributors who may already know and
>> use HTML.
>> * HTML rendering is more optimized in the platform than XUL.
>
> But XUL has prototype cache which makes for parsing faster and opening new
> windows even faster
> since one needs to just clone from the prototype, and not load anything.
> So, be careful with the performance numbers.

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] landed as part of Firefox 7 in 2011).

So, an even more careful investigation / comparison is warranted. The
prototype cache might not currently be doing anything.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1286082
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=592943

- Ryan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[J. Ryan Stinnett]

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 of the way here. It offers features like:

* same chrome / content separation that we have with 
* content loads in separate process, like 
* window.top, etc. work as web content expects them to
* message manager available to load frame scripts, send messages, etc.
* access to docshell, etc. from chrome scripts
* BrowserElement API[2] is available (unclear if desktop actually
wants this API)

It's not really a drop in replacement for  (but I would
guess we don't want it to be anyway, if we hope to reduce XBL usage):

* XBL things like browser.xml aren't used, so many properties from
 aren't present
* browser group frame scripts aren't currently loaded automatically

At the moment, it's only used on desktop by DevTools to implement the
Responsive Design Mode.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1238160
[2]: 
http://searchfox.org/mozilla-central/source/dom/webidl/BrowserElement.webidl

- Ryan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[Jaroslav Šnajdr]

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:

> 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, nor do I see anything obvious in
> the event code that would cause such a thing to happen.  Are you sure this
> is the behavior you're seeing (as opposed to the "dispatch to the chrome
> event target when reaching a window" behavior which we _do_ have and which
> is not XUL-specific, but rather chrome-docshell specific)?
>
> -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: Deprecating XUL in new UI

[Bobby Holley]

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 of the platform, my general experience is that XBL is
much, much more of a PITA than XUL itself. I would be very skeptical of a
plan to start using some form of heavily-XBL-reliant HTML.

I have generally ambivalent feelings towards XUL, but XBL cannot die fast
enough.

bholley


>
> -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: Deprecating XUL in new UI

[Boris Zbarsky]

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, nor do I see anything obvious in 
the event code that would cause such a thing to happen.  Are you sure 
this is the behavior you're seeing (as opposed to the "dispatch to the 
chrome event target when reaching a window" behavior which we _do_ have 
and which is not XUL-specific, but rather chrome-docshell specific)?


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[Boris Zbarsky]

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.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[Brian Grinstead]

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 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 DTD and 
> works in raw XUL and HTML binding elements to l10n messages with 
> `data-l10n-id` attribute.
> 
> 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.
> 
> zb.
> ___
> 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: Deprecating XUL in new UI

[zbraniecki]

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 DTD and 
works in raw XUL and HTML binding elements to l10n messages with `data-l10n-id` 
attribute.

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.

zb.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[Tim Guan-tin Chien]

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 
https://bugzilla.mozilla.org/show_bug.cgi?id=1271765
- The date/time picker to popup from  and  https://bugzilla.mozilla.org/show_bug.cgi?id=888320

Things are obviously not as perfect as we would have imagined. I would
say the outstanding complications learned are the quirks of the XUL
embedder. The video control is implemented in HTML but within a XUL
anno node. The pickers are implemented in an XHTML embedded inside an
xul:panel > xul:iframe. By looking at the
patches/follow-up/regressions there you will see how much code would
still be live inside XBL (e.g. event forwarding), and one unfortunate
layout surprise (bug 173).

We would need to look at that more broadly to achieve the goal stated.
That could even mean re-invest in some XUL layout features if we must.

Within HTML, a longer discussion is needed (and intentional decisions
outside of HTML features) on how components in HTML should work. Gaia
was started in 2011 and became hard to work with quickly due to
various reasons, and compartmentalization being one of the biggest. I
will stop here as an effort of stop beating the dead horse.

DevTools team is using React. We should be ready to make a similar
decision when we need to — single-page-web-app needs a committed way
of compartmentalization to stay sane, i.e. something (platform feature
or not) is needed here to replace XBL.

Yeah, the Web Components. I've been hearing about this ever since my
employment in Mozilla. Yet, around 2015, I was told the current
pref-off implementation will likely be changed as the spec matures so
front-end should not build anything on top of it. I don't know if the
status has changed but I will personally back away from it before I am
given a strong commitment from the platform engineering.

Feel free to reach out. Thanks,


Tim


On Tue, Jan 17, 2017 at 4:43 AM, 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 barely maintain it.
> * Shallower learning curve for new contributors who may already know and use
> HTML.
> * HTML rendering is more optimized in the platform than XUL.
> * Further integration of Servo code may require dropping XUL altogether.
>
> The necessary first step of reducing XUL use is to stop adding any more UI
> that uses XUL and here I'm talking about wholly new UI, additions to
> browser.xul and other existing UI are a separate concern. What do folks
> think about making this a rule for new projects in the near future?
>
> Of course there are some features missing from HTML that make this
> impossible in some cases right now. Some that I've already found:
>
> * HTML has no support for popup panels like XUL does. The devtools team have
> been working around this but they are still dependent on XUL right now.
> * iframe elements don't have the same capabilities that the XUL browser
> element does and we use that in some UI.
> * Top level menus on OSX are currently only able to be defined with XUL
> elements. This only affects UI that uses top-level windows and most of our
> new UI is in-content so may be less of an issue.
>
> What other features do we depend on in XUL that I haven't listed?
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[Robert O'Callahan]

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,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[Joshua Cranmer ]

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 barely maintain it.
* Shallower learning curve for new contributors who may already know and
use HTML.
* HTML rendering is more optimized in the platform than XUL.
* Further integration of Servo code may require dropping XUL altogether.

The necessary first step of reducing XUL use is to stop adding any more UI
that uses XUL and here I'm talking about wholly new UI, additions to
browser.xul and other existing UI are a separate concern. What do folks
think about making this a rule for new projects in the near future?

Of course there are some features missing from HTML that make this
impossible in some cases right now. Some that I've already found:

* HTML has no support for popup panels like XUL does. The devtools team
have been working around this but they are still dependent on XUL right now.
* iframe elements don't have the same capabilities that the XUL browser
element does and we use that in some UI.
* Top level menus on OSX are currently only able to be defined with XUL
elements. This only affects UI that uses top-level windows and most of our
new UI is in-content so may be less of an issue.

What other features do we depend on in XUL that I haven't listed?


XUL trees are probably the most complex feature that HTML doesn't have. 
Some of its features that I consider important include the use of an 
nsITreeView-like generative interface, advanced styling capabilities 
(you can style rows/cells based on content, effectively), lazy loading 
(in particular, data for child elements isn't asked for until their 
parents are expanded). There's also probably performance aspects and 
accessibility factors that don't normally feature in the minds of 
developers.


XUL overlays and XBL widgets are also things that are likely to be 
missed, although Web Components probably largely covers the same feature 
space (I don't know enough to know what is missing).


The final point I would make is that we probably need to pick a standard 
widget toolkit. I believe in the past, we were shipping 4 different 
versions of jQuery because every little frontend silo was importing it 
locally for their own needs. Particularly if we need to reimplement 
major widgets like , it makes much more sense to have one 
shared implementation that can be collaboratively improved. And put it 
in toolkit/, please, not browser/. :-)



--
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: Deprecating XUL in new UI

[Dave Townsend]

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 like an obvious alternative and I understand that
they are only preffed off right now. If we can have them work in chrome
documents they could be the right replacement.

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 even more different tree implementations (though I'd be
> fine with a one or two simpler replacements since many uses of a xul:tree
> don't need a lot of the feature like nesting) which brings me to my next
> point:
>
> What about XBL? Does it just work from XHTML documents? Is our
> implementation of Web Components ready to replace it and riding the trains?
> I think it would be good to implement drop-in replacements (or as close as
> possible) for some simple XBL bindings or native XUL elements to prove that
> Web Components are a replacement. Once the Web Component version is working
> we can transition to it everywhere. Perhaps something like 
> would be a good candidate.
>
> Matthew
>
> On Mon, Jan 16, 2017 at 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. The benefits for doing this are varied, some obvious examples:
>>
>> * XUL is a proprietary standard and we barely maintain it.
>> * Shallower learning curve for new contributors who may already know and
>> use HTML.
>> * HTML rendering is more optimized in the platform than XUL.
>> * Further integration of Servo code may require dropping XUL altogether.
>>
>> The necessary first step of reducing XUL use is to stop adding any more
>> UI that uses XUL and here I'm talking about wholly new UI, additions to
>> browser.xul and other existing UI are a separate concern. What do folks
>> think about making this a rule for new projects in the near future?
>>
>> Of course there are some features missing from HTML that make this
>> impossible in some cases right now. Some that I've already found:
>>
>> * HTML has no support for popup panels like XUL does. The devtools team
>> have been working around this but they are still dependent on XUL right now.
>> * iframe elements don't have the same capabilities that the XUL browser
>> element does and we use that in some UI.
>> * Top level menus on OSX are currently only able to be defined with XUL
>> elements. This only affects UI that uses top-level windows and most of our
>> new UI is in-content so may be less of an issue.
>>
>> What other features do we depend on in XUL that I haven't listed?
>>
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[Dave Townsend]

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 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 doesn't have this - ellipsis can be inserted
> only at the end, and after doing some RTL magic, also at the start (but not
> 100% bug-free). The "center" option is not available at all. Solving this
> in CSS would be a really nice addition to the web platform. There's been
> some spec work done by Sebastian Zartner few years ago.
>
> - 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. This
> causes problems for React and its event system, which relies on the HTML
> behavior. This can be solved by patching React, or adding a special flag to
> the iframe element.
>
> - when there are elements from both XUL and HTML namespaces inside one XUL
> document (happens when doing incremental migration), it can be challenging
> to make flex-like layouts work correctly. The standard flex layout and the
> XUL flex (-moz-box) interact in ways that are hard to understand.
>
> Jarda
>
>
>
> On Mon, Jan 16, 2017 at 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 benefits for doing this are varied, some obvious examples:
>>
>> * XUL is a proprietary standard and we barely maintain it.
>> * Shallower learning curve for new contributors who may already know and
>> use HTML.
>> * HTML rendering is more optimized in the platform than XUL.
>> * Further integration of Servo code may require dropping XUL altogether.
>>
>> The necessary first step of reducing XUL use is to stop adding any more
>> UI that uses XUL and here I'm talking about wholly new UI, additions to
>> browser.xul and other existing UI are a separate concern. What do folks
>> think about making this a rule for new projects in the near future?
>>
>> Of course there are some features missing from HTML that make this
>> impossible in some cases right now. Some that I've already found:
>>
>> * HTML has no support for popup panels like XUL does. The devtools team
>> have been working around this but they are still dependent on XUL right now.
>> * iframe elements don't have the same capabilities that the XUL browser
>> element does and we use that in some UI.
>> * Top level menus on OSX are currently only able to be defined with XUL
>> elements. This only affects UI that uses top-level windows and most of our
>> new UI is in-content so may be less of an issue.
>>
>> What other features do we depend on in XUL that I haven't listed?
>>
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[Dave Townsend]

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 that end, I'd propose an additional requirement that any major refactor
> or redesign of in-content or separate-window UI (i.e. I've heard rumblings
> of a pending preferences redesign) should move to HTML if possible.  If
> it's not possible, the relevant issues should be filed and tracked as a
> condition of waiving the refactor requirement.  (I think it's a module
> owner call whether to waive, since getting off XUL is likely going to
> matter more in another year or two.)
>

Yeah that makes a lot of sense. Of course as with any rule we make I expect
there to be small cases where we have to waive at least at first.

On your bullet points, I think the main blocker to moving everything to at
> least mostly-HTML outside of browser.xul is going to be the top-level menu
> issue.  That might be a good test case for a new Web Component binding, to
> follow on from MattN's thinking.
>
> -- Mike
>
> On Mon, Jan 16, 2017 at 3: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 barely maintain it.
>> * Shallower learning curve for new contributors who may already know and
>> use HTML.
>> * HTML rendering is more optimized in the platform than XUL.
>> * Further integration of Servo code may require dropping XUL altogether.
>>
>> The necessary first step of reducing XUL use is to stop adding any more
>> UI that uses XUL and here I'm talking about wholly new UI, additions to
>> browser.xul and other existing UI are a separate concern. What do folks
>> think about making this a rule for new projects in the near future?
>>
>> Of course there are some features missing from HTML that make this
>> impossible in some cases right now. Some that I've already found:
>>
>> * HTML has no support for popup panels like XUL does. The devtools team
>> have been working around this but they are still dependent on XUL right now.
>> * iframe elements don't have the same capabilities that the XUL browser
>> element does and we use that in some UI.
>> * Top level menus on OSX are currently only able to be defined with XUL
>> elements. This only affects UI that uses top-level windows and most of our
>> new UI is in-content so may be less of an issue.
>>
>> What other features do we depend on in XUL that I haven't listed?
>>
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[Mike Connor]

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 refactor
or redesign of in-content or separate-window UI (i.e. I've heard rumblings
of a pending preferences redesign) should move to HTML if possible.  If
it's not possible, the relevant issues should be filed and tracked as a
condition of waiving the refactor requirement.  (I think it's a module
owner call whether to waive, since getting off XUL is likely going to
matter more in another year or two.)

On your bullet points, I think the main blocker to moving everything to at
least mostly-HTML outside of browser.xul is going to be the top-level menu
issue.  That might be a good test case for a new Web Component binding, to
follow on from MattN's thinking.

-- Mike

On Mon, Jan 16, 2017 at 3: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 barely maintain it.
> * Shallower learning curve for new contributors who may already know and
> use HTML.
> * HTML rendering is more optimized in the platform than XUL.
> * Further integration of Servo code may require dropping XUL altogether.
>
> The necessary first step of reducing XUL use is to stop adding any more UI
> that uses XUL and here I'm talking about wholly new UI, additions to
> browser.xul and other existing UI are a separate concern. What do folks
> think about making this a rule for new projects in the near future?
>
> Of course there are some features missing from HTML that make this
> impossible in some cases right now. Some that I've already found:
>
> * HTML has no support for popup panels like XUL does. The devtools team
> have been working around this but they are still dependent on XUL right now.
> * iframe elements don't have the same capabilities that the XUL browser
> element does and we use that in some UI.
> * Top level menus on OSX are currently only able to be defined with XUL
> elements. This only affects UI that uses top-level windows and most of our
> new UI is in-content so may be less of an issue.
>
> What other features do we depend on in XUL that I haven't listed?
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[Jaroslav Šnajdr]

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 doesn't have this - ellipsis can be inserted
only at the end, and after doing some RTL magic, also at the start (but not
100% bug-free). The "center" option is not available at all. Solving this
in CSS would be a really nice addition to the web platform. There's been
some spec work done by Sebastian Zartner few years ago.

- 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. This
causes problems for React and its event system, which relies on the HTML
behavior. This can be solved by patching React, or adding a special flag to
the iframe element.

- when there are elements from both XUL and HTML namespaces inside one XUL
document (happens when doing incremental migration), it can be challenging
to make flex-like layouts work correctly. The standard flex layout and the
XUL flex (-moz-box) interact in ways that are hard to understand.

Jarda



On Mon, Jan 16, 2017 at 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
> benefits for doing this are varied, some obvious examples:
>
> * XUL is a proprietary standard and we barely maintain it.
> * Shallower learning curve for new contributors who may already know and
> use HTML.
> * HTML rendering is more optimized in the platform than XUL.
> * Further integration of Servo code may require dropping XUL altogether.
>
> The necessary first step of reducing XUL use is to stop adding any more UI
> that uses XUL and here I'm talking about wholly new UI, additions to
> browser.xul and other existing UI are a separate concern. What do folks
> think about making this a rule for new projects in the near future?
>
> Of course there are some features missing from HTML that make this
> impossible in some cases right now. Some that I've already found:
>
> * HTML has no support for popup panels like XUL does. The devtools team
> have been working around this but they are still dependent on XUL right now.
> * iframe elements don't have the same capabilities that the XUL browser
> element does and we use that in some UI.
> * Top level menus on OSX are currently only able to be defined with XUL
> elements. This only affects UI that uses top-level windows and most of our
> new UI is in-content so may be less of an issue.
>
> What other features do we depend on in XUL that I haven't listed?
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[Philipp Kewisch]

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 talking about wholly
> new UI, additions to browser.xul and other existing UI are a separate
> concern. What do folks think about making this a rule for new
> projects in the near future?
> 
> Of course there are some features missing from HTML that make this 
> impossible in some cases right now.

I think this would be a great step forward and help towards getting rid
of XUL. Thanks for kicking this off. One of the roadblocks I have had in
XUL applications where I was meaning to port to HTML is the decision on
what framework, if at all, to use.

I know devtools has been making heavy use of react, and I can see other
components following this lead. This is of course a pretty strong
dependency, with the usual caveats of using an external dependency.

Aside from XUL you should also make a recommendation for XBL
replacements, as widgets are fairly commonly used. React allows for
creating widgets, another alternative would be web components. I have
seen some progress there lately but am also aware the spec is still
somewhat in flux. Nevertheless, I think using web components would
better allow sticking to native web technologies (and it is also my
personal preference).

Anyway, if you make HTML a requirement for new features, I think you
also need to provide some direction on the framework to use, or if we
should be sticking to the built-in tech instead.

Philipp
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[Matthew N.]

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 with a one or two simpler replacements since many uses of a xul:tree
don't need a lot of the feature like nesting) which brings me to my next
point:

What about XBL? Does it just work from XHTML documents? Is our
implementation of Web Components ready to replace it and riding the trains?
I think it would be good to implement drop-in replacements (or as close as
possible) for some simple XBL bindings or native XUL elements to prove that
Web Components are a replacement. Once the Web Component version is working
we can transition to it everywhere. Perhaps something like 
would be a good candidate.

Matthew

On Mon, Jan 16, 2017 at 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. The
> benefits for doing this are varied, some obvious examples:
>
> * XUL is a proprietary standard and we barely maintain it.
> * Shallower learning curve for new contributors who may already know and
> use HTML.
> * HTML rendering is more optimized in the platform than XUL.
> * Further integration of Servo code may require dropping XUL altogether.
>
> The necessary first step of reducing XUL use is to stop adding any more UI
> that uses XUL and here I'm talking about wholly new UI, additions to
> browser.xul and other existing UI are a separate concern. What do folks
> think about making this a rule for new projects in the near future?
>
> Of course there are some features missing from HTML that make this
> impossible in some cases right now. Some that I've already found:
>
> * HTML has no support for popup panels like XUL does. The devtools team
> have been working around this but they are still dependent on XUL right now.
> * iframe elements don't have the same capabilities that the XUL browser
> element does and we use that in some UI.
> * Top level menus on OSX are currently only able to be defined with XUL
> elements. This only affects UI that uses top-level windows and most of our
> new UI is in-content so may be less of an issue.
>
> What other features do we depend on in XUL that I haven't listed?
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[smaug]

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 barely maintain it.
* Shallower learning curve for new contributors who may already know and
use HTML.
* HTML rendering is more optimized in the platform than XUL.


But XUL has prototype cache which makes for parsing faster and opening new 
windows even faster
since one needs to just clone from the prototype, and not load anything.
So, be careful with the performance numbers.



* Further integration of Servo code may require dropping XUL altogether.

The necessary first step of reducing XUL use is to stop adding any more UI
that uses XUL and here I'm talking about wholly new UI, additions to
browser.xul and other existing UI are a separate concern. What do folks
think about making this a rule for new projects in the near future?

Of course there are some features missing from HTML that make this
impossible in some cases right now. Some that I've already found:

* HTML has no support for popup panels like XUL does. The devtools team
have been working around this but they are still dependent on XUL right now.
* iframe elements don't have the same capabilities that the XUL browser
element does and we use that in some UI.
* Top level menus on OSX are currently only able to be defined with XUL
elements. This only affects UI that uses top-level windows and most of our
new UI is in-content so may be less of an issue.

What other features do we depend on in XUL that I haven't listed?


templates? xul:tree? I guess both those can be implemented in JS too, just 
possibly not as efficiently.



-Olli
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform