Hello, I'm almost certain this topic has been covered before so I'll try to keep my questions brief and will gladly read any resources already devoted to thereto (I just signed up for this mailing list). Basically, I'm an AJAX developer for a large civil engineering company. As User Interface Manager for the corporate intranet, I've regularly tried to enrich the capabilities of our intranet without increasing bandwidth needs and/or client requirements. To date, my efforts have focused primarily on IE (the corporate browser standard), but I am being asked (and honestly want) to support other browsers including FireFox and Safari. It seems to me that there are a couple of things that are missing from Safari. If anyone could speak to either of these (potentially incorrect) observations, please do. 1. Although Safari implements most of the XML Extras in FireFox, as far as I can tell it lacks a critical piece of the AJAX framework: the ability to apply an XSLT transform to an XML document received asynchronously from a server into HTML. I believe Safari supports .innerHTML on most tags (could be wrong), so the transform process seems to be the only missing piece of the puzzle in this regard. 2. There seems to be a number of bugs with contenteditable regions in Safari. Strictly speaking these are not part of the AJAX "platform", but having reliable editable regions would be very useful for online applications. The Writely.com website has some rather vague descriptions of the problems. I feel compelled to say that I am an ardinent Mac user at home. ;-) Thank you! Andrew Eberhard
Andrew, On Dec 24, 2005, at 6:03 PM, Andrew Eberhard wrote:
1. Although Safari implements most of the XML Extras in FireFox, as far as I can tell it lacks a critical piece of the AJAX framework: the ability to apply an XSLT transform to an XML document received asynchronously from a server into HTML. I believe Safari supports .innerHTML on most tags (could be wrong), so the transform process seems to be the only missing piece of the puzzle in this regard.
XSLTProcessor (the javascript object of which you are speaking) is available in tip-of-tree WebKit, which you can build yourself: http://webkit.opendarwin.org/building/build.html or just download the latest nightly build: http://nightly.webkit.org/ There if however no timeline as to when these fixes will make it into a released version of Safari, but with the above mentioned resources, you are able to test your sites today with what your users will have in the future.
2. There seems to be a number of bugs with contenteditable regions in Safari. Strictly speaking these are not part of the AJAX "platform", but having reliable editable regions would be very useful for online applications. The Writely.com website has some rather vague descriptions of the problems.
Many fixes have been made to contenteditable since the last released version of Safari. This is actually a very active area of development. Again, you can test your sites with the latest nightly to see what changes we've made. If you find there are still areas of your site which are broken with the latest WebKit nightly, I would encourage you to file a bug in our open source bug tracking database: http://webkit.opendarwin.org/quality/reporting.html I hope that helps. Happy holidays, -eric
Hi Eric, Well, I'm getting underway with Safari-enabling my AJAX project [using the latest nightly build ;-) ] and I've run into a problem that seems to be "as designed" but I wanted to run it by everyone first. Basically, Document.load is not supported in Safari. I assume that I can use XMLHttpRequest instead, but http:// bugzilla.opendarwin.org/show_bug.cgi?id=5411 led me to think that there might be reason to enter a bug on Document.load support. Since Sarissa currently relies on Document.load for SarissaDoc.load, I wasn't sure if bug #5411 was intended to include Document.load support in Safari or if the folks at Sarissa should be asked to update it to work with Safari's XmlHttpRequest approach. There is a bit of prior research on this subject at http:// www.xs4all.nl/~zanstra/inTec/safariIdea.htm. Thanks, Andrew
Andrew Eberhard wrote:
Hi Eric,
Well, I'm getting underway with Safari-enabling my AJAX project [using the latest nightly build ;-) ] and I've run into a problem that seems to be "as designed" but I wanted to run it by everyone first. Basically, Document.load is not supported in Safari. I assume that I can use XMLHttpRequest instead, but http://bugzilla.opendarwin.org/show_bug.cgi?id=5411 led me to think that there might be reason to enter a bug on Document.load support. Since Sarissa currently relies on Document.load for SarissaDoc.load, I wasn't sure if bug #5411 was intended to include Document.load support in Safari or if the folks at Sarissa should be asked to update it to work with Safari's XmlHttpRequest approach.
There is a bit of prior research on this subject at http://www.xs4all.nl/~zanstra/inTec/safariIdea.htm.
Hi Andrew. The Sarissa folks are taking a look at it. It's actually possible to work around the bug, I believe. Here is what triggers the bug: var oldDoc = document.implementation.createDocument("", "", null); (Note: This is against the Sarissa CVS HEAD.) Creating a document with a real node name for the document element, though, works: var oldDoc = document.implementation.createDocument("", "foo", null); Hmm, come to think of it, this works as well: var oldDoc = document.implementation.createDocument("", null, null); Anyway, my guess is that your application can be made to work with a patched Sarissa. I *think* (but I'm not sure) that the qualified name (2nd arg) should either be a real node name or null. In which case, WebKit is right and we need to change Sarissa. --Paul
Hi Paul, Thanks for responding (and sorry my post was inadvertently directed only to Eric). I did run into the problem that you mentioned and I patched sarissa.js to do exactly what you suggested (I used "temp"). Most of the sarissa test cases now run successfully (very good news), but the problem I mentioned is actually a separate issue. When creating an XML document, sarissa assumes that the output of document.implementation.createDocument implements a method called "load." This allows the XML document to load XML from an XML file using a standard URI (i.e. file://, http://, and relative paths). As far as I can tell, this method is not implemented in Safari causing sarissa to break whenever the SarissaDocument.load method is used. Technically, Sarissa could be updated to use XMLHttpRequest in order to provide this functionality to the web developer using the Sarissa library, but the more I investigate that approach, the more it resembles a crude substitute for implementing the load method as described in this standard: http://www.w3.org/TR/2004/REC-DOM-Level-3-LS-20040407/load-save.html I guess I'm not sure whether or not this is a bug, an oversight, or a deliberate omission in Safari. Once I determine this, I should be able to either convince the folks at Sarissa to modify their code, enter a bug report on Safari (still waiting on my BZ enrollment email...), or just hack Sarissa myself to implement SarissaDocument.load for Safari alone using XmlHTTPRequest. Many thanks! Andrew On 03.01.2006, at 01:35, Paul Everitt wrote:
Andrew Eberhard wrote:
Hi Eric, Well, I'm getting underway with Safari-enabling my AJAX project [using the latest nightly build ;-) ] and I've run into a problem that seems to be "as designed" but I wanted to run it by everyone first. Basically, Document.load is not supported in Safari. I assume that I can use XMLHttpRequest instead, but http:// bugzilla.opendarwin.org/show_bug.cgi?id=5411 led me to think that there might be reason to enter a bug on Document.load support. Since Sarissa currently relies on Document.load for SarissaDoc.load, I wasn't sure if bug #5411 was intended to include Document.load support in Safari or if the folks at Sarissa should be asked to update it to work with Safari's XmlHttpRequest approach. There is a bit of prior research on this subject at http:// www.xs4all.nl/~zanstra/inTec/safariIdea.htm.
Hi Andrew. The Sarissa folks are taking a look at it. It's actually possible to work around the bug, I believe.
Here is what triggers the bug:
var oldDoc = document.implementation.createDocument("", "", null);
(Note: This is against the Sarissa CVS HEAD.)
Creating a document with a real node name for the document element, though, works:
var oldDoc = document.implementation.createDocument("", "foo", null);
Hmm, come to think of it, this works as well:
var oldDoc = document.implementation.createDocument("", null, null);
Anyway, my guess is that your application can be made to work with a patched Sarissa. I *think* (but I'm not sure) that the qualified name (2nd arg) should either be a real node name or null. In which case, WebKit is right and we need to change Sarissa.
--Paul
Hi Paul, Thanks for responding (and sorry my post was inadvertently directed only to Eric). I did run into the problem that you mentioned and I patched sarissa.js to do exactly what you suggested (I used "temp"). Most of the sarissa test cases now run successfully (very good news), but the problem I mentioned is actually a separate issue. When creating an XML document, sarissa assumes that the output of document.implementation.createDocument implements a method called "load." This allows the XML document to load XML from an XML file using a standard URI (i.e. file://, http://, and relative paths). As far as I can tell, this method is not implemented in Safari causing sarissa to break whenever the SarissaDocument.load method is used. Technically, Sarissa goes a step further for browers that implement document.implementation.createLSParser by overriding the default document.implementation.createDocument.load method with a user defined function that makes use of the functionality described here (specifically document.implementation.createLSParser.parseURI): http://www.w3.org/TR/2004/REC-DOM-Level-3-LS-20040407/load-save.html I am not sure I understand why this approach is used for some browsers (document.implementation.hasFeature('LS', '3.0') == true), perhaps it performs better than the document.implementation.createDocument.load method. Nevertheless, FireFox will work just fine with either but sadly Safari won't do either. Technically, Sarissa could be updated to use XMLHttpRequest in order to provide SarissaDocument.load functionality to the web developer, but the more I investigate that approach, the more it resembles a crude substitute for implementing the load method on document.implementation.createDocument. I guess I'm not sure whether or not this is a bug, an oversight, or a deliberate omission in Safari. I'm also not certain what to ask for (document.load or LSParser support). Once I determine this, I should be able to either convince the folks at Sarissa to modify their code, enter a bug report on Safari (still waiting on my BZ enrollment email...), or just hack Sarissa myself to implement SarissaDocument.load for Safari alone using XmlHTTPRequest. Many thanks! Andrew On 03.01.2006, at 01:35, Paul Everitt wrote:
Andrew Eberhard wrote:
Hi Eric, Well, I'm getting underway with Safari-enabling my AJAX project [using the latest nightly build ;-) ] and I've run into a problem that seems to be "as designed" but I wanted to run it by everyone first. Basically, Document.load is not supported in Safari. I assume that I can use XMLHttpRequest instead, but http:// bugzilla.opendarwin.org/show_bug.cgi?id=5411 led me to think that there might be reason to enter a bug on Document.load support. Since Sarissa currently relies on Document.load for SarissaDoc.load, I wasn't sure if bug #5411 was intended to include Document.load support in Safari or if the folks at Sarissa should be asked to update it to work with Safari's XmlHttpRequest approach. There is a bit of prior research on this subject at http:// www.xs4all.nl/~zanstra/inTec/safariIdea.htm.
Hi Andrew. The Sarissa folks are taking a look at it. It's actually possible to work around the bug, I believe.
Here is what triggers the bug:
var oldDoc = document.implementation.createDocument("", "", null);
(Note: This is against the Sarissa CVS HEAD.)
Creating a document with a real node name for the document element, though, works:
var oldDoc = document.implementation.createDocument("", "foo", null);
Hmm, come to think of it, this works as well:
var oldDoc = document.implementation.createDocument("", null, null);
Anyway, my guess is that your application can be made to work with a patched Sarissa. I *think* (but I'm not sure) that the qualified name (2nd arg) should either be a real node name or null. In which case, WebKit is right and we need to change Sarissa.
--Paul
Err, I small detail I, uhh, ahem, forgot to mention. I wasn't testing against Safari. :^) I was testing against the WebKit nightly build. --Paul Andrew Eberhard wrote:
Hi Paul,
Thanks for responding (and sorry my post was inadvertently directed only to Eric). I did run into the problem that you mentioned and I patched sarissa.js to do exactly what you suggested (I used "temp"). Most of the sarissa test cases now run successfully (very good news), but the problem I mentioned is actually a separate issue.
When creating an XML document, sarissa assumes that the output of document.implementation.createDocument implements a method called "load." This allows the XML document to load XML from an XML file using a standard URI (i.e. file://, http://, and relative paths). As far as I can tell, this method is not implemented in Safari causing sarissa to break whenever the SarissaDocument.load method is used.
Technically, Sarissa goes a step further for browers that implement document.implementation.createLSParser by overriding the default document.implementation.createDocument.load method with a user defined function that makes use of the functionality described here (specifically document.implementation.createLSParser.parseURI): http://www.w3.org/TR/2004/REC-DOM-Level-3-LS-20040407/load-save.html I am not sure I understand why this approach is used for some browsers (document.implementation.hasFeature('LS', '3.0') == true), perhaps it performs better than the document.implementation.createDocument.load method. Nevertheless, FireFox will work just fine with either but sadly Safari won't do either.
Technically, Sarissa could be updated to use XMLHttpRequest in order to provide SarissaDocument.load functionality to the web developer, but the more I investigate that approach, the more it resembles a crude substitute for implementing the load method on document.implementation.createDocument.
I guess I'm not sure whether or not this is a bug, an oversight, or a deliberate omission in Safari. I'm also not certain what to ask for (document.load or LSParser support). Once I determine this, I should be able to either convince the folks at Sarissa to modify their code, enter a bug report on Safari (still waiting on my BZ enrollment email...), or just hack Sarissa myself to implement SarissaDocument.load for Safari alone using XmlHTTPRequest.
Many thanks! Andrew
On 03.01.2006, at 01:35, Paul Everitt wrote:
Andrew Eberhard wrote:
Hi Eric, Well, I'm getting underway with Safari-enabling my AJAX project [using the latest nightly build ;-) ] and I've run into a problem that seems to be "as designed" but I wanted to run it by everyone first. Basically, Document.load is not supported in Safari. I assume that I can use XMLHttpRequest instead, but http://bugzilla.opendarwin.org/show_bug.cgi?id=5411 led me to think that there might be reason to enter a bug on Document.load support. Since Sarissa currently relies on Document.load for SarissaDoc.load, I wasn't sure if bug #5411 was intended to include Document.load support in Safari or if the folks at Sarissa should be asked to update it to work with Safari's XmlHttpRequest approach. There is a bit of prior research on this subject at http://www.xs4all.nl/~zanstra/inTec/safariIdea.htm.
Hi Andrew. The Sarissa folks are taking a look at it. It's actually possible to work around the bug, I believe.
Here is what triggers the bug:
var oldDoc = document.implementation.createDocument("", "", null);
(Note: This is against the Sarissa CVS HEAD.)
Creating a document with a real node name for the document element, though, works:
var oldDoc = document.implementation.createDocument("", "foo", null);
Hmm, come to think of it, this works as well:
var oldDoc = document.implementation.createDocument("", null, null);
Anyway, my guess is that your application can be made to work with a patched Sarissa. I *think* (but I'm not sure) that the qualified name (2nd arg) should either be a real node name or null. In which case, WebKit is right and we need to change Sarissa.
--Paul
------------------------------------------------------------------------
_______________________________________________ webkit-dev mailing list webkit-dev@opendarwin.org http://www.opendarwin.org/mailman/listinfo/webkit-dev
Hi Andrew, On Dec 24, 2005, at 5:03 PM, Andrew Eberhard wrote:
Hello,
I'm almost certain this topic has been covered before so I'll try to keep my questions brief and will gladly read any resources already devoted to thereto (I just signed up for this mailing list).
Basically, I'm an AJAX developer for a large civil engineering company. As User Interface Manager for the corporate intranet, I've regularly tried to enrich the capabilities of our intranet without increasing bandwidth needs and/or client requirements.
To date, my efforts have focused primarily on IE (the corporate browser standard), but I am being asked (and honestly want) to support other browsers including FireFox and Safari.
Glad to hear it - supporting all major browsers is a great way to go.
It seems to me that there are a couple of things that are missing from Safari. If anyone could speak to either of these (potentially incorrect) observations, please do.
1. Although Safari implements most of the XML Extras in FireFox, as far as I can tell it lacks a critical piece of the AJAX framework: the ability to apply an XSLT transform to an XML document received asynchronously from a server into HTML. I believe Safari supports .innerHTML on most tags (could be wrong), so the transform process seems to be the only missing piece of the puzzle in this regard.
XSLTProcessor is available in the latest cvs version of WebKit, though not any released version of Safari yet. You might find it helpful for testing.
2. There seems to be a number of bugs with contenteditable regions in Safari. Strictly speaking these are not part of the AJAX "platform", but having reliable editable regions would be very useful for online applications. The Writely.com website has some rather vague descriptions of the problems.
We'd love to know what specific bugs you run into. Historically, WebKit editing support has focused on full-document editing in Mail. We're currently looking to make in-page editing via contenteditable work well too. Specific bug reports would really help in this area. Regards, Maciej
Hi Andrew, On Dec 25, 2005, at 11:21 AM, Maciej Stachowiak wrote:
1. Although Safari implements most of the XML Extras in FireFox, as far as I can tell it lacks a critical piece of the AJAX framework: the ability to apply an XSLT transform to an XML document received asynchronously from a server into HTML. I believe Safari supports .innerHTML on most tags (could be wrong), so the transform process seems to be the only missing piece of the puzzle in this regard.
XSLTProcessor is available in the latest cvs version of WebKit, though not any released version of Safari yet. You might find it helpful for testing.
i'd go even further: please test it, and file any bugs you may find :) If you need help filing, contact us in #webkit on irc.freenode.net, mail us here, or mail me personally, we / i will be glad to be of assistance. Merry christmas! Kind regards, Joost -- Joost de Valk #: AlthA on #webkit @ irc.freenode.net @: webkit@joostdevalk.nl W: http://www.joostdevalk.nl "The only people who find what they are looking for in life are the fault finders." - Foster's Law
Joost de Valk wrote:
Hi Andrew,
On Dec 25, 2005, at 11:21 AM, Maciej Stachowiak wrote:
1. Although Safari implements most of the XML Extras in FireFox, as far as I can tell it lacks a critical piece of the AJAX framework: the ability to apply an XSLT transform to an XML document received asynchronously from a server into HTML. I believe Safari supports .innerHTML on most tags (could be wrong), so the transform process seems to be the only missing piece of the puzzle in this regard.
XSLTProcessor is available in the latest cvs version of WebKit, though not any released version of Safari yet. You might find it helpful for testing.
i'd go even further: please test it, and file any bugs you may find :) If you need help filing, contact us in #webkit on irc.freenode.net, mail us here, or mail me personally, we / i will be glad to be of assistance.
I did that sequence and nothing happened. I went on IRC, was told to file a bug, and did so (first finding that a similar bug was already reported): http://bugzilla.opendarwin.org/show_bug.cgi?id=5576 This bug was first reported 2 months ago and hasn't gotten any response from the WebKit team. Is it not filed correctly? I might have funding in the next couple of weeks to get the Kupu editor working in WebKit. I don't mind filing bugs with good test cases, but I'd like some indication whether the bug reports will get noticed. [wink] --Paul
#webkit is not particularly active this week. Apple has the entire week off, and many WebKit hackers (apple or otherwise) are spending the holiday away from their computers with their families :) I would encourage you to try again on #webkit. Particularly after Jan 2nd, any time between 10AM and midnight PST, you should find lots of webkit hackers on irc :) -eric On Dec 27, 2005, at 3:13 AM, Paul Everitt wrote:
Joost de Valk wrote:
Hi Andrew, On Dec 25, 2005, at 11:21 AM, Maciej Stachowiak wrote:
1. Although Safari implements most of the XML Extras in FireFox, as far as I can tell it lacks a critical piece of the AJAX framework: the ability to apply an XSLT transform to an XML document received asynchronously from a server into HTML. I believe Safari supports .innerHTML on most tags (could be wrong), so the transform process seems to be the only missing piece of the puzzle in this regard.
XSLTProcessor is available in the latest cvs version of WebKit, though not any released version of Safari yet. You might find it helpful for testing. i'd go even further: please test it, and file any bugs you may find :) If you need help filing, contact us in #webkit on irc.freenode.net, mail us here, or mail me personally, we / i will be glad to be of assistance.
I did that sequence and nothing happened. I went on IRC, was told to file a bug, and did so (first finding that a similar bug was already reported):
http://bugzilla.opendarwin.org/show_bug.cgi?id=5576
This bug was first reported 2 months ago and hasn't gotten any response from the WebKit team. Is it not filed correctly?
I might have funding in the next couple of weeks to get the Kupu editor working in WebKit. I don't mind filing bugs with good test cases, but I'd like some indication whether the bug reports will get noticed. [wink]
--Paul
_______________________________________________ webkit-dev mailing list webkit-dev@opendarwin.org http://www.opendarwin.org/mailman/listinfo/webkit-dev
Hi Eric, thanks for the encouragement (and also, to Joost in private mail). I dropped by the channel and indeed found several helpful people. I spent a few hours today working on Kupu against a WebKit nightly. I sent a status report to the Kupu list: http://permalink.gmane.org/gmane.comp.web.kupu.devel/1642 In summary, I plan to wait until this lands: http://bugzilla.opendarwin.org/show_bug.cgi?id=4904 Kupu relies very, very heavily on Selection and Range support. As the context changes, the buttons get updated, drop-down lists get new items, etc. I'm eager to look at this more when the patch lands. Again, thanks for the encouragement. --Paul Eric Seidel wrote:
#webkit is not particularly active this week. Apple has the entire week off, and many WebKit hackers (apple or otherwise) are spending the holiday away from their computers with their families :)
I would encourage you to try again on #webkit. Particularly after Jan 2nd, any time between 10AM and midnight PST, you should find lots of webkit hackers on irc :)
-eric
On Dec 27, 2005, at 3:13 AM, Paul Everitt wrote:
Joost de Valk wrote:
Hi Andrew, On Dec 25, 2005, at 11:21 AM, Maciej Stachowiak wrote:
1. Although Safari implements most of the XML Extras in FireFox, as far as I can tell it lacks a critical piece of the AJAX framework: the ability to apply an XSLT transform to an XML document received asynchronously from a server into HTML. I believe Safari supports .innerHTML on most tags (could be wrong), so the transform process seems to be the only missing piece of the puzzle in this regard.
XSLTProcessor is available in the latest cvs version of WebKit, though not any released version of Safari yet. You might find it helpful for testing. i'd go even further: please test it, and file any bugs you may find :) If you need help filing, contact us in #webkit on irc.freenode.net, mail us here, or mail me personally, we / i will be glad to be of assistance.
I did that sequence and nothing happened. I went on IRC, was told to file a bug, and did so (first finding that a similar bug was already reported):
http://bugzilla.opendarwin.org/show_bug.cgi?id=5576
This bug was first reported 2 months ago and hasn't gotten any response from the WebKit team. Is it not filed correctly?
I might have funding in the next couple of weeks to get the Kupu editor working in WebKit. I don't mind filing bugs with good test cases, but I'd like some indication whether the bug reports will get noticed. [wink]
--Paul
_______________________________________________ webkit-dev mailing list webkit-dev@opendarwin.org http://www.opendarwin.org/mailman/listinfo/webkit-dev
participants (5)
-
Andrew Eberhard
-
Eric Seidel
-
Joost de Valk
-
Maciej Stachowiak
-
Paul Everitt