Conversation
…ng to add any data properties defined in the field's YAML
|
I'm seeing is you've moved the label block outside the |
|
It allows overriding the It does seem logical to me that everything label-related is within the |
|
I need a bit more time to test this especially in regard to the other PR that removes label block entirely from the checkbox field: #442 |
|
Thanks, understand. My early impression of the other PR is that it wouldn't be needed if this goes in, and this has less likely unintended consequences. |
| <label class="{{ layout_form_field_label_classes }}{{ form_field_label_trim }}" {% if field.id %}for="{{ form_field_for }}"{% endif %}> | ||
| {%- block label -%} | ||
| {%- if form_field_help -%} | ||
| <span class="tooltip" data-tooltip="{{ form_field_help|e }}">{{ form_field_label|raw }}</span> |
There was a problem hiding this comment.
Why was the escaping removed here?
There was a problem hiding this comment.
I don't like us using |raw without concent from the person who writes the form. Either the property should be called label_html or it should indicate it in some other way, maybe something like
but with html: true in it.
There was a problem hiding this comment.
Well in this case it is a attribute, so it MUST use escape anyways. It should be added back anyways.
What about this PR itself? Will it be merged?
I noticed the logic for showing labels using
show_labelisn't implemented as early as it should be.This means when labels aren't being shown, you still get the label wrapper divs rendered, causing problems like asterisks for required fields attached to nothing (empty label divs). Try it with
labelfalse andrequiredtrue on a field.