Jorg K (CEST = GMT+2) Reporter
	Description • 6 years ago

In bug 1424601 we forked the preferences binding to C-C, but we should get rid of in in the long run.

In bug 1460721 we've switched some of the processing to use JS Preference, like in https://hg.mozilla.org/comm-central/rev/045dc8345aea#l3.59 and more call sites, and in bug 1465061 we switched to "prefs in tab".

So nothing is stopping us to drop the use of the binding. Sadly, looking at
https://hg.mozilla.org/mozilla-central/rev/0adedb70b788
this is a big job.

	alta88
	Comment 1 • 6 years ago

This is indeed a massive change, to mirror Fx preferences and its search feature etc. What is odd is that after all the iterations of Fx prefs UI changes, they are still using xul. The reason may be that the dtd replacement is not ready, but if so then xhtml pages could be used.  While we're at it, Account Manager should be integrated in this rewrite using the same methods (I know Bug 1096006 is doing the move of AM xul into the prefs tab).

Jorg, I have some familiarity with this as you know (meaning I've already done it in private builds based on Fx57), and am open to porting/upgrading to current state of prefs in Fx and Tb trunk. The end result would be:
- no xul in preferences and account manager, with the sole exception of nested folderpicker <menu> for now
- no xbl

The screenshot shows how it would look and demonstrates (for aceman ;)) that html is not necessarily any uglier than xul. Let me know if the Council is interested in this direction.

	Jorg K (CEST = GMT+2) Reporter
	Comment 2 • 6 years ago

Hi there ;-) - I'm not sure why this is a Council issue, it's more of an ESC (Engineering Steering Committee) issue. There's been much talk about this, but little action. I'd say the best way forward here would be to ask Magnus. On one hand, he's taken part in taking UI decisions, on the other hand, he will be in charge of future directions.

I quite like what I see and "no XUL/XBL" is certainly the way to go.

Also, let's throw in an NI for Philipp for good measure.

	:aceman
	Comment 3 • 6 years ago

Account manager does not need any urgent change just because preferences are changed, because it does not use the preferences.xml bindings that m-c already dropped and we just adopted until we can drop them too (after the rewrite here). It if there want to be any change, it can be in a separate bug as the 2 (former) dialogs are not related.

But if you see any fun in rewriting the AM and remove all XUL and XBL nobody can stop you :)
I think the screenshot demonstrates that HTML is ugly as the widgets are different than the ones in the application chrome (it seems to be Firefox), does not fit into the platform toolkit (I guess the app is more or less GTK3 on Linux, but the rendered AM page is just some random ad-hoc UI attempt not resembling any other app). But others seem to be fine with that. I'm more concerned about the code ugliness, as XUL was a library of common code and behaviours. I do not see what other library replaces it (that avoids open-coding all common behaviour), unless of course HTML is already in the state to be that library. So I'd be happy if you could prove me wrong and show what I'm missing! Thanks

	Richard Marti (:Paenglab)
	Comment 4 • 6 years ago

Looks good. It doesn't need to look like native widgets as it's in in-content and should look li8ke the other in-content prefs.

Alta88, only to be sure, are you planning to convert only the Account manager or the the other prefs too?

	alta88
	Comment 5 • 6 years ago

(In reply to :aceman from comment #3)
> 
> But if you see any fun in rewriting the AM and remove all XUL and XBL nobody
> can stop you :)

fun and profit ;)

> I think the screenshot demonstrates that HTML is ugly as the widgets are
> different than the ones in the application chrome (it seems to be Firefox),
> does not fit into the platform toolkit (I guess the app is more or less GTK3
> on Linux, but the rendered AM page is just some random ad-hoc UI attempt not
> resembling any other app). But others seem to be fine with that. I'm more
> concerned about the code ugliness, as XUL was a library of common code and
> behaviours. I do not see what other library replaces it (that avoids
> open-coding all common behaviour), unless of course HTML is already in the
> state to be that library. So I'd be happy if you could prove me wrong and
> show what I'm missing! Thanks

I guess I'm personally much less concerned about pixel level differences that look 'better' with xul than getting rid of a deprecated/deprecating library. And if you compare xul prefs in Tb with xul prefs in Fx with the html in the accounts page screenshot, I'd have to ask what differences you see. Meaning that UI look has already been implemented, ugly or not. And then I'd wonder what can't be prettied up about that with just css, to the point of a XUL Retro skin.. There isn't any reason the buttons (or anything else) in the html can't be made to look like the buttons in the chrome, platform specific, if we really want, no?

Even if no, ie core Fx doesn't respect platform look for chrome html whenever that comes, then I'd not stress about it.

And the use of a (xul) tree in current AM left side, and elsewhere in AM, is not a great design, imo.

	alta88
	Comment 6 • 6 years ago

(In reply to Richard Marti (:Paenglab) from comment #4)
> Looks good. It doesn't need to look like native widgets as it's in
> in-content and should look li8ke the other in-content prefs.
> 
> Alta88, only to be sure, are you planning to convert only the Account
> manager or the the other prefs too?

I'd propose to do both. I think it's really correct to be following Fx, like you have been, in things like prefs, and especially unifying AM with prefs. In this case, Tb would be ahead in moving out of xul by doing prefs too. Note that I used html <dialog> where one was needed. That tree is an implementation of the html infinite list.

	Magnus Melin [:mkmelin]
	Comment 7 • 6 years ago

(In reply to alta88 from comment #1)
> The screenshot shows how it would look and demonstrates (for aceman ;)) that
> html is not necessarily any uglier than xul. Let me know if the Council is
> interested in this direction.

Looks like a good direction to go if you ask me!

	:aceman
	Comment 8 • 6 years ago

(In reply to alta88 from comment #5)
> I guess I'm personally much less concerned about pixel level differences
> that look 'better' with xul than getting rid of a deprecated/deprecating
> library.

And I object the fact that it is considered deprecated, while there is no replacement.

> And if you compare xul prefs in Tb with xul prefs in Fx with the
> html in the accounts page screenshot, I'd have to ask what differences you
> see. Meaning that UI look has already been implemented, ugly or not.

So how does comparing 2 ugly things make the second one somehow less ugly?

> And
> then I'd wonder what can't be prettied up about that with just css, to the
> point of a XUL Retro skin.. There isn't any reason the buttons (or anything
> else) in the html can't be made to look like the buttons in the chrome,
> platform specific, if we really want, no?

No, why would we have to add css, while that is the job of the platform/toolkit/widget library?
 
> Even if no, ie core Fx doesn't respect platform look for chrome html
> whenever that comes, then I'd not stress about it.

Yeah, then we have a bright example to follow. Thanks for confirming my point :)
These pages are part of the application UI, not a random webpage.
You can already see the inconsistent mess with gloda tab, new account provisioner dialog. Now throw preferences and account manager into the mix?
 
> And the use of a (xul) tree in current AM left side, and elsewhere in AM, is
> not a great design, imo.

At least it is a common and familiar widget, not a flat list where there is no reason to click into, as in your screenshot (but for some reason the user is expected to, as those are the pref 'tabs').

	alta88
	Comment 9 • 6 years ago

(In reply to :aceman from comment #8)
> (In reply to alta88 from comment #5)
> > I guess I'm personally much less concerned about pixel level differences
> > that look 'better' with xul than getting rid of a deprecated/deprecating
> > library.
> 
> And I object the fact that it is considered deprecated, while there is no
> replacement.
> 

We could have a long discussion about this, but it will end with 'if you are proposing forking xul and maintaining it, forget it'.

> > And if you compare xul prefs in Tb with xul prefs in Fx with the
> > html in the accounts page screenshot, I'd have to ask what differences you
> > see. Meaning that UI look has already been implemented, ugly or not.
> 
> So how does comparing 2 ugly things make the second one somehow less ugly?
> 

You've missed the point that the xul and screenshot html in prefs look ugly *exactly* alike, so that ship has sailed. It doesn't seem to make sense to keep xul given that, or does it?

> > And
> > then I'd wonder what can't be prettied up about that with just css, to the
> > point of a XUL Retro skin.. There isn't any reason the buttons (or anything
> > else) in the html can't be made to look like the buttons in the chrome,
> > platform specific, if we really want, no?
> 
> No, why would we have to add css, while that is the job of the
> platform/toolkit/widget library?
>  
> > Even if no, ie core Fx doesn't respect platform look for chrome html
> > whenever that comes, then I'd not stress about it.
> 
> Yeah, then we have a bright example to follow. Thanks for confirming my
> point :)

I don't like everything Fx has done, but I'm honestly not offended by any of it. I personally prefer to follow Fx on this and as much as we absolutely can, and concentrate on messaging things, not UI wars. ;)

> These pages are part of the application UI, not a random webpage.
> You can already see the inconsistent mess with gloda tab, new account
> provisioner dialog. Now throw preferences and account manager into the mix?
>  

As you can see from this screenshot, the most offensive UI/UX in Tb - New Accounts setup - would look just like prefs and eliminate an inconsistency ;)

> > And the use of a (xul) tree in current AM left side, and elsewhere in AM, is
> > not a great design, imo.
> 
> At least it is a common and familiar widget, not a flat list where there is
> no reason to click into, as in your screenshot (but for some reason the user
> is expected to, as those are the pref 'tabs').

I know you object, but I'd really be interested in seeing even one or two other user complaints about the look of prefs.  People just don't spend their time looking at that enough to care, meaning it's not justifiable to maintain legacy widgets.

	Richard Marti (:Paenglab)
	Comment 10 • 6 years ago

I think bug 1460392 is a part of this conversion.

	Philipp Kewisch [:Fallen] [:📆][:🧩]
	Comment 11 • 6 years ago

Hello Folks, a reminder to be careful about phrasing and word choice. However "ugly" you may find something, if someone has put in a fair amount of work I would appreciate if you could offer constructive criticism instead.

In general, moving away from xul/xbl to a html page would be preferable. We should aim to mimic an os-native look using stylesheets accordingly, and I am sure we can achieve this together with the help of Paenglab and/or Arshad.