Am 17.05.2011 22:28 schrieb Ryosuke Niwa:
On Tue, May 17, 2011 at 12:50 PM, Aryeh Gregor<simetrical+...@gmail.com>wrote:
On Tue, May 17, 2011 at 3:19 AM, Ryosuke Niwa<rn...@webkit.org> wrote:
I completely disagree. As a user, I want semantics when I write my blog
entry on WordPress so that I can tweak presentation afterwards. e.g. I
have
frequently used em {font-style: normal; font-weight:bold;} strong
{text-decoration:underline; font-weight: normal;} in the past.
Then the commands will completely break no matter what you do, because
they're tied to the CSS, not the HTML element. For instance, in this
test case:
No, I apply those CSS styles only on readonly published pages so my editor
isn't affected by those rules.
Re-reading the discussions I get the impression that we have actually
two different basic concepts of online rich-text editors:
1. A WYSIWYG editor. It offers all kinds of formatting options, allowing
users to apply their preferred fonts, colors, sizes, table column widths
and whatever. In this case I want to generate a code that preserves the
visuals in all kinds of situations. In this case, it may be a good idea
to generate style attributes whereever possible. It might even be a good
idea to use <div>s for paragraph separation, I don't know.
2. An HTML editor. Authors possibly want to restrict the formatting
options. The code generated should be as basic HTML as possible, so the
output adapts to the styles of the target page - even if they are
changed due to a redesign. In this case I want to avoid style attributes
whereever possible, and I definitely want to generate <p>s and <br>s. I
might even want to make a distinction between <i> and <em>. I assume
this is what Ryosuke (and myself) talk about.
With this distinction in mind, I think some of Aryeh's questions on what
markup we want to generate have two different answers by nature. I read
about the styleWithCSS option erlier in this list. Maybe it would be
helpful to have a more generic option to set the editor into a WYSIWYG
or HTML state. This would of course cause more speccing and
implementation work, but could allow to define two different and
consistent sets of standard behaviors.
