[webkit-dev] [resending] Improving ability to filter the tags produced by editable webkit?

[Darin Adler]

On Jan 5, 2007, at 7:56 AM, Dan Wood wrote:

> * Being able to control/prevent insertion of apple-only and/or  
> webkit-only tags and styles
> * Being able to control/prevent certain kinds of tags and style  
> tags from being inserted, to keep markup simpler and perhaps  
> prevent certain adjustments like changing fonts/colors
> * Having control over how "physical" attributes (like boldface) get  
> marked up (e.g. <b> or <strong> or <div style="font-weight:bold;">)
> * Better normalization of tags so you never get two identical,  
> adjacent style spans; they would be coalesced into one.
> * Semi-intelligent mapping of "physical" attributes to predefined  
> styles classes
> * Better use of CSS short-hand, e.g. use the "font:" property  
> instead of font-family and font-size
> * Be able to specify how plain text is dealt with when it's pasted  
> in; is it blocked within <pre> tags, separated by <br/> tags, or  
> each line enclosed in <div> tags.

We need to sort through these.

- Some of these are just bugs; we don't want to create API to request  
bug fixes!
- Some tags and styles WebKit is inserting for no good reason, and  
the best solution is to eliminate them rather than providing API to  
remove them.
- Some of these are policy changes we should make by default. We  
don't want to offer API if every reasonable customer would want the  
better policy.

Once we've dealt with those issue, I think it makes sense to take a  
look at the rest and consider what kind of API we'd need to provide  
so that someone can control the things that really are application  
dependent. I'm concerned that if there's a broad set of options there  
would be many untested combinations.

     -- Darin