Sunava Dutta wrote:
Thanks Ian, Zhenbin for clarifying the issues and a continuing very
productive discussion.
Meanwhile, I'm summarizing some of our requests for the editor based
on issues we've had an opportunity to clarify...There are many
conversations going on and I'd hate to see points getting lost and
would like the specs/test cases updated for issues where discussions
are not ongoing.
-Ongoing discussion: Specify the parseError attributes for Document
Objects or specify this can be sent out of band. This could be
something we don't have to hold the XHR spec back for as long as we
make a note in the specification that this is pending. There are
people currently talking for and/or against it. Zhenbin is
articulating IE's point.
Sounds good to me. We have an informative "Not in this specification"
section already, sounds like a good idea to add there.
- Throwing exceptions on state violations is easier to understand and
we should change the spec to reflect this. (for the sake of a
consistent programming model). The spec should have INVALID_STATE_ERR
exception (the exact language can be worked out) if a site is
expecting an exception and gets a null as this would not work if the
developer is trying to write a wrapper object in XHR. I haven't heard
any strong objection here or compelling argument against it that's
been sustained.
I do think there has been some disagreement here. Anne has commented on
reasons for returning null rather than throwing an exception, and I
think I agree with him. I think the correct cause of action here is to
raise an issue in the issue tracker.
- As Ian mentions, XHR should not require any particular level of DOM
support. Along those lines we should remove DOM dependencies that do
DOM tests from the spec/tests or at least change the test cases to use
getElementByTagName instead of getElementbyID.
Sounds fine to me. We could also include tests that first check if
getElementById is implemented at all and if so tests that it functions
properly.
The nice thing about testing getElementById is that it not only tests
the DOM, but also tests that ID parsing works properly.
But this way a DOM L1 implementation still passes fine.
/ Jonas
