Closed richardTowers closed 6 years ago
Hi @richardTowers thanks for raising this.
In the first iteration of the component macros we were using boolean values to represent variants (and output css classes).
In the base of the button, it can be a <button>
, <a>
or input type="submit"
. Users might be confused what a modifier does: is it a new class or different tag.
We're open to feedback from users and we'll evaluate this proposal to see if we can make it work for compound components as well, so that the approach is consistent.
I raised a similar issue related to breaking upgrades: https://github.com/alphagov/govuk-frontend/issues/460
See also the GOV.UK Publishing component: http://govuk-static.herokuapp.com/component-guide/button/start_now_button
We constructed the class based on booleans, then finally merge with classes
and inject into the markup.
In terms of confusion, if they're documented properly, I've not seen any issue with flags.
Ah, I hadn't seen #460, which looks similar enough that I think we should close this one as a dupe.
I'll add another comment to that with my opinions.
At the moment if you want to turn a button into a start button you would use a nunjucks macro like this:
The macro already knows it's a
govuk-button
element, so it feels redundant having to say it again in the classes. It also means the nunjucks macros don't protect the user from classname changes as well as they might.What do you think about adding a
modifiers
field alongsideclasses
which would automatically prepend the appropriate block / element bits of the classname to the output? So: