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
On Aug 24, 2006, at 11:40 PM, Rob Burns wrote:
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.
Glad to hear it.
I'm curious why the DOM would rearrange the HTML content in that way. Any ideas?
Rearranging HTML content that is technically invalid is something that browsers have done for a long time. The current generation of browsers has to do it to process invalid HTML in a compatible way.
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).
Elements in an HTML document will generate the specific subclasses. However, the document object will not be an HTMLDocument (at least not currently - we may reconsider this in the future; there are complications with things like document.write). Regards, Maciej
On Aug 25, 2006, at 2:13 AM, Maciej Stachowiak wrote:
Elements in an HTML document will generate the specific subclasses. However, the document object will not be an HTMLDocument (at least not currently - we may reconsider this in the future; there are complications with things like document.write).
OK, now I'm seeing the behavior you expected. However, there's a strange side-effect to this. The elements existing in the document upon load are instantiated as DOMHTML* subclasses while the elements I create with the DOMDocument createElement are now DOMElement classes. So now I have meta elements of class DOMelement and meta elements of class DOMHTMLMetaElement. I can work with this, but its a bit peculiar. best, Rob
On Fri, Aug 25, 2006 at 01:40:55AM -0500, Rob Burns wrote:
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.
You should really read this web page if you're not sending xhtml as application/xhtml+xml: http://www.hixie.ch/advocacy/xhtml Dave
David D. Kilzer wrote:
You should really read this web page if you're not sending xhtml as application/xhtml+xml:
http://www.hixie.ch/advocacy/xhtml
Dave
I was writing a small web application recently, and I - naturally - served my XHTML 1.1 as the MIME type prescribed by the standard. However, I ran into two issues: 1) Internet Explorer 6 on windows does not recognise the MIME type, asking the user where to save it. 2) Using Safari - with both released and (then) trunk WebKit - cookies didn't work. I've filed this bug in radar. So until the bugs are fixed WebKit, and IE7 sees widespread acceptance, I'd say the world isn't ready for application/xhtml+xml. - Dan
On Sep 15, 2006, at 1:18 AM, Dan Villiom Podlaski Christiansen wrote:
David D. Kilzer wrote:
You should really read this web page if you're not sending xhtml as application/xhtml+xml: http://www.hixie.ch/advocacy/xhtml Dave
I was writing a small web application recently, and I - naturally - served my XHTML 1.1 as the MIME type prescribed by the standard. However, I ran into two issues:
1) Internet Explorer 6 on windows does not recognise the MIME type, asking the user where to save it. 2) Using Safari - with both released and (then) trunk WebKit - cookies didn't work. I've filed this bug in radar.
So until the bugs are fixed WebKit, and IE7 sees widespread acceptance, I'd say the world isn't ready for application/xhtml+xml.
IE7 won't support XHTML either. I think the upshot is that you should make your content into proper HTML and serve it as text/html, if you want to serve it on the web. Regards, Maciej
participants (4)
-
Dan Villiom Podlaski Christiansen
-
David D. Kilzer
-
Maciej Stachowiak
-
Rob Burns