Since upgrading from RC3, all my date input boxes are suddenly huge! Take a look at the attached screenshot of some exposed filters; I'd say those boxes are about three times as wide as they need to be, and it causes the form to protrude out the side of my fixed-width layout by a good 200 pixels. There is also breakage in other places, like the view editing interface (due to the "Default" column in the filters list). Could these input boxes be made more flexible in size?

CommentFileSizeAuthor
#9 date-time-input.png10.89 KBcrutch
#1 wide-date.png16.31 KBGrantovich

Comments

Grantovich’s picture

Grantovich commented
StatusFileSize
new wide-date.png16.31 KB

Attachment, take two. I'm sure I hit the Attach button last time...

karens’s picture

karens commented
Title: Extremely long date input boxes » Extremely long date input boxes in some browsers

This is Safari then? I think this is a browser-specific problem. I increased the size of the boxes because the new Date Popup used in the D6 version allows for formats that include month and day names and I wanted to allow space for that. I expanded the box size in both D5 and D6 so the same css and formatting will work in both.

But the box is not supposed to be *that* big (and it isn't in my browsers) so we need some css tweaks here.

Grantovich’s picture

Grantovich commented

Firefox 3 actually. Should've specified that. The widgets are a lot more native-looking since version 2. Although now that I check, the boxes are exactly the same width in Safari as well.

Just did some tweaking with Firebug and I got the boxes to stop breaking my layout by changing the width from auto to 100%. Unfortunately, on forms where the boxes have room to expand (like the content creation form), this causes them to take up all available space and be ridiculously long. For some reason it seems like auto is some arbitrary fixed size, when you'd think it would work more like a max-width kind of thing.

karens’s picture

karens commented
Status: Active » Fixed

I shortened it up some and added a way for the API to control the size of that box that could be used in the future to give the end user more control. I didn't implement a way to control it right now because the UI is already pretty cluttered. We'll try this fix first.

Grantovich’s picture

Grantovich commented
Version: 5.x-2.0-rc4 » 5.x-2.0-rc6
Status: Fixed » Active

Wait, sorry, this has nothing to do with Date Popup; I'm not even using that field type. This is just with the regular freeform date input box. The page source informs me that the size of this box is being set to 60, if that helps (the most recent release didn't change this).

karens’s picture

karens commented
Status: Active » Closed (works as designed)

Well nothing changed in that type of date field, so I don't know why anything would 'suddenly' have happened, unless you're using a new or different browser and suddenly saw the effect.

The default size of a textbox in Drupal is always 60. That's set by Drupal unless I override it, which I never have done with the plain textfield since there's no way of knowing how big that box needs to be. It could be set up to expect a very long input format, like 'Saturday, December 31, 2008 12:30:00PM' and there has to be room for that. Basically this kind of date is always going to take up a full line in the form.

So this is not a 'bug', it's the expected behavior.

There are ways to get around this with css (you sometimes need to set the element to display:inline to get it to shrink). I suppose it could be a feature request to have a way to shorten that box, but I don't want to clutter up the UI with too many options and there are already a lot of them, so I'd have to think about that.

Grantovich’s picture

Grantovich commented

Hmmkay. For anyone else who comes across this, I managed to fix the layout breakage by using this CSS:

.view-search-nodes .container-inline-date input {
  width: 100% !important;
}

This modifies the width of the date input only when it appears in the view with the class "view-search-nodes". It doesn't do anything about the Default field in the view editing interface, but that's a back-end thing and I'm the only one who sees it anyway.

crutch’s picture

crutch commented
Issue summary: View changes

When using "Add another item" to date field on the node, the input fields for date and time seem to need a more granular class or id which I think would solve this problem as well.

When styling for administration we are unable to control the width of the input fields. Well we can but we would have to css each potential scenario.

ex. 

#edit-field-visit-choice-und-0-value-datepicker-popup-0 {
width: 100px;
}

#edit-field-visit-choice-und-1-value-datepicker-popup-0  {
width: 100px;
}

...

#edit-field-visit-choice-und-365-value-datepicker-popup-0  {
width: 100px;
}

but we don't know how many potential "Add another item" will happen. It could be 1 it could be 20.

If the input fields it would be great to have a general but unique class for date input and then for time input fields. Then we would be able to specifically size them no matter the number of fields added.

The full field html looks like this not having added another yet.

<div id="edit-field-visit-choice" class="field-type-datetime-form field-name-field-visit-choice-form field-widget-date-popup form-wrapper">
<div id="field-visit-choice-add-more-wrapper">
<div class="form-item">
<div class="tabledrag-toggle-weight-wrapper">
<table class="sticky-header" style="position: fixed; top: 22px; left: 35px; visibility: hidden;">
<table id="field-visit-choice-values" class="field-multiple-table sticky-enabled tabledrag-processed tableheader-processed sticky-table">
<thead>
<tbody>
<tr class="draggable odd">
<td class="field-multiple-drag">
<td>
<fieldset class="form-wrapper">
<legend>
<div class="fieldset-wrapper">
<div class="fieldset-description">
<div class="date-no-float start-date-wrapper container-inline-date">
<div class="form-item form-type-date-popup form-item-field-visit-choice-und-0-value">
<div id="edit-field-visit-choice-und-0-value" class="date-padding">
<div class="form-item form-type-textfield form-item-field-visit-choice-und-0-value-date">
<label for="edit-field-visit-choice-und-0-value-datepicker-popup-0">Date </label>
<input id="edit-field-visit-choice-und-0-value-datepicker-popup-0" class="date-clear form-text" type="text" maxlength="30" size="20" value="" name="field_visit_choice[und][0][value][date]">
<div class="description"> E.g., Sep 17 2015</div>
</div>
<div class="form-item form-type-textfield form-item-field-visit-choice-und-0-value-time">
<label for="edit-field-visit-choice-und-0-value-timeEntry-popup-1">Time </label>
<input id="edit-field-visit-choice-und-0-value-timeEntry-popup-1" class="date-clear form-text" type="text" maxlength="10" size="15" value="" name="field_visit_choice[und][0][value][time]">
<div class="description">E.g., 08:00am</div>
</div>
</div>
</div>

where we could have for the input a class, the parent id of the overall date field, but date would have a general class of .date, and time would have a general class of .time and use the specific parent id #edit-field-visit-choice

<input id="edit-field-visit-choice-und-0-value-datepicker-popup-0" class="date-clear form-text date edit-field-visit-choice" type="text" maxlength="30" size="20" value="" name="field_visit_choice[und][0][value][date]">

<input id="edit-field-visit-choice-und-0-value-timeEntry-popup-1" class="date-clear form-text time edit-field-visit-choice" type="text" maxlength="10" size="15" value="" name="field_visit_choice[und][0][value][time]">

so we could use this css and it would apply to all that are added

ex. 

#edit-field-visit-choice-und-0-value-datepicker-popup-0 input.date.edit-field-visit-choice {
width: 100px;
}

#edit-field-visit-choice-und-0-value-datepicker-popup-0 input.time.edit-field-visit-choice {
width: 70px;
}
crutch’s picture

crutch commented
StatusFileSize
new date-time-input.png10.89 KB

screenshot of field when in administration