Le 3 janv. 08 à 22:29, Alexey Proskuryakov a écrit :
on 03.01.2008 23:06, Max Barel at [EMAIL PROTECTED] wrote:
As I know no way to guess xhtml capability from javascript and modify
this default header, webkit gets xhtml served as text/html.
Does this qualify for a bug report or a feature request or do I miss
something?
We could probably change the default to match Firefox, but I do not
really
see the logic behind using the same Accept string for main resource
loading
and for XHR, given that Firefox itself uses different Accept strings
for
subresources.
Well, I just checked it again and see that Firefox send the very same
accept string in XHR and normal get. Thus it gets xhtml correctly
served.
As you said, serving as XHTML is your policy. Obviously, the
priority of
the bug would be higher if it cited technical reasons for this
policy, as it
would mean that many people could benefit from a fix.
Serving xhtml as application/xhtml+xml is the conforming content-type
and, moreover, the user agent is due to parse the returned data and
return a document object into XMLHttpRequest.responseXML . This must
be the right way to go rather than injecting raw html strings into
innerHTML/outerHTML or parsing the markup. Or else responseXML is an
empty concept.
Side note:
As long as the correct namespace is used, document content is almost
OK. Almost because every linefeed between elements created from ajax
data is displayed as #cdata-section in the web inspector.
Is this a difference from Firefox? This sounds like something worth
investigating to me.
In Firefox, blank/linefeed are shown as #text node, in both case,
served as text/html or application/xhtml+xml.
WebKit inspector does not show them when application/xhtml+xml and as
#cdata-section when text/html. This might be of no importance but
warned me somehow.
- WBR, Alexey Proskuryakov.
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
