Mark Birbeck wrote:
Uh... Are you serious? The SVG Tiny specs aren't written for certain
audiences, for example?
Anne was implying that only comments received from certain audiences
were relevant to the XHR draft.
I think he was implying that not all comment sources carry equal weight with him
as an editor... But either way, I stand by my SVG Tiny example, for what it's worth.
I was saying that this goes against
the way specs progress within the W3C, since anyone can comment
Anyone can comment, but not everyone is (or should be, perhaps) listened to.
Again, this is a general point. I'm NOT saying that you should not be listened
to in this particular instance.
I think it's more a matter of not all interested parties necessarily being
created equal. If you haven't read it yet, I urge you to read
<http://dbaron.org/log/2006-08#e20060818a>.
Right. And whilst I agree with a lot of it, my warning at the end of
the email was that we are now witnessing the same behaviour being
displayed by those who quite rightly criticised the 'corporate
monopolisation' of the W3C in the past.
I think you got a different message there than I did. My takeaway was that
specifications will always end up focusing on some particular audience. That
includes W3C specifications. This audience may well not include web browsers,
as things stand, so web browsers should not be considered obligated to implement
W3C specifications.
All the same things apply with "web browsers" replaced by any other
constituency.
Again, this does not imply that in this particular case some particular
constituencies are not relevant.
That's really not a big deal. If people need some help with doing
this, then I'm sure there are plenty of people who would volunteer
some time.
Given the difficulty I've seen recently with finding spec editors, I'm pretty
sure you're entirely too optimistic here. Keeping two documents like this in
sync is in fact a big deal, a good bit of work, and not sexy, so hard to find
someone to do.
I don't see this as a legitimate reason for not taking a more flexible
approach to the XHR object.
If the more flexible approach requires importing parts of the Window definition
in HTML5, then it's absolutely a legitimate reason to not do it. In that case
we need a better flexible approach.
Similar for the other things Window gives us now (base URI definition, etc).
Like what? Window gives us Document which gives us the base URI, so
the dependency is on Document, and not Window.
The dependency is currently on the following things:
1) The exact way of getting the right Window for the given XMLHttpRequest.
2) The exact way of getting the right Document for the given Window and
XMLHttpRequest.
I agree that these need not require a strong dependency on Window if item 1 can
be addressed in some other way.
Perhaps we should define how these things work when we're in a Window and
make it clear that any use of XHR in any other context will mean it's the
other context's responsibility to define exactly how XHR behaves there, and
list all the constraints such a definition must satisfy.
That seems very heavy-handed. Why not just indicate that anyone using
XHR will need to provide a context, and that context needs to provide
a base URI against which relative URI references can be calculated,
and security considerations can be resolved.
Your suggestion is more or less like mine, except you're focusing on two
specific "constraints such a definition must satisfy" while I suspect there may
be more. What's needed to take this approach is a good list of places where the
current spec depends on Window and the exact dependence.
If browser vendors (of all shades, not just Microsoft) had
'taken the web into account' in the past, then Thomas Fuchs, Sam
Stephenson and John Resig would not be as celebrated as they are. So
forgive me if I don't trumpet the arrival of the cavalry in the form
of limited specifications created by some of the browser vendors.
I'm not sure I follow this. "Taking the web into account" does not preclude
new functionality; it just limits what the spec can do with
already-implemented functionality.
My turn to not follow what you are saying...sorry.
Your claim was that if UAs "took the web into account" then those three people
would be less famous. It's not clear to me what the basis of that claim is, but
if you were saying that things like XMLHttpRequest would never have existed, for
example, then I was pointing out that this is likely not the case.
If you meant something else, then I would be interested in knowing what you
meant.
Remove the *unnecessary* restriction that an XHR object can only
function in the context of a Window object.
This needs to be replaced with other restrictions on the context object, in that
case. Which I think is a perfectly reasonable thing to do, if it can be done
carefully and without introducing too much complexity into the XHR spec. For
example, importing HTML5 bits wholesale would fail those criteria.
My point is also philosophical, but I'm not sure how your are responding to it.
I think the situation is that while I agree with your suggestion (or at least
agree that it seems to be worth further study), I don't agree that the reasons
currently given for the suggestion are necessarily strong enough to go through
with it if there are substantial costs in terms of spec maintenance burden to
doing so.
-Boris
