[resending] Improving ability to filter the tags produced by editable webkit?
(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
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
Thanks for the insight Darin. One thing that is frustrating is that I don't know exactly what the bugs are. Should I report each thing that annoys me as a separate bugzilla case, and see what happens? I'm just looking for the best "next action" I can take here. On Jan 5, 2007, at 10:09 AM, Darin Adler wrote:
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
-- Dan Wood Karelia Software — Sandvox for the Mac http://www.karelia.com/ People should not be afraid of their governments. Governments should be afraid of their people. — V, V for Vendetta
On Jan 5, 2007, at 2:11 PM, Dan Wood wrote:
Thanks for the insight Darin.
One thing that is frustrating is that I don't know exactly what the bugs are. Should I report each thing that annoys me as a separate bugzilla case, and see what happens? I'm just looking for the best "next action" I can take here.
I think a separate bug report for each one would be fine. I think we can make progress on these one at a time and eventually get where you want to be. I think you need to chose the one you care about most and start with that. -- Darin
participants (2)
-
Dan Wood
-
Darin Adler