3 ms·

Indeed, 100%. I learned to never do such things, and would rather not have a rule than have a brittle one. This explains that my experience differs from OP's.

db48x 3y ago
There are better ways to do it. For example, you can match elements containing specific text, such as the text that introduced the annoyance. On NewEgg you might match the text “Download our app” and use it to remove that whole box.
- ronjouch 3y ago
  Yup yup. - Standard CSS (for userContent.css): https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_selectors https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_s... - uBlock Origin: https://github.com/gorhill/uBlock/wiki/Static-filter-syntax https://github.com/gorhill/uBlock/wiki/Static-filter-syntax & https://github.com/gorhill/uBlock/wiki/Procedural-cosmetic-filters https://github.com/gorhill/uBlock/wiki/Procedural-cosmetic-f... Still, sometimes it's difficult/impossible to make a reliable filter, and in such cases I'd rather not have it than have a brittle one.
  - mig4ng 3y ago
    Yes, I feel the same. Even though I still have some brittle rules, I avoid most and prefer filtering for specific text or classes/ids and find the correct element from there. Before I did not use uBlock to filter elements that much because I used the filter. I wonder if you have your filter rules open source or available somewhere. Please share.
    - ronjouch 3y ago
      I didn't make the effort to share them, sorry. That being said, 1. My rules are not any different from yours. I doubt you'll learn much from them given what you're already doing in your repo. 2. I feel that the "what to hide" / "not to hide" choice is too personal to be reusable by anyone else. I'm sure some of the stuff I hide will be considered excessive, and some will be considered missing. What I enjoy in this HN thread is that we share the { practice, tools, docs, tips }, then to each their own :) 3. I'm not interested in maintaining a public repo of that kind of stuff, and/or replying to Issues. So, would rather not make it public. Sorry/notsorry ¯\_(ツ)_/¯ , at any rate, glad we're sharing tips around the practice.
      - mig4ng 3y ago
        The repository I shared is very opinionated and I will decide what goes in or not (a benevolent dictatorship). I want to make it easy for me to maintain, and others to use/fork if they want. You could share them publicly without having the burden of replying to issues/PRs etc. But I get you.

db48x 3y ago

There are better ways to do it. For example, you can match elements containing specific text, such as the text that introduced the annoyance. On NewEgg you might match the text “Download our app” and use it to remove that whole box.

ronjouch 3y ago
Yup yup. - Standard CSS (for userContent.css): https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_selectors https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_s... - uBlock Origin: https://github.com/gorhill/uBlock/wiki/Static-filter-syntax https://github.com/gorhill/uBlock/wiki/Static-filter-syntax & https://github.com/gorhill/uBlock/wiki/Procedural-cosmetic-filters https://github.com/gorhill/uBlock/wiki/Procedural-cosmetic-f... Still, sometimes it's difficult/impossible to make a reliable filter, and in such cases I'd rather not have it than have a brittle one.
- mig4ng 3y ago
  Yes, I feel the same. Even though I still have some brittle rules, I avoid most and prefer filtering for specific text or classes/ids and find the correct element from there. Before I did not use uBlock to filter elements that much because I used the filter. I wonder if you have your filter rules open source or available somewhere. Please share.
  - ronjouch 3y ago
    I didn't make the effort to share them, sorry. That being said, 1. My rules are not any different from yours. I doubt you'll learn much from them given what you're already doing in your repo. 2. I feel that the "what to hide" / "not to hide" choice is too personal to be reusable by anyone else. I'm sure some of the stuff I hide will be considered excessive, and some will be considered missing. What I enjoy in this HN thread is that we share the { practice, tools, docs, tips }, then to each their own :) 3. I'm not interested in maintaining a public repo of that kind of stuff, and/or replying to Issues. So, would rather not make it public. Sorry/notsorry ¯\_(ツ)_/¯ , at any rate, glad we're sharing tips around the practice.
    - mig4ng 3y ago
      The repository I shared is very opinionated and I will decide what goes in or not (a benevolent dictatorship). I want to make it easy for me to maintain, and others to use/fork if they want. You could share them publicly without having the burden of replying to issues/PRs etc. But I get you.