Ian Hickson wrote:
...in which case I'd say that (a) the references aren't normative after
all, and (b) the spec itself can't be normative as it is written.
I don't mind calling the references informative if that's what it takes.
I'm not sure what practical difference it would make.
You
On Tue, 13 May 2008 09:25:42 +0200, Julian Reschke [EMAIL PROTECTED]
wrote:
Anne van Kesteren wrote:
On Mon, 12 May 2008 17:26:07 +0200, Julian Reschke
[EMAIL PROTECTED] wrote:
Anne van Kesteren wrote:
- On the send algorithm, step 4 (If stored method is GET act as if
the data argument
On Tue, 13 May 2008 16:49:03 +0200, Thomas Roessler [EMAIL PROTECTED] wrote:
the Web Security Context Working Group is, as you might know,
working on user interactions for Web user agents when they encounter
TLS error conditions.
There have been a lot of messages about referencing HTML5 and how we can
mitigate that. I don't think that copying the text from HTML5 is an
option. The Window specification is fairly complex and especially the
interaction with browsing contexts is a complex bit of HTML5 that I don't
Anne van Kesteren wrote:
On Tue, 13 May 2008 09:25:42 +0200, Julian Reschke
[EMAIL PROTECTED] wrote:
Anne van Kesteren wrote:
On Mon, 12 May 2008 17:26:07 +0200, Julian Reschke
[EMAIL PROTECTED] wrote:
Anne van Kesteren wrote:
- On the send algorithm, step 4 (If stored method is GET act as
Anne van Kesteren wrote:
There have been a lot of messages about referencing HTML5 and how we can
mitigate that. I don't think that copying the text from HTML5 is an
option. The Window specification is fairly complex and especially the
interaction with browsing contexts is a complex bit of
Julian Reschke schreef:
Anne van Kesteren wrote:
On Thu, 15 May 2008 20:56:42 +0200, Laurens Holst
[EMAIL PROTECTED] wrote:
Why was this changed? Why should user agents pretend that they know
what
kind of resource the user expects by setting an Accept header that is
unreliable? FWIW,
Anne van Kesteren wrote:
On Thu, 15 May 2008 20:56:42 +0200, Laurens Holst
[EMAIL PROTECTED] wrote:
Why was this changed? Why should user agents pretend that they know what
kind of resource the user expects by setting an Accept header that is
unreliable? FWIW, Internet Explorer and Safari
On 2008-05-16 10:56:50 +0200, Anne van Kesteren wrote:
We notice that the XMLHttpRequest Last Call Working Draft
specifies that XMLHttpRequest can be used over both HTTP and
HTTPS, but does not specify behavior if TLS negotiation fails
for an HTTPS URI.
This would only be the case during a
Came across this:
http://doctype.googlecode.com/svn/trunk/goog/events/keycodes.js
Interesting stuff in our quest to standardise legacy key events and the
keyCode property.
--
Hallvord R. M. Steen
Core QA JavaScript tester, Opera Software
http://www.opera.com/
Opera - simply the best Internet
Julian Reschke wrote:
b) Algorithms: the spec uses a method to describe algorithms that IMHO
is extremely hard to read (see for instance send() method). This maybe
good for implementors, but seems to be bad for everybody else.
Minimally, the lists should be structured for better readability.
Anne van Kesteren wrote:
Since this is the second Last Call and credentials are already following
each other (and the same for other similar steps) I've decided not to
change this.
Unfortunately.
c) Structure: It would be nice if Section 4 had more structure.
Rightnow it's ugly to navigate
Julian Reschke wrote:
Yes, I noticed that. For instance, it happens for application/..+xml,
where it's really useless. Shouldn't this be restricted to text/*?
That could perhaps be done. The initial implementation just does it no matter
the MIME type so as to avoid making assumptions about
Boris Zbarsky wrote:
Julian Reschke wrote:
Yes, I noticed that. For instance, it happens for application/..+xml,
where it's really useless. Shouldn't this be restricted to text/*?
That could perhaps be done. The initial implementation just does it no
matter the MIME type so as to avoid
Julian Reschke wrote:
This assumes that every non-text/* mime type *can* take a charset
parameter, which IMHO is not true.
But this probably only becomes relevant once we have non XML/string
based ways to set the body.
For what it's worth, Mozilla does have such a way (only available to
15 matches
Mail list logo
