[webkit-dev] [resending] Improving ability to filter the
tags produced by editable webkit?
darin at apple.com
Fri Jan 5 10:09:03 PST 2007
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
- Some tags and styles WebKit is inserting for no good reason, and
the best solution is to eliminate them rather than providing API to
- 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
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.
More information about the webkit-dev