Planning the Future of Complete Themes

I think it might be a really interesting idea to have an abstract model of the browser UI in terms of a DOM structure and let you style it using CSS. That adds a good abstraction layer between the actual XUL-now/HTML-later/maybe-native implementation and the theming model.

What I don’t know is what that means for things like icons. Would you also style those using CSS?

I’d be really excited for somebody to propose some strawman ideas for how this would work.

But it’s also a lot of engineering, and so we want to be very careful about the overall complexity of the system. One primary goal here is to reduce both our API surfaces and the total amount of code so that we can properly maintain what’s left.

This entire approach of building the UI in XUL and styling it with CSS is the root of the problem, isn’t it?

Adding a layer of abstraction will achieve two things: a lack of fine-grained control over the styling, and even more code to maintain. Every time the implementation (XUL/HTML/native) is changed, the abstraction layer will have to be updated as well. Any abstraction layer will have to make some assumptions, some of which are bound to be problematic later on. Layers of abstraction also eat up CPU cycles, unless we’re talking about a translation/compilation engine, and that would be even more code to develop and maintain.

You know what makes XUL/CSS slow, as it’s currently implemented? The unlimited possibilities. Themers can add any number of expensive CSS selectors and styles and the rendering engine has to support all that, leading to the laggy performance that’s been plaguing the Firefox UI since what, 1956? I mean, on my i7/GTX 680/16GB system, I can actually see the different elements pop in one by one when I open developer tools.

The key to performance in any system is to simplify, reduce, strip things down to essentials. A whole lot of themability could be achieved by providing control over only the following properties:

  • Order (some people like tabs below the URL bar, some like them above)
  • Size
  • Visibility
  • Font
  • Padding around elements
  • Background color/gradient
  • Foreground color
  • Border width, radius and style (solid, inset, outset)

All of these options could be implemented as color pickers/sliders/drag-and-drop widgets, which would mean that users would have a lot more control over the look and feel of their Firefox instead of having to find the theme that comes closest to their needs.

Users should be able to specify their own icons as SVG files. Being vector glyphs rather than bitmaps, these can be styled using the properties listed above. There should be options to display icon+text, text only, or icon only.

There needs to be a way to define the appearance of a given widget. So if I want text input fields to be a certain style, that style should apply to all text fields within the UI. The same applies to fieldsets, trees, lists, etc.

There should be a way to reset the styling of an element, so that themers can specify only the properties that they want to style, instead of overriding a bunch of predefined styles using extremely convoluted selectors. Over time Firefox’s styles have gotten more and more bloated, meaning that themers have to reset a bunch of properties one by one. It’s insane that code like this should ever have to be written:

#tabbrowser-tabs[movingtab] > .tabbrowser-tab[beforeselected]:not([last-visible-tab])::after, .tabbrowser-tab:not([selected]):not([afterselected-visible]):not([afterhovered]):not([first-visible-tab]):not(:hover)::before, #tabbrowser-tabs:not([overflow]) > .tabbrowser-tab[last-visible-tab]:not([selected]):not([beforehovered]):not(:hover)::after { -moz-margin-start: -1.5px!important; -moz-margin-end: -1.5px!important; background-image: none)!important; background-position: left bottom 1px!important; background-repeat: no-repeat!important; background-size: 3px 100%!important; content: ""!important; display: -moz-box!important; width: 3px!important; }

And do not, for the love of all that’s holy, mix native UI components with a themable UI. The last thing anyone wants to see is ugly, unthemeable widgets all over their streamlined theme. The sheer number of solutions out there for styling form elements on web pages should be all the evidence anyone needs to understand this.

1 Like

Limiting what properties can be changed won’t speed it up - it’s still going through the CSS parser and being rendered by the engine.
Plus, it dismisses the notion that a Complete Theme can be lighter and faster than the Default theme, which isn’t terribly difficult with all its gradients and masks.

I agree about the rule resetting thing, although if we can only adjust minor things that’s moot.
If there were previous mention of us retaining CSS ability, I would have suggested a stylesheet sitting between global.css and the theme’s CSS. It would set some sane defaults but wouldn’t have things like borders and gradients. Your two choices as a Complete Theme dev at the moment are ‘re-implement everything’ or ‘override everything’, and a solid, less specific base would make both of those tasks easier. But that’s more about current Complete Themes.

Limiting what properties can be changed won’t speed it up - it’s still going through the CSS parser and being rendered by the engine.

We know that a lot of CSS properties are expensive - most animations, box-shadows and text-shadows, for instance. If the parsing/rendering engine didn’t have to account for those properties it would be a lot faster. Just like asm.js has better performance than plain Javascript (which it is a subset of) “by limiting language features to those amenable to ahead-of-time optimization.”

Plus, it dismisses the notion that a Complete Theme can be lighter and faster than the Default theme, which isn’t terribly difficult with all its gradients and masks.

That’s not what I’m saying at all. I use a complete theme (my own) which is very very lightweight. However, when you have to override a lot of extremely specific and CPU-heavy selectors like the one in my previous post, the rendering engine still has to parse those selectors and properties and they still have an impact on performance.

The more I think about it, the more I believe that the best way forward would be to have the UI engine only support a subset of high-performance selectors and properties, and keeping the UI XUL sane, simple and stable. The plugin ecosystem stays untouched, users are happy, addon developers are happy.

Let’s be honest, tabs would be just fine defined like this:

<tab>
    <image class="tab-throbber" />
    <label class="tab-label"></label>
    <button class="tab-close-button"></button>
</tab>

instead of this:

<tab class="tabbrowser-tab">
    <xul:stack class="tab-stack">
        <xul:hbox class="tab-background">
            <xul:hbox class="tab-background-start">
                _moz_generated_content_before
                _moz_generated_content_after
            </xul:hbox>
            <xul:hbox class="tab-background-middle">
            </xul:hbox>
            <xul:hbox class="tab-background-end">
                _moz_generated_content_before
                _moz_generated_content_after
            </xul:hbox>
        </xul:hbox>
        <xul:hbox class="tab-content">
            <xul:image class="tab-throbber" />
            <xul:image class="tab-icon-image" />
            <xul:image class="tab-icon-image" />
            <xul:image class="tab-icon-overlay" />
            <xul:label class="tab-label">
            <xul:image class="tab-icon-sound" />
            <xul:toolbarbutton class="tab-close-button close-icon">
                <xul:image class="toolbarbutton-icon" />
            </xul:toolbarbutton>
        </xul:hbox>
    </xul:stack>
</tab>

HTML+CSS: I think this would even out most of the differences between XUL and HTML: both can be styled by means of CSS, can’t they? Not all the differences: indeed, element names are accessible to CSS, and for instance elements like <vbox> or <hbox> don’t exist in HTML: I guess that most of the time these particular elements would become <DIV> or <TABLE> with some appropriate attributes and contents; and with ID and Class names not necessarily used elsewhere in Mozilla code, but serving as hooks for theming. XHTML would presumably remain supported, but the XUL namespace might become deprecated at first, and at a later time dropped… or would it? Maybe the decision to really drop it completely (or not) could be left for later?
Icons… Their background color is quite easy to theme via CSS, and the simple themes might be content with that, or maybe even with keeping icons the same as in the default theme. More ambitious authors will certainly want to altogether replace the icon pictures: does CSS allow that? If (as I think) it doesn’t, some mechanism, maybe (let’s dream) some ::-moz-replaced pseudo-element, should be found. But how should we define its properties? -moz-image maybe? Or shall we fall back on overlays like those we already use? The latter would not involve new standards, but it would jump outside of CSS.
If CSS doesn’t prove equal to the task, what should we do? Use XHTML (which can be regarded as either HTML or XML) for all our chrome, and allow XSL styling? I have no idea whatsoever of what XSL can and can’t do; all I know is that its supposed to be a “stylesheet language” and that it is has different (maybe more powerful) use cases than CSS. So I’m just tossing this idea into the air; let other people evaluate it.

That doesn’t seems to provide any control over background-start background-middle background-end, icon-image, icon-overlay and icon sound, so it’s clearly not enough.

Some of those selectors are very useful if you want to change the tabs appearance, with your option all themes will be just some icons and colors but everything else will look the same.

with your option all themes will be just some icons and colors but everything else will look the same.

It’d be more like:

  • icons
  • color
  • background-color
  • gradients
  • borders
  • border-radius
  • padding
  • margin
  • font

You might be surprised at what can be achieved with a simple XUL structure and some CSS skills.

This is the same kind of arbetrary garbage decision that makde windows8 and window10 failures. You mess with a comfortable useable UI.
I don’t want a chrome lookalike. I don’t use chrome, don’t like chrome.
My Firefox “theme” is information dense - not all 'touch friendly" like half the garbage being created these days. My chrome, including tabs, is as minimal as you can make it using classic theme restorer and glass my fox.
Not upgrading to a worse UI experience that wastes an extra 1/4 inch… not gonna do it.
Your reasons - developers - are yours, but they’re impacting your users.
So before you blow this theming engine out, create the new one so that I can move the icons around, use one single row for all my controls and get rid of that stupid tab drop-down you introduced with australius. Not trading in my customized mustang for a wheel and a windscreen (great analogy…)

Nothing left to add here. Just to quote someone:

“* wrote:Meanwhile, the whole logic that any product in any field that Google is in has to compete directly with Google is idiotic. It’s exactly what promote’s Mozilla’s thinking. Meanwhile there’s this awesome thing called niche markets where many products live long and successful lives without having to expand into unwieldy code nightmares or worry about Google squatting on their party.”

Very true - and this makes me sad because Mozilla has all the things that differentiate it from the competition (like powerful extensions, customizability) but has chosen to dump it all in the name of competing with the giants. Firefox would never die in its original form because there are simply things that you cannot do in other browsers that you can in Firefox and there will always be market for that. Unfortunately, that will not last long. The sad thing is that Mozilla has really great and talented programmers that can do a lot - but the management just wastes all that potential.

Can be found in http://forums.mozillazine.org/viewtopic.php?p=14433875#p14433875

That includes all the reason why Mozilla kills features. All to be simple, all to compete with Chrome.

Very wrong vision Mozilla, I and tons of other guys will not follow you down that road. Please reconsider, not only in that right now, also in Australis and all the other feature removals you have done because of that sick reasoning!

Thanks!

Fascinating read this thread, somewhat unproductive it would seem, but fascinating nonetheless.

Pleasantries done, Kev, I actually popped in to ask one question. Do you have an actual date for the demise of Firefox Complete Themes on AMO, as we all know them, yet or not?

Good luck with your, well, whatever it is you think you intend doing.

Frank

I’d like to reiterate that the one thing that makes Firefox so beloved to its users (we can all see the level of emotional investment people have in this debate) is its customizability. Some people don’t care that there is a huge world of features out there, all they want is a URL bar and a point-and-drool interface. Chrome is perfect for those users, and you cannot unseat Chrome from that throne because those people are already invested in Chrome, Chrome is noticeably faster, and is backed by the Google brand. Just like people who were already Facebook users saw no reason to switch to Google Plus.

Then there are the users who do care about things beyond a URL bar. The ones (like me) who may complain about the performance and lagginess, but still stick with Firefox because of one thing and one thing only: the customizability.

I don’t think Mozilla developers/designers have a clear notion of exactly how people use their product, so here are some examples of the customizations I use:

  • The theme. I dislike wasting space, fat tabs, big buttons, rounded corners and gradients. Using XUL/CSS, I can remove all the cruft and make it look exactly the way I like.
  • Stylish is an invaluable addon. However, it doesn’t provide a way to toggle styles using the keyboard - instead, you have to take your hand off the keyboard, move the mouse, click on the icon, move the mouse, then click again. With the current XUL system, I open overlay.xul, copy and paste three lines of code, and I can toggle styles with keyboard shortcuts, and even open the editor with another shortcut.
  • I really dislike the URL bar drop-down which shows every item in two lines with highlight boxes around the substring matches. I find this visually noisy, wasteful of space, and too distracting. Using XUL/CSS, I can restore the old URL bar drop down where one line contains one row of data, period. I can also style the highlight to be a simple text color instead of a box background.
  • Some of the popup menus have too many options when I only ever use a few. With XUL/CSS, I can remove the options I don’t use, and make the most-used items use a larger font and much more padding so that I can click them quickly and reliably.
  • Because Firefox (still) has a menu bar, I can do things like set up my bookmarks/bookmarklets so that I can use the keyboard to invoke them. For instance, I have a bookmarklet “Show Document Structure” that’s very useful for web development. To invoke it, all I have to do is Alt+B-I-S (Bookmarks > Inspect > Show Document Structure). Similarly “Analyse element” is Alt-B-A.
  • I just love that I can add and define my own search engines in the search bar. The decision to make it a touch-friendly, non-theme-friendly “tappable” dropdown was a huge mistake. For now, I can change that behaviour back to the old way where I can choose a search engine using Ctrl + up/down arrows and Alt + up/down arrows. I really hope that option stays.
  • I use a status bar addon (Status-4-Evar) to see where a URL leads, download progress bars, various status icons, the IP address of the website I’m on, etc. The decision to take away the status bar and not even have it as an option was one of the worst blunders in Firefox history.

This is all just to give Mozilla developers and designers an idea of how people are using your product. I’m certain other people have their own, uniquely personal setups. If you switch from XUL/CSS to an API-based approach, please try to keep this level of customisability available.

You should be thinking how to improve the customizability, instead of crippling it. Everything is moving to the browser these days, and a lot of people see the browser UI more than they see their operating system UI. Every sane product like that offers customizability - on my smartphone I can choose which apps/settings to put on my start screen, which icons I see in the notification bar, the color and size of my tiles, etc. In the Drupal CMS’s admin section, you have a toolbar that you can drag your most-used items to. Deciding to remove user choices is a giant backwards leap for Mozilla, and a huge loss for mankind.

I’ll say it yet again, because it bears repeating:

If Firefox becomes a slower clone of Chrome, why would people use Firefox at all?

The only reason I can think of is if Firefox became significantly faster than Chrome, which I think is unlikely to happen because Google has a lot more dollars to throw at development. You cannot beat Chrome at that game. The only thing you can do is play to your strengths. The C-word. Customizability.

I understand that it’s hard to support a browser that is so customizable. So don’t! Tell users up front that you can only support the vanilla browser.

For a long time I’ve been getting the strong impression that Mozilla developers are tired of maintaining the existing code base. Removing features, dropping Thunderbird development, the push for automated addon verification, all indicate a general weariness that’s been building over years.

The real problem here is code quality and code bloat. Mozilla’s own theme XUL/CSS is horribly bloated and monstrously complicated. Burn it to the ground and start over. Keep it lean, clean, and simple. Throw out the obscenely complex CSS selectors (see my post above). If you’re writing CSS even one-tenth as complicated as that, you’re doing it wrong. Why do you need a bazillion elements to represent a simple tab/button? Is the “feature” of having overlapping S-curved tab edges and sliding tabs worth so much extra code and the resulting performance hit? I’ll bet if you removed all those frills and the UI became noticeably snappier, users wouldn’t even notice that their tab edges don’t overlap any more and would be happier.

I still keep a copy of Firefox 3 around for comparison. Every time I fire it up I’m blown away by how responsive the UI is - try it sometime. Because the performance drops have been so gradual and cumulative, I think Firefox devs have forgotten how snappy it used to be - the UI responsiveness is native-like. Not just the UI - scrolling is very noticeably faster than any recent version of Firefox. I understand that some of this may be because FF3 doesn’t support fancy new web features, but most pages don’t use those features.

Firefox 3 used XUL/CSS, so why is it so fast? To me, it indicates that the problem is not XUL/CSS, but badly written XUL/CSS that has gotten bloated and overly complicated over the years.

##XUL? HTML?

I really like the idea of switching from XUL to HTML. The idea that the UI becomes essentially a fixed-positioned overlay div above/around the content is beautifully elegant. Instead of having two engines, one for the UI and one for content, you could have just one. Save developer time, reduce the size of the codebase by a huge amount, and save CPU and RAM usage into the bargain. For addon/theme developers, not having to learn another language is a huge plus, and for Mozilla, being able to tap into the much larger talent pool of web developers (compared to the Firefox themer talent pool) is another.

The only thing I would change is that instead of using generic <div> elements with classes and IDs, I’d use custom elements and have all the basic styling/functionality defined in native code instead of CSS/JS, with themers only being able to change the cosmetic values. So, for instance, instead of a long nested list of <hbox>es and <vbox>es we’d have

<tabs>
    <tab>
        <tab-icon />
        <tab-text />
        <tab-closebutton />
    </tab>
    ...
</tabs>

Instead of the truly horrible code that is the XUL tree and its associated styling, use tables as Antoine suggested above. What exactly do trees provide that tables don’t?

Make a list of all the properties that are CPU-intensive, and remove support for them in the UI rendering engine. If an addon developer uses those properties, either throw an error, or silently ignore them. There’s no need for, say, drop downs to have animated box-shadows and blur effects. Keep the UI rendering engine as lean as possible.

Having addon authors create their own widgets is a huge waste of developer time and an invitation to badly-written (at least in part) addons - a developer who may be great at JS may not be very good at CSS/XUL, and the widgets he builds will probably be ugly and badly-written. So for instance, instead of a bunch of addon developers each creating their own implementation of a progress bar, give them a progress bar widget:

<progressbar-wrapper>
    <progressbar-icon />
    <progressbar />
    <progressbar-text />
</progressbar-wrapper>

This way, the developers who do want to define their own widgets can still do so, and the ones who’d rather not can use the built-in ones.

Another example: Stylish has a built-in code editor that is not only nowhere near as good as a native code editor, but completely pointless, and a waste of the developer’s time. If an addon needs an editor, why not let the user specify their own code editor and have Firefox interface with that? User clicks a button, Firefox creates a temp file and passes it to, say, Sublime Text, and updates its internal copy whenever the file is saved. The user gets to use their favourite, familiar code editor with all features. Addon developers can focus on their actual addon features instead of reinventing the wheel.

I’d also strongly recommend having the editors in Developer Tools, View Source, GCLI etc. be a native implementation. Why exactly do we need XUL for that? It’s completely unnecessary, inelegant, and immensely wasteful of CPU and RAM.

##To sum up:

  • If any fancy-pants designer says they need to change the XUL yet again to implement their latest, greatest aesthetic inspiration, slap them
  • Menu bar good, status bar good, more options good
  • Removing features bad
  • Clean up the code
  • Simple CSS selectors good, complex selectors bad
  • Lean XUL good, complex XUL bad

While i am no power user and more in love with a well crafted design and minimalism/less features i still think Mozilla does one thing very wrong:

The way it treats their current/past power user base. While it is Mozilla’s right to try out if Google Chrome’s way is leading them to success it is really a shame how Mozilla is behaving towards that mentioned users.
Instead of telling them clearly that they can not support them anymore/that they can’t support their features anymore and making a simple and fair blog post about it, Mozilla tries with a terrible load of obfuscation and just not responding to sit out the whole affair aka “We do not hear, we do not see, just go away, we do not want/need you anymore”.

That is NO way to treat loyal users of Firefox. While i and many other recent users of Firefox enjoy this new concept much more than the previous customizable one i can understand the annoyance and partly also anger of those left alone users. Mozilla owns those users at least such a blog post, some kind of apology, a good reason they can understand and that helps them to move on.

Or, and this is in my opinion the much better attempt to handle that whole unpleasant affair which ends only with losers on both sides:

Stop trying to get Seamonkey away from Mozilla. Instead how about helping them keep features, keep them alive, support them with infrastructure and web standard supports and advertise it as the
"Firefox powered browser for power users by Mozilla and the Seamonkey Council". Look developers of Mozilla, if you read here, you earn 100’s of millions of money and you are unable to put a little bit amount of money in a spin-of project which could lead that every user base is happy again? Simple users can use Firefox, advanced users use Seamonkey, everyone would be happy, and with a little bit of help and money you could turn that whole negative publicity instantly into a good one.

And now to the unpleasant thing. I moved on from Google Chrome for one reason: Google treats their users with more and more disrespect, and if i take a look at lot of recent decisions of Mozilla since Australis (where i switched towards Firefox) i get more and more the feeling that i have just exchanged just one Google against another one. Many users have left Chrome for this reason and you can count on one thing, that i am not the only one who is thinking that way. If Mozilla keeps on doing what they do right now they will also lose many of us simple users again because if you treat your users the way you are doing now, how can we be sure we are not treated the same way when another trend arrives? Instead of finding their own way, Mozilla seems to be just trend hopping. Stop that please too.

Not every simple user is against features and choice, perhaps not keen to have them in the main product, but if there is a simple and easy and not too expensive way to support complexity loving users too with a side product, sure, of course! So, why Mozilla is damaging their brand that much instead of doing for once something logical and helpful and keeping Seamonkey alive for those power users?

Give them a honest We’re sorry or give them a replacement. But just do something Mozilla developers!

I really honestly believe attempting to build a flexible UI in HTML is a complete disaster. It’s a popular idea based on assumptions and prejudices that have no real bearing on the real world whatsoever. HTML is a terrible language for building a UI and the amount of “base” CSS that’s going to be required to build up UI elements out of DIV elements is going to be tremendous… and slow. Just look at the results of the CSS “flex” element.

And forget about using native HTML elements, because the standards are so restrictive about allowed properties and styling that it’s basically impossible… remember that most of the elements in HTML that look like UI elements belong to an HTML “form” and are extremely restricted to how they can be used. Ask any web developer who’s ever tried to custom style a checkbox or menulist in HTML how much fun that is. HTML is a vertical document format. It has always been a vertical document format, and recent advances in “web semantics” have only reinforced it’s limited purpose and role.

Stop trying to use the wrong technology just because some hipster at some tech journal who’s never coded a day in their life thinks it’s a cute idea. Looking around on Google it looks like the Rust project has had XML parsing ability for about a year now. Hmm.

Wow… Just wow! That was the most provocative comment i have read here so far.

So, you do not dislike power users but want us and our features gone? That is the source for Mozilla’s problems lately. That they listen more to the kind of users like you than to their old caring user-base consisting of geeks, power users or other advanced users in general.

Mozilla should finally stop their rivalry with Google - Since their first contract and after Chrome has entered the browser war, Mozilla always tried to damage Google’s market share no matter what, even if that means today pushing out all advanced features to finally reach that goal.

This rivalry even was speeding up after Google kicked Mozilla out after their last contract ended, and Mozilla’s attempts to harm Google and reduce their market share was speeding up like crazy, they decided to adopt webextensions and kill full themes just to make themselves more compatible for the Chrome users need.

God damn it Mozilla, get yourself healthy again, stop that rivalry which only brings misery to your users!

And to you… how about if you try to understand how that features work which we love so much, they can be also for you of use, you only have to be open and not selfish to think that only your features have the right to exist in the browser’s core!

Anyway, the opinion of users like you and Mozilla’s very counterproductive rivalry with Google is utterly disappointing to see. Seriously, enough of that!

A UI widget built in XML would have a similar structure and complexity to one built in HTML or XUL (or any other markup language). Plus, by using HTML, you get the huge benefit of an existing talent pool that already knows HTML/CSS and theme/addon developers don’t have to learn yet another language.

the amount of “base” CSS that’s going to be required to build up UI elements out of DIV elements is going to be tremendous… and slow.

This is why I suggested using custom elements with the essential behaviour hardcoded and only a subset of themeable properties exposed.