Hi Sunava,
Thanks for your feedback. I had a couple of additional comments on top
of the ones Anne had.
On Thu, 07 Feb 2008 02:57:50 +0100, Sunava Dutta
<[EMAIL PROTECTED]> wrote:
o This spec is very different from existing HTML/CSS/DOM spec where
the functionality/API specification is the focus. This spec talks
about interface specification as well as a lot of details that appear
to be internal implementation issues that cannot be verified by Web
developers.
I don't think that's true, actually. In fact, the specification leaves
implementation details up to the implementation. It says so in the
conformance criteria.
So one thing to note is that the implementation doesn't need to keep
exactly the same flags, references, states etc as the ones talked about
in the spec. As long as it to any user behaves as if it did.
So for example in the mozilla implementation we don't have the send()
flag, instead we have one additional main state for the object. I.e. we
have 6 states, including OPENED_BUT_NOT_SENT and OPENED_BUT_SENT.
To the outside world this is not noticeable since the getter for the
readyState property returns 1 for both those states.
Maybe we need to point out at the top of the specification something to
the effect of "the implemenatation doesn't need to use the same
algorithms or use the same states as the ones described in this
specification. As long as it to any user of the interface yields the
same results as if it had".
Having internal implementation recommendation for UA's is nice,
however we can improve the readability by calling out implementation
detail sections or having a separate section for this detail . What
we've love is to have the spec clearly state what is external API
specification, and what is internal implementation details. This way a
web developer can read this without reading the whole spec and take
away the key points.
I think everything that is not important is not there. So I don't really
see the issue.
I think the request here is to use language like "if the opened method
has been called, but the send method has not then do X" rather than "if
we're in the OPENED state with the send() flag set to false then do X".
Is that correct?
The problem with that is that it's hard to get that unambigious and
correct. For example the first wording above is wrong since open might
have been called, but abort had later been called, and so we should
behave as if open had not been called.
Or I might just be misunderstanding you :)
o Is this included due to security concerns?
ยง Scripts in the resulting document tree will not be executed,
resources referenced will not be loaded and no associated XSLT will be
applied.
It's included to get consistent behavior.
Right, I don't think any current implementation applies XSLT
stylesheets. Additionally, loading resources, such as images and
stylesheets, pointed to by the document would largely be a waste of
network traffic as they won't be displayed anyway.
We've had cases where people load XSLT stylesheets using XHR and then
use javascript to dynamically apply these stylesheets to documents. XSLT
stylesheets can contain markup like:
<xsl:for-each select="images/image">
<html:img src="/static/images/[EMAIL PROTECTED]">
</xsl:for-each>
In this case it would be clearly undesirable if the loading the XSLT
stylesheet using XHR would attempt to load the resource
"/static/image/[EMAIL PROTECTED]" from the server.
Hope that helps?
Actually, the spec should probably also say that stylesheets should not
be applied. This is needed since the stylesheet might be inline and thus
not stopped by the "don't load resources" rule.
Anne, should that be added to the draft?
/ Jonas
