Closed florianbouvot closed 8 years ago
+1 to all that @florianbouvot suggested.
I'd add arrow mixin to the mix (it could probably need some improvements).
Also, .flyout
might be improved with position (top/bottom/left/right) and also with positioning/alignment of .flyout__content
(left/center/right for top/bottom flyout, and top/center/bottom for left/right layout).
Old debug could be useful as well. There are probably more of old partials that could be included but I guess Harry already has a todo list about it somewhere.
@florianbouvot Helpers are available now:
As well as their responsive equivalents:
@csshugs thank you, I currently work with my own modules (not public), but I will have a look at your work.
@florianbouvot @nenadjelovac @csswizardry Over the last 11/2 years I've come to the conclusion that the core inuit project does not need to implement more modules than exist at the moment. Rather the contrary. Inuit provides this scaffold (well, it's a framework in the truest sense) on which one can build things beautifully on top. It provides a great way to enhance the framework with individual modules to fit ones individual needs in individual projects – a plugin ecosystem so to speak.
But to keep inuit that flexible, simplicity is the major key. Simplicity in terms of few as possible, unopinionated, style-/cosmetic-free and independent modules.
What I want to say is: I've seen so much GitHub-issues/pull-requests recently where some module/functionality is beeing demanded. And that's OK, of course. But the thing is: Almost everytime, it's something opinionated, individually, project specific, which would lead to a less flexible framework in the whole, when beeing implemented in the framework. Why not just provide the module, someone thinks is missing ourself as an own GitHub-repo and make it an inuit plugin?
In concrete:
The above mentioned nav
module is a module everyone needs on every project. But every nav on every page is different then the other. So why try to integrate some allrounder into inuit and risk various pull-requests because everyone needs it a little different (no offense here @florianbouvot for pointing you out. I dig your desire and have (/had) them, too). Trying to please everybody increases the complexity in an unnecessary way. And the more modules, the more we have to look after (> even more complexity).
After all, nav
is more a component than an object, so it does not belong in the framework per definition anyway.
It's impossible to fit everybody's needs, so by providing as little modules as possible/sensible and keeping inuit extendable (via plugins from within the community) it keeps beeing that flexible as it is now. I think we are all here because we are fed up with the Bootstraps and Foundations (To stress it another time: They are both great in their own way!). Let's not make the mistake and expect inuit to become more and more a UI-Toolkit in which we have to permanently work around something we would actually do slightly different.
@csshugs I share your opinion (nav
module is an old request). I work with inuitcss v5 since early 2014 and it provides everything I need for my projects... thank you again @csswizardry
However, I would like as the project evolves : add missing namespaces, reflection about responsive suffix, ...
Hey, I’m going to close this issue for now. We are currently evaluating ideas for an upcoming next major version of inuitcss. Thanks for the contribution and idea!
Hi Harry,
I enjoy working with your framework and I understand that this is a pre-alpha version. For months I start project with inuitcss v6 and I often include some modules of v5.
I open this issue to share the list of modules from v5 that I use most often and get your opinion on the evolution of these modules.
Base
forms
Objects
nav
partially available in inuitcss v6 :objects.list-bare
,objects.list-inline
,objects.tabs
breadcrumb
pagination
flyout
Generic
helper