tachyons
tachyons copied to clipboard
Document with Sidebar
- Collapsed sidebar that expands to show list of articles
- Article with title, body
- Footer nav with next and previous article links
Something like https://perrera.com/2017/designing-with-tachyons/ or https://makingmusic.ableton.com/on-work (the latter is perhaps more user-friendly)
Testing a component request on the new Components project — input welcomed.
The card status can be set to update as this issue progresses... or we can do it manually.
@j-greig where do you belive the state of the menu should be kept ?
- inside a class like
.is-visible { ... }(JS is required) - inside an auxiliar html element like
/* naive implementation */
nav {
display: none;
}
input.toggler:cheked ~ nav {
display: block;
}
- with this approach tachyons new users should make and extra effort to put pieces together
- this approach on the other hand will enforce the markup to be something like:
<input type="checkbox" />
<nav>...</nav>
because of it's toggler ~ nav selector
@cmnstmntmn Good question — I'm more than designer than developer so I'm not sure which option is better. Wonder if there is consensus on this for existing Tachyons components @johno ?
TBH, I think both approaches are viable depending on the project and context. Though I'm not sure if one is perhaps better to show in component examples, or if it makes sense to even show both implementations.
Another nice example for this component: https://www.purgecss.com/
@johno
I have used the approach for hobby project or quick static site. However, once you the project gets bigger, people should store the state in their choice of state engine (React, mobx ...)