[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 micasuh):

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

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