User login

Why not WYSIWYG: Style and Markup for Content Management System web sites

The below is the why that goes with this how: Style content in Drupal using standard HTML tags (and have it match your custom site perfectly and meet your styling needs!)

any ideas for adding text size and color to the BUE editor = my current mission
ask them what styles they want to add
just font size
and font color

explain to them the extreme importance of consistency and not letting people randomly change font size and color
so *specific* font sizes and colors

and then do it with <span class="big red"></span> or, semantically, <span class="important"></span>
in BUE editor

h1, h2...

yeah, <h1> and <h2> is even better if that's what they really want to look special, headlines
and then do it in CSS of course

then everything can be changed at once if the look of the site is changed later

you can also give them the <big></big> tag

but the value of semantic markup is the future compatibility, the consistency and control right away

We could give them TinyMCE or FCKeditor or whatever they had. There might be a better rich text editor done with jquery now. But ugh.

ohhhh... jquery
my favorite

no one's wrapped a Drupal solution around it yet


it would be better if we could convince our client of the fact that for a highly professional public-facing site, it should provide a consistent and unified look to the world, so specific tags and CSS is simply the way to go. Size and font tags are not standards-compliant and are deprecated and to be discouraged.

We wanted to mention also that we can make all headers and titles, bold text, and other text match your specifications -- including custom displays -- but that these elements of style should be handled as part of the overall theming of the site, in the style sheets.


I'd go with BUEditor

I always question what wysiwyg editors actually do to your content behind the scenes... will there be crazy inline styles added? will adding such a module be reversible? etc

There is also value to keeping the consistency of your site and not letting people randomly change font size and color and make it look 90s, and also the whole semantic markup thing for future times, blah blah


Reasons for using semantic tags, with style defined by Cascading Style Sheets, rather than inline as many web rich text editors tend to do their markup:

  • Importance of consistency and not letting people randomly change font size and color.
  • Storing non-semantic mark-up in the database with the content makes it hard to work with this content in the future, and locks you in to a specific rich text editor solution that may well not be optimal or well maintained going forward.
  • The most important value of semantic markup is the future compatibility, as well as the consistency and control right away.
  • any public-facing site should provide a consistent and unified look to the world. For this to persist across the site and over time, specific tags, ideally standard HTML tags, customized with CSS is the way to go. Size and font tags are not standards-compliant, are deprecated, and are to be discouraged.
Searched words: 
richtext semantic markup CSS WYSIWYG - What You See Is What You Get BUeditor better than TinyMCE or FCKEditor rte - rich text editor reasons not to use tinymce aside from too complicated drupal jquery rich text editor old editor problems look stupid add / edit text


oh sure, just take a couple

oh sure, just take a couple of quotes from Gus and I and make your own post out of it!

A good solution

Thanks for this post. I am taking the time to find a * final * solution for the wysiwyg editor. I totally agree with the points made here, I've been trying to keep markup and design seperate for years now. Inline styles are just plain bad. However I started having doubts when I read the following:

Styles are applied with inline styles, so we've disabled the default Drupal HTML Filter in Filtered HTML input format and used HTML Purifier filter instead. It protects the output against cross-site scripting (XSS) attack while still allowing users to use inline styles. By default in Drupal it is possible to use inline styles only with Full HTML input format.

I was completely surprised. Is inline styling salonfahig nowadays??? I really don't think so and a small search reveals that it's just not. I can't believe a good editor like that could so simply walk over that issue.

The solution is quite simple. It is possible to use custom classes with a wysiwyg editor (at least with fckeditor it is, haven't checked ckeditor yet). Allowing users to append classes to content is not an issue, especially when it's done semantically, so this is what I am going to implement. It'll be a bit more work initially, but in the end the best solution.

Thank you for the great

Thank you for the great information, it’s useful to check out Web content management system consultants advice outside of the normal channels sometimes. I’m often finding interesting solutions to problems I never considered before.

I've been using WYSIWYG

I've been using WYSIWYG editors (TinyMCE and lately, FCKEditor) for some while and I never had any problems. I guess each person has his own opinion and his own taste when it comes to implementing and optimizing stuff on their websites.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • You may post code using <code>...</code> (generic) or <?php ... ?> (highlighted PHP) tags.
  • You can use Markdown syntax to format and style the text. Also see Markdown Extra for tables, footnotes, and more.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <blockquote> <small> <h2> <h3> <h4> <h5> <h6> <sub> <sup> <p> <br> <strike> <table> <tr> <td> <thead> <th> <tbody> <tt> <output>
  • Syntax highlight code surrounded by the {syntaxhighlighter SPEC}...{/syntaxhighlighter} tags, where SPEC is a Syntaxhighlighter options string or "class="OPTIONS" title="the title".
  • Lines and paragraphs break automatically.

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.