The 'Machine name' text is on the same line as Name

tagging for the novice queue

I'm not sure about the menu behavior described in #1, but it looks like the problem text is generated at line 12 of ./modules/node/content_types.js. the quick solution would be to change

          $('#node-type-name-suffix').empty().append(' Machine name: ' + machine + ' // ...

to:

          $('#node-type-name-suffix').empty().append('<br /> Machine name: ' + machine + ' // ...

but I'm not sure if that would get in the way of adjusting the presentation with the theme. Any ideas?

Hmm.. the patch passed once before. I got this hiccup on some of my patches too. Retesting.

Line breaks like these are evil. A paragraph would be better. The attached patch also fixes two coding style errors.

In closer inspection, the root problem seems to be that the encapsulating span.field-suffix element should be a block-level element.

#3 fixes the visual problem just for node-type forms, but the change should apply to all field-suffixes and I do agree with #7 that a breakline doesn't make sense semantically in this case: a span#node-type-name-suffix shouldn't start with a line break.

Still, inserting a paragraph element inside that span like #7 isn't W3C-compliant since block-level elements (like a paragraph) aren't permitted inside inline elements (like a span).

I think the better solution is to just change the span#field-suffix into a div.field-suffix, especially since it's often followed by a div.description anyway. This change is done in form.inc as in this patch:
$output .= ' <span class="field-suffix">' . $element['#field_suffix'] . '</span>';
becomes
$output .= ' <div class="field-suffix">' . $element['#field_suffix'] . '</div>';

Yes/no?

This makes sense, although I'm not sure if having it as an inline element might be by design? Marking 'needs design review' - obviously it's broken on the content types page, but not sure this is the right fix.

Patch from #8 worked for me and successfully moves the machine name down to the next line rather than inline to the name input box.

But as per comments in #10 is this by design? I think inline is OK except it doesn't wrap cleanly on 800x600

It looks good as it is on resolutions 1024x768 or greater. However, it looks good on a separate line on those resolutions too, so we can get an improvement for rarer resolutions at no real cost for the mainstream.

Here be screenshots.

Maybe examine the alternative of just shortening the text field so everything will fit on one line. Who needs 60 characters for a type identifier anyway?

It is not supposed to be under it, it should be beside it. Obviously when this isn't possible (ie 800x600), it shouldn't.

Just trying this... Lets see if I can fix.

patch #8 works fine for me.
Unless there is another place to show field suffixes they should come underneath.

I think this is a non-fix. As Bohjan said, it is supposed to be next to the text field, but it will wrap at low resolutions.

@Bojhan, @Dries. Yes it is OK if we follow the rule of keeping suffixes beside their parents. But then on 800x600 the whole text block should be beneath the parent. This is what I mean:
It should not be this on smaller resolution:

Name: *
[Page                                                           ]   Machine name:
page [Edit]

It should be this:

Name: *
[Page                                                           ]
Machine name: page [Edit]

A line of text breaking midway like that is odd to look at.
And on wider resolution it can stay beside as Bojhan says.
What do you think?

The wrapping is indeed a problem, and 800x600 is not sufficiently obscure for us to ignore it entirely.

A CSS rule of whitespace:nowrap (or something like that; I always forget how it is spelled) on this particular element should prevent it from being wrapped in part. It would either fit on the same line as a whole, or be moved to the next line as a whole; everyone's happy.

I'm only going through my subscriptions in passing right now and can't muster the time to roll a patch. :)

This one is just a CSS line added to modules/system/system.css, line 146:

.form-item .field-suffix {
  white-space: nowrap;
}

This patch is needed if we want the "Machine name: page [Edit]" to not wrap on a small resolution.
In small resolution the entire text will go beneath its parent text box.
In wider resolution it will stay beside, as Bojhan says.
I think it is better to keep a line intact either below or beside.
What do others say?

Lovely. I have attached some screenshots that show what this does:

1.) Large resolutions won't notice this change.
2.) If the machine name gets too long for the line, the entire text will be moved down rather than a part.
3.) Before the patch, the text wraps in part, which is ugly.

I have some concern that .form-field .field-suffix may be too general. This isn't the only thing a field suffix is used for, and we haven't seen a need for this functionality anywhere else yet. A field suffix could span entire paragraphs, in which case it's intended to wrap. This patch would make a field suffix avoid wrapping even if it is very long.

A specific application of the rule to this particular element might be safer. The element has an ID that would lend itself to that.

This patch changes node.css to add the same property as an ID-specific rule.

It seems like a simpler solution is to reduce the widht of the textfield a bit. It seems overly long anyway ...

Yeah, exactly. :)

Who needs 60 characters for a type identifier anyway?

Let's simply shrink the textfield a bit.

The patch shrinks the textfield size to 30. The screenshot is the form viewed in 800x600 in Firefox 3.5b4. No line wrap!

Committed to CVS HEAD. Thanks JamesAn.