WordPress.org

Make WordPress Core

Opened 10 years ago

Closed 5 years ago

#13529 closed defect (bug) (wontfix)

Twenty Ten max-width in editor style wraps too early

Reported by: longjasonm Owned by: iammattthomas
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: TinyMCE Keywords: needs-patch close
Focuses: Cc:
PR Number:

Description

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...

Attachments (1)

changeset-13178-screenshot.jpg (194.8 KB) - added by longjasonm 10 years ago.
Screenshot showing odd max-width behavior

Download all attachments as: .zip

Change History (20)

@longjasonm
10 years ago

Screenshot showing odd max-width behavior

#1 @nacin
10 years ago

  • Keywords close added; css mceEditor UI UX removed

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.

#2 @dd32
9 years ago

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..

#3 @westi
9 years ago

  • Component changed from Editor to Themes
  • Owner set to iammattthomas
  • Status changed from new to assigned
  • Summary changed from Disagree with Changeset 13178 to Twenty Ten max-width in editor style wraps too early

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.

#4 @longjasonm
9 years ago

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?

#5 @iandstewart
9 years ago

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.

#6 @nacin
9 years ago

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

#7 @markjaquith
9 years ago

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?

#8 @nacin
9 years ago

  • Keywords close removed

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.

#9 @azaozz
9 years ago

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.

#10 @nacin
9 years ago

  • Keywords needs-patch added

#11 follow-up: @markjaquith
9 years ago

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.

#12 @markjaquith
9 years ago

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.

#13 @paulgregory
9 years ago

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.

#14 @nacin
9 years ago

  • Component changed from Themes to TinyMCE
  • Milestone changed from 3.0 to 3.1

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.

#15 in reply to: ↑ 11 @azaozz
9 years ago

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.

#16 @macgruder
9 years ago

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.

#17 @nacin
9 years ago

  • Milestone changed from Awaiting Triage to Future Release

#18 follow-up: @chriscct7
5 years ago

  • Keywords close added

Should this be closed as wontfix?

#19 in reply to: ↑ 18 @azaozz
5 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from assigned to closed

Replying to chriscct7:

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

Note: See TracTickets for help on using tickets.