Todd and Maciej, Thank you both for your help. I was not loading this as an application/xhtml+xml but instead as html. This has taken care of many issues that i though i was going to have to work around and makes me quite happy. The content is no longer being rearranged, and its looks like well-formed and valid xhtml. I'm curious why the DOM would rearrange the HTML content in that way. Any ideas? BTW Maciej, why would getElementsByName not work? I haven't tried, but the other HTML specific methods seem to be working. From what I can tell the XHTML content still seems to be instantiated with the DOMHTML element subclasses of the DOMCore classes. I think that's how it should be. if the DOM is to treat HTML elements as subclasses then it makes sense to treat the XHTML elements as HTML subclasses too (at least for XHTML 1.0 and probably 1.1). Beyond that it may require new subclasses descended off of the core DOM classes or perhaps another approach. For example, CoreDOM nodes could associate instance variables (say dictionaries) that encapsulate properties about that element-class. So for example, a 'img' element could be instantiated as a straight CoreDOM element but with instance variables indicating that it can have 'id', class', title', etc., attributes and must have a 'src' and 'alt' attribute. Other instance variables would indicate its prohibited, required, permitted, minimal and maximum content model. By including these instance variables in the CoreElement (and CoreAttribute) objects, the DOM would be duly abstracted and easily extended to other situations. Ideally these instance variables could be set directly from the document schema and sub-schema. Perhaps this it the direction things are heading already, but for now, I'm happy to see the HTML subclasses work. I'm using a few category methods attached to a couple of the DOMHTML subclasses. Thanks again, best wishes, Rob On Aug 24, 2006, at 3:56 PM, Todd Ditchendorf wrote:

Are you loading the XHTML programatically from ObjC? If so, are you using - [WebFrame loadHTMLString:baseURL:] ?

If that's the case, I'm not totally positive, but I think using this method instad will fix your issue:

- [WebFrame loadData:MIMEType:textEncodingName:baseURL:]

and passing in @"application/xml" or @"text/xml" as the mime type.

Todd

On Aug 24, 2006, at 12:33 PM, Rob Burns wrote:

...

I sent the following message to the sdk list, but perhaps this list is more appropriate. Briefly, when loading XHTML into an editable WebView, the contents are getting rearranged: moving elements from the HEAD to the BODY. I thought someone here might know where the code is located that does this editing of rhd source upon load. In addition to rearranging elements, the WebView is also removing "/" from self-closing elements. I

Originally, was loading the file as HTML, but i've since corrected that but still encounter this bug.

(http://bugzilla.opendarwin.org/show_bug.cgi?id=10507)

Thanks for any assistance.

Rob

...

I'm working on an application that uses WebKit's editing capabilities. Though the headers show ample support for XHTML concepts and Safari handles XHTML very well, the use of XHTML in an editing situation seems to be difficult.

1) First of all, WebView immediately converts all elements in an XHTML document to upper case, which is not consistent wit the recommendation.

2) It also converts all self-closing elements to HTML style implicitly closed elements.

3) WebView removes the DocType declaration and the XML declaration from the document.

I've found work-arounds for these unfortunate bugs, but now I'm encounter more difficult problems. If an XHTML document includes elements from another namespace in the head, WEbView graciously moves them to the body element instead. The previous issues I planed to just fix upon save, but now I can't work with non-XHTM elements in the head whiole the document is editable by WebView because WebView jmoves those elements to where they do not belong. I filed a bug report on this, (http:// bugzilla.opendarwin.org/show_bug.cgi?id=10507).

Has anyone else encountered these problems and found ways to work around them. I'd like to get in there and fix them myself, but I'm not that familiar with C++ and I'm still getting my head around the vast array of classes. Any thoughts?

best, Rob Burns

_______________________________________________ webkit-dev mailing list webkit-dev@opendarwin.org http://www.opendarwin.org/mailman/listinfo/webkit-dev