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

Geoffrey Garen ggaren at apple.com
Thu Dec 21 11:44:21 PST 2006


Do you really need to customize these things through the editing  
delegate, or do you just need WebKit to fix them in its own editing  
code? Most of your comments suggest that the latter is the case.


On Dec 21, 2006, at 11:14 AM, Dan Wood wrote:

> Hi folks,
> 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/
> Liberty means responsibility. That is why most men dread it. —  
> George Bernard Shaw
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

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

More information about the webkit-dev mailing list