ninetydegrees (90d)☕ (
ninetydegrees) wrote in
dreamscapes2011-09-17 11:38 am
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png)
Entry tags:
For THEME Designers: Helping Patchers Out
Here are a few things you can do to help developers patching themes. If you have the time and energy to do any of them, please consider it. Otherwise, don't worry, 'k?
-- Alphabetizing themes when your submit them seems like a tiny detail but actually makes editing our giant spreadsheet (currently at over 1,000 lines) ten times easier.
-- Keeping code lines alphabetized and removing any empty ones such as
-- Making sure you have set color_page_text as black may not be the default for everybody.
-- Keeping the # symbol before any color code. This one is pretty unexpected and very easy to miss so pretty please?
-- Using #000 for black and #fff for white instead of the full hexadecimal code. This works for #333, #666, etc.
-- Setting apart code lines which aren't color settings or things which won't end up in the theme such as module settings is very helpful too.
-- Sorting colors into categories -- page, header & footer / entry and comment / module -- would be most helpful, even if it's just by adding blank lines between section.
Besides testing, reformatting themes to sort settings into categories and adding proper headers is what takes patchers most time.
Here's a good example of what a color-only theme look like and here's another one with one with fonts, images and custom CSS.
Also, we've had about 200 new submissions since August. What have you been eating?! *is stunned*
-- Alphabetizing themes when your submit them seems like a tiny detail but actually makes editing our giant spreadsheet (currently at over 1,000 lines) ten times easier.
-- Keeping code lines alphabetized and removing any empty ones such as
set blahblahblah = "";
makes patching much easier and faster.-- Making sure you have set color_page_text as black may not be the default for everybody.
-- Keeping the # symbol before any color code. This one is pretty unexpected and very easy to miss so pretty please?
-- Using #000 for black and #fff for white instead of the full hexadecimal code. This works for #333, #666, etc.
-- Setting apart code lines which aren't color settings or things which won't end up in the theme such as module settings is very helpful too.
-- Sorting colors into categories -- page, header & footer / entry and comment / module -- would be most helpful, even if it's just by adding blank lines between section.
Besides testing, reformatting themes to sort settings into categories and adding proper headers is what takes patchers most time.
Here's a good example of what a color-only theme look like and here's another one with one with fonts, images and custom CSS.
Also, we've had about 200 new submissions since August. What have you been eating?! *is stunned*
no subject
(Also, aaa you used my theme as an example? I know I do a lot of custom CSS stuff like that and all, but still! Aaaaaa.)
Also, I try and remove the blank lines, and I'll try and remember to stick all the custom CSS at the bottom instead of at the top of layers, which is what I tend to do while I'm editing it because I want to see what I've got going and all that. :D So I will try and remember better, and such.
no subject
I'll try to remember re: blank lines but sometimes I forget. I'll at least try to alphabetise my next batch. /o\
no subject
Is there a specific preference for themes that set a color to be empty or blank where normally there would be a color?
For example, the Gradients themes I submitted for Crisped depend somewhat on blanking out/removing the background color for the entry titles, entry headers, and module headers so that the gradients will be visible. The way we did that was setting
set blahblahblah = "none";
instead ofset blahblahblah = "#NNNNNN";
—though I realized after submitting thatset blahblahblah = "transparent";
might work just as well, and might also be easier on the end user. We didn't really want to completely code background colors out of the CSS, in case the user wanted to have backgrounds in some places and gradients in others, instead of gradients everywhere.Is it also acceptable to edit for corrections when a theme is submitted but still under review? It occurred to us that some of the s2 color value choices that we originally made in the Gradients themes should be changed around for usability and easier user customization. (We realized that repurposing the currently "blanked" s2 border color for the drop shadow color makes more sense than matching the drop shadows to the s2 entry title color. It's not exactly a giant thing to fix, but we feel a little dumb now.)
no subject
Styles don't have default colors -- they're all set by themes -- so you shouldn't have to do this. Unless I'm misunderstanding what you mean here?
It's perfectly ok to edit your code. :)
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
I don't know what time it is in your part of the world and when you plan on doing this but I'm available on GoogleTalk if you need me or just want me to be there if you have questions (or you can comment here or PM me if you prefer) and I know there are always people on the #dreamwidth IRC channel willing to help.
no subject
no subject
Thanks for all the help so far!
no subject
no subject
I'll try and do this for next time. Could perhaps this bet stickied at the top of the community? It would be helpful for general reference. :D
no subject