On 05/01/2012 02:43 AM, Anne van Kesteren wrote:
On Mon, 30 Apr 2012 16:57:06 -0700, Rafael Weinstein
rafa...@google.com wrote:
There aren't any parser changes required. DocumentFragment.innerHTML
can still provide the fragment case with a context element and
procede normally. It's not obvious
A Candidate Recommendation for HTML5 Web Messaging has been published
and as such, this is a Call for Implementations:
http://www.w3.org/TR/2012/CR-webmessaging-20120501/
The root of the spec's test mirror is:
http://test.w3.org/webapps/WebMessaging/tests/.
CanIUse reports very broad
On Mon, Mar 19, 2012 at 3:55 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Feb 29, 2012 at 8:44 AM, Eric U er...@google.com wrote:
On Mon, Feb 27, 2012 at 4:40 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Feb 27, 2012 at 11:36 PM, Eric U er...@google.com wrote:
One working subset
On Tue, May 1, 2012 at 3:29 AM, Ms2ger ms2...@gmail.com wrote:
On 05/01/2012 02:43 AM, Anne van Kesteren wrote:
On Mon, 30 Apr 2012 16:57:06 -0700, Rafael Weinstein
rafa...@google.com wrote:
There aren't any parser changes required. DocumentFragment.innerHTML
can still provide the fragment
Hi,
Trident and WebKit both implement beforecopy, beforecut, and beforepaste
events.
These events need to be spec'ed in
http://dev.w3.org/2006/webapi/clipops/clipops.html
Most significantly, those events appear to be fired when UAs try to
determine whether copy, cut, and paste menu items in
On 5/1/12 4:52 PM, Ryosuke Niwa wrote:
Hi,
Trident and WebKit both implement beforecopy, beforecut, and beforepaste
events.
These events need to be spec'ed in
http://dev.w3.org/2006/webapi/clipops/clipops.html
Most significantly, those events appear to be fired when UAs try to
determine
On Tue, May 1, 2012 at 5:08 PM, Boris Zbarsky bzbar...@mit.edu wrote:
If we _do_ decide to specify them then their interaction with script
running inside the events that changes the focus needs to be very carefully
specified, since changing focus will change what cut/copy/paste behavior.
I
On May 1, 2012, at 4:07 PM, Scott González scott.gonza...@gmail.com wrote:
On Tue, May 1, 2012 at 5:08 PM, Boris Zbarsky bzbar...@mit.edu wrote:
If we _do_ decide to specify them then their interaction with script running
inside the events that changes the focus needs to be very carefully
On Tue, May 1, 2012 at 3:07 PM, Scott González scott.gonza...@gmail.comwrote:
On Tue, May 1, 2012 at 5:08 PM, Boris Zbarsky bzbar...@mit.edu wrote:
If we _do_ decide to specify them then their interaction with script
running inside the events that changes the focus needs to be very carefully
On 5/1/12 6:07 PM, Scott González wrote:
I recall moving focus for paste events in order to figure out what is
being pasted. I believe this is common in WYSIWYG editors; a new element
is created and focus is moved to that element, then the paste occurs,
then the element is inspected for the
Based on the hallway conversations at the F2F, here are some notes for
the upcoming Custom Elements spec.
Custom tags vs. is attribute
- is attribute is awkward, overly verbose
- custom tags introduce local semantics
- generally viewed as a rabbit-hole discussion in WebApps scope
- Tantek
On Tue, May 1, 2012 at 4:40 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/1/12 6:07 PM, Scott González wrote:
I recall moving focus for paste events in order to figure out what is
being pasted. I believe this is common in WYSIWYG editors; a new element
is created and focus is moved to that
On 5/1/12 7:51 PM, Ryosuke Niwa wrote:
I agree that these events are broken and has very different semantics
from other before* events. I would be fine with adding non-normative
section describing the current behavior as well (or even mark them as
deprecated). I just feel that it needs to be
On Tue, May 1, 2012 at 6:38 PM, Ryosuke Niwa rn...@webkit.org wrote:
Does the dataTransfer interface available through via paste event address
your use cases?
http://dev.w3.org/2006/webapi/clipops/clipops.html#fire-a-clipboard-event
On Tue, May 1, 2012 at 7:40 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/1/12 6:07 PM, Scott González wrote:
I recall moving focus for paste events in order to figure out what is
being pasted. I believe this is common in WYSIWYG editors; a new element
is created and focus is moved to that
On 5/1/12 8:47 PM, Scott González wrote:
I believe I was actually doing this in the paste event.
That's a different story entirely. The paste event is already specced
in http://dev.w3.org/2006/webapi/clipops/clipops.html#paste-event
(complete with how it interacts with focus changes), and
On Tue, May 1, 2012 at 4:57 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/1/12 7:51 PM, Ryosuke Niwa wrote:
I agree that these events are broken and has very different semantics
from other before* events. I would be fine with adding non-normative
section describing the current behavior as
Brad, Eric, Thomas - during WebApps' May 1 meeting, the group agreed [1]
it would be useful to have a joint meeting with WebAppSec during
WebAppSec's May 2 f2f meeting re CORS.
Since CORS is on the WebAppSec's May 2 agenda from 9:45-10:15 [2], how
about WebAppSec join WebApps during that time
During WebApps' May 1 discussion about Web Components, a proposal was
made ([1],[2]) to stop work on the XBL2 spec and this is a Call for
Consensus to do do.
If you have any comments or concerns about this CfC, please send them to
public-webapps@w3.org by May 8 at the latest. Positive
On Tue, 1 May 2012, Arthur Barstow wrote:
During WebApps' May 1 discussion about Web Components, a proposal was
made ([1],[2]) to stop work on the XBL2 spec and this is a Call for
Consensus to do do.
If this CfC passes, the spec will be republished as a WG Note (as was
done with other
20 matches
Mail list logo
