W3C home > Mailing lists > Public > public-html@w3.org > March 2008

Re: several messages about contentEditable, text selection, and related subjects

From: Alfonso Martínez de Lizarrondo <amla70@gmail.com>
Date: Sun, 9 Mar 2008 13:23:31 +0100
Message-ID: <af2a8eab0803090523r293f2a6bjb0d9ea4769b8f3f3@mail.gmail.com>
To: "Simon Pieters" <simonp@opera.com>
Cc: "Mihai Sucan" <mihai.sucan@gmail.com>, "Ian Hickson" <ian@hixie.ch>, "HTML WG" <public-html@w3.org>

>  >> Should removeformat remove things like 'em' and 'strong' and 'cite' and
>  >> 'var' and 'b' and 'i' and 'span' and 'a'?
>  >
>  > Afaik, this doesn't remove links, it doesn't remove semantical markup
>  > (e.g. var, kbd, code). It does remove style attributes, b, i, font,
>  > span, and similar presentational tags. I don't know the exact behaviour
>  > - it would be best if you would ask some of the implementors (Opera,
>  > Mozilla).
>
>
> I tested Opera and Mozilla, and they do different things, and both are
>  IMHO undesirable (e.g. Opera removes links, Mozilla removes bold but not
>  italic). Removeformat is, AIUI, intended to get rid of style information
>  without loosing "semantics" after pasting in a chunk of text from another
>  application. I would argue that <b> and <i> should not be removed since
>  they are generally tied to the content while font family is generally not.
>
In FCKeditor the RemoveFormat command has been rewritten so everything
is done by code without relying on the browser due to those huge
differences that didn't really cleaned up the format.

Now the developer can choose the elements and attributes that must be
removed, there's really no other way to do it because each developer
wants a different set of removed elements:

// Only inline elements are valid.
FCKConfig.RemoveFormatTags =
'b,big,code,del,dfn,em,font,i,ins,kbd,q,samp,small,span,strike,strong,sub,sup,tt,u,var'
;

// Attributes that will be removed
FCKConfig.RemoveAttributes =
'class,style,lang,width,height,align,hspace,valign' ;

>  Maybe UAs should just strike style information when pasting from another
>  app directly as to make this command redundant?
>

No. There will be many times when the expected result is just to
include everything that is pasted, so anything that automatically
removes that styling or any element should be considered a bug.
The onPaste event should be able to satisfy this need: the developer
can choose to intercept it, read the full html that is gonna be
pasted, and then clean it up the way that he wants, canceling the
original event and inserting the new code.
Received on Sunday, 9 March 2008 12:23:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:53 UTC