On Wed, 20 Jul 2011 16:30:41 +0200, Arthur Barstow
wrote:
As mentioned in [1], the exit criteria of the view-mode Media Feature
Candidate Recommendation [2] has been met (at least two implementations
pass every test):
http://dev.w3.org/2006/waf/widgets-vmmf/imp-report/
As such, this
FYI
--- Forwarded message ---
From: "Philippe Le Hegaret"
To: w3c-html-cg , w3c-xml...@w3.org
Cc:
Subject: Media Type Sepecifications and Registration Procedures
Date: Sun, 24 Jul 2011 22:00:26 +0200
W3C Working Groups are *highly* encouraged to review
[[
Media Type Specifications and R
This issue was discussed on some mailing list a while back (I forget
which). The consensus seemed to be that redirects are the source of a
large number of security vulnerabilities in HTTP and we'd like users
of the WebSocket API to handle them explicitly.
I'm not sure I understand your question r
When discussing mutation events use-cases, mostly so far people have
been talking about editors. However, I think mutation event
replacements would have a much more general appeal if they were easily
usable in certain cases with little performance impact. Specifically,
one use-case I've run into
On Fri, Jul 22, 2011 at 11:54 AM, Boris Zbarsky wrote:
> Actually, you can pretty easily do it in the other order (move the text into
> the , and then put the in the DOM), and may want to so as to minimize
> the number of changes the the live DOM; that's something that's often
> recommended as a
The hybi WG is concerned about the following clause in the websocket API spec:
> When the user agent validates the server's response during the "establish a
> WebSocket connection" algorithm, if the status code received from the server
> is not 101 (e.g. it is a redirect), the user agent must fa
