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:
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.
Comment | File | Size | Author |
---|---|---|---|
#160 | drupal.text-format-widget-160.patch | 10.05 KB | sun |
#157 | drupal.text-format-widget-157.patch | 9.39 KB | sun |
#154 | drupal.text-format-widget-154.patch | 9.42 KB | sun |
#151 | drupal.text-format-widget-151.patch | 7.79 KB | sun |
#150 | drupal.text-format-widget.patch | 7.75 KB | sun |
Comments
Comment #1
ximo CreditAttribution: ximo commentedOh, the irony. I forgot to change the Input format to be able to use <img> tags. Here are the mockups:
Comment #2
Damien Tournoud CreditAttribution: Damien Tournoud commentedI love it :)
Comment #3
Gábor HojtsyThis looks great, lovely even :) We should move forward quick and get this into Drupal 7 as soon as the base issue is resolved.
Comment #4
yoroy CreditAttribution: yoroy commentedLooks nice. Small detail: I suggest adding the little triangle like in the standard collapsible fieldsets while still keeping the entire area clickable
Comment #5
ximo CreditAttribution: ximo commentedyoroy: 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.
Comment #6
ximo CreditAttribution: ximo commentedWhat 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.
Comment #7
elv CreditAttribution: elv commentedShould we use plurals to be consistent with other fieldsets?
or
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.
Comment #8
Rowanw CreditAttribution: Rowanw commentedThe 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.
Comment #9
Krummrey CreditAttribution: Krummrey commentedWhat 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.
Comment #10
sunDid 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.
Comment #11
SteveBayerIN CreditAttribution: SteveBayerIN commentedHow about something like the attached image?
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.
Comment #12
Rowanw CreditAttribution: Rowanw commentedSteveJB, 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.
Comment #13
Dries CreditAttribution: Dries commentedI want this badly! Love it.
Comment #14
webchickSubscriiiiiibe. :)
Comment #15
Rowanw CreditAttribution: Rowanw commentedIs 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.
Comment #16
Gábor HojtsyNeil 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.
Comment #17
sunI thought about this for quite some time. So, with the potential of hi-jacking this issue...
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.
Comment #18
Rowanw CreditAttribution: Rowanw commentedIn 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.
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.
Comment #19
Gábor Hojtsy@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.
Comment #20
Krummrey CreditAttribution: Krummrey commentedHi, 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
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.
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...
Comment #21
Gábor Hojtsy@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.
Comment #22
Anonymous (not verified) CreditAttribution: Anonymous commentedsubscribe
Comment #23
meba CreditAttribution: meba commentedsubscribe
Comment #24
illuminaut CreditAttribution: illuminaut commentedI 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.
Comment #25
yoroy CreditAttribution: yoroy commented##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)
Comment #26
Rowanw CreditAttribution: Rowanw commentedYoroy, 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.
Comment #27
webchickI 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.
Comment #28
Rowanw CreditAttribution: Rowanw commentedUsers 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?
Comment #29
Damien Tournoud CreditAttribution: Damien Tournoud commentedI 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.
Comment #30
Anonymous (not verified) CreditAttribution: Anonymous commented"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.
Comment #31
Gábor HojtsyInput 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.
Comment #32
yoroy CreditAttribution: yoroy commentedYoroy, 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.
Comment #33
Rowanw CreditAttribution: Rowanw commentedRemember 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.
Comment #34
SeanBannister CreditAttribution: SeanBannister commentedI agree with WebChick the idea in #1 is really nice.
Comment #35
illuminaut CreditAttribution: illuminaut commentedI'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.
Comment #36
yoroy CreditAttribution: yoroy commentedilluminaut and Rowanw totally convinced me there.
I propose we work towards an actual patch that realises this:
ximo, are you still up for it?
Comment #37
alpritt CreditAttribution: alpritt commentedI 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.
Comment #38
sunThanks 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.
Comment #39
SteveBayerIN CreditAttribution: SteveBayerIN commentedLooks good. How about an ok/'apply input format' button in #36 to activate the relevant editor tied to the selected input format?
Comment #40
sunI 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.
Comment #41
ff1 CreditAttribution: ff1 commentedCould 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.
Comment #42
sunUnfortunately, 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.
Comment #43
ximo CreditAttribution: ximo commentedThe 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")?
Comment #44
Dries CreditAttribution: Dries commentedComment #45
sunI agree with Dries, especially with regard to the invisible input format guidelines for the currently selected format.
Comment #46
Rowanw CreditAttribution: Rowanw commented@Dries: #244904: UMN usability: Rename 'input formats'
Comment #47
ximo CreditAttribution: ximo commentedThe 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
Comment #48
Noyz CreditAttribution: Noyz commentedlittle nit, but I personally like the word format vs formatting. Formatting is past tense. In contrast format begs an answer.
Comment #49
SeanBannister CreditAttribution: SeanBannister commentedMight want to check out UMN usability: Rename 'input formats' as Rowanw mentioned.
As the first response states
Comment #50
ximo CreditAttribution: ximo commentedLet'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.
Comment #51
Rowanw CreditAttribution: Rowanw commented@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
Comment #52
ximo CreditAttribution: ximo commentedRowanw: 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.
Comment #53
Rowanw CreditAttribution: Rowanw commentedAfter 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.
Comment #54
alpritt CreditAttribution: alpritt commentedUpdated 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.
Comment #55
webchickalpritt, would you be able to setup another one of your awesome demo sites for this patch? :)
Comment #56
alpritt CreditAttribution: alpritt commentedLooked 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.
Comment #57
ximo CreditAttribution: ximo commented@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!
Comment #58
alpritt CreditAttribution: alpritt commented@57: I should think you can add an
$element['#prefix']
and$element['#suffix']
in form_process_input_format() in form.incComment #59
David_Rothstein CreditAttribution: David_Rothstein commentedSubscribe. 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 :)
Comment #60
amitaibuRe-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 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]
Comment #61
amitaibuAnd 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.Comment #62
amitaibuRe-rolled against HEAD. jQuery still doesn't work properly...
Comment #63
Dries CreditAttribution: Dries commentedComment #64
ximo CreditAttribution: ximo commentedI've looked over the patch trying to bring it further, and there seem to be two things that make it difficult.
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:
To this:
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 :)
Comment #65
sunComment #66
webchickComment #67
edmund.kwok CreditAttribution: edmund.kwok commentedTweaked 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
Comment #69
edmund.kwok CreditAttribution: edmund.kwok commentedThank God for the test bot. I forgot to set the format type when there is only one format. Attached patch rectifies that.
Comment #71
catchsending for a re-test
Comment #72
amitaibuJquery 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:'.
Comment #73
Rowanw CreditAttribution: Rowanw commentedDefinitely 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?
Comment #74
Dries CreditAttribution: Dries commentedAgreed. 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'.
Comment #75
XanoSubscribing.
Comment #77
Gurpartap Singh CreditAttribution: Gurpartap Singh commented
Comment #78
edmund.kwok CreditAttribution: edmund.kwok commentedRerolled 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?
Comment #79
amitaibuTested patch and all seems to work properly. RTBC in my opinion.
I've attached a snapshot of the lazy ones :)
Comment #80
XanoThe screenshot in #79 isn't right. The widget should be stuck to the bottom of the textarea and have the same width.
Comment #81
amitaibuIndeed. Patch adds CSS to adjust widget, according to Xano's comment.
Comment #82
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedIs the widget width proper even when Drupal.behaviors.textarea (resizing) is disabled?
Comment #83
amitaibuNo, when JS is disabled then the CSS isn't correct - back to CNW.
Comment #84
XanoTried the patch:
I'm working on a follow-up patch.
Comment #85
XanoThe 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.Comment #86
XanoAnd here are the screenshots.
Comment #87
XanoD'oh.
Comment #88
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedFor 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.
Comment #89
XanoI 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.
Comment #90
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedSure, at least "Filtered HTML" without any label isn't making a point. Either replace it with Formatting: label or removed the name as well.
Comment #91
XanoAnd here it is.
Comment #92
Rowanw CreditAttribution: Rowanw commentedThe layout/design looks right now, haven't done any testing though.
Comment #93
yoroy CreditAttribution: yoroy commentedSince #244904: UMN usability: Rename 'input formats' got committed in the meantime, we should incorporate those naming changes here.
Comment #94
yoroy CreditAttribution: yoroy commentedstatus
Comment #95
XanoDone. All occurences of 'input format' or anything similar have been replaced by 'text format'.
Comment #96
XanoThis 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.
Comment #97
SeanBannister CreditAttribution: SeanBannister commentedNice work Xano, looks really good. In particular moving "More information about formatting options" to the right was a good choice.
Comment #98
XanoMy to-do list for tomorrow:
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.
Comment #99
SeanBannister CreditAttribution: SeanBannister commentedSorry my post hijacked your setting change
Comment #100
sun{filter_format} is a database table of filter.module, i.e. the table name is correct.
Typo.
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.
Please use the same structure for either case.
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.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.
Comment #101
XanoThe widget does not fully work with textfields in FF3/Mac.
Comment #102
birdmanx35 CreditAttribution: birdmanx35 commentedComment #103
ff1 CreditAttribution: ff1 commentedUsing 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.
Comment #104
yoroy CreditAttribution: yoroy commentedThank 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"
Comment #105
ff1 CreditAttribution: ff1 commentedAdditional 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.
Comment #106
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedSorry 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
Comment #107
Gurpartap Singh CreditAttribution: Gurpartap Singh commenteduh, 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!
Comment #108
XanoWe do, so either the screenshot in #105 was taken with JavaScript turned of or the JS doesn't work properly in IE6.
Comment #109
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedI'm using FF3 on Mac with the demo in #103. I'll try the patch myself.
Comment #110
ff1 CreditAttribution: ff1 commentedMy 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.
Comment #111
SeanBannister CreditAttribution: SeanBannister commentedI'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.
Comment #112
ff1 CreditAttribution: ff1 commentedOn 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.
Comment #113
David_Rothstein CreditAttribution: David_Rothstein commentedThis 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"?
Comment #114
ff1 CreditAttribution: ff1 commentedWhile 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.
Comment #115
BrightLoudNoise CreditAttribution: BrightLoudNoise commentedThe 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.
Comment #116
BrightLoudNoise CreditAttribution: BrightLoudNoise commentedThe 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.
Comment #117
ff1 CreditAttribution: ff1 commentedThe 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.
Comment #118
BrightLoudNoise CreditAttribution: BrightLoudNoise commentedAttached is an updated patch from #95 with the following additions to node.css
Comment #119
yoroy CreditAttribution: yoroy commentedWhat say you, testing bot?
Comment #121
BrightLoudNoise CreditAttribution: BrightLoudNoise commentedI'll try re-rolling it against HEAD later today.
Comment #122
BrightLoudNoise CreditAttribution: BrightLoudNoise commentedI'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.
Comment #123
catchIf 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.
Comment #124
XanoI'll try to spend some time on it this Sunday, but don't hang me if I can't.
Comment #125
BrightLoudNoise CreditAttribution: BrightLoudNoise commentedRolled 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.
Comment #126
BrightLoudNoise CreditAttribution: BrightLoudNoise commentedRe-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.
Comment #127
BrightLoudNoise CreditAttribution: BrightLoudNoise commentedComment #129
Damien Tournoud CreditAttribution: Damien Tournoud commentedRerolled.
Comment #130
XanoWasn'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
Comment #131
Damien Tournoud CreditAttribution: Damien Tournoud commentedI haven't been able to see any beer during the day. Am I missing something?
Comment #132
jhedstromSubscribing.
Comment #133
Jaza CreditAttribution: Jaza commentedNice patch. Some comments:
Note: Not sure if this has been mentioned already, but you need to clear your cache after applying this patch.
Comment #134
David_Rothstein CreditAttribution: David_Rothstein commented@Jaza: For #1, I think this is a separate issue and shouldn't hold this patch back. See #87994: Quit clobbering people's work when they click the filter tips link and #153313: ckeditor input is lost when using the browser's back button.
Comment #135
yoroy CreditAttribution: yoroy commented#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.
Comment #136
Damien Tournoud CreditAttribution: Damien Tournoud commentedSounds 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.
Comment #137
webchickI made one tiny adjustment, which was to move the comment for the JS to a docblock above it and COMMITTED. YAY!!!!!!!!! :D
Comment #138
Damien Tournoud CreditAttribution: Damien Tournoud commentedLet's fix some whitespace ;)
Comment #139
webchickFixed! :)
This code commit brought to you by delicious Chunky Monkey! Mmmm...
Comment #140
XanoDoes it work in all major browsers? Also, I believe it conflicts with vertical tabs.
Comment #141
webchickYes, vertical tabs needs to be re-rolled.
If it doesn't work in all browsers, why was it marked RTBC? :P
Comment #142
ff1 CreditAttribution: ff1 commentedI'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?
Comment #143
Rowanw CreditAttribution: Rowanw commentedThe 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.
Comment #144
ff1 CreditAttribution: ff1 commentedThe 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.
Comment #145
XanoThis stuff breaks at admin/build/block/add and everywhere else a description is being used.
Comment #146
bjaspan CreditAttribution: bjaspan commentedI 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.
Comment #147
yched CreditAttribution: yched commentedTrue, 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
Comment #148
David_Rothstein CreditAttribution: David_Rothstein commentedIt 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.
Comment #149
sunThe 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.
Comment #150
sunAlso, 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.
Comment #151
sunLet'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.
Comment #152
sunI 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.
Comment #153
Damien Tournoud CreditAttribution: Damien Tournoud commentedThis effectively prevent anyone to add a #prefix or #suffix themselves.
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!I suggest flipping those: first initialize $form['format_guidelines'] with its #prefix and #suffix, and then fill it with format guidelines.
Comment #154
sunIntroduced theme_text_format_wrapper().
Comment #155
jrabeemer CreditAttribution: jrabeemer commentedI 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.
Comment #156
sun@momendo: Please test the latest patch. Fixes the layout in IE6 for me.
Comment #157
sunRequested by chx, we still want to use #type 'markup' for the text-format-wrapper element.
Comment #158
webchickI tested in Safari and sun's patch appears to be working. We need confirmation in IE 7 and 8 still.
Comment #159
sunIE6 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.
Comment #160
sunWell, 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.
Comment #161
webchickTested latest patch in Safari as well. Works great.
Committed to HEAD. Thanks a lot, folks!
Comment #163
treksler CreditAttribution: treksler commentedbingo!
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
Edit: this was supposed to be in reply to comment #32