Konstantin, let me say up front that this is perfect feedback, very valuable! On Feb 19, 2008 4:06 PM, Konstantin Käfer <kkaefer@gmail.com> wrote:
Any other field one would need to support? Do we need to support textfields really?
IIRC, textarea and textfield are the only input types in core which allow entering of freeform text. I'd absolutely go for supporting textfield input formats as well; I see a lot of use cases here, e.g. allowing specific HTML tags (Like <strong> or <em>) or parts of other input formats (e.g. **bold**) for node titles. I'd add an additional locked input format named "Plain text" which represents the current format (without any filtering // only check_plain (depending on the use case)).
Yeah, I am also thinking about adding formats like "Plain text" (check_plain()) and possibly even "XSS filtered" (filter_[admin_]xss()), although I am for introducing format support for stuff like site settings as well somehow (eg. site mission, slogan, footer, instead of tying them to the filter_admin_xss() as they are now).
Another issue with allowing filters for regular textfields is the vast space required by the current filter selector. I think we can minimize this by not displaying it for textfields when there is only one available input format. The input method can be specified in the textfield's description.
I am also about to submit a patch to allow admins to limit certain input formats to certain "input types" (eg. story node body, comment body, ...). Look at http://groups.drupal.org/node/8911 for related discussions. There is valuable feedback there as well for this topic (although I started it for a different purpose :)
- Expand textareas with #format to a textarea and a format selector (or just help if there is only one format) with the help of #process
No. I see the input format selector as part of the textarea/textfield entity itself, not as a separate control.
You mean we should generate the HTML for the format selector / indicator and never have this in a FAPI structure more then the meta information? I did not think about this yet, but it sounds like a good idea to me :)
If #format a good idea for input format specification on forms, or should I use a better name?
No, #format is perfectly fine. I don't think we should use less obvious names only because contrib modules for a previous version used them for a *slightly* different purpose or with a different syntax.
I was rather thinking about #format being too generic and possibly misleading / conflicting for efforts to get email, number, etc. type fields, which would probably need a similar meta-mechanism for format limiting / specification. Anyway, if this comes significantly sooner, then the patch coming later needs to bother with this :P I am just trying to solicit some initial feedback, so that the keywords do not need to be modified later. Gabor