Followup from #1200478: Changing the comment path to the node path triggers a PHP fatal error in l() due to wrongly structured options, Drupal currently "allows" $element['#attributes']['class'] to be an array or a string (meaning that it's documented as being an array, but if you set it to a string it will still print the class to the HTML on the page, with no errors).
At least, this is definitely the case in Drupal 7, and I believe it still is in Drupal 8 too.
As shown in the above issue, this can cause problems in certain scenarios and is generally not consistent, so it might be a good idea for the system to force it to always be an array and refuse to use it if it's a string.
Todo: Discuss if this is a good idea for Drupal 8; if so, write a patch and write tests.
Comments
Comment #1
David_Rothstein commentedComment #2
sunNote: This related issue is only related; #attributes 'class' is used outside of form elements, too.
Right now, we don't really have a data 'validation' concept/layer in the element rendering process. That's hard to do, because nothing is really formally declared, no data is typed, and it would also be costly in terms of performance.
Comment #3
Aki Tendo commentedI've accidentally done much of this as part of an overall hardening process. As far as performance overhead - my understanding is that end users don't provide data to these elements so, as a result, the validation is done by assertions during development to catch mistakes at that time, but in production there is no validation in place - assertion statements can be disabled and should be disabled in production.
I'll be updating the ticket for that process sometime tonight or tomorrow.
Comment #4
Aki Tendo commentedI'm currently debugging it, but once the Template patch is done the class attribute will be a member of AttributeNamedClass, an object that also has the special class handling code that previously was in Attribute.
Comment #5
joelpittetThis has been done! If the name is 'class' it's changed to AttributeArray.