[wp-trac] [WordPress Trac] #10753: Introduce pre-defined styles that are available in the editor

[WordPress Trac]

#10753: Introduce pre-defined styles that are available in the editor
--------------------------------------+-------------------------------------
 Reporter:  micasuh                   |        Owner:  azaozz        
     Type:  feature request           |       Status:  reopened      
 Priority:  normal                    |    Milestone:  Future Release
Component:  Themes                    |      Version:  2.8.4         
 Severity:  normal                    |   Resolution:                
 Keywords:  needs-patch dev-feedback  |  
--------------------------------------+-------------------------------------

Comment(by Otto42):

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

 Replying to [comment:12 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.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/10753#comment:21>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software