Planning the Future of Complete Themes

Not true at all. They still CAN support all those features if they would want.

But they do not want. Mozilla implements instead Pocket, Chat, DRM support, social sharing, EME - those features are much more time consuming to maintain as compared with stuff like the status/add-on bar or UI customization.

Seen from your point of view as a simple user, this is a heaven sent that you are getting now exactly that what you want or need. But the downside is for this our features have to go. That is not fair at all. Mozilla has betrayed power users, for the likes of you!

No, Mozilla could still be able to support both functions. They just changed functionality of so called geek features against Pocket, DRM integration, EME integration, Chat and sharing features.

Those features are much more difficult and time consuming to maintain. It just was a replacement of features, and that it truly disappointing to see that Mozilla acts like that.

@Amigalover and saturanus, frankly I don’t care what you believe Mozilla can or can’t do. Either they’re being honest and want to fix this feature (whether you like the solution or not), or they clearly don’t have the resources to do it and want to remove it (there’s no other sensible reason for them to do this otherwise, unless you feel they just LOVE negative PR).

But more importantly: please take stock of your situation in the space-time continuum already, guys. This thread is supposed to be about helping Mozilla figure out a better approach to themeing compared to what we have now. It’s not about your egos and what you think constitutes a “geek” or “power user”. It’s not about your gripes with Mozilla or what features you feel they should focus on. It’s about THIS feature’s future, and not every single thread on the Internet has to be turned into this kind of circus.

Seriously, your blatant dislike for features and advanced users is really scary. This is not about ego - this is about being unfair towards the origin of Mozilla Firefox userbase.

Beause of simple users like you we are facing that dire times. That much progress would not have been possible during the C64 age, Amiga or Atari days if users like you would have been so stubborn and expect that everything which goes beyond the feature range what YOU are using has to be removed!

How about a little bit respect and fairness? We are all properly mannered adults, aren’t we? Btw. i think i have seen you also spitting hate against features and power users on Reddit countless of times… Dr.Dichoitomous or something like that!

If someone has a big ego it is you. You expect that as your birthright that your features are getting supported and ours have to go missing in the process. I am so terribly disappointed that guys like you are so resistant in learning how technology works. If you would understand you would realize why we care about our features!

Please, guys. I agree with most of the people here that complete themes and full-fledged extensions are part of what made Firefox attractive, and even great, but flame wars aren’t going to make MoCo change anything to what was apparently decided some time ago. Let’s try to see how we can save at least part of that greatness, and maybe even convince them not to throw it all down the drain if we can, rather than tear each other’s hair in a quarrel that’s going nowhere.

Indeed, that’s basically what I was trying to argue. I’ve had enough of trying to talk some sense into these guys. They clearly don’t understand that I just want them to leave one bloody place for devs to have a serious chat about how to improve Firefox themes. Since they feel compelled to clog this post up with yet more compulsive preaching to the choir, so be it. I apologize for my part in this.

Why only a little bit and not all of them? You have presented here from other guys already the hint that Mozilla could do it. With a system like Vivaldi you can restore almost 70-90% of the functionality which has been around in Firefox versions before Australis.

You guys know this, you experiment with Browser.html too. So why only talking about limited API which gives only back parts of the freedom and not going full non native UI like it was mentioned here too and restore all features which got lost?

Why are simple users so much more of interest for Mozilla today? I really want an answer to this. Why serving users which want that all other functions they do not see as interesting for their own workflow to be gone?

Are you really so far away from your old ideology which meant to offer the user both: maximum flexibility in the browser and maximum flexibility outside of the browser with the help of add-ons?

You know, Mozilla as it is right now is just a shadow of it’s glorious former self, Open Source totally screwed up! I really value Open Source more than anything, but as things are the way they are, i am today totally unable to recommend Firefox to anyone!

You guys really should think back into the past and find out when stuff has gone wrong for you and restore your old ideology and throw away that limited and restricted functions are better than full functions one!

Back on topic, please. The purpose of this thread as I understand it is to ask how so called “lightweight themes” (aka the new way to do themes) can be extended to support the functionality of the old “heavyweight themes.” I for one am tired of the old complete themes breaking between versions of FF. I’m not a FF/addon/theme developer, but if this new way of doing themes is extended to support all that complete themes can do (or at least support all the modifications made by top themes such as FT DeepDark) through a new, safer method that doesn’t break between FF updates and makes themes easier to maintain then I am all for it! I don’t know how multi-process FF (e10s) and theme-related addons like Classic Theme Restorer and Stylish factor in, but supporting the functionality of those is also critical.

TLDR: Look to popular complete themes such as FT DeepDark and theme-related addons like Classic Theme Restorer and Stylish (if applicable) and focus on making sure those can be 100% ported to the new way of doing themes.

Would virtual CSS classes be an idea for an API? Having predefined semantic class names which would be mapped to the correct elements.

Or maybe make an abstract representation of the browser in HTML. Have people style that through CSS. And then you could apply the CSS styles to the correct elements by having a map between the elements of the abstract representation and the actual browser elements.
That would be pretty awesome if you ask me :open_mouth:

Anyways, if I can express some other points about improving theming:

  • Make theming more targeted towards UI web developers. I think that both lightweight and complete theming have missed that target on both ends. Whilst this is such a large and relevant crowd to tap into.
  • Make (semi-)complete and lightweight one. I expect that the line between the two will blur when this simplified API comes out. And right now, complete themes have this uninviting second rank status.
  • Take ownership of the complete UI. Right now lightweight and complete themes always collide with the OS integration. Although Google Chrome might have severely limited options in theming, it has some beautiful themes that trump all lightweight and most complete themes on Firefox. Mainly because of Chromes’ control over the entire UI.

Here is a screen-shot of what I mean with the colliding OS integration, note the window buttons and border:

I must agree with @optional though, it’s very vague what is exactly suppose to happen. Which makes it hard to give any real feedback. Are we just suppose to shout out what we want and cross our fingers.

Most of the feedback I’ve seen is along “Give us everything” and “Support everything that is out now”. Which is somewhat expected, because there is nothing real to bargain over.

You can fix the “OS integration” now… it’s a bit tricky but it works.


I’ll miss all this flexibility in the future if this ended badly for both extensions and themes.

the ironic thing about all this “great or dead” stuff is your company decided to keep the crap, while killing the great. nice job! Why don’t you just admit it, Mozilla is going to be nothing more than a ‘me too’ chrome clone. Right down to the shitty gui. If you kill off full themes that will be the last straw for me. You’ve ruined just about everything else I used to love about firefox, while implementing all kinds of bloat and stupid features that seems like just a way to garner more income. I mean seriously? who the hell wants a video chat feature in a web browser. Pretty sure the usage is in single digit percentages.

Was anyone that currently works for mozilla around when the company was formed? Its like mozilla completely lost their way and forgot about their core philosophy. CHOICE. OPTIONS. Not “we’re going to nail down certain things and make them unchangeable for everyone”.

Maybe this won’t make any difference, but being I’ve used firefox before it was even called that, all these changes your company keeps making keep pushing more and more people away. Remember when ff had 30% market share? Remember when it started to sink more and more? I guess mozilla only think that by turning themselves into a chrome clone (down to the shitty gui like chrome has) that they’ll rebound. Well guess what? You’re about to drive away the last remaining diehards by making all these terrible decisions.

You make your product like a lame chrome wanna-be, people will just up and move to chrome.

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!