You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
More often than using the actual .o-list-bare and .o-list-inline objects, I create mixins for those abstractions, so I can use these on my custom components. E.g.:
This way, I can keep my markup “clean”, i.e. not mixing object and component classes.
Proposal
By extracting the CSS of the list-bare and list-inline to mixins, we can give users the possibility to use just the mixins in their custom components. Additionally, we still provide the objects for those users who are more attracted towards adding the object classes to their markup.
This is backwards compatible and doesn’t introduce a breaking change, hence can be implemented into the current v6 major version.
The text was updated successfully, but these errors were encountered:
While I won't say "don't do it", I'll point out that this kills the concept of an object per the ITCSS model. It removes the code from the objects layer and repeat it n times in the components one instead, making it non-abstract in the compiled code. You can discuss if it does or doesn't matter for you and make it optional, but what makes the list related objects special in that regard? If you go with this, the same apply to any object. One way or another, I see no benefit and personally wouldn't use it.
More often than using the actual
.o-list-bare
and.o-list-inline
objects, I create mixins for those abstractions, so I can use these on my custom components. E.g.:This way, I can keep my markup “clean”, i.e. not mixing object and component classes.
Proposal
By extracting the CSS of the list-bare and list-inline to mixins, we can give users the possibility to use just the mixins in their custom components. Additionally, we still provide the objects for those users who are more attracted towards adding the object classes to their markup.
This is backwards compatible and doesn’t introduce a breaking change, hence can be implemented into the current v6 major version.
The text was updated successfully, but these errors were encountered: