Brief - feed reading extension for Firefox

I'm not quite sure if this actually simplifies anything. Lets think about it. The new mechanism is supposed to let users style the extension without editing userChrome.css but I already accomplished that in 1.1 with my custom style sheet. I just supplied my own CSS which acted as an overlay for the original look. So in this regard nothing happened except for the way custom styles are being supplied to Brief. And in my opinion it's a change to worse.

The new mechanism should not only make it easier to customize stuff for yourself, but also to exchange these customizations with others, because you you'll be able apply a couple of separate customizations at once. In the old system, when customizations were distributed as replacements for the default style instead of sets of isolated rules, using more than one customization required merging their files, which was not fun (to say the least).

I really can't see how the users will benefit from this change as opposed to previous mechanism. For example, if I wanted to share my custom theme, I could upload the file somewhere and provide the link on the forums. Then someone else would download it, set the file as active theme in Brief and that's it. If he liked it, he'd keep it and if not, he'd just delete it. Simple and effective.

Not anymore, though, as currently trying a new theme requires the user to: backup his own changes by copying and pasting contents of the editor, paste new theme into the editor, check if he likes it and if not, delete the contents of the editor, open backup, paste its contents. A lot of hassle. And imagine that the user wants to check not one but - say - five new themes that he thinks he may like using. Oh my...

And on top of that the new editor requires the user to know CSS and to look into userChrome.css for reference just as much, as previous mechanism did. It is therefore safe to asssume that only a power user will edit themes and that he will prefer doing it with his own editor of choice, with syntax highlighting, snippets and whatnot.

Finally, it's going to make user styles more independent from the changes to the default appearance, so that you won't have to redo your customizations almost every time when upgrading Brief.

I am using my own theme for Brief since 1.1 version and until this beta it worked exactly like you said it would with the new mechanism.

I really can't see how the users will benefit from this change as opposed to previous mechanism. For example, if I wanted to share my custom theme, I could upload the file somewhere and provide the link on the forums. Then someone else would download it, set the file as active theme in Brief and that's it. If he liked it, he'd keep it and if not, he'd just delete it. Simple and effective.

Not anymore, though, as currently trying a new theme requires the user to: backup his own changes by copying and pasting contents of the editor, paste new theme into the editor, check if he likes it and if not, delete the contents of the editor, open backup, paste its contents. A lot of hassle. And imagine that the user wants to check not one but - say - five new themes that he thinks he may like using. Oh my...

I can hit you with an opposite example. Imagine that a user wants to make a simple change, for example increase the font size. How does he go about doing it?

• First he finds an option to select a custom style in the options window.
• "It looks like I have to provide a complete style replacement. I need to get the default style, so that I can modify it. Where do I get it from?".
• Sooner or later he's gonna think of looking for it on the extensions homepage. Tools > Add-ons > Extensions > Brief > context menu > Visit homepage. Either that or he's gonna Google it.
• "Yay, there's a page called Customization, that may be it!"
• He reads the guide and saves the default style somewhere on his disk.
• Then he opens the 250-line CSS file and searches for an appropriate rule, alters it, saves the file
• He picks the file from the Brief's options window.
• Thinks: "All this just to change the frigging font size?!"

And this is how he's gonna do it using the new system:

• First he finds an option to customize the CSS in the options window.
• "Oh, I can type in the rule here. But I need to know the structure of the page. There's a >>learn more<< link, let's try that"
• Takes a look at the HTML structure, finds out that .article-content is what he needs
• Goes back to options, enters the rule, confirms

That's more like it, isn't it?

Another example. Let's say that the user has already modified the font size and some other stuff here and there (using the old system). Now he comes across another customization that he likes, created by someone else. If he wants to apply that alternation, he needs to figure out which parts of that 250-line CSS file was modified compared to the default style and then manually merge it with his own 250-line CSS file. Madness!

Even complete styles usually modify a relatively small part of the default rules. The overwhelming majority of rules end up being common to all the styles. The new system allows for separation of significant rules from the boilerplate.

Yes, switching complete styles is a more time-consuming, but most actions are easier. It is a fair trade-off, I believe. Managing simple customizations is quick, managing big changes is a little slower, instead of vice versa.

Finally, there is something you can do to make switching styles a lot easier than you described. Just save a standalone CSS file on your disk, like you used to and add this to the custom style:

@import "file:///path-to-css-file";

To try out different styles, you just substitute the file name. You can add more than one @import to apply a couple of customizations at once. You can even link to remote CSS files, if you want!

ancestor,
creator of Brief

Well with the last two posts, this solves the issue of remote linking stylesheets. That is as long as one is willing to tag all the changes from the default style with "!important" -- ancestor, could you set Brief to automatically replace the default stylesheet if the import command is invoked? That would beat the heck out of marking "!important" to all changes from the default style...

Look at this suggestion like a compromise. You still get the intended editor functions (thanks for mentioning we can open brief-custom-style.css from our profile's chrome to speed up CSS editing) and advanced CSS stylesheet themers would be able to do advanced CSS editing without having to constantly invoke "!important" for every line they change.

Oh and by the way, you meant "@import url(*path to stylesheet here*);". For best importing results, store your custom stylesheet in your profile's chrome folder (this way you can do "@import url(/*stylesheet name here*.css); ). Oh and I see you moved feedview.css to your profile's "extensions/brief@mozdev.org/defaults/data" folder. Unless you're going to put the updated styleshet on your site, I'm still going to continue suggesting a quick link to the feedview.css from the CSS editor or Brief's options.

People (newbie and veteran alike) will still need to see what all options are available for tweaking. ;)

That's precisely what I wanted to do after installing Brief for the first time. It was version 1.1 and here's how I did it:

* Found the option
* Created single line file containing my rule
* Added path to my file in Brief

And that was it. Since Brief was loading its defaults before using my new set of rules, they worked as an overlay and I wasn't forced to dig through 250 lines of original CSS file. And I didn't have any negative thoughts about the process.

Impossible. You must be misremembering, you must have done more than that. In the old system Brief did not load the default style before applying the user's style. It does it now and this change was the whole point of the new system.

I still say the new mechanism is a regression. Sure, giving the user a simple editor that separates him from the code sounds very nice, but if the user ever wants to do something more than just changing font size, he can't avoid diving into the code, it just can't be helped. And in that case this editor works as a frustrating obstacle instead of being helpful.

Did you read my other post? You don't have to use the built-in editor if you don't want to, you can still use whatever text editing application you prefer. The user's style is still stored as a separate, standalone CSS file.

ancestor,
creator of Brief

ancestor wrote:
You often won't have to use !important. The custom style is included in the page after the default style and usually the custom rules will take precedence over the default ones even without the !important declaration.

Actually... Elements not marked as "!important" will be ignored if they match the default stylesheet's elements or be added if they don't match the default stylesheet's elements. Elements marked "!important" will override the default stylesheet's elements.

I prefer the past way where custom stylesheets overrode the default stylesheet. Now I cannot use full stylesheets any more. I have to use CSS rules tagged with "!important" to customize the default stylesheet. You've actually stifled advanced custom themeing in favor of simple CSS themeing.

To put that another way, you're stifling standards just like how Microsoft stifled standards with IE before all the open-source browsers came along. While I realize it's important to take into account newbies, you shouldn't do that at the expense of advanced users.

ancestor wrote:
Both forms are valid.

Some how the earlier method generated Error Console messages. Something about the file type ending abruptly before importing could be completed. I may just have specified the wrong path file syntax (IE, I gave the right path, but didn't enter it in the correct format...) though.