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

Dan Wood dw7904954 at karelia.com
Fri Jan 5 07:56:06 PST 2007


(I'm RESENDING this conversation-opening email; I am afraid it got  
lost in the holiday shuffle.  I would appreciate some replies from  
all you WebKats and WebKittens!)



I've been working with the webkit editing APIs for well over a year  
now, and I've long had some frustrations with the quality of the HTML  
markup that is produced when one edits a block of text with webkit.

I've mentioned this over the months to various webkats and  
webkittens, but I haven't really gotten anywhere with it, so I  
thought I would post my thoughts here and see if I can get some  
discussion going, and maybe we all can draw up a spec on how to  
improve WebKit.

I have a number of concerns about the HTML markup that I'd lke to  
address:

* 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.

As a launching point, I wanted to point out some existing APIs in  
NSAttributedString, namely -[NSAttributedString  
dataFromRange:documentAttributes:error:].  You can pass in  
NSHTMLTextDocumentType to convert an attributed string to HTML, and  
you can then pass in NSExcludedElementsDocumentAttribute, described  
as "An NSArray object containing NSString objects, representing HTML  
elements not to be used in generated HTML."  These attributes are  
documented on this page <http://developer.apple.com/releasenotes/ 
Cocoa/AppKit.html>.

WebKit actually uses this technique in -[WebHTMLView  
_documentFragmentFromPasteboard:...], for what it's worth.

I think that ideally how this would best work would be a method or  
some methods in the editing delegate, where you could specify the  
kind of markup that is allowed and specify other options.  This  
would, of course, affect the actual editing behavior while editing  
happens, e.g. if you were to exclude the special apple/webkit tags  
that provide fine control over the text (such as allowing multiple  
spaces), then the text would reflect that while editing.

Comments?

--
Dan Wood
Karelia Software — Sandvox for the Mac
http://www.karelia.com/

A rising tide lifts all boats — John F. Kennedy


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20070105/ff00fb90/attachment.html


More information about the webkit-dev mailing list