101–109 of 109 posts
.rabbit.drivingACar.onIce.withRocketBoosters {
color: pink; /* pretty specific */
}Earlier quoted context omitted.
Once I needed to make an internal IE addon to listen for certain elements being selected on pages outside of our control. (to ensure we never collected sensitive data for compliance reasons, long story. Trust me it makes more sense in context than it does in a single paragraph.) My co-worker wanted to grab by id and attach listeners, but I was convinced that wouldn't work. I wanted to listen at the top level and filt…
A friend once told me about a girl in their cs 101 class, who learned about arrays, and proceeded to make every variable an array. When queried, she responded, "I might end up realizing I need a multiple of the variable, and this way I won't have to change anything when I do".
I get where you're coming from, but I don't think it's a good reason to avoid classes. That's what they're there for.
Earlier quoted context omitted.
So? The only people looking at your html classes are you and your team. Bots don't process css, and most people don't look at html.
The same people looking and working on the CSS are the same people looking and working on the HTML. HTML full of long complex class names is a bit harder to grok. I actually prefer nice semantic HTML but I admit that's not always possible.
I wouldn't recommend long and complex names either, but with something like tachyons, they're not long or complex, there are simply long lists of orthogonal classes.
Earlier quoted context omitted.
Generally you would want to avoid descendant and child selectors. With rules like ul > li > a .selector .selector1 li a The system will check ALL anchor tags and move left until it has completely matched the rule. This makes the above selectors extremely expensive (perfomance-wise) and can cause slow page-loads. Tag selectors and universal selectors are generally a bad idea for this same reason. And using inheritance…
The good news is all modern browsers use a Bloom Filter to quickly skip over elements that wouldn't match the descendant or child selector relationship. You could probably construct situations with very deep selector relationships and thousands of matching elements where the ancestor walking adds up but the other costs of computing style often end up being more important than the selector matching in many scenarios.…
Earlier quoted context omitted.
Sure, the author is describing good practice, not best practice. If you have a choice, use class, then if you need to modify a specific use of the class, use id. I would still use .footer instead of #footer. Of course you should consider as well.
You can have many classes!! .footer.special.enterprise { background-color: blue; }
Earlier quoted context omitted.
My argument about the attribute is not invalid because they are doing it the wrong way. Custom attributes for HTML should make use of the data attribute, as you point out. One could use data attributes in such a way, I have, but in the past it was something to avoid due to performance issues. To be fair, I don't know the latest performance figures on attribute selection.
> My argument about the attribute is not invalid because they are doing it the wrong way. The problem with this argument is that just a few years ago everything ReactJS does now was the wrong way, but for some reason today, it's the best way. So which is it? It seems to me, that unless it's broken, or goes against an explicit rule from the browser/code designers of html/css etc... it's totally valid. And if it doesn'…
As far as I know right now, custom attributes goes against the html standard.
Earlier quoted context omitted.
The ability for good practices is already there, just too many people would rather complain about their bad practices to bother learning the good practices and blame the language.
-it is not possible to decrease scope -tooling is hard e.g. to detect unused styles -scope problems are a pain to debug -some constructs are awkward (e.g. tooltips with :before and positioning styles) -vertical text behaves unexpected wrt box model -variables are suboptimal There are probably a lot more.
2. Sure, I understand the discipline necessary to prevent that is difficult in a team setting. I would say that likely at reaching that point something went wrong before then. That seems a tooling problem, not a language problem. How many languages provide features out-of-the-box that assist with discovering unused code without some form of third-party exploring that space?
3. In what way? What scope problems? I can think of several bad practices that lead to scope problems. I can think of examples of two people following two different best practices creating such problems.
4. I know it's not exactly a fair thing to say, but I don't have those issues with the example you provide. I'm sure there's plenty of examples of showing how to do it.
5. Flex. But, granted, old practices didn't handle vertical issues well because originally HTML wasn't intended for that.
6. In what way? Do you mean variables from a pre-processor or CSS custom properties?
I'm sure there are more, just like almost all languages have their quirks and issues that make it difficult to address if not understood. Do you have any other examples that we could discuss? Are there any specific use cases where you are having difficulties that I might be able to help out with?
Earlier quoted context omitted.
> My argument about the attribute is not invalid because they are doing it the wrong way. The problem with this argument is that just a few years ago everything ReactJS does now was the wrong way, but for some reason today, it's the best way. So which is it? It seems to me, that unless it's broken, or goes against an explicit rule from the browser/code designers of html/css etc... it's totally valid. And if it doesn'…
What was ReactJS doing a few years ago that was wrong then but correct now? Since I don't know what that is, did the spec change during that time? As far as I know right now, custom attributes goes against the html standard.
Inline styles for one... created with javascript no less. This was totally verboten not long ago. But then became a "best practice" only because React started doing it.
Earlier quoted context omitted.
What was ReactJS doing a few years ago that was wrong then but correct now? Since I don't know what that is, did the spec change during that time? As far as I know right now, custom attributes goes against the html standard.
> What was ReactJS doing a few years ago that was wrong then but correct now? Inline styles for one... created with javascript no less. This was totally verboten not long ago. But then became a "best practice" only because React started doing it.