4 ms·

You've never had to search through multiple stylesheets and Inspect to figure out inheritance and cascading for a CSS rule that is resisting editing? I recently

You've never had to search through multiple stylesheets and Inspect to figure out inheritance and cascading for a CSS rule that is resisting editing? I recently had to work with another developer's codebase that had four different CSS files influencing the HTML, only to find in a fifth file an !important that was mucking everything up. If you haven't experienced costly context switching working on FE then consider yourself fortunate.

emmacharp 3y ago
Well, this is bad CSS indeed. But it does not have to be that way. A little linting with Stylelint can make sure this does not happen. As an added bonus there are less dependencies and complexity.
nhinck 3y ago
No, the element inspector will tell you what css file the rule is coming from.
- yurishimo 3y ago
  Assuming you work with a build system that can generate source maps...
  - emmacharp 3y ago
    This is easy and should not be a problem. It also is the kind of help/solution that should be implemented first, before any librairies or frameworks are added.
    - for1nner 3y ago
      "should" is often the enemy of "speed" even when it's the _correct_ way to build a system. I think most of us here have experienced that at businesses of varying sizes.
      - emmacharp 3y ago
        As I said below, I don't understand how the number of team members can impede our capacity to activate source maps. Again, I may be wrong so go ahead and tell me if that's the case.
    - ofcourseyoudo 3y ago
      Have you worked on a FE team with 5 or more people? There's a lot that is easy and shouldn't be a problem when you get to define the scope and technologies and shared conventions used.
      - emmacharp 3y ago
        Yes, I have. And I don't see how it can impact the feasibility and easiness of activating source maps. I may be wrong, though. Don't hesitate to correct me if that's the case.
        ofcourseyoudo 3y ago
        I'm not particularly interested in arguing the specifics of a solution, my point is that on a larger team especially where an individual does not get to define the approach, I'm surprised that you haven't run into issues with context switching or hunting. But regarding one of your specifics, for example you said "the kind of help/solution that should be implemented first" before frameworks are added. On the teams you've been on, was it easy for a developer (especially a junior) to say "Hey, we should really be implementing X, and we should have done it before I joined the team, can we restructure at this point?"
        emmacharp 3y ago
        Well, I'd say yes, we welcomed and considered any proposition made by our team members, junior or not. The CTO makes the final decision. But if it's a good idea, it'll be included in the workflow, yes. Source maps would be a good example of this. And it's not hard to include in my experience, even more when considering the added value. And, yes, I've had problems in the past with hunting rules as you say. But it's been a good long while since it happened.

emmacharp 3y ago

Well, this is bad CSS indeed. But it does not have to be that way. A little linting with Stylelint can make sure this does not happen. As an added bonus there are less dependencies and complexity.

nhinck 3y ago

No, the element inspector will tell you what css file the rule is coming from.

yurishimo 3y ago
Assuming you work with a build system that can generate source maps...
- emmacharp 3y ago
  This is easy and should not be a problem. It also is the kind of help/solution that should be implemented first, before any librairies or frameworks are added.
  - for1nner 3y ago
    "should" is often the enemy of "speed" even when it's the _correct_ way to build a system. I think most of us here have experienced that at businesses of varying sizes.
    - emmacharp 3y ago
      As I said below, I don't understand how the number of team members can impede our capacity to activate source maps. Again, I may be wrong so go ahead and tell me if that's the case.
  - ofcourseyoudo 3y ago
    Have you worked on a FE team with 5 or more people? There's a lot that is easy and shouldn't be a problem when you get to define the scope and technologies and shared conventions used.
    - emmacharp 3y ago
      Yes, I have. And I don't see how it can impact the feasibility and easiness of activating source maps. I may be wrong, though. Don't hesitate to correct me if that's the case.
      - ofcourseyoudo 3y ago
        I'm not particularly interested in arguing the specifics of a solution, my point is that on a larger team especially where an individual does not get to define the approach, I'm surprised that you haven't run into issues with context switching or hunting. But regarding one of your specifics, for example you said "the kind of help/solution that should be implemented first" before frameworks are added. On the teams you've been on, was it easy for a developer (especially a junior) to say "Hey, we should really be implementing X, and we should have done it before I joined the team, can we restructure at this point?"
        emmacharp 3y ago
        Well, I'd say yes, we welcomed and considered any proposition made by our team members, junior or not. The CTO makes the final decision. But if it's a good idea, it'll be included in the workflow, yes. Source maps would be a good example of this. And it's not hard to include in my experience, even more when considering the added value. And, yes, I've had problems in the past with hunting rules as you say. But it's been a good long while since it happened.