Twenty Ten max-width in editor style wraps too early

[longjasonm]

While I get where iammattthomas was going with his change to the mceEditor, in practice it looks confusing...while editing my text, there are arbitrary line breaks that I didn't ask for, and there's no explanation why...

See file: ​http://core.trac.wordpress.org/browser/trunk/wp-content/themes/twentyten/editor-style.css?rev=13178

I propose eliminating the max-width property.

I apologize if this isn't the right way to do this, it's my first ticket.

I've attached a screenshot so you can see the issue as I see it...

[longjasonm]

Screenshot showing odd max-width behavior

[nacin]

I highly doubt this will be reverted. I'll be honest, this is one of the things I love about the editor style currently. A lot of bloggers like this because it really is what-you-see-is-what-you-get, which helps with orphaned words, floated images, what have you.

While I'm glad to see you get involved in development (first tickets are intimidating), I am suggesting close as wontfix. Keep in mind you can add your own styles here.

[dd32]

For what its worth, I agree with eliminating the max width.

Its one thing to have the styling the same, but the content width is another.

My only reasoning for it, Is that it can be annoying when you're floating images right/left, and wraping text, You never know what its going to look like until you try it.

Also note, This affects the Full screen edit as well, which results in it using less than half the width of my screen..

[westi]

As dd32 says this looks very bad in full screen mode on my 1600x1200 screen.

However I can see the desire to keep the width of the edited content to that which you will see on the front end.

Assigning to matt t for feedback.

[longjasonm]

Thanks for the feedback, guys. I do like the fact that you see the text as it would appear on the theme, and I've already made the CSS change in my copy of twentyten. I just think it should either fit the entire text editor (eliminating the whitespace seen in ever-growing monitors/resolutions) or the content editor textarea should only be 640px...could a checkbox or some user-selection method control this behavior?

[iandstewart]

I kinda like that the width is limited. Especially when you're floating images in the visual editor. It gives you an accurate representation of what you're going to wind up with when you hit publish. If there's need for full-width text-editing there's always the HTML editor.

[nacin]

Having an ability to turn it off might be nice, but we're way past that I think.

[markjaquith]

I like the accurate representation.

But it's a little odd in full-screen mode. Could we tweak the CSS so that it doesn't apply the max-width to to the full screen Visual editor?

[nacin]

I tried, but we don't have any CSS inside the iframe (only on the iframe itself) when we're in full screen mode. If someone wants to dive into TinyMCE, though, that'd be a good compromise here.

[azaozz]

The full screen mode in TinyMCE is actually another instance of the editor (together with the iframe) and is wrapped in a <span id="mce_fullscreen_parent"... so the max-width can be overridden in the CSS easily.

[markjaquith]

azaozz — that span is outside the iframe. CSS outside the iframe cannot affect content within the iframe. We'd need a fullscreen/normal class implemented within the iframe in order to target it with twentyten's editor-style.css file.

[markjaquith]

And I should add, CSS inside the iframe doesn't know about the parent div outside of the iframe. The fullscreen-ness isn't communicated to the contents of the iframe.

[paulgregory]

If we go back to the ticket text, part of the problem is "there's no explanation why".

I propose a visual clue that a max-width has been imposed.

A light grey dashed line at the right would be fairly simple to achieve in the CSS.
OK it's not accurate WYSIWYG as it's not like the theme - but most WYSIWYG software shows margin lines that aren't on the print/PDF and it would therefore be a good hint as to why lines were breaking at that point.

Long term, a fullscreen variant CSS is probably a good idea but in the meantime a subtle line on both fullscreen and normal editors would help explain why it looks odd.

[nacin]

We're going to leave this as is for now. I'm moving this to 3.1 so we can use this ticket to add full screen awareness to the iframe's HTML.

[azaozz]

Replying to markjaquith:

that span is outside the iframe...

Of course, you're right. I was thinking of TinyMCE plugin access... It seems the only way to do this would be through JS. There is some logic in our "wordpress" plugin that adds the Insert Media buttons in full screen mode only. Perhaps can use that to add (or remove/replace) a CSS class on the body tag in the iframe. I'll run some tests.

[macgruder]

I don't really agree with the argument that it gives an accurate representation of the screen: it gives an accurate representation of the screen only if you have your textarea wider than the max width.

In other words, there are two behaviours going on in the one interface. An 'accurate' representation when your screen is wider and another when it's not which seems inconsistent and confusing.

[chriscct7]

Should this be closed as wontfix?

[azaozz]

Replying to chriscct7:

Right. Themes have been setting max-width on the editor body for years. Can be disabled/overridden from a plugin.