-
-
Notifications
You must be signed in to change notification settings - Fork 14
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BUGFIX: Ad id attribute to form fields #86
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like
Spec says that about identifiers: see https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/id
|
Not sure if I'm correct, but wouldn't this change lead to the id attribute value potentially starting with a number? Shouldn't it be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not so sure anymore as rendering an identifier by default is quite invasive. Assume there are better options to achieve the same.
Having an id attribute is the only way to associate an input with a label. Therefore, if a form field is used with a label, there is no way around an id attribute. I checked on other solutions, such as TYPO3 Powermail, TYPO3 Form Framework, WordPress Gravity Forms, all of them have id attributes by default. Personally, I think it's a no-brainer to just have an id attribute. But if we don't want this in Neos.Fusion.Form, we should at least be able to activate the id attribute:
(Or similar) |
We should have a logic that ensures uniqueness for id's or use the optIn as suggested. Without that we can easily cause issues for documents that render multiple forms and wich very likely have some fields in common. Maybe we allow to set the id on the fieldContainer and only after that is done render it for label and field. |
Yes, the uniqueness should be established using a "namespace", in
|
@mficzel You merged sitegeist/Sitegeist.PaperTiger#18 in the meantime, but this one is still unmerged. How should be progress here? |
"Self correction": sitegeist/Sitegeist.PaperTiger#18 doesn't depend on this issue, it works well as long as there is only one form (or unique form field names) on a page. |
Closes #85