Closed Bug 305746 Opened 19 years ago Closed 6 years ago

Move default toolkit and Firefox theming from skin to content packages

Categories

(Toolkit Graveyard :: Build Config, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INACTIVE

People

(Reporter: benjamin, Unassigned)

References

()

Details

Attachments

(1 file)

This is the result of a mini-WG meeting between vlad, mconnor, and myself. We
decided that it makes a lot more sense for the default theming to live in the
content packages, instead of the skin packages. That way theming simply involves
overriding the special parts of a theme, rather than copying all of the default
theme.

The end result will be that the default skin files don't have any CSS
instructions in them at all.

This bug will be mainly a tracking bug... I'll do this incrementally, filing a
bug for each piece of the puzzle.
Priority: -- → P3
Target Milestone: --- → mozilla1.9alpha1
Depends on: 305767
That might work for Firefox when all people do to create a new theme is to
change the images but the Modern and Classic themes differ substantially even on
occasion using different XBL bindings for the same widgets.
Depends on: 306054
That should be ok; those themes should be able to override the defaults easily.
 However, if they're using different XBL widgets, then maybe we should look at
resolving that first..
You can override the XBL widgets using CSS just like the other stuff.
Depends on: 306475
For those watching, this is being postponed until after ff2 stops using the trunk/branch merging.
Do you really want to express themes in terms of the default theme?

Like Neil said, if all you're doing is changing images and colours, that's not a big deal. But if the default theme styles elements where your theme would be fine with (or requires!) the default values, it now needs to explicitly override those rules and reset the properties. Keeping track of what needs to be reset seems like a PITA to me, and I fear it'll lead to subtle theme bugs and plenty of pulled hair.
Currently theme authors duplicate the entire theme code anyway, so I don't see how overriding only the attributes they want to change will be more difficult. This should also reduce the amount of coding required to produce themes and lower the barrier of entry for theme authors.

See the Theme forum on MozillaZine for lists of changes between recent major releases. That looks a lot more like a PITA to me than what is proposed here.
> Do you really want to express themes in terms of the default theme?

Yes. The most common theming changes are replacing icons and colors, and we'd like to facilitate a theme development style that centers on overrriding specific default UI elements rather than copying and modifying an entire set of theme styles. Ben speaks truly about the current difficulties of theme authors who have to track changes in the underlying XUL very carefully, or risk introducing instability in the browser (see bug 283624 and the dups it collected as one of the more painful examples).
Would it be possible to write the chrome registry so that if a particular file is missing from the theme then it is loaded from content instead? Theme authors would then have three options: 1) omit a CSS file, causing the content default to be used; 2) provide a CSS file, @import the content default and override some rules or 3) provide a CSS file that simply replaces the content default.
That would require some fundamental changes in the chrome registry... perhaps not impossible, but certainly complicated. For one, it would require knowledge of the underlying channels.
Neil's suggestion (or a variation that's easier to implement?) seems like it'd be much more sane than trying to implement e.g. Modern on top of Classic.

One option is to move the default theme to content, and replace the css files in skin/ with one line @imports, and maybe a small comment (which the preprocessor can strip away) about how skin authors can do something similar and add any overrides in their copies. That would take the logic out of the chrome registry, and provide theme authors with a template.
As one who has many themes that don't use native widget/controls (-moz-appearance: none;) and that makes heavy use of image backgrounds (gradients and such) this change seems like it will be very difficult to implement/debug and maintain since, conceivably, many overrides will require the use of the "! important" flag and in some case, even that won't suffice.

Another alternative might be to offload the theming difficulties for cookie-cutter themes to a set of userChrome.css changes. The developers of Netscape 8 attempted this via a master.css stylesheet, see http://ftp.netscape.com/pub/netscape/themes/NS_ThemeSDK.zip for their initial development kit (included is a PDF file explaining the attached master.css file.)

Conceivably, a person could create a theme that only contained the master.css file within and a theme-named directory/folder, along with whatever images, and the installation could simply add the theme directory+contents as a subdirectory in the user's profile chrome folder. There would need to be some GUI to allow a user to switch between these folders, however.
Isn't this bug a dup from bug 274326 - "Allow theme inheritance"?
As originally filed, no, not really at all.
Something else just occured to me. Many people involved in complex theme design are not tied into the CVS method but, instead, simply use the output of a diff program from the last theme jar file version they were current with to the lastest version. It's not clear from reading this bug just how the content theme would be implemented, i.e., will all the CSS skinning statements be included in a single theme content folder or will it then begin to spread out to the various component content folders? If it's the latter then this would make it almost impossible for independent theme designers to follow the changes unless there is some methodology put in place that would make it convenient for theme designers to gather all the changes over, sometimes, a long stretch in time.
(In reply to comment #14)
> unless there is some methodology put in place that would make it convenient for
> theme designers to gather all the changes over, sometimes, a long stretch in
> time.

Well the whole point of this bug is to make creating and maintaining themes easier and to stop themes breaking every five minutes. I can't imagine that anyone implementing this is going to throw CSS files all over the place just for the heck of it.

Presumably, the changes also mean that if your custom theme doesn't contain an override for something which is added to or changed in the default theme, all that will happen is that your theme will look bad (i.e. the defaults will show through). To solve this, all you'd need to do is whip out DOMi and see what you need to override.
Re: comment #15
> Well the whole point of this bug is to make creating and maintaining
> themes easier and to stop themes breaking every five minutes. I can't imagine
> that anyone implementing this is going to throw CSS files all over the place
> just for the heck of it.

While a better place to discuss this would be on a mozillazine forum, since I can no longer log into there I'll provide one last clarification here.

I believe the premise of this simplifying development/maintenance only applies to "cookie-cutter" themes, i.e., ones that simply override toolbarbuttons, toolbar colors and rely mostly on native widgets. For complex themes, putting the CSS statements in "content" could make the current job much more difficult. The reason I queried about a methodolgy is so that those who are implementing this bug solution will think about how to do it in such a way that even within "content" it will be encapsulated such that a theme designer could easily extract the encapsulated changes from one build to another and be able to see the differences.

Frankly, your cavalier comment about just bringing up DOMi to check the changes suggests that you've not been involved too much in maintaining complex themes and perhaps are more familiar with using DOMi for extensions where there is, normally, less structural and more localized changes from one release to another? Theme changes, otoh, transcend many "content" components from the simpler toolbar and buttons to the more complex Options, Add-on, tabs, sidebar, bookmarks, &c. As an example, just look at the amount of theme changes that have been implemented in Bon Echo over the past few days, see http://forums.mozillazine.org/viewtopic.php?p=2430230#2430230. Now consider the number of changes between 1.5 and 2.0. Attempting to gain an understanding of how to accomodate all those changes using DOMi alone would be a Herculean effort that very few theme designers would see fit to undertake, imo.
Maintaining two rather complex themes (EarlyBlue and LCARStrek), I'd also prefer if we could do something along the lines of comment #8 or comment #10 - though still it's much harder tracking CSS changes then, as they will be intermingled with UI changes in the source. Still, it might make things easier for authors of simple themes, and not make creating complex themes much harder, only maintaining any themes (as probably all of us should track relevant changes and only discard them when we know they don't affect our theme).
(In reply to comment #16)
> I believe the premise of this simplifying development/maintenance only applies
> to "cookie-cutter" themes, i.e., ones that simply override toolbarbuttons,
> toolbar colors and rely mostly on native widgets. For complex themes, putting
> the CSS statements in "content" could make the current job much more difficult.

Again, how would this be more complicated than copying the entire theme CSS and having to change it (or track changes in it) anyway? I do sympathise with what themers have to put up with currently, and I wouldn't support any system that makes it worse. I don't think this is going to, though.

I assume that the intention is to keep the files inside one folder as part of the content package. Doing otherwise would make this more difficult to implement and would yield no major benefits as far as I can see. Certainly, there's no advantage to spreading CSS files all over the place from a packaging point of view.

> Frankly, your cavalier comment about just bringing up DOMi to check the changes
> suggests that you've not been involved too much in maintaining complex themes
> and perhaps are more familiar with using DOMi for extensions where there is,
> normally, less structural and more localized changes from one release to
> another? 

Well, if all themes become overrides of the default, it really shouldn't make any difference how complicated your theme is from a maintainability point of view - you're still overriding default rules, and the more rules you override to start with, the fewer things you'll have to actually deal with when the defaults change.

I admit that this might not seem like a big advantage to you, but the key difference is that your theme will never, ever break in a totally unusable way. 

The only reason I mention DOMi is because it has facilities for tracking the individual rules in individual CSS files that affect whichever element you target. Hence, if something in your theme starts looking broken in a nightly build, you should be able to infer why, based on the computed style information and the style rule views. 
Re - comment #18 : You can't track changes very well in DOMi. It has severe limitations. For example you can't test your theme for [xyz="true"], and coordinating pseudo-classes does not always work. Worse, you can't pull out menus and click on menuitems to see where their code is. It's a great tool, but not for tracking changes.

This is why I maintain threads on the changes in classic.jar.

Actually, I don't mind if you try this experiment, but only on the promise that you'll change it back if it makes themers' lives worse. This would mean that you would have to have the discipline to keep yourselves from falling in love with your code.

Re- comment #19: I suspect that this is a discussion bug. If not, then perhaps a better place for discussion is on google groups.
Ed, it's posted on news.mozilla.org in mozilla.dev.theme under "All Things Considered - Bug 305746"
Correct me if I'm wrong, but I don't think the suggested new approach would allow a theme developer to express that "there are no CSS rules that apply to DOM elements that match selector S", if the default theme code supplied with Firefox did contain a CSS rule having selector S.  In other words, if the Firefox default theme defined a rule, there would be no way for the developer of an add-on theme to underfine that rule.

I can't yet think of a case in a theme where this would matter.
Ref. Comment #22
I can, bug #349079 introduced a binding overlay that breaks many existing 3rd party themes, see bug #349079 and discussion at http://forums.mozillazine.org/viewtopic.php?p=2441976#2441976. If the default theme were in "content" then it's not clear how a third party theme could back-out the binding changes.
"see bug #349079" s/b "see bug #349418"

Regrets
-moz-binding can be set to "none". If all themes are an override of the base theme, you would undefine the binding by setting the rule where appropriate.

Is this still on the 3.0 radar? Themes are already breaking features in the nightlies, apparently.
Ref: comment #25

Wouldn't that lead to other problems where the default theme had selectors defined that depended on the new (since removed) binding structures, causing javascript errors unless these selectors are also nullified? If so, this then makes creating a non-cookie-cutter theme much more difficult to design and maintain, what with having to locate and include any number of default theme selectors needing to be nullified simply because they do things that another theme may not want? Actually, as pointed out in comment #22, this will be the case even without the content binding complication. 
I wasn't looking to get into this debate again, just answering a straightforward question. See comment 10 for the way this should probably be implemented, seeing as it offers the best of both worlds ("cookie-cutter" and "non-cookie-cutter").
Okay, but I disagree for all the reasons I've stated above, at least for non-trivial themes.
Patrick: Following comment 10 (or comment 8) would leave non-trivial themes looking exactly like currently code-wise, so I'm not sure why you disagree on that.
Re comment 8 and comment 10, would that meet the goal of having rules that were accidentally left out of add-on themes (particularly bindings) still apply by virtue of being part of this "inner default theme"?  It doesn't seem like a scheme that operates at the granularity of entire files would get us there.

If this is going to happen, I'd love to see a pilot/trial version so we can think concretely about how to make it work.

But the big question is still the one asked by Cusser in comment 25: is this still on the radar?
Re: comment #29

I'm having difficulty getting my mind wrapped around this then. After thinking more about the overlay issue, I suppose if one nullifies a binding then any linked stylesheets within it would simply become moot which would be fine but what about the need to create nullification styles for all embedded selectors not wanted, e.g., dynamic pseudo classes (:hover, :active, &c)?

Having a prototype build using Fx2 as a base where theme authors could experiment with would help make this issue less murky and go a long way to relieve my and others anxiety on this, if that would be feasible.
(In reply to comment #30)
> Re comment 8 and comment 10, would that meet the goal of having rules that were
> accidentally left out of add-on themes (particularly bindings) still apply by
> virtue of being part of this "inner default theme"?  It doesn't seem like a
> scheme that operates at the granularity of entire files would get us there.

I can't envision a solution that makes this work both ways. It's really a judgement call between optional and mandatory future-proofing, based on the comments made about potential difficulties with the latter.
Patrick:
The solutions proposed in those two comments wouldn't need you overrule any single definition of the default theme. You just need to define somewhere which files' definitions from the original theme you want to be or be not inherited (the comment 8 model could potentially allow inheriting anything not defined in your theme, while the comment 10 model needs you to manually define every single file you want to import).
With the comment 10 model, nothing will get imported from the content-based default theme definitions unless you explicitly import those into every single of your theme files.
With the comment 8 model, probably everything will get imported unless you define a file with the same name, which would overrider the whole file of the default theme. That would satisfy complex themes. Still, the case where you _want_ to import the original file's rules and extend them is not solved there yet, but is probably possible in some way.

Ben:
I believe the comment 8 model could basically work in both ways, but it's probably hard to implement. The comment 10 model is easy to do, but probably poses too much work and care on simple-theme-authors. Thinking of stuff we might need for locale fallbacks in Mozilla2, we will probably end up with having to put similar code into chromereg anyways - and might not necessarily end up with the files in content at all, as we might be able to flexibly fall back to a different real theme (that is, again, if we adopt similar code to what we'll probably need for the "L20n" locale framework).
Robert:
You know, I read those two comments several times and until you restated what was being suggested, the concept just hadn't sunk in. Go figger?? Ben, excuse my denseness.

My trepidation on this issue is borne from the fact that I attempted to create something similar in the Mozilla Suite (now SeaMonkey) where I used an underlying theme as a base and wrote overrides to skin just the browser component (see RaceDay theme on my site, if interested.) While it was able to be accomplished, the need to nullify all the underlying theme elements that weren't desired convinced me that while in theory this seemed like a grand idea, once implemented, became a project from hell.)

Anyway, yes, if such a design could be implemented then that would be okay (my preference would be comment #10, or explicit imports, fwiw.)

The only other issue I see as problematic is discussed in comment #14.
Flags: blocking1.9?
Assignee: benjamin → nobody
Priority: P3 → --
Target Milestone: mozilla1.9alpha1 → ---
Flags: blocking1.9? → blocking1.9-
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.