[Ext] Stylish 0.4 (and userstyles.org)

[old np]

New thread

[rtk]

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.

[old np]

An easier way to find a style among all the styles you have is one of the things I plan for the next version. I'm not sure about categorizing, but I think I'll have a search.

I need to find some way to make people notice when I add stuff to the tips page.

[Old Makondo]

Thanks for the update, np. I do agree with rtk - would be nice to have some sort of order (right now i rename them but that doesn't work very well when updating). Search will do too, i guess. Better than nothing. TIA!

[Uncle Spellbinder]

Thanks, np. Auto-updated from the dev build nicely.

[alta88]

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

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.

[old np]

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".

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.

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]

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]).

[old np]

-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.

[XerBlade]

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:

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.

[alta88]

thanks for the explanantion, very useful.

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]

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 ?

[Old Makondo]

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.

[Old Makondo]

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.

[Zoolcar9]

Zoolcar9 (you know, yours is the only name i can type w/out pasting!)

You mean you have to paste np's name?

Which dropdown menu? Dropdown menu on a button? On location bar? Is the dropdown menu in the same toolbar with the menubar?