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)
Toolkit Graveyard
Build Config
Tracking
(Not tracked)
RESOLVED
INACTIVE
People
(Reporter: benjamin, Unassigned)
References
()
Details
Attachments
(1 file)
(deleted),
text/plain
|
Details |
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.
Reporter | ||
Updated•19 years ago
|
Reporter | ||
Updated•19 years ago
|
Priority: -- → P3
Target Milestone: --- → mozilla1.9alpha1
Comment 1•19 years ago
|
||
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.
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..
Reporter | ||
Comment 3•19 years ago
|
||
You can override the XBL widgets using CSS just like the other stuff.
Reporter | ||
Comment 4•19 years ago
|
||
For those watching, this is being postponed until after ff2 stops using the trunk/branch merging.
Comment 5•18 years ago
|
||
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.
Comment 6•18 years ago
|
||
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.
Reporter | ||
Comment 7•18 years ago
|
||
> 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).
Comment 8•18 years ago
|
||
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.
Reporter | ||
Comment 9•18 years ago
|
||
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.
Comment 10•18 years ago
|
||
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.
Comment 11•18 years ago
|
||
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.
Comment 12•18 years ago
|
||
Isn't this bug a dup from bug 274326 - "Allow theme inheritance"?
Reporter | ||
Comment 13•18 years ago
|
||
As originally filed, no, not really at all.
Comment 14•18 years ago
|
||
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.
Comment 15•18 years ago
|
||
(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.
Comment 16•18 years ago
|
||
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.
Comment 17•18 years ago
|
||
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).
Comment 18•18 years ago
|
||
(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.
Comment 19•18 years ago
|
||
RE: comment #18
adjourn and reconvene here:
news://news.mozilla.org/Y7WdnZggwcwKuXvZnZ2dnUVZ_s6dnZ2d@mozilla.org
Comment 20•18 years ago
|
||
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.
Comment 21•18 years ago
|
||
Ed, it's posted on news.mozilla.org in mozilla.dev.theme under "All Things Considered - Bug 305746"
Comment 22•18 years ago
|
||
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.
Comment 23•18 years ago
|
||
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.
Comment 24•18 years ago
|
||
"see bug #349079" s/b "see bug #349418"
Regrets
Comment 25•18 years ago
|
||
-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.
Comment 26•18 years ago
|
||
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.
Comment 27•18 years ago
|
||
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").
Comment 28•18 years ago
|
||
Okay, but I disagree for all the reasons I've stated above, at least for non-trivial themes.
Comment 29•18 years ago
|
||
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.
Comment 30•18 years ago
|
||
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?
Comment 31•18 years ago
|
||
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.
Comment 32•18 years ago
|
||
(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.
Comment 33•18 years ago
|
||
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).
Comment 34•18 years ago
|
||
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.
Updated•18 years ago
|
Flags: blocking1.9?
Reporter | ||
Updated•18 years ago
|
Assignee: benjamin → nobody
Priority: P3 → --
Target Milestone: mozilla1.9alpha1 → ---
Reporter | ||
Updated•17 years ago
|
Flags: blocking1.9? → blocking1.9-
Updated•6 years ago
|
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE
Updated•6 years ago
|
Product: Toolkit → Toolkit Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•