4 ms·

> Having a good justification for misuse doesn't make it not misuse. If there is a good justification for misuse, that would logically mean the original intent

by bryans 5y ago

> Having a good justification for misuse doesn't make it not misuse. If there is a good justification for misuse, that would logically mean the original intent isn't applicable to real world scenarios -- which doesn't make the intent incorrect, but it does betray short-sightedness. To claim misuse strictly because it's outside of that extremely narrow original vision, is completely disregarding the actual logistics of front-end development.

galaxyLogic 5y ago
It's a bold claim to say that "anything else is misuse". To prove a claim like that you would have to show how every possible use of !important is "misuse", except when it is for font-size problems. Now maybe it is possible to show that every conceivable other use is misuse, but until we see such a proof we shouldn't just take for granted just because somebody makes such a claim. A better claim would be "I don't see any good reason to use it". Just because one person doesn't see any good reason to use it doesn't mean there isn't one, or two, or three, or more. It is always very hard to prove a negative ("There isn't any such that ...")
- willseth 5y ago
  Pemberton is one of the OG designers of the spec. He explained the motivation for the feature when it was designed in committee. It's a much bolder claim to say that because you find it useful in some other way, it's not misuse. If you have a specific case where you think it shouldn't be considered misuse, I'm sure he'd be happy to explain to you how it should be avoided. He's a friendly guy. But you did not design CSS. He did, so you fundamentally misunderstand that the burden is on you to prove there are cases where !important cannot reasonably be avoided, not the other way around.
  - galaxyLogic 5y ago
    When anybody says "Everything else is misuse" that is a very large claim because "everything else" includes very many things. Thus the burden is on them, or you, to give evidence to such a broad claim, if you want us to believe that the validity of such a claim. I don't have a burden to prove anything since I'm making no claims except saying that whoever makes a broad claim should offer some evidence for it. The broader the claim, more evidence is needed, to convince your readers.
    - willseth 5y ago
      The evidence is that he was one of the designers. You seem to be missing the very simple fact that CSS is has not always existed, and it was not suddenly discovered by programmer explorers, whose prerogative it is to define its usage by their usage. It was designed by a standards body. Of designers. The designers designed the usage, and it's the designers' prerogative to define mis-use.
willseth 5y ago
That's not what it means at all. It just means you find it easier to work outside of the spec's design. He's very clearly saying that if you are doing that, it's always possible to avoid it and work within the intent of the spec instead. If you're happier working outside of that, good for you. The "logistics" of you needing to get your work done has no bearing on what the designers of the tools you're using intended.
- bryans 5y ago
  > He's very clearly saying that if you are doing that, it's always possible to avoid it and work within the intent of the spec instead. No, he very plainly (almost literally) said that if the tool isn't used exclusively in the way that he imagined, then you don't understand what you're doing. It was a blatant attempt at belittling a community which has been forced to tirelessly work around CSS's terrible spec for decades. > The "logistics" of you needing to get your work done has no bearing on what the designers of the tools you're using intended. You have this completely backward, and you may think you're defending Pemberton, but you're actually making him look more elitist and foolish by highlighting why the real world is different from the spec. Implementations of CSS have been an absolute disaster since day one, and that is largely because of early design mistakes that did not account for countless scenarios and necessary functionality, making interfaces extremely difficult to both build and test, and forcing browser developers to create their own solutions over decades. A lot of those have been "fixed" by adding completely new methods (flex, etc) to replace the broken concepts, but that doesn't automagically make the original bad spec any better, which to this day still makes everything in CSS more difficult than it needs to be. If a designer is not factoring in those real-world elements, then they have completely failed at their task, because the real world is the part that actually matters -- everything else is an ideological theory.
  - galaxyLogic 5y ago
    I second that. Well said. Trying to get something look like you want with CSS takes too much time. If you know what you want it should be easy but it takes a lot of trial and error. Because of that we now have Flexbox and Grid. The problem with all the new add-ons is the amount of stuff you must learn and remember about how they work and how they work together, or don't, to get the results you want. Then to hear from someone that the problem is "You don't understand the cascade" is annoying. The question is why don't I understand the cascade? The answer is because it is complicated, and it's not only about understanding it in principle but about then understanding its effects on your (current state of) application, and how you should or could change the cascading elements and or where they are defined to make your app look like you want. And then the answer is perhaps: "Clearly you don't understand it but it is really easy" -- implying it is difficult for you because you are dumb or lazy and not a very good developer in general. Give me a break :-) I wonder if it would help if the !important -feature should in fact be extended so you could have !important2, !important3, etc. with increasing levels of importance. That might make things easier, in practice. Or even better make it work like "z-index" does. If z-index can take on any numeric value including negative ones, why not have the same with "importance"? That would mean that instead of having to calculate the "specificity" in your head, correctly, to understand what is happening with your app, you could just choose the specificity you want and make it part of any rule whose impact you want to differ from the default. "Custom Specificity for CSS"

by bryans 5y ago

galaxyLogic 5y ago

It's a bold claim to say that "anything else is misuse". To prove a claim like that you would have to show how every possible use of !important is "misuse", except when it is for font-size problems. Now maybe it is possible to show that every conceivable other use is misuse, but until we see such a proof we shouldn't just take for granted just because somebody makes such a claim. A better claim would be "I don't see any good reason to use it". Just because one person doesn't see any good reason to use it doesn't mean there isn't one, or two, or three, or more. It is always very hard to prove a negative ("There isn't any such that ...")

willseth 5y ago
Pemberton is one of the OG designers of the spec. He explained the motivation for the feature when it was designed in committee. It's a much bolder claim to say that because you find it useful in some other way, it's not misuse. If you have a specific case where you think it shouldn't be considered misuse, I'm sure he'd be happy to explain to you how it should be avoided. He's a friendly guy. But you did not design CSS. He did, so you fundamentally misunderstand that the burden is on you to prove there are cases where !important cannot reasonably be avoided, not the other way around.
- galaxyLogic 5y ago
  When anybody says "Everything else is misuse" that is a very large claim because "everything else" includes very many things. Thus the burden is on them, or you, to give evidence to such a broad claim, if you want us to believe that the validity of such a claim. I don't have a burden to prove anything since I'm making no claims except saying that whoever makes a broad claim should offer some evidence for it. The broader the claim, more evidence is needed, to convince your readers.
  - willseth 5y ago
    The evidence is that he was one of the designers. You seem to be missing the very simple fact that CSS is has not always existed, and it was not suddenly discovered by programmer explorers, whose prerogative it is to define its usage by their usage. It was designed by a standards body. Of designers. The designers designed the usage, and it's the designers' prerogative to define mis-use.

willseth 5y ago

That's not what it means at all. It just means you find it easier to work outside of the spec's design. He's very clearly saying that if you are doing that, it's always possible to avoid it and work within the intent of the spec instead. If you're happier working outside of that, good for you. The "logistics" of you needing to get your work done has no bearing on what the designers of the tools you're using intended.

bryans 5y ago
> He's very clearly saying that if you are doing that, it's always possible to avoid it and work within the intent of the spec instead. No, he very plainly (almost literally) said that if the tool isn't used exclusively in the way that he imagined, then you don't understand what you're doing. It was a blatant attempt at belittling a community which has been forced to tirelessly work around CSS's terrible spec for decades. > The "logistics" of you needing to get your work done has no bearing on what the designers of the tools you're using intended. You have this completely backward, and you may think you're defending Pemberton, but you're actually making him look more elitist and foolish by highlighting why the real world is different from the spec. Implementations of CSS have been an absolute disaster since day one, and that is largely because of early design mistakes that did not account for countless scenarios and necessary functionality, making interfaces extremely difficult to both build and test, and forcing browser developers to create their own solutions over decades. A lot of those have been "fixed" by adding completely new methods (flex, etc) to replace the broken concepts, but that doesn't automagically make the original bad spec any better, which to this day still makes everything in CSS more difficult than it needs to be. If a designer is not factoring in those real-world elements, then they have completely failed at their task, because the real world is the part that actually matters -- everything else is an ideological theory.
- galaxyLogic 5y ago
  I second that. Well said. Trying to get something look like you want with CSS takes too much time. If you know what you want it should be easy but it takes a lot of trial and error. Because of that we now have Flexbox and Grid. The problem with all the new add-ons is the amount of stuff you must learn and remember about how they work and how they work together, or don't, to get the results you want. Then to hear from someone that the problem is "You don't understand the cascade" is annoying. The question is why don't I understand the cascade? The answer is because it is complicated, and it's not only about understanding it in principle but about then understanding its effects on your (current state of) application, and how you should or could change the cascading elements and or where they are defined to make your app look like you want. And then the answer is perhaps: "Clearly you don't understand it but it is really easy" -- implying it is difficult for you because you are dumb or lazy and not a very good developer in general. Give me a break :-) I wonder if it would help if the !important -feature should in fact be extended so you could have !important2, !important3, etc. with increasing levels of importance. That might make things easier, in practice. Or even better make it work like "z-index" does. If z-index can take on any numeric value including negative ones, why not have the same with "importance"? That would mean that instead of having to calculate the "specificity" in your head, correctly, to understand what is happening with your app, you could just choose the specificity you want and make it part of any rule whose impact you want to differ from the default. "Custom Specificity for CSS"