I don't like the actual way the date form item is rendered.
I think there's no consistency with other core CCK widgets.
I think it has been shaped upon the project.module issue submission form. But on that module fieldsets wrap all the form items and the UI is clear.
Since on CCK there's no use of fieldsets I'd prefer to get rid of it.(And then users can define their own fieldset using the filedgroup.module).
More, we need the user defined date-field label styled as all others labels (and not as a fieldset legend).

There's a screenshot attached to show you how I think it should look.
And there's an html file that shows the markup and css styling.

I got rid of a lot of (I think useless) markup:
Basically there's a div.form-item that wraps all the forms (this is how CCK radios forms are organized).
Then I added a class to the label elements to unbold them (and eventually let the user hide them via CSS in those case where the user submitted datefield label is so clear (eg. Birthday) that we don't need a description for each select form (year, month, day).
Then I added an orphan label just after the wrapper form-item where we print the actual date-field label (this is taken from how radio buttons are coded in CCK and may even be not so correct since this label doesn't have a corresponding form elements but, hey, validates!).
I wrapped the help text with a div.description element inside the main form-item wrapper at the very end of the forms just before a clearing elements (I used br.clear the official clearing element as styled in drupal.css (but we can even think of using modern ways of clearing elements without structural markup as proposed here). This way the help text is automagically styled by drupal.css.

Let me know what you think.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dodorama’s picture

FileSize
3.43 KB

and here's teh html file

mh86’s picture

+1 for that idea
A possible solution would be to manually render form elements in the hook_widget, like $markup = form_render($form) and to call the theme_form_element function with this $markup, where you can easily set title and description and return it with $form[$field['field_name']] = array('#value' => theme('form_element', $markup))

KarenS’s picture

Status: Active » Postponed

I'm going to put this off for just a bit because the select widget code is being rewritten to allow the field order to change based on locale (see http://drupal.org/node/79449). Once those changes have been made, we can address the css issues, since those changes will affect the html that is produced.

I agree that the use of the fieldset is not standard drupal, it was used partly to keep elements from escaping, but there may be other, possibly better, ways to do it. Also, keep in mind that anything that is done has to allow for the possibility that various elements may be missing (a field might be displaying year and month only, with or without timezone, etc.), which is part of the reason for extra wrapping in some places. Anyway, any css must work reliably in standard browsers regardless of which elements are displayed (and in what order), so it will be helpful when you make suggestions about changes to html/css to let me know if those kinds of things have been verified for any solutions you propose.

dodorama’s picture

Sounds right for me.
In the meanwhile I'll work on what you suggested, testing all possible combinations.
Thanks for attention.

mh86’s picture

FileSize
4.67 KB

I worked a little bit on this topic (because I need a solution for this now for a project) and added two settings options in the widget settings, where you can choose whether you want to show your fields in a fieldset and whether you want to show the titles (month, day, year) foreach field. In the case you want to hide the fieldset, I chose the 'date field' (form API) as form type.

KarenS’s picture

I'm getting concerned about the complexity of the date field settings. I think the display would be better handled with some theme magic rather than adding more settings to the field setup. There's a fine line between the things that I would use settings for and those I would theme. Basically my plan is that anywhere the program needs to know what data to expect (a selector field input vs text field input vs jscalendar input, or granularity, or timezone settings), I want to use settings. Anything that is purely visual (fieldset or no fieldset, labels or no labels) should probably be handled in the theme (where it can be overridden easily).

I haven't figured out the best way to do this, and I've already violated that criteria in the initial version of this module, but I'd be glad for input/patches that will take things in this direction.

dodorama’s picture

FileSize
5.01 KB

I agree with Karen that the date settings is becoming huge.
I understand that the ability choose to hide the select list label is a minor feature. (a display:none on the CSS can easily do that (even if it will hapen in all date fields)
But I still believe that we doesn't need the fieldset.
So I attach my first patch ever.
I made it mocking up mh86 patch.
It should work but I've gotta warn you that my coding skills are poor.

What the patch does:

get rid of the fieldset... eh, eh:)
get rid of not needed extra markup (the date-date, date-time div etc. (I can't see why we need a div that wrap each form-item. Maybe there's a reason that I don't understand)
instead of the clearing div to contain the floats, I used a div that wrap everythings with the new drupal clearing class .clear-block that doesn't require the (extra) empty clearing div. (this class will be avaiable in drupal.css with version 5.0; for the moment I had to add the necessary styling in date.css. But the head version of datefield won't need it)

Added two tips on the readme: a link to the fieldgroup module for people who like fieldsets. a css snippet to hide the select list label

I tested it with Safari and Firefox Mac. I don't have a win machine right now but there's shouldn't be problem with thetrick to contain the floats since it has been tested for drupal.

I hope this is more useful than my usual complains.

Remember: my first patch ever. don't sue me if something doesn't work :)

dodorama’s picture

Status: Postponed » Needs review
FileSize
12.19 KB

status+screenshot

KarenS’s picture

@dodazzi -- I just committed changes to the selector that will affect this patch. Can you try to re-roll what you did on the latest version?

dodorama’s picture

I'm busy at the moment but I will work on it in a couple of weeks (I hope sooner).
In the meantime I was investigating if it's possible to theme the form in a theme_function as explained in the form api quickstart guide. even if I don't know if this has any sense (It still hard for me to understand how things work with php and drupal programming).

dodorama’s picture

FileSize
4.6 KB

Here's an updated patch for datefield 4.7 module (30th Sept version)

A summary of what it does.

End users point of view:
no more fieldset
datefield label styled as other CCK fields label (in bold as defined in drupal CSS)
select list label unbolded
help description styled as defined in drupal CSS

Coders point of view:
select list cleared using drupal 5.0 new clearing class
no more container-inline-date wrapper div. There's a form-item wrapper div instead (in this way there's more consistency with others forms)
select list are contained inside a clear-block div that contains the floats.
no more spacing div to avoid not needed extra markup

The main goal of this patch is to get rid of the fieldset that makes the submission form unclear (IMHO) and to make a clean-up of the styling using modern CSS tecniques and avoiding the use of empty divs.

It should works in all browsers, but since I don't have access to IE win further testing is needed.

dodorama’s picture

FileSize
4.52 KB

Here's a softer aprroach to the above patch.
In this one the fieldset remain but I added a class to it (so that we can style it via CSS without styiling all drupal fieldsets).
Again I used modern CSS tecniques to clear the floats without extra-markup (the fieldset itself clear the floats).
And I even made a general cleanup of not needed extra-markup.

Enjoy and, if interested, test it on IE win.

This patch apply to date.module 4.70 sept. 30th

KarenS’s picture

I couldn't get your patch to apply, but no problem, I added it in manually. This looks like a reasonable approach to me, and it seems to work fine in IE 6 on windows. I made a couple small changes to space the items a bit closer together and to fix a problem rendering the jscalendar icon in IE 6. I'll commit the changes later today.

Thanks! I meant to clean up the css, but never had time. I didn't realize the clear-after trick was getting added to 5.0 css. That's good to know.

KarenS’s picture

Status: Needs review » Fixed

Changes committed to both cvs and 4.7. Thanks again, dodazzi!

dodorama’s picture

I'm still learning how to create proper patches.
But I'm happy that I've been able to help instead of just asking for :)

Anonymous’s picture

Status: Fixed » Closed (fixed)