Open Timvde opened 5 years ago
Other than the latency, my primary motivation for forking was #58 - if we could all make the code reStyle-compatible, it would be easier for both developers and users to use this, like in the old Stylish days.
Here are my suggestions:
Require userStyle-compatibility for every new PR and possibly revise old ones (#58, maybe some CI?)
Now I read that again, I see no reason not to add an @-moz-document
to the styles. It seems better than the namespace I had in mind earlier.
Some kind of CSS lint CI (not familiar with CIs yet, so can't be more specific)
The thing is: me neither. I looked into this shortly, but I couldn't easily figure it out. That's why I proposed to do no checking at all.
Consistent branches - either automate the versioning with Firefox's calendar somehow or get rid of the branches altogether and just mention in code comments what it has been tested with
That's not really a lot for work actually. The problem there is that I postponed branching until after I merged in some PRs, but then never got to merging them...
No need to test every piece of code IMO, CSS can't do very malicious things (that could not be reverted easily)
Yes, it wasn't because of security, but correctness on all platforms. People usually only test on their own platform, but Firefox is different on all OSes, e.g. window buttons on the left in MacOS, no tabs in title bar on most Linux DEs...
I looked into this shortly, but I couldn't easily figure it out.
Quick search now found me this. https://github.com/marketplace/codefactor/
That's not really a lot for work actually
So you are willing to adjust all branches on every Firefox major update?
correctness on all platforms.
I guess that could be solved by issues:
Asking uploaders to just test them on everything is going to slow/demotivate things down, especially because Firefox changes its CSS very often nowadays.
I made a PR that adds all @-moz-document
blocks. I have no idea if I should apply them to the style in the extension
folder too. I copied the block from your quote in #58, but now I look at it, I actually think I should add quotes around the chrome://
url...
So you are willing to adjust all branches on every Firefox major update?
I won't maintain older branches, just fork once after every move from Nightly to beta
I guess that could be solved by issues
Agreed, that was the plan.
Asking uploaders to just test them on everything is going to slow/demotivate things down, especially because Firefox changes its CSS very often nowadays.
Yes, that's exactly what I noticed too, which is why I want to loosen it up.
I'll review your PR soon.
So how are the branches going to work for contributors? You should clarify that in contributing.md to make everyone push to the right one.
Also, you might want to create an issue template too.
So how are the branches going to work for contributors? You should clarify that in contributing.md to make everyone push to the right one.
The PR should usually be to master. I won't merge new features in other branches, although I'd take a PR for beta or release (not for unsupported versions) if they fix a bug.
Also, you might want to create an issue template too.
What should be in it?
What should be in it?
Assuming the issue is about a style, otherwise the template can be ignored by the user.
https://help.github.com/articles/about-issue-and-pull-request-templates/
Hi all,
I started this repository because I had the feeling somebody needed to step up and do it. Over the past year-and-a-few-months, I learned a few things:
So, how would I like to proceed? I still think that this repository can have purpose for many, and seeing PRs arrive every now and then, I think I'm not alone. So I'd like to make this a real community repository that minimizes the work for me, and gives all of you more freedom. More concretely:
How does this sound?
@Madis0 I am particularly interested in your opinion, as I see that you have forked this repository.