To reproduce: 0. Launch Blot_editableDiv_showSource, my modified version of "Blot" available from <http://dan.karelia.com/webkit/Blot_editableDiv_showSource.zip> with DYLD_FRAMEWORK_PATH pointing to TOT. (I'm using r18941) 1. Using some sort of webkit viewing program, render the following markup: <div style="font:24px 'Lucida Grande';">Hello this is <i>Italic</i> Lucida.</div> 2. Copy that text (noting that it is Lucida Grande, with a synthesized italic) 3. Click on the top panel in the modified Blot 4. Paste in the text. (Note that the italic is transferred over) 5. Select some other text, such as the word "this" 6. Attempt to make this text italic from within Blot Results: You can't. So even though WebKit can (with some font synthesis) display italic Lucida, you can't actually make text be italic using the standard menus. Suggestion: Since Lucida Grande "italic" is supported for display by WebKit, please also make that property editable. Otherwise, a user might see some text in italic, remove it, and then want to restore it to being italic.
I don't fully understand your description. What kind of markup do you want WebKit to produce / handle?
When somebody is typing text in an editable field, they expect to be able to choose Italic, Bold, etc. Since WebKit is able to display Lucida Grande in italic (although it cheats, by actually showing another font), it would make sense to be able to allow the user to set Italic. Does that clarify things?
(In reply to comment #2) > When somebody is typing text in an editable field, they expect to be able to choose Italic, Bold, etc. > > Since WebKit is able to display Lucida Grande in italic (although it cheats, by actually showing another font), it would make sense to be able to allow the user to set Italic. > > Does that clarify things? Yes, but I can italicize <div style="font-family: 'Lucida Grande';">hello world</div> on WebKit to obtain <div style="font-family: 'Lucida Grande';"><i>hello world</i></div> (try it out on http://www.mozilla.org/editor/midasdemo/), which seems to be what you desire. What kind of problems are you having?
Hi, Maybe my steps to reproduce wasn't clear. What I want to be able to do is to have an editable div, where the font is a font like Lucida Grande. Type in some text. Select some text. Choose "Italic" from the Format menu. But it is grayed out. This is a request to allow Italic to be chosen *anyhow*, and use the "synthesized" italic display, as you showed that WebKit is able to display. Does that clarify?
(In reply to comment #4) > Maybe my steps to reproduce wasn't clear. > > What I want to be able to do is to have an editable div, where the font is a font like Lucida Grande. > > Type in some text. > > Select some text. > > Choose "Italic" from the Format menu. So this bug is not reproducible on WebKit? > But it is grayed out. By grayed out, are you saying a menu item or toolbar icon to italicize text is grayed out and thus not selectable? Then that sounds like a bug with queryCommandEnabled. > This is a request to allow Italic to be chosen *anyhow*, and use the "synthesized" italic display, as you showed that WebKit is able to display. As I said earlier, I can italicize the text using execCommand('italic', false, null) so I haven't been able to reproduce the issue.
I just discovered that my modified "Blot" application had been removed. I have restored it. I just reproduced my original report. (This would be linked against the version of Webkit installed on my system; I have the latest Safari installed.) When I tried to make the word "this" into italics, by choosing "Italic" from the menu Format -> Style -> Italic, it is grayed out. Are you able to run the test application and verify this? Thanks.
(In reply to comment #6) > I just reproduced my original report. (This would be linked against the version of Webkit installed on my system; I have the latest Safari installed.) Please use the nightly or TOT. > When I tried to make the word "this" into italics, by choosing "Italic" from the menu Format -> Style -> Italic, it is grayed out. > > Are you able to run the test application and verify this? Just because there is a bug in an application that uses WebKit doesn't mean there's a bug in WebKit. There are many applications that use WebKit, and we cannot possibly go verify each bug of each such application to verify that it's not a bug in WebKit. Please make a test that demonstrates a bug in WebKit without having to install an application. Or describe tests that reproduce the same issue.
(In reply to comment #7) > (In reply to comment #6) > > When I tried to make the word "this" into italics, by choosing "Italic" from the menu Format -> Style -> Italic, it is grayed out. > > > > Are you able to run the test application and verify this? > > Just because there is a bug in an application that uses WebKit doesn't mean there's a bug in WebKit. There are many applications that use WebKit, and we cannot possibly go verify each bug of each such application to verify that it's not a bug in WebKit. Please make a test that demonstrates a bug in WebKit without having to install an application. Or describe tests that reproduce the same issue. Per IRC discussion, I learned that blot used to be a WebKit demo app. Sorry about that. I can verify the issue. But still need a reduction for this bug.
(In reply to comment #7) > (In reply to comment #6) > > I just reproduced my original report. (This would be linked against the version of Webkit installed on my system; I have the latest Safari installed.) > > Please use the nightly or TOT. > > > When I tried to make the word "this" into italics, by choosing "Italic" from the menu Format -> Style -> Italic, it is grayed out. > > > > Are you able to run the test application and verify this? > > Just because there is a bug in an application that uses WebKit doesn't mean there's a bug in WebKit. There are many applications that use WebKit, and we cannot possibly go verify each bug of each such application to verify that it's not a bug in WebKit. Please make a test that demonstrates a bug in WebKit without having to install an application. Or describe tests that reproduce the same issue. Providing a demo app is normal practice for bugs that cannot be easily reproduced in the browser. Sometimes there are bugs in WebKit APIs or functionality that is not directly exposed in the browser, but do affect other apps. We do not normally reject such bugs.
(In reply to comment #7) > Just because there is a bug in an application that uses WebKit doesn't mean there's a bug in WebKit. This report is not about a bug in an application that uses WebKit. It is about WebKit. > There are many applications that use WebKit, and we cannot possibly go verify each bug of each such application to verify that it's not a bug in WebKit. > Please make a test that demonstrates a bug in WebKit without having to install an application. Or describe tests that reproduce the same issue. I am not sure how one would demonstrate a WebKit API issue without some code that uses the WebKit API in question. Dan went through the extra trouble of not just describing the API issue but also making a complete example available. This is really good! As to the bug itself: WebKit’s API follows AppKit in only allowing you to use real typefaces and not synthesized ones. This is similar to how if you select some text in Lucida Grande in TextEdit, then Format > Font > Italic is disabled. Arguably, since WebKit is able to synthesize typefaces and the user may encounter them in content, we should relax this (note that it’s already possible to produce synthetic italics in editable HTML in Safari by hitting Command-I). Alternatively, there may already be a way for an application to send the corresponding selector to the WebView and get the same behavior that you get in Safari.
(In reply to comment #10) > (In reply to comment #7) > > Just because there is a bug in an application that uses WebKit doesn't mean there's a bug in WebKit. > This report is not about a bug in an application that uses WebKit. It is about WebKit. It was not clear at all from the original bug report. I would have responded more reasonably if the original report contained the particular API that caused this problem. In particular, the reproduction steps is: > 1. Using some sort of webkit viewing program, render the following markup: ... > 4. Paste in the text. (Note that the italic is transferred over) > 5. Select some other text, such as the word "this" > 6. Attempt to make this text italic from within Blot And I can italicize the text in WebKit.
Perhaps the misunderstanding is that this is about the interaction between WebKit (where it is obviously possible to make text be italic by introducing the right markup) and the Cocoa user interface - in other words, hook up a standard "Format" menu to the webview, and does this work as you would expect? I think that comment #10 is good analysis -- since it's possible to see synthesized italics in a webkit application, and since you can choose command-I in Safari (which, I presume, had to work around things a bit), it would make sense for other client applications to make text italic as well, without having to re-invent the wheel.
I did some simple tests in the browser with document.queryCommandEnabled("Italic") and confirmed that the document seems to return true even when text of a font such as Lucida Grande is selected. I think I ran into similar problems to this when I was developing MarsEdit's rich editor. As I recall I worked around it by moving away from the changeFontTrait: as the menu item action for these style items. By bypassing the font manager and going straight to WebKit, I believe I was able to use a combination of queryCommandEnabled to validate and execCommand to perform the toggle.
Thanks for the info. (In reply to comment #10) > As to the bug itself: WebKit’s API follows AppKit in only allowing you to use real typefaces and not synthesized ones. This is similar to how if you select some text in Lucida Grande in TextEdit, then Format > Font > Italic is disabled. Do you know where we're deciding this? I've been looking through WebCore / WebKit but I can't find the place where we update the menu item status. >Arguably, since WebKit is able to synthesize typefaces and the user may encounter them in content, we should relax this (note that it’s already possible to produce synthetic italics in editable HTML in Safari by hitting Command-I). Alternatively, there may already be a way for an application to send the corresponding selector to the WebView and get the same behavior that you get in Safari. I have to read the code to understand to respond to this. (In reply to comment #13) > I did some simple tests in the browser with document.queryCommandEnabled("Italic") and confirmed that the document seems to return true even when text of a font such as Lucida Grande is selected. Yeah, so it seems like we have a different code path to detect whether or not the text can be italicized. > I think I ran into similar problems to this when I was developing MarsEdit's rich editor. As I recall I worked around it by moving away from the changeFontTrait: as the menu item action for these style items. By bypassing the font manager and going straight to WebKit, I believe I was able to use a combination of queryCommandEnabled to validate and execCommand to perform the toggle. I looked at changeFontTrait and - (void)_addToStyle:(DOMCSSStyleDeclaration *)style fontA:(NSFont *)a fontB:(NSFont *)b seems to be the key functions here. But I don't hink bypassing them will fix the menu item being grayed out. We probably have a separate code path to mimic AppKit's behavior but I think the default fall back should be queryCommandEnabled or execCommand, or at least they should share some code.
<rdar://problem/8466780>
(In reply to comment #14) > (In reply to comment #10) > > As to the bug itself: WebKit’s API follows AppKit in only allowing you to use real typefaces and not synthesized ones. This is similar to how if you select some text in Lucida Grande in TextEdit, then Format > Font > Italic is disabled. > > Do you know where we're deciding this? I've been looking through WebCore / WebKit but I can't find the place where we update the menu item status. This is a complicated topic. I’m not surprised you couldn’t find the code in WebKit because WebKit doesn’t get consulted. The menu in question has the selector addFontTrait: and points to the NSFontManager object. The NSFontManager’s validateMenuItem: and validateUserInterfaceItem: methods decide whether the menu item should be enabled or not by looking at the available fonts directly and does not consult WebKit. Influencing the AppKit behavior in cases like this where we don’t like it may require some tricky Mac-specific work and possibly even changes to AppKit.
Thanks for the info, Darin. (In reply to comment #16) > The menu in question has the selector addFontTrait: and points to the NSFontManager object. The NSFontManager’s validateMenuItem: and validateUserInterfaceItem: methods decide whether the menu item should be enabled or not by looking at the available fonts directly and does not consult WebKit. > > Influencing the AppKit behavior in cases like this where we don’t like it may require some tricky Mac-specific work and possibly even changes to AppKit. Doesn't that mean this is a bug with AppKit? Regardless, yours and other comments such as #10 and #13 seem to imply that this bug belongs to WebKit API rather than HTML Editing because it's the problem with the embedding API we have on Mac. As much as I'd like to fix this bug, I think someone from Apple or someone familiar with AppKit should take over this bug since I don't know anything about AppKit.