Screen shot 1: http://i12.tinypic.com/5zqea12.png
...because of:

.form-button, .form-submit {
  margin: 2em 0.5em 1em 0pt;
}

Screen shot 2: http://i10.tinypic.com/5ytxgdy.png
Patch adds the following to system.css:

.container-inline .form-button, .container-inline .form-submit {
  margin: 0;
}

[And, does the component for issue tracker need an update(from drupal.css to CSS styles)?]

Comments

dries’s picture

Status: Needs review » Needs work

This doesn't seem to be a problem for some other forms, such as the various search forms (content search, user search, patch search). This could mean that these modules have their own custom CSS snippets to correct this behavior. We'll want to investigate this a bit more, and clean up the CSS if possible.

maartenvg’s picture

How is this going? I'm planning to use the .container-inline class in a module I'm updating, and came across this bug.

Most modules in core are fixed by this part of garland's style.css:

#watchdog-form-overview .form-submit,
.confirmation .form-submit,
.search-form .form-submit,
.poll .form-submit,
fieldset .form-button, fieldset .form-submit,
.sidebar .form-button, .sidebar .form-submit,
table .form-button, table .form-submit {
  margin: 0;
}

That's why for instance searches and every form inside a fieldset shows its form-submit && form-button properly, but comment.module isn't because it hasn't got a fieldset or a table around it.

It wouldn't be a problem for me to add some custom css to the module, but as far as I can see every form-submit & form-button inside a .container-inline should not have a top or bottom margin. Therefore a (small) fix in core might be better.

I opt for Gurpartap's solution, maybe for an later 5.x release as well.

sun.core’s picture

Component: drupal.css » markup

Moving "drupal.css" component issues to "markup".

sun’s picture

Title: Form buttons not obeying container-inline class » Form buttons not obeying .container-inline class
Version: 6.x-dev » 7.x-dev
Assigned: Gurpartap Singh » Unassigned
Status: Needs work » Active
jacine’s picture

Status: Active » Postponed (maintainer needs more info)

What are we supposed to test this on? Given the fact that the last reply was 3 years ago, I wonder if this is an issue at all anymore. I don't see any option to turn on comment display options anymore. Seems like it's gone from D7. Also, if the issue is only happening in Garland, it doesn't belong in this component.

sun’s picture

Title: Form buttons not obeying .container-inline class » .container-inline class overridden by system.theme.css; also not working with .form-actions
Status: Postponed (maintainer needs more info) » Needs review
StatusFileSize
new3.33 KB

Slightly re-purposing this issue.

1) Labels within .container-inline are currently overridden by system.theme.css

2) system.theme.css does not seem to account for .form-actions yet, and also not for .form-actions in combination with .container-inline.

Attached patch fixes that + Garland accordingly. Bartik seems to be fine. Didn't test others.

Test pages/forms:

node/1/delete (i.e., any confirmation form)
admin/config/regional/translate/translate (Locale module)
admin/config/system/actions
admin/content/comment

jacine’s picture

Status: Needs review » Reviewed & tested by the community

I tested with Stark and the others. Looks good to me.

sun’s picture

StatusFileSize
new2.41 KB

Only removed the PHP hunk, which duplicated #922634: Odd form actions in confirm_form()

dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to CVS HEAD. Thanks.

sun’s picture

Thanks! This patch revealed some very odd CSS styles in SimpleTest module, to be fixed over in #924158: SimpleTest test selection form markup/styling broken

Status: Fixed » Closed (fixed)

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