4 ms·

What’s your opinion on using selector patterns based on the sequence/order of the elements, like: // Sass [data-UI-component="textfield"] { & > label

What’s your opinion on using selector patterns based on the sequence/order of the elements, like: // Sass [data-UI-component="textfield"] { & > label:only-of-type, & > label:first-of-type {} & > input {} & > label:last-of-type {} } /* css output */ [data-UI-component="textfield"] {} [data-UI-component="textfield"] > label:only-of-type, [data-UI-component="textfield"] > label:first-of-type {} [data-UI-component="textfield"] > input {} [data-UI-component="textfield"] > label:last-of-type {} That way, you don’t mess-up your template/html with classitis. I like to reserve the use of classes for js logic (states) and for semantics (SEO, schema.org, …), thus using the `data-x` attribute to create and select components. Sure your component’s html/handlebars/whatever template must be kept in sync with its css, and adding elements could totally mess-up things. But I think that’s okay, since changing a component’s template should require a revisit of its stylesheet. What do you think?

ianstormtaylor 13y ago
Hmm, I use to try that kind of stuff, but it gets kind of unmanageable pretty quickly. And sometimes it just plain breaks down. For example, with the same form field example. We use the idea of `Field-label` and `Field-legend` across multiple field types. Checkboxes end up having the `Field-label` be the second child instead of the first. Generally trying to tie it to order in the DOM just becomes very fragile, when really a classname is actually more semantic in terms of the meaning sticking with the element and being able to use it anywhere. I think trying to separate JS hooks from CSS hooks is an anti-pattern actually. Like having `js-` prefixed classes. Because realistically you aren't changing the class names enough for it to be a problem. And if you do change the class names there's a good chance you'd want to change the `js-` prefixed one too and eliminate any benefit they were giving you in the first place. You might be able to get it to work for simple components though. But I'd be weary since there are only so many HTML different elements, and the special pseudo-selectors can only get you so far.
- rhizome 13y ago
  I think trying to separate JS hooks from CSS hooks is an anti-pattern actually. Like having `js-` prefixed classes. I'm not a frontend engineer, so forgive my ignorance, but if you could indulge me, what makes "js-" classes bad and "field" and "label" classes OK?
  - ianstormtaylor 13y ago
    No worries, I like explaining it as a way for me to think through it myself. The problem is that if you add "js-" classes that probably means you add the equivalent "js-"-less classes on the element as well. So then you just have duplication with the idea that they are "decoupled". Which might be good if it was true, but realistically if you change the component around to have a different DOM structure you're just going to end up changing both instances of the class anyways. Really it's just trying to solve a problem that shouldn't be solved. Just agree upon an API (and put more effort into making the API good from the start) and then you don't have the problem to begin with. If you really do need to change the API later (which should happen rarely) then just put in the work to do it. Generally breaking API changes are rare if the component was design properly from the beginning, and if it stays small in scope. Templates already have too many classes as it is without having to dupe them all :)
- deleted 13y ago
  [deleted]

ianstormtaylor 13y ago

Hmm, I use to try that kind of stuff, but it gets kind of unmanageable pretty quickly. And sometimes it just plain breaks down. For example, with the same form field example. We use the idea of `Field-label` and `Field-legend` across multiple field types. Checkboxes end up having the `Field-label` be the second child instead of the first. Generally trying to tie it to order in the DOM just becomes very fragile, when really a classname is actually more semantic in terms of the meaning sticking with the element and being able to use it anywhere. I think trying to separate JS hooks from CSS hooks is an anti-pattern actually. Like having `js-` prefixed classes. Because realistically you aren't changing the class names enough for it to be a problem. And if you do change the class names there's a good chance you'd want to change the `js-` prefixed one too and eliminate any benefit they were giving you in the first place. You might be able to get it to work for simple components though. But I'd be weary since there are only so many HTML different elements, and the special pseudo-selectors can only get you so far.

rhizome 13y ago
I think trying to separate JS hooks from CSS hooks is an anti-pattern actually. Like having `js-` prefixed classes. I'm not a frontend engineer, so forgive my ignorance, but if you could indulge me, what makes "js-" classes bad and "field" and "label" classes OK?
- ianstormtaylor 13y ago
  No worries, I like explaining it as a way for me to think through it myself. The problem is that if you add "js-" classes that probably means you add the equivalent "js-"-less classes on the element as well. So then you just have duplication with the idea that they are "decoupled". Which might be good if it was true, but realistically if you change the component around to have a different DOM structure you're just going to end up changing both instances of the class anyways. Really it's just trying to solve a problem that shouldn't be solved. Just agree upon an API (and put more effort into making the API good from the start) and then you don't have the problem to begin with. If you really do need to change the API later (which should happen rarely) then just put in the work to do it. Generally breaking API changes are rare if the component was design properly from the beginning, and if it stays small in scope. Templates already have too many classes as it is without having to dupe them all :)
deleted 13y ago
[deleted]