Introduce pre-defined styles that are available in the editor

[micasuh]

Inline styling for content can be detrimental for theme upgrades and style refreshes. Currently, TinyMCE menu uses inline styles for paragraph alignments, text colors and background colors, font families, font sizes, etc.

Replace these inline styles with custom class names using either p, span, or div tags relative to what editor selects.

Two examples:

1. If editor wants complete Post content to be text-align: right, insert one class name into surrounding div instead of surrounding it with new span tag and inline style.

2. A phrase of text must stand out within a paragraph by changing the font-size and font-family. In this instance, add span, bold, or em tag with custom class instead of inline styles with font-size and font-family attributes.

Content aware styling: When an editor wants to make a complete paragraph bold or emphasized, these elements don't always need to be surrounded with strong and em tags. Complete paragraphs or multi-paragraphs should be classed and styled within CSS. Content aware styling means Wordpress knows when editor has selected a paragraph versus a sentence, phrase or word and adjusts accordingly.

These custom classes can be styled with new custom CSS file inserted within wp_head for all future builds of Wordpress. Designer can opt to turn off this feature and go back to current way of styling if he or she wants.

[azaozz]

-1. Custom CSS classes are quite easy to do on per site/per theme basis. The bad thing about them is that when the user switches the theme all the styling will disappear. If this is implemented the same would happen when switching from 'supporting' to 'non-supporting' theme.

Currently this can be implemented with a small (3-4 lines of code) plugin and perhaps that is the better way of doing it as the person making the plugin would be able to adjust the theme to support previous posts too.

Force-inserting major CSS in wp_head would be disastrous.

[novasource]

This isn't about a developer's whim. It's about product strategy.

If WordPress aspires to be designer-friendly, it can't arbitrarily decline web best practices.

Profuse use of inline styles is a bad practice. E.g., ​http://webdesign.about.com/od/css/a/aa073106.htm. WP should not default to bad practices.

The bad thing about them is that when the user switches the theme all the styling will disappear.

No:

1. Nobody is proposing modifying existing content. Already-existing inline styles will continue to work.
2. This would be new CSS classes. They cannot affect existing content except by sheer coincidence.

Styling will continue to work with themes created by responsible developers who monitor ​http://codex.wordpress.org/Migrating_Plugins_and_Themes.

Not only is this enhancement a major strategic improvement, it complies with WP's own apparent standard at ​http://codex.wordpress.org/CSS#WordPress_Generated_Classes.

Force-inserting major CSS in wp_head would be disastrous.

Not disastrous, just not a 2 line patch.

Admittedly, this is a large issue and may may need to be broken down into smaller issues. But let's not kneejerk a "wontfix" on this.

[scribu]

Ok, we need to consider this issue more carefully.

All those tags don't help anybody. Please don't put them back.

[azaozz]

Yes it's a large change that would take months for the themes to adopt and for the users to update their themes. Perhaps the proper place for such discussion is wp-hackers.

[scribu]

Replying to azaozz:

Yes it's a large change that would take months for the themes to adopt and for the users to update their themes. Perhaps the proper place for such discussion is wp-hackers.

Created a new thread: Inline styles and TinyMCE

[ev3rywh3re]

Before something like this sets some design precedents in stone, I would like to suggest that some sort of CSS coding standards are established.

I know it seems silly, but most CSS element names in WordPress are named fairly arbitrarily and there really isn't a guide like ​http://codex.wordpress.org/WordPress_Coding_Standards related to HTML or CSS.

This is probably more important for the Admin UI, but if CSS starts being predefined for the objects WordPress spits out then some coding standard should thought about.

For example: Once upon a time the underscore could not be used and dashes were mostly used in class and id names. Now that the underscore is more widely supported, it is being used make elements more readable. I have no preference, but .alignright could be made more readable as .align-right.

[micasuh]

Replying to azaozz:

Yes it's a large change that would take months for the themes to adopt and for the users to update their themes. Perhaps the proper place for such discussion is wp-hackers.

While it could take months for theme developers to catch on and support the idea, I think the implementation of this idea should not take long. Starting out, this could easily be an optional switch that exists in Settings>Writing. Provide a checkbox which, when enabled, would do two things:

1. Switch functionality of TinyMCE from inline styles to modular HTML and class name attributes. Modular HTML means that if designer wants to use divs instead of spans, he'll have that option.
2. Insert TinyMCE CSS with predefined, best practices styles (i.e. class="strong" functions similarly to strong tag).

Assuming theme developers adopt this in mass, this optional feature could become permanent feature down the road. At present, when this functionality becomes available, it would only become functional when activated through the Settings menu option.

scribu - Where is this new thread called "Inline styles and TinyMCE"? I couldn't find it.

[micasuh]

2. Insert TinyMCE CSS with predefined, best practices styles (i.e. class="strong" functions similarly to strong tag).

class="strong" is a terrible example, admittedly. It needs a more semantic name that will work for elements that don't just need a typical bold. I just couldn't think of anything else off the top of my head. My apologies.

[scribu]

Replying to micasuh:

scribu - Where is this new thread called "Inline styles and TinyMCE"? I couldn't find it.

Here it is: ​http://lists.automattic.com/pipermail/wp-hackers/2009-September/027500.html

This is my proposed solution:

Instead of relying on each theme developer, make a 'default.css' file and add
it through 'wp_head'.

- fixes the inline styles in TinyMCE
- potentially fixes inline styles generated by [gallery]
- themers can disable it if they wish

People seem to like it.

[Otto42]

I can support this, but *ONLY* for inline style="whatever" elements. The strong example is indeed a terrible one, because I'd have to oppose that. Strong is a meaningful tag. Same with em and others along those lines.

For the specific case of text-align, we can use the existing aligncenter, alignleft, alignright styles that are required in themes, however I expect this will still cause breakage. Those are more generally applied to image blocks, not to paragraphs, for example.

New styles like wp-textleft and wp-textright and such would work, and including them via wp_head would be acceptable in my view, if:

1. All the styles were new names,
2. All the styles started with a prefix like wp- (this should be the case anyway, going forward)
3. The styling applied to them in the CSS was absolutely minimalistic. Nothing extra that could be applied to any specific theme. wp-textright must be text-align:right and nothing more than that.
4. Overriding these must be as simple as using !important in the theme's CSS file. If a theme has to do a remove_action to get rid of them, then that's too much to expect.

Then I could give this a tentative +1. But I'd have to see the implementation to look for flaws. Adding CSS files into themes from the core code is fraught with peril.

[micasuh]

Replying to Otto42:

I can support this, but *ONLY* for inline style="whatever" elements. The strong example is indeed a terrible one, because I'd have to oppose that. Strong is a meaningful tag. Same with em and others along those lines.

I agree with you. This is where I'd really like to see content aware styling. If a word, sentence fragment, phrase, or incomplete sentence are highlighted, the appropriate strong tag could be applied. If more than a sentence is highlighted, a strong tag would not be appropriate and a class name should be inserted into the paragraph, or two paragraphs should be surrounded by another block element containing a class name.

I've seen editors try emphasize complete paragraphs using bold tags just to distinguish the paragraph from the rest of the content. While technically there's nothing really wrong with this, it semantically deprecates the usage of the strong tag. This in turn could hurt the SEO used on a website.

For the specific case of text-align, we can use the existing aligncenter, alignleft, alignright styles that are required in themes, however I expect this will still cause breakage. Those are more generally applied to image blocks, not to paragraphs, for example.

Conversely, using inline style for every single paragraph just to right align or justify paragraphs adds incremental but unnecessary bulk to a document's size. Updating the theme will also cause presentation problems down the line due to this frequent inline style. It goes the against the principle of separating content from presentation.

My personal thought about aligning images is that they should be surrounded by divs and followed by paragraphs for captions.

<div class="image">
	<img src="image.jpg" alt="alternative text" />
	<p class="caption">This caption describes the image</p>
</div>

New styles like wp-textleft and wp-textright and such would work, and including them via wp_head would be acceptable in my view, if:

1. All the styles were new names,

All these new class names must have semantic meaning as well.

2. All the styles started with a prefix like wp- (this should be the case anyway, going forward)

This is debatable. As long as the styles are semantic, I think adding the wp- prefix is trivial.

3. The styling applied to them in the CSS was absolutely minimalistic. Nothing extra that could be applied to any specific theme. wp-textright must be text-align:right and nothing more than that.

Yes, minimalism is definitely preferred as default. However, I think building a system that allows you to easily modify both the HTML and CSS of this new function would make this even more valuable.

For instance, to right-align a paragraph, the corresponding TinyMCE button might insert this code:

<p><span class="paragraph-right">This is a paragraph.</span></p>

I'd like the ability to override both the CSS class name and HTML so that it would come up like this:

<p class="secondary">This is a paragraph.</p>

This promotes minimalistic , extensible and modular markup, as well as flexibility. Most people could easily adapt to the default markup and style and make it work for him or her, but this will provide the flexibility that both designers and editors often need.

4. Overriding these must be as simple as using !important in the theme's CSS file. If a theme has to do a remove_action to get rid of them, then that's too much to expect.

If we offer the ability to turn on this new functionality but turn off the CSS insertion, designers could then just copy and paste the CSS code into their own files. Less links and scripts equals faster rendering times.

Then I could give this a tentative +1. But I'd have to see the implementation to look for flaws. Adding CSS files into themes from the core code is fraught with peril.

I don't see this as being fraught with peril at all. By allowing people to choose this new functionality with TinyMCE, we promote extensibility and flexibility. This new function for TinyMCE would only add one new CSS file with default styles into a designers theme. And as proposed, this would start out as an optional feature that could be turned on in the Settings panel.

I'm excited this is getting a lot of attention so far, but I hope to see it generate a lot more attention in the future.

[scribu]

Related: #10465

[novasource]

Replying to scribu:

Related: #10465

That ticket is an overly literal interpretation of em and strong that doesn't consider compromises of WYSIWYG editing or historical context. I added a comment to it.

[micasuh]

Related: ​Customizing TinyMCE without Advanced TinyMCE

This is a really good start to replace Wordpress' default custom classes with your own custom classes. It works pretty well with sentences and up to one paragraph, but is screwy with multiple paragraphs. It also defaults to span when selecting incomplete sentences, phrases or words. I'd love to see an option to use span, strong, em, or other inline elements rather than just defaulting to span. It'd also be great to intelligently use div and other block elements at times when selecting multiple paragraphs.

[hakre]

Looks to me like this ticket is highly theoretical only and a bit re-inventing the wheel. On the one hand micasuh does not like how wordpress makes use of tinymce on the other hand he does not provide a patch / plugin with an editor that does all he wants. So he likes to push forward changing the dirty but worky tinymce usage we already have but only on a theoretical level.

Therefore: Plugin material. If it works in a plugin and we all can see it, we can think about changing it in core. But I do not like discuss here about castles built in the air. Other programmer got farer then that, there are editors that work on markup not on wysiwyg.

[hakre]

micasuh: any chance to see this in a plugin?

[micasuh]

I am not a PHP developer but I wanted to give back to WP through suggestions and feedback. It never was clear that I wasn't following any normal protocol about submitting tickets because there's no obvious protocol describing how to submit tickets, when to join the mailing list and discuss, and how to test a patch or bug.

Having seen the frustration of so many people who don't know HTML trying to work with TinyMCE's broken system and Wordpress' editor, I think a plugin could help this but is only patching the larger problem.

I'm not going to stop you from closing this ticket. You seem set on closing any tickets with which I'm associated no matter what I say. It sucks I quickly came under your radar as someone to attack. Based on the minimal discussion and interest raised by scribu's email to the mailing list, I thought this would get more support.

[hakre]

micsuh, I have no problem with your report. I put the focus on plugin material because that's my opinion (you see my nick above the lines? and I did not close this ticket here) because I think that with a plugin this discussion will be a) more concrete (and therefore productive) and b) a plugin can better reflect different approaches to the problem. What ​azaozz writes is incompatible with your approach (I do not say that I dislike your approach, I prefer styles and style-based editing on my websites as well). This is about finding the right strategy on how this can be implemented, not fighting you. Sorry for my bad english if it does not sound polite all the time, it's not my first language.

I'm sorry but I'm not so into TinyMCE progging to offer a plugin right away for tests.

[Otto42]

Missed your reply 4 months ago, so I'll comment on it now.

Replying to micasuh:

I agree with you. This is where I'd really like to see content aware styling. If a word, sentence fragment, phrase, or incomplete sentence are highlighted, the appropriate strong tag could be applied. If more than a sentence is highlighted, a strong tag would not be appropriate and a class name should be inserted into the paragraph, or two paragraphs should be surrounded by another block element containing a class name.

-100 million to this notion. Under absolutely no circumstances, would this be appropriate. Having consistent behavior is critical to making this idea work.

If I highlight something and click a button, then that button should do the same thing it does every time, not behave differently depending on what or how much I highlighted. If I click the bold button, then it should either do a strong or apply a class with a bold effect. But only one or the other, not both.

Conversely, using inline style for every single paragraph just to right align or justify paragraphs adds incremental but unnecessary bulk to a document's size.

Size of the resulting HTML document is irrelevant to the issue. Adding a style is not any real different than a class in terms of size additions to the document.

Updating the theme will also cause presentation problems down the line due to this frequent inline style. It goes the against the principle of separating content from presentation.

Yes, and then again no. An inline style is perfectly justified in some cases. I grant you that a class would be better in most cases, but the notion of inserting CSS into the document from the core is the real problem here. The theme traditionally controls the display (if you prefer, it's the "View" in the MVC idea). By having the core insert CSS, you're distorting that display from outside the theme. That's the fundamental issue you have to overcome here.

Yes, minimalism is definitely preferred as default. However, I think building a system that allows you to easily modify both the HTML and CSS of this new function would make this even more valuable.

For instance, to right-align a paragraph, the corresponding TinyMCE button might insert this code:

<p><span class="paragraph-right">This is a paragraph.</span></p>

I'd like the ability to override both the CSS class name and HTML so that it would come up like this:

<p class="secondary">This is a paragraph.</p>

This promotes minimalistic , extensible and modular markup, as well as flexibility.

Again, absolutely no way and -100 million. If you do that, then you lose all advantages to this idea. The whole point of having classes is to have those classes be *known values*. Themes can then style them as appropriate for that theme. If these values are flexible in any way, then you lose all value to the idea itself.

Remember, the content should be (mostly) static HTML code. It's stored in the database. Making these change means that old posts become broken. Or, if you generate these dynamically using shortcodes or something, then you add a huge processing layer which is totally unnecessary.

The class names chosen must be fixed, rigid words which will never, ever change. Changing means breaking both themes and older posts.

[scribu]

See the TinyMCE formats introduced in [16090]