[development] implementing #format

[Gábor Hojtsy]

Konstantin, let me say up front that this is perfect feedback, very valuable!

On Feb 19, 2008 4:06 PM, Konstantin Käfer <kkaefer at 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