Opened 16 years ago

Closed 16 years ago

Last modified 16 years ago

#1980 closed Task (fixed)

Change default <b> and <i> to <strong> and <em>

Reported by: Frederico Caldeira Knabben Owned by: Frederico Caldeira Knabben
Priority: Normal Milestone: FCKeditor 2.6
Component: Core : Styles Version:
Keywords: Confirmed Review+ Cc:


People around there doesn't understand the real meaning of <strong> and <em> and are using them indiscriminately for formatting, enforcing loudly that in this way they are XHTML aware.

They are also accusing us to use the good and old <b> and <i> "formatting" tags for "formatting", instead of the new and fashionable <strong> and <em> "semantic" tags (even if those are available in the Styles combo anyway).

So, to shut up the general mass opinion, it seems that it would be better for us to configure the editor to produce <strong> and <em> by default, removing those entries from the Styles combo.

At this point, we should also think about the following tags, which are produced by default with the "formatting" buttons:

  • <u> : change to <span style="text-decoration: underline;">
  • <strike> : change to <span style="text-decoration: line-through;"> (or <del>?)

We can use the powerful features of FCKeditor to easily configure it to produce the above tags. But... does all that makes sense? Would anyone get angry with us because of it?

Attachments (1)

1980.patch (1.7 KB) - added by Frederico Caldeira Knabben 16 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 16 years ago by Robert Hafner

When possible avoiding the inline styles is preferred, so the designer of the site can place how they want tags to display from their own style sheets. Using <del> instead of <strike> would be great, but I think <u> should stay as is.

comment:2 Changed 16 years ago by Alfonso Martínez de Lizarrondo

I think that this isn't just an issue of one tag over the other. This is almost a religious issue for some people, and the fact is that from a semantic point of view <strong> isn't the same than <b>, and <strike> isn't the same than <del>. But if you want to see how far people can argue about that differences, take a look at this thread:

From my point of view the solution would be to offer some "profiles", just a set of configuration settings that makes the editor behave in one way or another according to each developer taste.

So one profile would be something like "html3", where no styles are used, useful to work with outdated systems that don't understand css, but are parte of the workflow (some pdf converters, partially flash did have also some limitations, but I think that currently is much better).

Another one would be "html4", (i'm trying to figure out the different profiles just to express my point of view), this would use for example inline-styles, <b> and <i> (after all the user is probably just wanting to make the text bold, not to give them any semantic meaning), everything that is possible with html4.

Another is "pure xhtml1.1" now everything that is disallowed in xhtml1.1 is removed. Presentational attributes from the elements (border, style..) aren't allowed, and the developer must configure the classes that he wants to use. Instead of the <b> and <i> the <strong> and <em> buttons are present, but those buttons must not be the same ones (the pictures), they must reflect that they are used to mark a section as <strong> or <em>. The underline, strike, color, background color buttons aren't available. Don't even mention font-size or font-family...

With this mode you would end up with a WYSIWYM editor, and the people cared about the purity of the content can use that mode and leave the rest of the humanity keep using something that works for them. Setting up and using such configuration is much more difficult (you need to define the classes that you want to use beforehand so if you want to leave end users working with that mode they will find that they are too restricted and might have to face their anger about such a bad editor that doesn't even have a color chooser).

So my vote would be to create such profiles (that's it: a different fckconfig.js file for each one) and leave as the default one one that resembles the current configuration, but maybe adjusting it a little (I'm thinking about the option to clean content from Word to preserve the formating instead of removing headers and generating font tags).

I would even remove the <u> and <strike> buttons from the default toolbar.

comment:3 Changed 16 years ago by Alfonso Martínez de Lizarrondo

These are the tags allowed by Flash

It's much worse than I expected.

comment:4 Changed 16 years ago by Frederico Caldeira Knabben

You idea is interesting Alfonso, but I believe it is much is doable and mainly easier to maintain through documentation only. It would be a pain to maintain several configuration files, and it would even bring some confusion to the end developers. After all, the changes for a HTML4 profile would be quite a few, Flash would have its own needs, and HTML1.1, as you have well described, can't be done with a single profile change.

We should instead properly defined the default behavior of the editor. And this is why we have this ticket.

For now we could think about a simple <strong> and <em> change, leaving the rest as is.

We could instead plan for the V3 a change to the default toolbar. We should provide the following pre-configured toolbar sets: Basic, Default and Full. The Full is what we have today, but it's not the default one, which would have the most used things (or the correct things to have).

Changed 16 years ago by Frederico Caldeira Knabben

Attachment: 1980.patch added

comment:5 Changed 16 years ago by Frederico Caldeira Knabben

Keywords: Confirmed Review? added; Discussion removed
Owner: set to Frederico Caldeira Knabben
Status: newassigned

comment:6 Changed 16 years ago by Alfonso Martínez de Lizarrondo

Keywords: Review+ added; Review? removed

comment:7 Changed 16 years ago by Frederico Caldeira Knabben

Resolution: fixed
Status: assignedclosed

Fixed with [1773]. Click here for more info about our SVN system.

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy