[webkit-dev] XHTML, XML and WebKit editing

[Rob Burns]

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 at opendarwin.org
>> http://www.opendarwin.org/mailman/listinfo/webkit-dev
>