Le 4 janv. 08 à 00:24, Max Barel a écrit :
Le 3 janv. 08 à 22:32, Darin Adler a écrit :
On Jan 3, 2008, at 2:03 PM, Max Barel wrote:
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.
That is not correct.
An XMLHttpRequest could be used to get any kind of content, even
non-XML. There's no reason to assume it would be XHTML. I don't
think it's right for the browser to assume that XMLHttpRequest is
going to be getting an XHTML document as opposed to other kinds of
XML and set the Accept header field accordingly.
We sure agree on this and, in fact, Firefox default Accept header is
rather open:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/
plain;q=0.8,image/png,*/*;q=0.5
And the current draft of the W3C XMLHttpRequest specification <http://www.w3.org/TR/XMLHttpRequest/
> explicitly forbids setting the Accept header field:
"If the user agent implements server-driven content-negotiation it
should set Accept-Language, Accept-Encoding and Accept-Charset
headers as appropriate; it must not automatically set the Accept
header."
You get a point. I didn't see this and the reason for this
prohibition is beyond my understanding.
WebKit is not currently conforming to this, because it's sending "*/
*" rather than no header at all.
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.
Sounds fine. I think you should set the Accept header field based
on the browser capabilities. The fact that Firefox is currently
giving you this Accept header field automatically is a bug, and I
think you should not rely on it.
I still have to investigate the DOMImplementation.hasFeature method
you suggested to see if it's a working way to reliably discriminate
browsers and then set the Accept header accordingly.
Once again doing thing (simple DOM injection) the right way (xml
compliant and DOM methods) will turn trickier than the dirty way
(raw html string into innerHTML).
Or if you like this behavior and think that other browsers need to
support it, then we should get the W3C XMLHttpRequest specification
fixed.
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.
That seems important. Would you be willing to file a bug with a
test case?
OK, I'll do it, even if I'm not sure how to entitle it.
Max
Filed a bug to report #cdata problem and also namespace requirement on
injected xhtml chunks:
http://bugs.webkit.org/show_bug.cgi?id=16731_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
