-
Notifications
You must be signed in to change notification settings - Fork 319
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for HTML5 boolean attributes #1665
Conversation
Hey Colin, Thanks for putting this together it seems logical to me. Maybe you've explored this but is it possible to make this change by updating the existing attribute tests? That would be preferable to the extra complexity with helpers and snapshots. Side note: I wonder if we should consider a 'utilities' template with macros for common things in all templates, so we could have this sort of logic tested once and make newer components or attributes functionality easier to add. |
@NickColley Unfortunately I tried this, but So my tests were already passing, without making any Nunjucks changes. That's why I had to test the Nunjucks HTML directly. |
We could still combine the new |
@NickColley Here's where |
Thanks for the clarification on Cheerio stuff, makes sense. We're gonna chat about this idea as a team tomorrow and let you know the next steps for your proposal, thanks again. |
Bypasses cheerio to get the exact rendered HTML
18f3070
to
1bc8167
Compare
We've chatted about this as a team, we like the change however since we don't have evidence this is an issue for people we think the added complexity to our testing suite and templates is not worth it right now. If this comes up again this'll be super useful thanks a lot, sorry we have to close this. |
Afternoon 馃憢
I noticed the
attributes
params don't support HTML5 boolean attributes:https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#boolean-attributes
For example to support attributes here:
With the current macros they'd render as:
This could cause problems in CSS or JS query selectors where
element[open]
might wrongly match foropen="false"
etc. Worth a fix?I've added a truthy check around the attribute value:
Before
After
With a Jest snapshot matcher to ensure the attribute has no empty
=""
value appended: