MozillaZine

Could/should themes be more like overlays than overrides

Discuss application theming and theme development.
ShareBird

User avatar
 
Posts: 2740
Joined: December 8th, 2004, 7:09 am
Location: Berlin | Made in Brasil

Post Posted December 1st, 2011, 3:43 pm

Patrick...
What is for you the "overlay method"? The override approach? If yes, this statement is totally wrong:
It used to be we could just ignore this stuff in overlay themes
The opposite. Using this method you can't ignore the rules from the default theme, because you have to override rules you don't like or don't fit your necessities. As I said before, normally you don't have to change a lot of things in your theme, because you are only touching a small piece of code (for example the code for toolbar buttons), but if the default theme changes the technique the use for those buttons, of course you have to change things in your theme...

And what drives you to think that
but ever since Firefox 4.0 came out the CSS has been more strict
??? Do you have a bug number for making Firefox be "more strict" to interpret CSS? Do you have a concrete example of this behavior?

And why should you
have to include everything the default theme has in order to override the instructions
??? Again: you just have to override the rules that don't fit your necessities.
Silvermel - A Theme for Firefox and Thunderbird
YATT - Yet Another Theme Tutorial
Don't give a man a fish. Teach him how to fish instead.

patrickjdempsey

User avatar
 
Posts: 23734
Joined: October 23rd, 2008, 11:43 am
Location: Asheville NC

Post Posted December 1st, 2011, 4:16 pm

I don't know anything about a bug number, it's just something I noticed happened during the 4.0 development process. It used to be that when you used !important it would override *all* of the styles for an element. So if I coded:

#stop-button {
list-style-image: url(chrome://browser/skin/stopbutton.png)!important;
-moz-image-region: rect(0px, 20px, 20px, 0px)!important;
}

... and no other different styles, then the stop button would just always show the static image of stopbutton.png. Now you *have* to include every variation of selectors that are in the default theme, or the image will change. That difference in how !important is handled makes a big difference in the level of complexity of one of these kinds of themes.
Tip of the day: If it has "toolbar" in the name, it's crap.
What my avatar is about: https://addons.mozilla.org/en-US/seamonkey/addon/sea-fox/

ShareBird

User avatar
 
Posts: 2740
Joined: December 8th, 2004, 7:09 am
Location: Berlin | Made in Brasil

Post Posted December 1st, 2011, 4:56 pm

patrickjdempsey wrote:I don't know anything about a bug number, it's just something I noticed happened during the 4.0 development process. It used to be that when you used !important it would override *all* of the styles for an element. So if I coded:

#stop-button {
list-style-image: url(chrome://browser/skin/stopbutton.png)!important;
-moz-image-region: rect(0px, 20px, 20px, 0px)!important;
}

... and no other different styles, then the stop button would just always show the static image of stopbutton.png. Now you *have* to include every variation of selectors that are in the default theme, or the image will change. That difference in how !important is handled makes a big difference in the level of complexity of one of these kinds of themes.

I don't understand what you are saying...

What do you think it should happen if the default theme uses something like
Code: Select all
#stop-button:hover {
  list-style-image: url(chrome://browser/skin/myOtherImage.png);
  -moz-image-region: rect(0px, 60px, 60px, 0px);
}
???

Are you saying that before FF4 your important flag used to "magically" override this rule??

Ahhh... And a very important lecture for the override approach:
http://www.w3.org/TR/CSS21/cascade.html#specificity
Silvermel - A Theme for Firefox and Thunderbird
YATT - Yet Another Theme Tutorial
Don't give a man a fish. Teach him how to fish instead.

patrickjdempsey

User avatar
 
Posts: 23734
Joined: October 23rd, 2008, 11:43 am
Location: Asheville NC

Post Posted December 1st, 2011, 5:37 pm

Maybe it was a glitch in the way things used to work, but yes !important tags could be used to override things without being explicit about every little detail. At least that's the way I remember it working... it's been a long year. ;)
Tip of the day: If it has "toolbar" in the name, it's crap.
What my avatar is about: https://addons.mozilla.org/en-US/seamonkey/addon/sea-fox/

LoudNoise
New Member

User avatar
 
Posts: 40048
Joined: October 18th, 2007, 1:45 pm
Location: Next door to the west

Post Posted December 1st, 2011, 8:09 pm

I really don't understand the need for an overlay theme nor this statement:
the blog wrote:Theme developers have to track all user interface changes and add corresponding changes to their themes — every 6 weeks, no way around it.


From what I understand you would have the better part of 12 weeks since few UI changes land on AURORA and nothing more then major breakage lands on the Beta. I would think you folks are in the same boat as the extension devs.
Post wrangler
"Choose between the Food Select Feature or other Functions. If no food or function is chosen, Toast is the default."

KLB

User avatar
 
Posts: 2282
Joined: December 21st, 2003, 9:25 am
Location: Saco Maine

Post Posted December 1st, 2011, 8:18 pm

LoudNoise wrote:I really don't understand the need for an overlay theme nor this statement:
the blog wrote:Theme developers have to track all user interface changes and add corresponding changes to their themes — every 6 weeks, no way around it.


From what I understand you would have the better part of 12 weeks since few UI changes land on AURORA and nothing more then major breakage lands on the Beta. I would think you folks are in the same boat as the extension devs.


1) Aurora's land every six weeks, just like betas and releases, so yes themes need to be updated at least every six weeks.

2) Extensions have it easier because tools have been developed that allows AMO to have a pretty good idea which extensions get broken by API changes and to warn those developers with enough time to make adjustments. Every theme gets broken with every release unless updates are made.

The only thing that can be done to help theme developers is for AMO editors like myself to test themes against Beta when updates are submitted for review and to warn theme developers of potential issues we find.
Ken Barbalace - AMO Editor (I focus on reviewing themes)
I maintain Classic Compact, a very compact yet clean Firefox theme.
EnvironmentalChemistry.com (Periodic Table)

patrickjdempsey

User avatar
 
Posts: 23734
Joined: October 23rd, 2008, 11:43 am
Location: Asheville NC

Post Posted December 2nd, 2011, 3:48 am

What doesn't help matters is that the folks programming for Mozilla these days don't understand the concept of global XUL and classes. The fact that the new HTML Inspector is using a resizer where there should be splitter is proof positive to me that some of these folks aren't even aware of what the basic XUL toolkit contains... and it's really not that many elements to learn. If new features actually used real XUL toolkit parts then themes would *automatically* support everything except the icons. The new addons manager and the tab view are basically completely devoid of standardized XUL and completely built out of custom BOX's so that when a non-compatible theme is loaded they are completely and utterly broken. I'm really surprised some of this stuff passes review.
Tip of the day: If it has "toolbar" in the name, it's crap.
What my avatar is about: https://addons.mozilla.org/en-US/seamonkey/addon/sea-fox/

ShareBird

User avatar
 
Posts: 2740
Joined: December 8th, 2004, 7:09 am
Location: Berlin | Made in Brasil

Post Posted December 4th, 2011, 4:59 am

Hi Patrick,
I've made some tests on FF3.6 and FF8.0 with the different states for toolbar buttons and yes, you are right. Indeed setting the !important flag for a button override rules for the different states.
BUT... FF8.0 behaviors exactly in the same way for the tests I've made....
Silvermel - A Theme for Firefox and Thunderbird
YATT - Yet Another Theme Tutorial
Don't give a man a fish. Teach him how to fish instead.

patrickjdempsey

User avatar
 
Posts: 23734
Joined: October 23rd, 2008, 11:43 am
Location: Asheville NC

Post Posted December 5th, 2011, 4:15 am

I spent exactly two hours hacking omni.jar to restructure it to run a simplified theme structure with a new "basic-theme" skin. That included the time it took me to figure out how to edit the chrome.manifest, what image files to copy or move over, and editing browser.css (in regular and /aero/) to fix the image paths and splitting off the parts I wanted in /basic-theme/ and the parts I wanted to leave in /browser/. I've successfully built a new skin that includes 34 images and 4 CSS files: basic-theme.css (based on browser.css), searchbar.css and findBar.css, organizer.css (for the places back/forward buttons). It works beautifully with no css errors or missing images. I also tested the new structure against Nasa Night Launch and it ran beautifully on top of this with no problems.

At the beginning of nonlocalized.manifest I added this line:
Code: Select all
# basic-theme.manifest
skin basic-theme classic/1.0 browser/skin/classic/basic-theme/


And at the beginning of browser.css I added this line:
@import url("chrome://basic-theme/skin/basic-theme.css");

In omni.jar: omni/chrome/browser/skin/classic/ I added the directory /basic-theme/ and dumped all of my stuff in there.

And that does 99% of the work. I also removed all of the code from searchbar.css and findBar.css and used an @import to call the new files in /basic-theme/.
Tip of the day: If it has "toolbar" in the name, it's crap.
What my avatar is about: https://addons.mozilla.org/en-US/seamonkey/addon/sea-fox/

Return to Theme Development


Who is online

Users browsing this forum: No registered users and 0 guests