Conclusion

In Twig templates, we will be printing attributes like this:

<div class="{{ attributes.class }}" {{- attributes }}>{{ children]]</div>

Classes are treated specially, since people need to be able to add a class easily, without reading the docs, without using a preprocess function, and without usung a jQuery like syntax to do so.

All other attributes are printed together following classes, using the Twig whitespace controler on the opening print tag {{- and no space after the closing peint tag.

History

This has already been heavily discussed, and concluded in:
#1808254: Standardize and simplify the attribute syntax in Twig template files

Original issue

I propose that we we adopt the simpler version:

<element {{- attributes }}>

Or, my preference:

<element{{ attributes }}>

This has the following benefits:

* Easier to read and write because it uses a simpler syntax. On all of the projects I've worked I have pushed classes_array into attributes_array (why we needed a separate array just for classes, I don't know) and replaced the horrible "explicit printing of classes/id followed by attributes" syntax with the much more simple <element<?php print $attributes; ?>>. This is doing the same thing but for twig files.
* Avoids the problem with potentially empty class/id properties. What happens when attributes.class is empty? We get an empty class attribute? We could workaround this by adding more complex template syntax for merging or checking if attributes.class is defined, and do the same for id, but I would much prefer to adopt this simple syntax for template files that sidesteps the issue completely.
* Helps to promote that attributes are added in a more consistent way. Instead of promoting developers to add classes in template files, we naturally invite the developer slightly deeper down the stack (I think classes should be added in hook_*_view(), hook_*_view_alter(), and hook_preprocess()).
* Any attributes could be edited via the admin interface. This is simply not possible if you hardcode them in template files! I'd prefer it if we avoided hardcoding things so much.

Also, I'd like to point out that themes are free to implement this as they wish. As long as all attributes are in the attributes array (duh), they can be explicitly printed however the theme creator decides, for example if they wish they could use:

<article id="{{ attributes.id }}" class="{{ attributes.class }}" {{- attributes }}>

Thoughts, counter-arguments?

Comments

markabur’s picture

markabur commented

See: #1808254: Standardize and simplify the attribute syntax in Twig template files

podarok’s picture

podarok
🇺🇦 he/him/his
Primary language Ukrainian
Location Ukraine
commented

vote for
<element {{ attributes }}>
against
<element{{ attributes }}>

for better visual reading

vlad.dancer’s picture

vlad.dancer
Primary language Ukrainian
Location Kyiv
commented

I completely agree with this <element {{ attributes }}>

EVIIILJ’s picture

EVIIILJ commented

The only issue I see here is that the current code to print the attributes automatically prepends a space between each attribute. So if we use the suggested <element {{ attributes }}> it will have 2 spaces in front of the first attribute printed out. So we would be left with:
<element class="hello">
instead of the desired:
<element class="hello">

One way to do this is to add a twig white space controller <element {{- attributes }}> to eliminate leading whitespace. Or eliminate any spaces within the element tag and attributes -> <element{{ attributes }}>

steveoliver’s picture

steveoliver commented

I think this is what we've been doing:

<element {{- attributes }}>

psynaptic’s picture

psynaptic commented

Yes, it's:

<element {{- attributes }}>

vs.

<element{{ attributes }}>

If you use:

<element {{ attributes }}>

then you get 2 spaces in the source.

My order of preference in these purely based on template file syntax is:

1. <element {{ attributes }}>
2. <element{{ attributes }}>
3. <element {{- attributes }}>

Would you rather have the extra trim than no space between the element and the print brackets?

steveoliver’s picture

steveoliver commented

<element {{-attributes}}> would be my preferred syntax in this example. Is there a reason we've adopted the spacey {{ attributes }} syntax?

steveoliver’s picture

steveoliver commented

To answer my Q in #7, I see that's just the way Twig (docs, at least) does it with all syntax; control structures {% if this is defined %} and comments {# Comment. #} use the same spacing.

jenlampton’s picture

jenlampton
she / her
commented
Status: Active » Fixed

I'm going to mark this issue as fixed since we have agreed on a standard for the first round of conversions. We can revisit this issue the safter feature freeze, but to summarize, we will be printing attributes like this:

<div class="{{ attributes.class }}" {{- attributes }}>{{ children]]</div>

Classes are treated special, since people need to be able to add a class easily, without reading docs, without using preprocess, and without usung a jQuery like syntax.

All other attributes are printed together following classes, using the Twig whitespace controler on the opening print tag {{- and no space after the closing print tag.

jenlampton’s picture

jenlampton
she / her
commented
Issue summary: View changes

add summary to initial issue

jenlampton’s picture

jenlampton
she / her
commented
Issue summary: View changes

typo

jenlampton’s picture

jenlampton
she / her
commented
Issue summary: View changes

add link to history

jenlampton’s picture

jenlampton
she / her
commented
Status: Fixed » Closed (duplicate)

Actually, this is just a dupe. (Thanks @markabur) :)
See #1808254: Standardize and simplify the attribute syntax in Twig template files

jwilson3’s picture

jwilson3
Primary language English
Location Ecuador
commented

There is a new proposal to bring some level of consistency, embracing a "jQuery-like syntax" as you put it Jen. This is not to ignore your point that it should be easy to add classes, but i think it should be equally easy to remove or modify classes as well.

Additionally, if the syntax was embraced everywhere, it would essentially document itself in such a away that would make it plainly clear on how to add/remove a class that rivals our current <tag class="{{ attribute.class}}" {{- attributes }}> syntax.

Please see: #1835396: Attribute modifier functions for themers

psynaptic’s picture

psynaptic commented
Component: Twig templates » Twig templates conversion (front-end branch)

#9 is precisely what I hoped to avoid. I severely dislike that syntax. I believe wrapper classes shouldn't be added in template files, since it promotes excessive use of additional template files via theme suggestions. I think classes should be added using PHP logic.

What I really want to see is:

<div {{- attributes }}>
joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented

I vote (albeit late):
<element{{ attributes }}>

Splitting out the <element class="{{ attributes.class }}"{{ attributes }}> may be slightly easier for some themers but makes for messy code with tones of blank class="" in the rendered HTML markup, which would look like a mistake to most themers.

c4rl’s picture

c4rl commented

#12 @psynaptic & #13 @joelpittet Appreciate your input today, but this present issue is a dupe, please follow-up on #1808254: Standardize and simplify the attribute syntax in Twig template files instead.

c4rl’s picture

c4rl commented
Issue summary: View changes

typo

Project: » Lost & found issues

This issue’s project has disappeared. Most likely, it was a sandbox project, which can be deleted by its maintainer. See the Lost & found issues project page for more details. (The missing project ID was 1750250)