As suggested in #125315 and probably elsewhere, Input format fieldsets need a better visual representation, especially now that we're moving towards attaching input formats to all textareas. Having them as a normal fieldset can cause confusion as to which textareas they belong. Instead, we could theme the fieldset to have it visually attach to its textarea.

Some mockups for Garland:
Only local images are allowed.
Only local images are allowed.

This works well with the idea of a GUI widget library for Drupal, where it could be available as a generic widget (an accordion maybe?). If we do get a widget library, that is.

The issue relies heavily on #125315 getting into core.

CommentFileSizeAuthor
#160 drupal.text-format-widget-160.patch10.05 KBsun
#157 drupal.text-format-widget-157.patch9.39 KBsun
#154 drupal.text-format-widget-154.patch9.42 KBsun
#151 drupal.text-format-widget-151.patch7.79 KBsun
#150 drupal.text-format-widget.patch7.75 KBsun
#146 20090314-d1p55sari7mc3enic9geixj2rn.jpg63.78 KBbjaspan
#145 Picture 11.png39.87 KBXano
#138 304330-text-format-widget.patch472 bytesDamien Tournoud
#129 304330-text-format-widget.patch7.25 KBDamien Tournoud
#126 input_format_widget_05_unstable5.patch7.58 KBBrightLoudNoise
#125 input_format_widget_04_unstable5.patch7.58 KBBrightLoudNoise
#122 input_format_widget_04.patch7.64 KBBrightLoudNoise
#118 input_format_widget_03.patch7.53 KBBrightLoudNoise
#111 bug.jpg19.04 KBSeanBannister
#110 screenshot-304330-ff3.png9.32 KBff1
#110 screenshot-304330-ie6.png9.41 KBff1
#105 304330 - screenshot.png15.18 KBff1
#95 input_format_widget_02.patch7.43 KBXano
#91 input_format_widget_01.patch7.35 KBXano
#91 input_format_widget2_js_one.png21.93 KBXano
#91 input_format_widget2_js_multiple.png26.18 KBXano
#91 input_format_widget2_nojs_multiple.png37.87 KBXano
#86 input_format_widget_js_multiple.png26.26 KBXano
#86 input_format_widget_js_one.png23.06 KBXano
#86 input_format_widget_nojs_multiple.png38.12 KBXano
#85 input_format_widget_00.patch7.22 KBXano
#81 304330_81_input_format_widget.patch5.87 KBamitaibu
#81 Screenshot.png20.13 KBamitaibu
#79 Screenshot.png20.41 KBamitaibu
#78 input_format_widget_4.patch6.02 KBedmund.kwok
#72 snap.png11.77 KBamitaibu
#69 input_format_widget_3.patch5.36 KBedmund.kwok
#67 input_format_widget_2.patch5.19 KBedmund.kwok
#62 304330_62_input_format_widget.patch5.71 KBamitaibu
#61 304330_61_input_format_widget.patch7.15 KBamitaibu
#60 304330_60_input_format_widget.patch8.84 KBamitaibu
#60 Screenshot.png14.72 KBamitaibu
#54 inputformatwidget_2.patch7.46 KBalpritt
#47 inputformatwidget.patch7.39 KBximo
#44 formatting.jpg35.36 KBDries
#43 inputformatwidget.patch5.75 KBximo
#20 Input-closed.png8.14 KBKrummrey
#20 Input-open.png12.64 KBKrummrey
#17 input-format-widget-v020.png11.94 KBsun
#11 Drupal-input-format-scrolling.jpg25.61 KBSteveBayerIN
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ximo’s picture

Oh, the irony. I forgot to change the Input format to be able to use <img> tags. Here are the mockups:
input-filter-remix-1
input-filter-remix-2

Damien Tournoud’s picture

I love it :)

Gábor Hojtsy’s picture

This looks great, lovely even :) We should move forward quick and get this into Drupal 7 as soon as the base issue is resolved.

yoroy’s picture

Title: Inut format widget » Input format widget

Looks nice. Small detail: I suggest adding the little triangle like in the standard collapsible fieldsets while still keeping the entire area clickable

ximo’s picture

Title: Input format widget » Inut format widget

yoroy: Good idea, will keep it in mind..

Gábor: I don't need the patch in order to theme the fieldset, so will get working on it tomorrow.

I'm also considering using a paranthese instead of a colon. So.. Input format (Filtered HTML). Will try out both.

ximo’s picture

Title: Inut format widget » Input format widget

What happened to the title..? Strange.

Edit (as not to send out a notification mail to everyone):
Err.. While I wanted to work on this over the weekend, I was overwhelmed with stuff to do. Will get to this as soon as I can.

elv’s picture

Should we use plurals to be consistent with other fieldsets?

Input formats: Filtered HTML

or

Input formats (Filtered HTML)

Is it clear, even to newcomers, that the grey word is the actual setting AND that it can be changed? (The question is also for vertical tabs). I'm still trying to find a clearer way to display this.
Yoroy suggested adding the triangle for the Input format link, but I think I would add it to the vertical tabs too. Then it would be more obvious that you are about to expand something, and not navigate to another settings page.

Rowanw’s picture

The clickable area is too subtle, I can imagine a lot of people passing over it without considering that it might be editable. The suggestion for adding an arrow would be a good starting point. However I don't agree with adding arrows to the tabs since the difference between an active tab and a disabled tab already has a strong visual cue.

In regards to parenthesis vs colon - in this example we're displaying the value of an option, a parenthesis would be used to show additional information, for example: Input format (controls how text is formatted). It would be wrong to use a parenthesis in my view. Also, "Input format" should remain singular.

Krummrey’s picture

What about a dropdown menu? That would fit into a single line and still give you all the options to select.
That would still not resolve to way on how to display the help text. Maybe the advanced help from views2 could serve as an idea.

sun’s picture

Did anyone incorporate quicksketch's thoughts and mockup on this topic? See http://groups.drupal.org/node/11144

Some of the comments over there are invalid IMO though (like mixing input formats and client-side editor interfaces in one list), but I really would like to see crazy ideas and approaches on this topic. FWIW, "Input format" and "Filtered HTML" in itself are disgusting terms (what does it mean to the novice user who is not familiar with Drupal in any way? Do I have to format my input? Is my input HTML? What? My input is filtered?!). I do not know any other CMS, which exposes such internals this way.

SteveBayerIN’s picture

How about something like the attached image?
Only local images are allowed.

The input format is more visible/noticeable by appearing above the body field.
There are scroll buttons to change the input format. (A drop down can work too.)
On click of the input format (underlined to highlight that it is click-able) the box can expand and reveal the allowed tags, url filtering, etc.

Rowanw’s picture

SteveJB, why not have a standard select drop down with a help icon beside it?

I think it's important that the description text about the selected format is presented clearly and at all times. The name of the format itself is useless to 99% of users, and they shouldn't have to manually seek out information about what they're allowed to use - you could write an entire page of content before noticing the input filter information.

In Drupal 5 and 6 if you only have access to one input format it shows a summary of what's available straight up, we should use JavaScript to do this in D7 and only show info on the selected format.

Dries’s picture

I want this badly! Love it.

webchick’s picture

Subscriiiiiibe. :)

Rowanw’s picture

Is it appropriate to suggest alternate ideas here, or is that for another issue? Because I've posted about my thoughts with a wireframe in this discussion if anyone cares to comment.

Gábor Hojtsy’s picture

Neil Drumm was also proposed this approach multiple times, but it never happened so far :| There is good discussion going on here and at http://groups.drupal.org/node/11144 with various UI idea to display the format selector.

sun’s picture

FileSize
11.94 KB
  • Injecting the input format filter tips above the grippie does not work, because the maximum size of textarea would be reduced by the filter tips then. For example, when posting long issue follow-ups or essays on g.d.o, the available space should not be unnecessarily decreased by filter tips. While the example is d.o specific, the usability issue is generic.
  • Attaching the input format selector directly below the form field results in a fairly displaced form element description. But the description can contain important information about what should be entered, whereas the input format selector tells me how it can be entered. I'm unsure which of both variants is worse.
  • Since we are heading towards better Wysiwyg support, we have to bear in mind that also textfields (not only textareas) can be input format enabled. Previous mockups only deal with textareas and textareas automatically take up 95% of the available width. Textfields can have an arbitrary width and contain a single line only.

I thought about this for quite some time. So, with the potential of hi-jacking this issue...

  • Presenting the terms/phrases "Input format" and "Filtered HTML" to a user who is not familiar with Drupal's terminology is not very user-friendly. Given the fact that input formats can have arbitrary names, and "Filtered HTML" is used as is on many sites, "Do I have to format my input?", "Which format is expected here?", "What? My input is filtered?", ...
  • Many sites are using additional input filters, for example to automatically convert special tags/macros, or to have certain words automatically linked to other pages. In such cases, site administrators are forced to duplicate an existing input format, just to be able to add another input filter. I have seen sites with a bloat of input formats, each one supporting different input filters, and the input format selector for privileged users looked like ...
  • One of the goals for D7 is to have better support for Wysiwyg in core. This is a different, but closely related topic. I could advance on this, but I'm trying to keep it as short as possible: Client-side editors are able to add arbitrary content into a form element, but some of Drupal's input filters alter the final presentation in a way that leads to unpredictable results. There are two ways for interacting with client-side editors. Either we allow client-side editors to disable input filters that are optional (repeat: NOT speaking of HTML filter here), or we automatically limit the available functions of an editor. Wysiwyg API is heading to the latter, BUT: it cannot do anything on the paragraph or URL filter, so site administrators (not the posting user) still have to ensure that input formats, which are supposed to work with a client-side editor, do not use certain input filters.
  • The result of the previous points lets me question the whole current input format paradigm. If we had permission-based input filters (f.e. HTML filter, PHP filter), and optional input filters (most others, f.e. paragraph filter, URL filter, etc.), then the whole story would be easier; including the user interface as well.
  • Moshe pointed out that filtered contents are cached so this might not work out. But after another thought, it does not matter whether we are applying a bunch of filters based on a selected input format, or a bunch of filters based on actual selected input filters. The only difference is the stored information, because "input formats" are nothing else than a pre-configured group of input filters.
  • This way, a user (but also a client-side editor) would be able to enable/disable the input filters that she either wants to apply/avoid, or a client-side editor was able to enable required or disable known-to-conflict input filters on behalf of the user.

Yes, call me nuts. I don't care. But I care about better content-editing in Drupal.

Attached mockup outlines what I am thinking of.

Rowanw’s picture

In regard to the tips being above the grippy - the tips aren't intended to remove any height from the default textarea size, although if your tips took up a dozen lines then the grippy could be shoved off the viewport. So it's probably best that the grippy stays at the top.

The idea of choosing specific filters with checkboxes makes sense as it gives the user proper control over his content, but I can see a couple of potential issues with the suggested approach.

  1. The first issue depends on whether or not the fieldset is expanded or collapsed by default. If it's collapsed then many users will fail to notice it, if it's expanded then that's good, however seeing all those checkboxes could intimidate users the first time they see it.
  2. What happens when you choose a filter that's 'not compatible' with other filters? Such as the PHP filter... then again, after thinking about this more, I don't see why the PHP filter should be incompatible with other filters as the other filters should still work outside PHP tags.

In conclusion, Sun, I can't really come up with a solid argument against your approach except that it probably requires the most effort to build. There's no doubt in my mind that it would improve the user experience and usability more so than other ideas I've come across.

Gábor Hojtsy’s picture

@sun: selecint input filters one by one does not really work, since their order cannot be arbitrary in lots of cases. Eg. filtering out all HTML and then adding paragraph and br tags, where newlines are used works, but not the other way around, since there will be no paragraphs. The input formats set up logical *ordered* sets of input filters for which web site admins hand out permissions. I'd happily hand out permissions to the whole world for markdown and HTML filtering of malicious markup possibly generated by markdown, but not markdown only (which itself allows for malicious markup). So we basically need permissions to sets of input filters in given orders. Bingo, this is what input formats are exactly.

Krummrey’s picture

FileSize
12.64 KB
8.14 KB

Hi, I didn't see this before I was pointed to it.

I've proposed a similar approach in the Usability Group
UX sprint group 4 (Long Content Creation Form) progress

Only local images are allowed.
This would be the "normal" state. with binding it to the gray box to the text area, it is clearer that they belong together.
The dropdown menu shows the current setting and also allows easy acces to change it.
The whole box is just another fieldset and behaves just like the other ones. I.e. when you click on the triangle or link it openes up.

Only local images are allowed.
The radio buttons are gone now since the seeting is changed with the dropdown menu.

I tried to include the mockups as images, but apparently I can't do that...

Gábor Hojtsy’s picture

@jan krummrey: well, good ideas. I'd rather display only the current filter format help, makes it easier to understand and swap between help if user swaps between format. Certainly makes it harder to scan through the options in other formats, so you'd need to choose by name, but makes the options simpler.

Anonymous’s picture

subscribe

meba’s picture

subscribe

illuminaut’s picture

I agree with this. Overall, I think being able to choose the input format in the dropdown list, which is always visible to the user, is better than the rather subtle approach of the OP. If the help text is limited to the option that is currently selected, the field could even be expanded by default.

yoroy’s picture

##1

##2

##3

##4

I like 1 the best because most of the times I just really don't want to be bothered with it. The format descriptions can be huge, even for just one and showing it by default is a big waste of space. (example of long inputformatdescriptions: http://img.skitch.com/20081001-erkidmdf328bbswspnt92axdid.jpg)

Rowanw’s picture

Yoroy, when presenting relevant, useful and helpful text to the user you can't call it a waste of space (that's not to say that having text everywhere is always better). In the case of the formatting tips I don't think any common user would understand what "Input format: Filtered HTML" would mean, thus they're unlikely to click for more info since they wouldn't have a reason to.

On community sites everyone benefits when contributors know how to format their content properly, the filter tips shouldn't be 'hidden' by default.

If a WYSIWYG was enabled then the tips might be able to go, not too sure about that though.

I'd love to see #3 get committed.

webchick’s picture

I love #1.

If people don't know what an input format is, they can click the ? exactly once, learn what it is, and then never click it again.

Rowanw’s picture

Users aren't likely to expand the filter tips because they don't know what input formats are. Why would you ask for help on something if it wasn't relevant to your interests? People don't have time to click on everything (see Links without Information Scent), in this case the information scent should be the quick tips, while the link would be to /filter/tips. Documentation or Filtered HTML doesn't count as information scent in my opinion.

The only people who get a benefit out of seeing "Input format: Filtered HTML" are those who have already memorized filtered HTML, for other people it's just a bit of meaningless information.

Apart from that, I also noticed that Yoroy's mockups (where tips are hidden by default) are missing a way to view the quick tips.

Furthermore, from a design/usability perspective it seems pointless to shift the control over the right side, can you explain what purpose this serves?

Damien Tournoud’s picture

I agree with Rowanw on #3. But if we really want to keep the quick tips displayed all the time, we should *really* refactor them.

For example, there is not even a reference to HTML in the default Filtered HTML quick tips.

Anonymous’s picture

"Input formats" aren't really input formats. They are more "Presentation filters" or "Node rendering filters". The input is stored in the DB as typed and these so called "Input formats" are applied during the rendering phase. I.E.: I would suggest that we rename "Input formats" to represent what they truly are.

Gábor Hojtsy’s picture

Input formats are input formats in the sense that this is what makes sense to be input. Like this is what a WYSIWYG input widget should display controls for. If the input format is bbcode, the output is most probably not bbcode, so therefore we call bbcode the *input* format, and what comes out is most cases HTML. We have been arguing on and off on what to call these formats, but I did not come around a discussion where we ended up with a better name. Maybe it would be better to decouple the terminology discussion from the UI widget and do the widget anyway (since we are more likely to have agreement on it), and move to terminology after that.

yoroy’s picture

Yoroy, when presenting relevant, useful and helpful text to the user you can't call it a waste of space (that's not to say that having text everywhere is always better).

It's just that I feel the Drupal interface is giving answers before questions are being asked. I find that very annoying, but this may well be different for new users. This example may not be the best place to cut everything, because 'input formats' may need some explaining indeed.

I'd be curious to know how often people use this functionality at all. How often do we change the input format for a text field anyway? Like I said, personally I don't want to be bothered with it. Aligning it to the right side might take it out of the visual flow a bit, making it easier to ignore.

And yes, let's not discuss the terminology here but focus on the widget itself.

Rowanw’s picture

Remember that when I refer to users I'm not thinking of webmasters or editors.

"It's just that I feel the Drupal interface is giving answers before questions are being asked."

Think of it this way, when you have a WYSIWYG editor you can see what sort of markup you can use just by looking at the buttons, I don't know of any WYSIWYG editors that hide their buttons by default.

Would users know they could add HTML or other markup if they never glanced over the quick tips?

Input formats were also brought up in two separate usability tests where some users presumably (from what I can gather) didn't realize they could use any formatting. It would help to know whether or not the instructors had to point out the obscure input formats link. UMN, UB.

SeanBannister’s picture

I agree with WebChick the idea in #1 is really nice.

illuminaut’s picture

I'm for #3 for the reasons RowanW mentioned. The most important information for the end-user shouldn't be hidden by default. The end-user could care less what the input formats are called and is mainly interested in what he can enter in the text field and how the format affects what will be displayed. That's especially true if there's only one format available. With #1 and #2, what would you actually show if there's just one input format? We currently do and should continue to show the allowed tags etc in that scenario, and I don't see a reason to make that a special case.

To reduce clutter for users who are already familiar with the available input formats, we could make the accompanying help text expandable and show it in expanded state by default. It could remember the previous state, i.e. if a user hides the input format description, it could be shown hidden the next time he gets to that form (maybe content-type specific). Not sure if that's currently feasible, but it's not a necessity at any rate and could be added at a later time.

yoroy’s picture

illuminaut and Rowanw totally convinced me there.

I propose we work towards an actual patch that realises this:

ximo, are you still up for it?

alpritt’s picture

I concur. The option depicted #36 is good.

How will this look with a wysiwyg editor enabled? I've been imagining that you'd select a 'wysiwyg editor' input format to enable it, and then select, for example, 'filtered html' to disabled it.

sun’s picture

Thanks for bringing this point into this discussion. No, client-side editors (a.k.a. WYSIWYG editors) are tied to input formats from now on. By selecting a different input format, a different editor (or none) will appear. You can test the latest development snapshot of Wysiwyg API if you are interested to see this live. However, support for multiple, different editors on the same page is not yet implemented, but the current module gives you an idea of how it works.

Actually, the radio buttons have been pretty handy to attach several CSS classes to them. Given this new select list input format selector, I have to rethink how we can attach editors to the widget.

SteveBayerIN’s picture

Looks good. How about an ok/'apply input format' button in #36 to activate the relevant editor tied to the selected input format?

sun’s picture

I would disagree on the proposal in #39. If the admin of a Drupal site intentionally associates an editor with an input format, the editor should appear directly after selecting the input format. Consider an input format "BBcode" with an associated "BBedit(or)" - most /regular/ users would not know how to write BBcode without the editor.

What (additionally) matters is an option to disable the editor. However, this is (and needs to be) properly handled by Wysiwyg API.

ff1’s picture

Could we use a similar approach to #199870: Usability: Even better password strength experience, where the input format and help text is displayed only when the text box has focus? This keeps the user interface uncluttered when its not needed, but will draw attention to the available input filters for new users. Experienced users will just ignore it.

sun’s picture

Unfortunately, almost all of the currently available WYSIWYG editors are "replacing" the textarea with an IFRAME. So, testing the focus on a textarea would make the integration of client-side editors even harder.

ximo’s picture

Status: Active » Needs review
FileSize
5.75 KB

The attached patch themes the Input format fieldset to look like alternative 2 (in #25). Alternative 3, which includes a description for the selected format, can be achieved with jQuery, but I thought I'd post what I have so far without having to mess around in .js files.

Looks great in FF3 and Safari 3, while Opera 9.6 makes the fieldset a bit shorter than the textarea in width. It also totally messes up the form when resizing the textarea, but that also happens without the patch applied and is something that probably should be fixed anyway. Haven't tested in IE yet.

Some snapshots for the lazy ;)

Multiple input formats:

One input format only:

The additions to system.css has been overly documented for clarity only, and isn't inteded for being committed.

As explained in system.css, I had to make the wrapper div 95% and the textarea 100% in order to equal the widths of the textarea and the Input format fieldset. I've only done this for the Body field, so CCK textarea fields will have to do the same.

Btw, I removed the filter_form_validate() function because the select FAPI element validates itself. I also altered theme_filter_tips_more_info() to be able to present the "More information about formatting options" link as a help icon, hope that's the right place to do it.

On a related note, the "More information..." links open in the same window, making the poor bastards using IE lose what they've entered in the form when they click back. Could this be opened in a new window (target="_blank")?

Dries’s picture

FileSize
35.36 KB

sun’s picture

Status: Needs review » Needs work

I agree with Dries, especially with regard to the invisible input format guidelines for the currently selected format.

Rowanw’s picture

ximo’s picture

FileSize
7.39 KB

The previous patch only delivered alt 2 from #25, which doesn't show guidelines. This one gives us alt 3, with guidelines dynamically displayed below. I also took the liberty to change "Input format" to "Formatting" like Dries suggested, even though that has its own issue as Rowanw pointed out.

The jQuery function isn't streamlined, but it does the job. It degrades nicely by displaying all guidelines when JS is disabled, and only the guidelines for the selected format if enabled. I wasn't sure where to put the function, but form.js seemed logical.. if not a new filter.js file?

Skitchshots:
JavaScript enabled
JavaScript disabled

Noyz’s picture

Status: Needs work » Needs review

little nit, but I personally like the word format vs formatting. Formatting is past tense. In contrast format begs an answer.

SeanBannister’s picture

Might want to check out UMN usability: Rename 'input formats' as Rowanw mentioned.

As the first response states

"Text filtering" is probably the best choice. "Formatting" is going to invoke ideas of bold and italics, whereas "filtering" is going to invoke some idea of stripping out or converting things

ximo’s picture

Let's have the discussion on renaming "Input formats" in its own issue, and focus on the widget here. I'll change it back to "Input formats" in the next patch, and let the other issue provide patches for the wording.

Rowanw’s picture

Status: Needs review » Needs work

@ximo, to get the help icon aligned correctly add vertical-align: middle to the image. I checked over the CSS and it looks perfect, although the JS doesn't seem to be running for me - the filter tips don't appear whether or not JS is enabled. Only time the tips display is when there's only one format available.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.3) Gecko/2008092510 Ubuntu/8.04 (hardy) Firefox/3.0.3

ximo’s picture

Rowanw: It should work. Try a hard refresh or emptying your cache for the changes in form.js to take effect.

I've tested the patch in IE 6 and 7, and while it works, the box model bug messes with the width of the fieldset and the padding on top.

Rowanw’s picture

After clearing the Drupal cache in performance settings the tips appeared, but the JS still has no effect (cleared browser cache too). There are no JS errors from the error console or Firebug. I'll let you know if I work it out.

alpritt’s picture

FileSize
7.46 KB

Updated to work with #316225: Allow behaviors to detach from AHAH/AJAX contents.

Tested with 2 textareas and a textfield. The first renders fine, but the subsequent two don't receive a .fieldname-field-wrapper div. It appears to function correctly still, but the different nesting of the DOM elements messes up the rendering ever so slightly. I've not yet looked into why this is inconsistent.

webchick’s picture

alpritt, would you be able to setup another one of your awesome demo sites for this patch? :)

alpritt’s picture

Looked into it. I believe the body field only has a container div to deal with the split summary stuff. So we _could_ put container divs around all textfields that have a choice of input formats (which may be useful for themers in general, maybe?). However, the real pain is the 95% that textareas are set to, which causes all kinds of misalignment woes; including this one. So I've created an issue to deal with that... #331852: Change 95% textarea width to 100%.

@webchick: sure thing.

ximo’s picture

@alpritt: You're right. A wrapper div around both the textarea and the input format fieldset is needed in order to give them the same width. I'm not too familiar with how Forms API builds its elements, but would it be possible to dynamically add a wrapper around all textareas with input formats somehow?

Achieving 100% width seems difficult.. a wrapper might be the best solution for now. If someone finds out how to get 100% width, that would be fantastic, though!

alpritt’s picture

@57: I should think you can add an $element['#prefix'] and $element['#suffix'] in form_process_input_format() in form.inc

David_Rothstein’s picture

Subscribe. This looks really great! Note that this is going to become really critical if the work we're doing at #11218: Allow default text formats per role, and integrate text format permissions goes in, because that patch would make it so that the vast majority of Drupal users have access to more than one input format... thereby exposing the input format selector to almost everybody, so it would be great if it is nice and usable :)

amitaibu’s picture

Re-rolled patch according to #303660: Collapse the input format into a fieldset even if there is only a single input format, which allows removing some lines of code.
webchick said:

The overall goal you have here -- make this more consistent so it looks the same for users regardless of how many formats they have access to -- is a very good one.

The JS doesn't seem to work on FF3, though - and I still don't have the jQuery skills to handle it, so it's still CNW.

[EDIT: something is wrong with the patch, re-rolling]

amitaibu’s picture

And here is the correct patch.
The difference is that in filter_form() we are checking count($formats) > 0 ; later we disable the select list if count == 1.

amitaibu’s picture

Re-rolled against HEAD. jQuery still doesn't work properly...

Dries’s picture

Issue tags: +Favorite-of-Dries
ximo’s picture

I've looked over the patch trying to bring it further, and there seem to be two things that make it difficult.

  1. Making the widget have the same width as the textarea. See #56.
  2. If a textarea has a description, the description will come in-between the textarea and the widget. No good.

Both problems would be solved if we could have the widget output right after the textarea element. To illustrate what I would like to see, the XHTML for the whole form item should go from:

<div id="edit-foo-wrapper" class="form-item">
  <label for="edit-foo">Foo: </label>
  <div class="resizable-textarea">...</div>
  <div class="description">...</div>
</div>
<fieldset>...</fieldset>

To this:

<div id="edit-foo-wrapper" class="form-item">
  <label for="edit-foo">Foo:</label>
  <div class="resizable-textarea">...</div>
  <div class="format">...</div>
  <div class="description">...</div>
</div>

As far as I can tell, theme_textarea() is the place to do this, and the newly introduced form_process_input_format() where to prepare the widget. I couldn't make it work, but will have another go at it. Any thoughts on how to best do this with regard to Forms API?

Also, using a fieldset for the widget and taking away padding etc. through CSS doesn't feel right. Themers may want to theme all fieldsets without necessarily touching this widget. A wrapper div with its own styling should be more than enough.

@Amitaibu: I'd prefer to show the guidelines for the default text format if only one is available. Disabling the select element saves some code, but I'd rather save some pixel real estate by not showing the select element at all :)

sun’s picture

Component: usability » filter.module
Issue tags: +Usability, +wysiwyg
webchick’s picture

edmund.kwok’s picture

Status: Needs work » Needs review
FileSize
5.19 KB

Tweaked Amitaibu's patch in #62.

- jQuery works now - drupal_add_js call is different in HEAD.
- When only one format is available, only the label shows, the select element is not rendered
- Still haven't fix ximo's dilemma in #64

Status: Needs review » Needs work

The last submitted patch failed testing.

edmund.kwok’s picture

Status: Needs work » Needs review
FileSize
5.36 KB

Thank God for the test bot. I forgot to set the format type when there is only one format. Attached patch rectifies that.

Status: Needs review » Needs work

The last submitted patch failed testing.

catch’s picture

Status: Needs work » Needs review

sending for a re-test

amitaibu’s picture

FileSize
11.77 KB

Jquery seems to be working. Two things I'm thinking:
1) Maybe if we have JS then we don't have to show twice the input format name (snap1.png), and keep only the selectlist.
2) Maybe move the (?) icon in the same line as 'Formatting:'.

Rowanw’s picture

Definitely no reason to show the name of the format twice.

The question mark doesn't seem like it should be on the same line as formatting as it links to a page that just provides visual examples; hence it doesn't explain what formatting is. So I think the question mark should be placed below the quick tips with the words Example usage next to it. Does that make sense?

Dries’s picture

Agreed. Let's not repeat the name. :)

I'm not sure what the question mark is for. Is it to get _more_ help? If so, it shouldn't be at the top, and it should probably read 'more help'.

Xano’s picture

Subscribing.

Status: Needs review » Needs work

The last submitted patch failed testing.

Gurpartap Singh’s picture

edmund.kwok’s picture

Status: Needs work » Needs review
FileSize
6.02 KB

Rerolled patch, update the following:
- Removed format name label with JS so it doesn't repeat twice
- Updated filter test to reflect change from radio button to select list; the one failed test should pass now
- Fix some coding standards

Agree with Dries on the question mark. It can be quite confusing. Users shouldn't need to think what the question mark is for and hovering over the icon to find out what it is, is an extra step. They might not even know that it's clickable - if it doesn't help, it shouldn't be there or it'll be noise. Reverted to old UI where with the link 'More information about formatting options'. It's more straightforward and self explanatory.

Thoughts?

amitaibu’s picture

FileSize
20.41 KB

Tested patch and all seems to work properly. RTBC in my opinion.
I've attached a snapshot of the lazy ones :)

Xano’s picture

The screenshot in #79 isn't right. The widget should be stuck to the bottom of the textarea and have the same width.

amitaibu’s picture

Indeed. Patch adds CSS to adjust widget, according to Xano's comment.

Gurpartap Singh’s picture

Is the widget width proper even when Drupal.behaviors.textarea (resizing) is disabled?

amitaibu’s picture

Status: Needs review » Needs work

No, when JS is disabled then the CSS isn't correct - back to CNW.

Xano’s picture

Tried the patch:

  1. The fieldset isn't exactly as wide as the textarea.
  2. The fieldset has too much padding taking up space.
  3. It might be best not to use fieldsets at all, to prevent collisions the other fieldsets.
  4. I'd put the "More information (...)" next to the select list to save space. Also, it should be accompanied by the question mark that was present in earlier versions of this patch.

I'm working on a follow-up patch.

Xano’s picture

The attached patch fixes all my comments in the previously reply.

Note that the page will not validate anymore and that the JS will not work as soon as there are multiple textarea's used at a single page. HTML IDs for the filter guidelines are used more than once in that case: #filter-guidelines-1. This might be solved by adding a unique token to all those IDs.

Xano’s picture

Xano’s picture

Status: Needs work » Needs review

D'oh.

Gurpartap Singh’s picture

For input_format_widget_js_one.png, it should read "Formatting:" instead of format name. Because it's just one, an option/name won't matter. Everything else's good for me in screen shots.

Xano’s picture

I deliberately removed the label if only one format may be used to keep things as simple as possible. I might even go that far to remove the format's name as well, so only the guidelines are being displayed.

Gurpartap Singh’s picture

Sure, at least "Filtered HTML" without any label isn't making a point. Either replace it with Formatting: label or removed the name as well.

Xano’s picture

Rowanw’s picture

The layout/design looks right now, haven't done any testing though.

yoroy’s picture

Since #244904: UMN usability: Rename 'input formats' got committed in the meantime, we should incorporate those naming changes here.

yoroy’s picture

Status: Needs review » Needs work

status

Xano’s picture

Assigned: ximo » Xano
Status: Needs work » Needs review
FileSize
7.43 KB

Done. All occurences of 'input format' or anything similar have been replaced by 'text format'.

Xano’s picture

Status: Needs review » Needs work

[...] especially now that we're moving towards attaching input formats to all textareas.

This was said in #1. I haven't looked closely, but it doesn't seem this patch allows the widget to be used for much else than nodes and stuff. At the very least the comment block for filter_form() needs to be updated in that case.

Also, why are we using $form['format'] and $form[$format->format] for storing the used format? This should be unified.

//Edit: we should also make this widget available to text inputs.

SeanBannister’s picture

Status: Needs work » Needs review

Nice work Xano, looks really good. In particular moving "More information about formatting options" to the right was a good choice.

Xano’s picture

My to-do list for tomorrow:

  1. Make sure all CSS works if the input widget is being used in conjunction with textfields.
  2. Check if the PHP code can be cleaned up. Will need to take a good look at how filter_form() is being called and what it's supposed to return.
  3. Check Safari and Opera on Mac

Could others please check how this looks in other browsers across different platforms? It works good in FF/Mac, but I have no other OS (yet) to test with.

SeanBannister’s picture

Status: Needs review » Needs work

Sorry my post hijacked your setting change

sun’s picture

{filter_format} is a database table of filter.module, i.e. the table name is correct.

+Drupal.behaviors.filterGuildelines = {

Typo.

+  attach: function (context) {
+  // Automatically displays the guidelines of the selected text format.
+  $('.filter-guidelines:not(.filterGuidelines-processed)', context)
+      .addClass('filterGuidelines-processed')
+      .find('label').hide()
+      .parents('.filter-wrapper').find('select.filter-list')

Wrong indentation. Also, no camelCase please - use a hiven instead. Furthermore, can we use .each() like in almost all other Drupal behaviors?

-
+  

Blank lines should be blank. No white-space, please.

+      $guidelines[$format->format] = array('#markup' => theme('filter_guidelines', $format));
...
+    $guidelines = array('#markup' => theme('filter_guidelines', $format));

Please use the same structure for either case.

+    $form['format'] = array(
+      '#type' => 'select',
+      '#title' => t('Text format'),
+      '#options' => $options,
+      '#default_value' => $value,
+      '#parents' => $parents,
+      '#id' => $element_id,
+      '#attributes' => array('class' => 'filter-list'),
+    );
...
     $form[$format->format] = array('#type' => 'value', '#value' => $format->format, '#parents' => $parents);

Likewise, please use 'format' in both cases. That said, I think we could also define $form['format'] as #type 'select' in either case, but for the latter, we just set #access => FALSE additionally.

+  $form['format_help'] = array('#markup' => '<div id="' . $element_id . '-help" class="filter-help">' . theme('filter_tips_more_info') . '</div>');
+  $form['format_guidelines'] = array_merge($guidelines, array('#prefix' => '<div id="' . $element_id . '-guidelines" class="filter-guidelines">', '#suffix' => '</div>'));

Those two lines look really scary. Why didn't you use #prefix and #suffix for 'format_help' as well instead of concatenating them into #markup? Likewise, you can define #prefix and #suffix for 'format_guidelines' and just add the children ($guidelines).

The CSS needs to go somewhere else, not node.css. I would not mind if filter.module would ship with filter.css. Would make it easier for themers to override this stuff.

Xano’s picture

The widget does not fully work with textfields in FF3/Mac.

birdmanx35’s picture

Title: Input format widget » Text format widget
ff1’s picture

Using the patch from #95, I have set up a test site at http://d7test.fantasyf1game.net.

You can login and create content with:
Username: d7test
Password: drupal

Hopefully, this will enable more users to test this important user interface.

yoroy’s picture

Thank you for the demo. Any chance you could enable multiple input formats?

Looking at it, I think we can ommit some needless words on the help link and just make it say
"About text formats"

ff1’s picture

FileSize
15.18 KB

Additional text formats now added to demo site.
See attached screenshot produced in IE6 on WinXP. It looks wrong to me because the text format box is not attached to the field.

Gurpartap Singh’s picture

Sorry about picky, yet again. The more information link looks too dominant and compelling to click. Can we reduce it's size to say .9em viz the same as the rest of the formatting text? :D

Gurpartap Singh’s picture

uh, why don't we hide the formats other than the selected one? i don't want to increase the length of an already lengthy node form (thanks to cck).

Display details only for the selected text format. I didn't know we missed that unless I saw this demo. Thanks ff1!

Xano’s picture

uh, why don't we hide the formats other than the selected one?

We do, so either the screenshot in #105 was taken with JavaScript turned of or the JS doesn't work properly in IE6.

Gurpartap Singh’s picture

I'm using FF3 on Mac with the demo in #103. I'll try the patch myself.

ff1’s picture

My apologies! The test site was failing because the patched misc/form.js had not overwritten the original file :P

It is now fixed and properly implements the patch in #95.

The 2 images attached show this working in both FF3 and IE6, although the IE6 screenshot does appear to be disconnected from the text area.

SeanBannister’s picture

FileSize
19.04 KB

I'm using Chrome 1.0.154 and the text format div doesn't quite line up with the textarea, not a huge deal but every pixel counts.

ff1’s picture

On the test site...
To test the patch with only one text format available, post a comment on the front page without logging in.
To test the patch with multiple text formats, login and then post a comment.

David_Rothstein’s picture

This looks really good in general! Two small comments:

1. In the case where only one text format is available, I think you might want to reconsider the decision to not show the "Text format: label" text at the top. For one thing, it's good for the sake of consistency. More important, the name of the text format is a very good clue to people what they can type into the box -- for example, if I see something like "Text format: Full HTML" or "Text format: Plain text", I'll know right away what I can and can't type, without having to study and decipher the bulleted list below.... however, if this is controversial it could easily be a followup patch.

2. I agree with a previous comment that "More information about text formats" is too long for the help text. It's also a bit misleading, I think, given where the link takes you. Is there any reason it couldn't just be shortened to "More information"?

ff1’s picture

While creating the test site for this issue, I discovered a small bug on the filter admin page. I've provided a patch here: #366253: No 'Configure' option on text formats list page. The fix is so simple, but it just needs one or 2 reviews and someone to set it RTBC.

BrightLoudNoise’s picture

The IE6 "disconnected" issue is due to IE6's poor handling of floats and negative margins. Adding a "float: left" attribute to .filter-wrapper corrects the issue, but causes Safari 3.2.1 to render the fieldset below incorrectly.

The width in IE6 also isn't correct, I'll tinker with the CSS further.

BrightLoudNoise’s picture

The resulting issue with Safari 3.2.1 from floating .filter-wrapper can be remedied with the application of "clear: left" to the fieldsets, still looking at the IE6 width issue.

ff1’s picture

The width was also a problem in FF3, so it may not be an IE6 specific fix we need. If you post a patch with your current fixes, I'll update the test site again.

BrightLoudNoise’s picture

Attached is an updated patch from #95 with the following additions to node.css

  • Added a "float: left" to .filter-wrapper for IE6 negative margin (gap issue)
  • Added a "clear: left" to html.js fieldset.collapsible (I know this shouldn't be in node.css, but let's test it and if it is indeed necessary, we can create a seperate issue to add it to the collapsible fieldset code.
yoroy’s picture

Status: Needs work » Needs review
Issue tags: +ui-pattern

What say you, testing bot?

Status: Needs review » Needs work

The last submitted patch failed testing.

BrightLoudNoise’s picture

I'll try re-rolling it against HEAD later today.

BrightLoudNoise’s picture

I've done a re-roll that patches cleanly, but it looks like the javascript behaviour is no longer hiding the descriptions for the text format(s) not currently selected.

catch’s picture

If anyone's working on this this weekend - we'd like to test it in Baltimore - but with Vertical Tabs #323112: Vertical Tabs as well. However with #50 from vertical tabs, and #118 from this issue applied together against UNSTABLE-5, it breaks quite significantly (the vertical tabs are shifted about 50% over to the right). Removing the float: left; which was added for IE6 does it, might need a clearfix or something in there as well.

Xano’s picture

I'll try to spend some time on it this Sunday, but don't hang me if I can't.

BrightLoudNoise’s picture

Rolled against unstable-5 to help get this in for the usability testing, there is still some problem with the js behaviour which I'm working on fixing.

BrightLoudNoise’s picture

Re-rolled against unstable 5, fixed a typo I had introduced into my first re-roll which broke the behaviour.

also fixed camelCase error in css classes.

BrightLoudNoise’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch failed testing.

Damien Tournoud’s picture

Status: Needs work » Needs review
FileSize
7.25 KB

Rerolled.

Xano’s picture

Wasn't there a version that worked and that was used for the usability tests in Baltimore?

@Damien: You're in DC. Why do development while you can hang out or get drunk? :-P

Damien Tournoud’s picture

@Damien: You're in DC. Why do development while you can hang out or get drunk? :-P

I haven't been able to see any beer during the day. Am I missing something?

jhedstrom’s picture

Subscribing.

Jaza’s picture

Status: Needs review » Needs work

Nice patch. Some comments:

  1. The link 'more information about text formats' should really open in a popup window, or it should bring up a JS dialog saying "warning: this will send you to a new page, and you will lose all unsaved work here", or it should do something apart from simply taking the user to the help page. This was an issue before, but it's even more of an issue now, because the text format select box is JS-enabled (with this patch applied), so users will expect an adjacent link to be similarly funky. Hopefully fixing this is within the scope of this patch. If not, it should definitely be tackled in a new thread.
  2. Could we also take this opportunity to make the text format information a bit more hidden? My suggestion is that we hide the text format information (i.e. the bullet points under the JS-enabled select box) on load, and that we show it (slide down accordion-style?) when the user hovers over the 'text format' bar. It would then hide again a second or two after mouse-hovering away from the bar. It's a lot of information to present to the user, if they're not even interested in changing the text format. Hiding it will reduce clutter and will ++ node form usability.

Note: Not sure if this has been mentioned already, but you need to clear your cache after applying this patch.

David_Rothstein’s picture

yoroy’s picture

Status: Needs work » Needs review

#133:

1. This is a follow up we can work on once the new help system gets committed
2. Sounds like a follow up feature request to me.

Both your points make sense, but user interface patches are already taking enough time as it is, lets not add even more to the task at hand.

Damien Tournoud’s picture

Status: Needs review » Reviewed & tested by the community

Sounds like this one is really ready. It got a lot of usability testing, the code and the UI looks great, there is no point in waiting more on this.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

I made one tiny adjustment, which was to move the comment for the JS to a docblock above it and COMMITTED. YAY!!!!!!!!! :D

Damien Tournoud’s picture

Status: Fixed » Reviewed & tested by the community
FileSize
472 bytes

Let's fix some whitespace ;)

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Fixed! :)

This code commit brought to you by delicious Chunky Monkey! Mmmm...

Xano’s picture

Does it work in all major browsers? Also, I believe it conflicts with vertical tabs.

webchick’s picture

Yes, vertical tabs needs to be re-rolled.

If it doesn't work in all browsers, why was it marked RTBC? :P

ff1’s picture

I've just updated my test site: http://d7test.fantasyf1game.net with drupal head. I think there is still an alignment problem as discussed in #111. Should this be tackled in a separate issue?

Rowanw’s picture

The size of the gap is negligible in my opinion. A proper solution could take a while to work out, so it should be its own issue.

ff1’s picture

The patch has already been committed in #139.

I was just pointing out that a problem highlighted earlier in this thread remains unsolved. #118 even has a patch that suggests this problem is fixed, but I was unable to test it as it didn't apply cleanly. If everyone here agrees that it is not worth fixing, then no separate issue is required.

Xano’s picture

Assigned: Xano » Unassigned
Status: Fixed » Needs work
FileSize
39.87 KB

This stuff breaks at admin/build/block/add and everywhere else a description is being used.

bjaspan’s picture

I think this is breaking node forms because the filter-wrapper fieldset is floated left and, in general, the thing which follows it is not cleared left. When I remove the float:left on filter-wrapper with firebug, the page looks fine, so I do not know why the float is there at all, but then I also have not been paying attention to this issue so maybe there is a reason I don't know about.

yched’s picture

True, noticed #146 as well.

Also, the form generated in the degenerate case where there is only one format available is not consistent with the generic case. Causes problems for #372743: Body and teaser as fields / #375907: Make text field use D7 '#text_format' selector.
Opened a separate issue : #411596: filter format form when only 1 format available

David_Rothstein’s picture

It seems like the issue in #411596: filter format form when only 1 format available was also discussed by @sun in #100 above, along with other issues, but that most (all?) of them did not get included in the final patch :(

In addition to the other fixes that have to go in here, it seems like we should revisit @sun's code cleanup comments in #100 and make sure they don't get lost.

sun’s picture

Category: feature » bug
Priority: Normal » Critical

The entire implementation is not working as it should. Aside from the previously mentioned bugs, the introduced CSS breaks the form layout, f.e. when a checkbox is following the text format widget.

I'd rather mark the other issues as duplicate, because we either want to revert this patch or fix the mess in here.

sun’s picture

Status: Needs work » Needs review
FileSize
7.75 KB

Also, I have no idea why the stylesheet was still in node.css. Since when are text formats bound to nodes?

.clearfix seems to be broken for IE6.

Now, someone mark those other issues as duplicate, please.

sun’s picture

Let's also fix all cross-browser issues.

Besides the widget width issue. Those 95% were always error-prone. Resizable textareas badly need some love.

This one eliminates all styling issues since ~#100.

Broken .clearfix in IE6 no longer matters for this issue.

sun’s picture

I should have added that Drupal core _has to_ completely avoid hacks such as the one introduced in the original patch.

If stock themes in Drupal core need nasty CSS hacks, then all other themes require them, too. 99% of all CSS hacks can be avoided by using proper markup. Like this patch demonstrates.

Thanks for listening.

Damien Tournoud’s picture

Status: Needs review » Needs work
+    $element['#prefix'] = '<div class="text-format">';
+    $element['#suffix'] = '</div>';

This effectively prevent anyone to add a #prefix or #suffix themselves.

+    if (isset($element['#description'])) {
+      $element['description'] = array(
+        '#type' => 'item',
+        '#description' => $element['#description'],
+        '#weight' => 2,
+      );
+      unset($element['value']['#description']);
+    }

This looks hackish... what's wrong with having a proper theme function for this? If only we defined a proper #type => 'textarea_formatted' FAPI element!

+  foreach ($formats as $format) {
+    $options[$format->format] = $format->name;
+    $guidelines[$format->format] = array('#markup' => theme('filter_guidelines', $format));
   }
[...]
+  $form['format_guidelines'] = $guidelines + array(
+    '#prefix' => '<div id="' . $element_id . '-guidelines" class="filter-guidelines">',
+    '#suffix' => '</div>',
+  );

I suggest flipping those: first initialize $form['format_guidelines'] with its #prefix and #suffix, and then fill it with format guidelines.

sun’s picture

Status: Needs work » Needs review
FileSize
9.42 KB

Introduced theme_text_format_wrapper().

jrabeemer’s picture

I have a strong feeling no one is testing in IE6/7/8. I posted a screenshot awhile ago. #395464: New text format filter box CSS layout is broken in IE6/7 Until we can agree that Garland in D7 breaks IE6 support or has a separate IE stylesheet (#409392: Move ALL IE specific CSS to IE style sheet), then these IE CSS bugs *must* be fixed.

sun’s picture

@momendo: Please test the latest patch. Fixes the layout in IE6 for me.

sun’s picture

Requested by chx, we still want to use #type 'markup' for the text-format-wrapper element.

webchick’s picture

I tested in Safari and sun's patch appears to be working. We need confirmation in IE 7 and 8 still.

sun’s picture

Assigned: Unassigned » sun
Status: Needs review » Needs work

IE6 works. IE7 fails, renders a gap at the top of text-format-wrapper due to floating text format help. Not yet sure why that is, but I'll solve it.

sun’s picture

Status: Needs work » Needs review
FileSize
10.05 KB

Well, of course, that IE7 bug was caused by some ill overrides specifically targeted on IE7 in Garland's style.css. Another reason why CSS hacks suck. For now, I've simply added another override for IE7 right below the existing to revert the badness and make this widget work. However, all of this cries for a major clean-up (and I'm NOT talking about removing IE support, I'm talking about doing it properly).

Attached patch works for me in Firefox 3.0, IE6, IE7, and Opera.

webchick’s picture

Status: Needs review » Fixed

Tested latest patch in Safari as well. Works great.

Committed to HEAD. Thanks a lot, folks!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

treksler’s picture

bingo!

I also suspect not many care about these input formats.
This is why i used a form alter to move them out of the visual flow altogether years ago
... of course this now breaks with wysiwyg api because it insists we force our users to care about input formats .. grr

    /*
     * Put "input format" settings under advanced
     * becasue once a sane default is set, users shouldn't have to touch this
     */
    $form['advanced_settings']['format'] = $form['body_filter']['format'];
    unset($form['body_filter']['format']);
    $form['advanced_settings']['format']['#title'] = 'Body Field Input Format';
    foreach ($form as $key => $value) {

      if (substr($key,0,6) == 'field_') {
        /*
         * Also hide CCK field input formats
         */
        if (is_array($value[0]) && array_key_exists('format', $value[0])) {
          $form['advanced_settings'][$key .'_format'] = $form[$key][0]['format'];
          unset($form[$key][0]['format']);
          $form['advanced_settings'][$key .'_format']['#title'] = $form[$key][0]['value']['#title'] .' Field Input Format';
        }
      }
    }

Edit: this was supposed to be in reply to comment #32