[Ext] Stylish 0.4 (and userstyles.org)
-
- Posts: 0
- Joined: December 31st, 1969, 5:00 pm
[Ext] Stylish 0.4 (and userstyles.org)
Last edited by old np on January 22nd, 2007, 2:12 pm, edited 3 times in total.
-
- Posts: 275
- Joined: January 17th, 2005, 4:33 pm
nice work NP!
Now that the site categorizes styles, is there plans to expand this grouping into the extension itself? For those of us with dozens of styles, it's getting a little crowded in there.
As well, I'd neglected to note that with this change, the "website - cleaner:" junk isn't needed, but it wasn't until I was bored and browsing the tips section that I noted you are now actively discouraging their use. I'd guess most of the authors haven't read this page in a long time, if ever.
Now that the site categorizes styles, is there plans to expand this grouping into the extension itself? For those of us with dozens of styles, it's getting a little crowded in there.
As well, I'd neglected to note that with this change, the "website - cleaner:" junk isn't needed, but it wasn't until I was bored and browsing the tips section that I noted you are now actively discouraging their use. I'd guess most of the authors haven't read this page in a long time, if ever.
rtk
-
- Posts: 0
- Joined: December 31st, 1969, 5:00 pm
-
- Posts: 0
- Joined: December 31st, 1969, 5:00 pm
- Uncle Spellbinder
- Posts: 3519
- Joined: May 28th, 2004, 4:52 pm
- Location: Highland, IN - U.S.A.
- Contact:
Thanks, np. Auto-updated from the dev build nicely.
My Firefox Add-Ons Collection: Firefox Essentials
-
- Posts: 1029
- Joined: January 28th, 2006, 3:08 pm
nice indeed. some comments:
1. update feature is very nice. but how does it work, ie match style name and overwrite, or do a dif type update? would user changes in stylish.org styles be lost etc.? also, a last changed/updated date column would be useful to keep track (or is this overkill for frequency of updates here).
2. if Fx or Tb is started with a style active, then deactivating does not apply the deactivation; to do tweaking one has to start without the style active, then activate/apply, then it's possible to deactivate/apply. is this just the way it has to work, given state of stylesheet apply bugs etc.? this is re chrome, not html..
3. i noticed the 'stylish replaces these extensions' section; it can be fine tuned/expanded a bit, and is a great idea.
re RIP: i'd like to get rid of it (ab+, rip, and stylish is 1 too many). but can't, since RIP's rt click element highlight/select for block is unbeatable. it's too difficult for both novice and DOMi maven to manually find stuff like
can anyone take something like Aardvark, or Mouseover DOMi, or RIP code and just make a very lite extension with very granular element highlighting and copy to clipboard in 1) css format, 2) AB+ format, 3)xpath format?
and if this were built into Stylish, wow too cool.
1. update feature is very nice. but how does it work, ie match style name and overwrite, or do a dif type update? would user changes in stylish.org styles be lost etc.? also, a last changed/updated date column would be useful to keep track (or is this overkill for frequency of updates here).
2. if Fx or Tb is started with a style active, then deactivating does not apply the deactivation; to do tweaking one has to start without the style active, then activate/apply, then it's possible to deactivate/apply. is this just the way it has to work, given state of stylesheet apply bugs etc.? this is re chrome, not html..
3. i noticed the 'stylish replaces these extensions' section; it can be fine tuned/expanded a bit, and is a great idea.
re RIP: i'd like to get rid of it (ab+, rip, and stylish is 1 too many). but can't, since RIP's rt click element highlight/select for block is unbeatable. it's too difficult for both novice and DOMi maven to manually find stuff like
Code: Select all
center > p > table:first-child + table > tbody > tr > td:first-child + td + td > table > tbody:first-child > tr:first-child {
display: none !important;
}
can anyone take something like Aardvark, or Mouseover DOMi, or RIP code and just make a very lite extension with very granular element highlighting and copy to clipboard in 1) css format, 2) AB+ format, 3)xpath format?
and if this were built into Stylish, wow too cool.
-
- Posts: 0
- Joined: December 31st, 1969, 5:00 pm
alta88 wrote:update feature is very nice. but how does it work, ie match style name and overwrite, or do a dif type update? would user changes in stylish.org styles be lost etc.? also, a last changed/updated date column would be useful to keep track (or is this overkill for frequency of updates here).
When you install a style from userstyles.org, it records meta-data from that page. One of the pieces of data it gets is an update URL associated to that style. When you first save a style, it saves a "current" copy of the CSS, and an "original" copy. If you edit a style, you're changing the "current" copy and the style is marked as "Customized".
When you run Find Updates, it downloads the CSS from the update URL it recorded for each style and compares it to the "original" copy. If they're different, it's listed as an update. If you customized the style, that's also marked so that you don't blow away the customizations you have and the one on userstyles.org doesn't.
When you choose to update a style, both "original" and "current" copies get replaced by what's on the server and the style is set back to "not customized".
alta88 wrote:if Fx or Tb is started with a style active, then deactivating does not apply the deactivation; to do tweaking one has to start without the style active, then activate/apply, then it's possible to deactivate/apply. is this just the way it has to work, given state of stylesheet apply bugs etc.? this is re chrome, not html.
Yes, this is the way the Gecko interface works pre-3.0. In 3.0 (including trunk nightlies), this works perfectly. 3.0 also resolves the issue you get when you don't include !important.
alta88 wrote:RIP's rt click element highlight/select for block is unbeatable (...) and if this were built into Stylish, wow too cool.
Yes, that's one of the things I'm looking at for the next version. XPath (which is what RIP uses) is more suited to this than CSS (which is what Stylish uses), but it should be doable.
- XerBlade
- Posts: 865
- Joined: October 4th, 2005, 10:45 pm
- Location: Nashville, TN, US
np wrote:alta88 wrote:update feature is very nice. but how does it work, ie match style name and overwrite, or do a dif type update? would user changes in stylish.org styles be lost etc.? also, a last changed/updated date column would be useful to keep track (or is this overkill for frequency of updates here).
When you install a style from userstyles.org, it records meta-data from that page. One of the pieces of data it gets is an update URL associated to that style. When you first save a style, it saves a "current" copy of the CSS, and an "original" copy. If you edit a style, you're changing the "current" copy and the style is marked as "Customized".
When you run Find Updates, it downloads the CSS from the update URL it recorded for each style and compares it to the "original" copy. If they're different, it's listed as an update. If you customized the style, that's also marked so that you don't blow away the customizations you have and the one on userstyles.org doesn't.
When you choose to update a style, both "original" and "current" copies get replaced by what's on the server and the style is set back to "not customized".
What if you included a timestamp in the style meta-data on UserStyles.org to be downloaded as well as the updateURL, and checking for updates just checked against the timestamp [then only download the CSS for styles you choose to update]? And just have a boolean value that's toggled true when you edit a style to show it's been customized and back to false if you overwrite it with an update? Seems to me that would be cleaner than storing two copies of every style and downloading the entire CSS of every style when checking for updates, especially when you have a lot of styles. After all, my stylish.rdf is over a meg and update checks are pretty slow (on a 6.0Mbps broadband connection [I clocked one just now at 40 seconds]).
-
- Posts: 0
- Joined: December 31st, 1969, 5:00 pm
-The update feature also allows for updates from static CSS files, which have no meta-data.
-Checking against a timestamp assumes that both server and client clocks are in sync.
-The update doesn't take long because there's a lot to download, it takes long because the userstyles.org is a shared server and sometimes the database lookup is slow. It would likely take the same amount of time to fetch a bunch of dates as a bunch of CSS.
-Checking against a timestamp assumes that both server and client clocks are in sync.
-The update doesn't take long because there's a lot to download, it takes long because the userstyles.org is a shared server and sometimes the database lookup is slow. It would likely take the same amount of time to fetch a bunch of dates as a bunch of CSS.
- XerBlade
- Posts: 865
- Joined: October 4th, 2005, 10:45 pm
- Location: Nashville, TN, US
All right, near the end of the previous thread, someone, I forgot who, during the discussion on the Stylish toolbar button dropmarker being below the icon on Firefox 2.0, mentioned that toolbar button dropmarkers seemed too high (which I noticed, but it was very recent). Well, I looked into this, as well as the causes of some other toolbar nuances I'd been noticing, and found that all but 2 were actually caused by the same thing (the other 2 by extensions I have [poorly made] toolbar buttons for [which I plan to alert them to as soon as I can figure out how to contact the elusive devs for them]). I asked in the builds thread about it, and found out the cause was the fix/work-around for bug 351623, which is in Firefox 2.0 RC1 (and the nightlies for the last couple weeks). Anyway, the problem is not that the dropmarkers are too high, but the icons are too low.
Here's my work-around for it:
I might post this or a later revised version on UserStyles.org eventually if this isn't fixed in Firefox before 2.0 final is released.
Edit: zeniko just filed bug 354884 about this, but it still might not make it into 2.0.
Here's my work-around for it:
Code: Select all
@namespace url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul);
/* work-around for issues caused by the bug 351623 work-around */
toolbar:not([iconsize="small"]) .toolbarbutton-1 .toolbarbutton-icon {
padding-top: 0 !important;
}
toolbar:not([iconsize="small"]) #back-button .toolbarbutton-icon,
toolbar:not([iconsize="small"]) #forward-button .toolbarbutton-icon,
toolbar:not([iconsize="small"]) #stop-button .toolbarbutton-icon,
toolbar:not([iconsize="small"]) #reload-button .toolbarbutton-icon,
toolbar:not([iconsize="small"]) #home-button .toolbarbutton-icon,
toolbar:not([iconsize="small"]) #new-tab-button .toolbarbutton-icon,
toolbar:not([iconsize="small"]) #new-window-button .toolbarbutton-icon,
toolbar:not([iconsize="small"]) #downloads-button .toolbarbutton-icon,
toolbar:not([iconsize="small"]) #history-button .toolbarbutton-icon,
toolbar:not([iconsize="small"]) #bookmarks-button .toolbarbutton-icon,
toolbar:not([iconsize="small"]) #cut-button .toolbarbutton-icon,
toolbar:not([iconsize="small"]) #copy-button .toolbarbutton-icon,
toolbar:not([iconsize="small"]) #paste-button .toolbarbutton-icon,
toolbar:not([iconsize="small"]) #print-button .toolbarbutton-icon {
margin-bottom: -1px !important;
}
I might post this or a later revised version on UserStyles.org eventually if this isn't fixed in Firefox before 2.0 final is released.
Edit: zeniko just filed bug 354884 about this, but it still might not make it into 2.0.
Last edited by XerBlade on September 29th, 2006, 4:41 pm, edited 1 time in total.
-
- Posts: 1029
- Joined: January 28th, 2006, 3:08 pm
thanks for the explanantion, very useful.
personally, this is the top enhancement i'd like in the Fx world (yeah it's getting really good). there was discussion of this in ABP, and it was felt (rather legitimately) that there exist user support issues as error would be easy and pinpointing it hard to find with element blocking. so the idea for a separate extension.
great news; hope to discuss more as you get to it.
np wrote:alta88 wrote:RIP's rt click element highlight/select for block is unbeatable (...) and if this were built into Stylish, wow too cool.
Yes, that's one of the things I'm looking at for the next version. XPath (which is what RIP uses) is more suited to this than CSS (which is what Stylish uses), but it should be doable.
personally, this is the top enhancement i'd like in the Fx world (yeah it's getting really good). there was discussion of this in ABP, and it was felt (rather legitimately) that there exist user support issues as error would be easy and pinpointing it hard to find with element blocking. so the idea for a separate extension.
great news; hope to discuss more as you get to it.
- theaulddubliner
- Posts: 78
- Joined: January 11th, 2005, 8:29 pm
- Location: Dublin
i remember a long time ago [pre or just after fx 1] adding something to my usercontent to make menus stay open till i clicked off them
what i was wondering is would it be possible to make bookmark dropdowns stay open after i have made a selection in case i wish to make a subsequent selection
am i describing this correctly ?
what i was wondering is would it be possible to make bookmark dropdowns stay open after i have made a selection in case i wish to make a subsequent selection
am i describing this correctly ?
:: the auld dubliner ::
-
- Posts: 0
- Joined: December 31st, 1969, 5:00 pm
I know exactly what you mean - 've been annoyed by this forever! Wonder why this isn't fixed in Fx yet but suspect it might be in 3.0. Until then, could someone write a style, please?
XerBlade,
that's very interesting, thanks for posting. I have a problem only with 3 buttons - two LI, Edit My Config and EM (must be TM as well but i don't use it). They both have an arrow on the right side and both are 1px too low. The other one is actually a custom button for closed tabs (made out of TMP, as i understand). Below, i grouped them so that it can be easily seen. Stylish used to look exactly the same, low, before i removed the dropmarker:
I applied your code (id changed, of course) and it didn't work. But i think it shows that you're correct (and i have to work on id's, i guess, a bit more...)
Oh, and one more thing, np! I think this has been asked before, is there a way (style?) to have multi styles open instead of reusing the edit window? TIA.
XerBlade,
that's very interesting, thanks for posting. I have a problem only with 3 buttons - two LI, Edit My Config and EM (must be TM as well but i don't use it). They both have an arrow on the right side and both are 1px too low. The other one is actually a custom button for closed tabs (made out of TMP, as i understand). Below, i grouped them so that it can be easily seen. Stylish used to look exactly the same, low, before i removed the dropmarker:
I applied your code (id changed, of course) and it didn't work. But i think it shows that you're correct (and i have to work on id's, i guess, a bit more...)
Oh, and one more thing, np! I think this has been asked before, is there a way (style?) to have multi styles open instead of reusing the edit window? TIA.
-
- Posts: 0
- Joined: December 31st, 1969, 5:00 pm
Zoolcar9 (you know, yours is the only name i can type w/out pasting!),
there seems to be another prob with your sliding menu style: when hovered and menu items slide out, if i click on an item, i can't then click on a dropdown menu, it disappears. Hope you understand what i mean. I thought it might be due to some of my bar(-s) sizing but if i disable the style, there's no problem, dropdown menus stay put.
there seems to be another prob with your sliding menu style: when hovered and menu items slide out, if i click on an item, i can't then click on a dropdown menu, it disappears. Hope you understand what i mean. I thought it might be due to some of my bar(-s) sizing but if i disable the style, there's no problem, dropdown menus stay put.
-
- Posts: 2225
- Joined: November 9th, 2004, 6:45 pm
- Location: Jakarta, Indonesia (UTC+7)
- Contact: